idnits 2.17.1 draft-ietf-mile-iodef-guidance-08.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 26 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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) Summary: 4 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: September 14, 2017 NICT 6 March 13, 2017 8 IODEF Usage Guidance 9 draft-ietf-mile-iodef-guidance-08 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 practitioners. It also addresses how common security indicators can 22 be represented in IODEF and use-cases of how IODEF is being. The 23 goal of this document is to make IODEF's adoption by vendors easier 24 and encourage faster and wider adoption of the model by Computer 25 Security 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 September 14, 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 . . . . . . . . . . . . . . . . . 3 65 3.2. Information represented . . . . . . . . . . . . . . . . . 4 66 3.3. IODEF Classes . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. External References . . . . . . . . . . . . . . . . . . . 6 69 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Indicator predicate logic . . . . . . . . . . . . . . . . 6 71 4.4. Disclosure level . . . . . . . . . . . . . . . . . . . . 7 72 5. IODEF Uses . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Implementations . . . . . . . . . . . . . . . . . . . . . 7 74 5.2. Inter-vendor and Service Provider Exercise . . . . . . . 8 75 5.3. More use-cases . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 8.2. Informative References . . . . . . . . . . . . . . . . . 14 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 89 1. Introduction 91 The Incident Object Description Exchange Format v2 [RFC7970] defines 92 a data representation that provides a framework for sharing 93 information commonly exchanged by Computer Security Incident Response 94 Teams (CSIRTs) about computer security incidents. The IODEF data 95 model consists of multiple classes and data types that are defined in 96 the IODEF XML schema. 98 The IODEF schema was designed to be able to describe all the possible 99 fields that would be needed in a security incident exchange. Thus, 100 IODEF contains a plethora of data constructs that could potentially 101 make it harder for IODEF implementers to decide which are the most 102 important ones to use. Additionally, in the IODEF schema, there 103 exist multiple fields and classes which do not necessarily need to be 104 used in every possible data exchange. Moreover, some IODEF classes 105 are useful only in rare security events representation exchanges. 106 This document tries to address how to avoid these concerns. It also 107 addresses how common security indicators can be represented in IODEF. 108 It points out the most important IODEF classes for an implementer and 109 describe other ones that are not as important. Also, it presents 110 some common challenges for IODEF implementers and how to address 111 them. The end goal of this document is to make IODEF's use by 112 vendors easier and encourage wider adoption of the model by CSIRTs 113 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 practicioner 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 [RFC5070] 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 practitioners 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 practicioner should take 138 into consideration before using IODEF, or designing an 139 implementation. 141 3.1. Minimal IODEF document 143 IODEF includes some mandatory classes. An IODEF document MUST 144 include at least an Incident class and a version attribute. An 145 Incident MUST contain three minimal mandatory-to-implement classes. 147 An Incident class needs to have a Generation time and IncidentID 148 class and at least one Contact class. The structure of the minimal- 149 style Incident 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 an practicioner to use or implement IODEF 176 classes and fields other than the minimal ones (Section 3.1) and the 177 ones 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 has DDoS as a potential use-case, then the 182 Flow class and its included information are the most important 183 classes to use. The Flow class describes information related to the 184 attacker hosts and victim hosts, which information could help 185 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 and the necessary included in it classes will be 197 implemented instead of the EventData class and its subclasses. 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 3.3. IODEF Classes 209 [RFC7970] contains classes that can describe attack Methods, Events, 210 Indicents, how they were discovered and the Assessment of the 211 reprecussions of the incident to the victim. It is important for 212 IODEF users to know the distinction between these classes in order to 213 decide which ones fulfills their use-cases. 215 An IndicatorData class depicts a threat indicator or observable that 216 could be used to describe a threat that does not necessarily mean 217 that an exploit happened. For example, we could see an attack 218 happening but it might have been prevented and not have resulted in 219 an incident or security event. On the other hand an EventData class 220 usually describes a security event and can be considered as an 221 incident report of something that took place. 223 Classes like Discovery, Assessment, Method, RecoveryTime are used in 224 conjuction with EventData as they related to the incident report 225 described in the EventData. The RelatedActivity class can reference 226 an incident, an indicator or other related threat activity. 228 While deciding what classes are important for the needed use-cases, 229 IODEF users SHOULD carefully evaluate the necessary classes and how 230 these are used in order to avoid unnecessary work. For example, if 231 we want to only describe indicators in IODEF, the implementation of 232 Method or Assessment might not be important. 234 4. Considerations 236 When defining the IODEF use strategy practitioners need to consider 237 some common options defined in standards. 239 4.1. External References 241 The IODEF format includes the Reference class that refers to 242 externally defined information such as a vulnerability, Intrusion 243 Detection System (IDS) alert, malware sample, advisory, or attack 244 technique. To facilitate the exchange of information, the Reference 245 class was extended to the Enumeration Reference Format [RFC7495]. 246 The Enumeration Reference Format specifies a format to include 247 enumeration values from external data representations into IODEF like 248 CVE, and manages references to external representations using IANA 249 registry. Practitioners SHOULD only support external enumerations 250 that are expected to be used in IODEF documents for their use-cases. 252 4.2. Extensions 254 The IODEF data model ([RFC7970]) is extensible. Many class 255 attributes and their values can be extended using the "ext-*" prefix. 256 Additional classed can also be defined by using the AdditionalData 257 and RecordItem classes. An extension to the AdditionalData class for 258 reporting Phishing emails is defined in [RFC5901]. Information about 259 extending IODEF class attributes and enumerated values can be found 260 in Section 5 of [RFC7970]. 262 Additionally, IODEF can import existing schemata by using an 263 extension framework defined in [RFC7203]. The framework enables 264 IODEF users to embed XML data inside an IODEF document using external 265 schemata or structures defined by external specifications. Examples 266 include CVE, CVRF and OVAL. Thus, [RFC7203] enhances the IODEF 267 capabilities without further extending the data model. 269 IODEF practitioners SHOULD NOT consider using their own IODEF 270 extensions unless data cannot be represented using existing standards 271 or importing them in and IODEF document using [RFC7203] is not a 272 suitable option. 274 4.3. Indicator predicate logic 276 An IODEF [RFC7970] document can describe incident reports and 277 indicators. The Indicator class can include references to other 278 indicators, observables and more classes the contain details about 279 the indicator. When describing security indicators, it is often 280 common to need to group them together in order to form a group of 281 indicator that constitute a security threat. For example, a botnet 282 might have multiple command and control servers. For that reason, 283 IODEF v2 introduced the IndicatorExpression class that is used to add 284 the indicator predicate logic when grouping more than one indicators 285 or observables. 287 Implementations MUST be able to parse and apply the Boolean logic 288 offered by an IndicatorExpression in order to evaluate the existence 289 of an indicator. As explained in Section 3.29.5 of [RFC7970] the 290 IndicatorExpression element operator defines the operator applied to 291 all the child element of the IndicatorExpression. If no operator is 292 defined "and" SHOULD be assumed. IndicatorExpressions can also be 293 nested together. Child IndicatorExpressions should be treated as 294 child elements of their parent and they SHOULD be evaluated first 295 before evaluated with the operator of their parent. 297 Users can refer to Appendix A for example uses of the 298 IndicatorExpressions in an IODEF v2. 300 4.4. Disclosure level 302 The information conveyed in IODEF documents SHOULD be treated 303 carefully since the content may be confidential. IODEF has a common 304 attribute, called "restriction", which indicates the disclosure 305 guideline to which the sender expects the recipient to adhere to for 306 the information represented in the class and its children. That way, 307 the sender can express the level of disclosure for each component of 308 an IODEF document. Appropriate external measures could be 309 implemented based on the restriction level. One example is when RID 310 is used to transfer the IODEF documents, it can provide policy 311 guidelines for handling IODEF documents by using the RIDPolicy class. 313 The enforcement of the disclosure guidelines goes beyond IODEF. The 314 recipient of the IODEF document needs to follow the guidelines, but 315 these guidelines themselves do not provide any enforcement measures. 316 For that purpose, practitioners SHOULD consider appropriate measures, 317 technical or operational. 319 5. IODEF Uses 321 IODEF is currently used by various organizations in order to 322 represent security incidents and share incident and threat 323 information between security operations organizations. 325 5.1. Implementations 327 In order to use IODEF, tools like IODEF parsers are necessary. 328 [I-D.ietf-mile-implementreport] describes a set of IODEF 329 implementations and uses by various vendors and CERT organizations. 330 The document does not specify any specific mandatory to implement 331 (MTI) IODEF classes but provides a list of real world uses. Perl and 332 Python modules (XML::IODEF, Iodef::Pb, iodeflib) are some examples. 333 Section 7 also includes practical IODEF use guidelines. Implementers 334 are encouraged to refer to [I-D.ietf-mile-implementreport]. 336 [implementations], on the other hand, includes various vendor 337 incident reporting products that can consume and export in IODEF 338 format. 340 5.2. Inter-vendor and Service Provider Exercise 342 Various vendors organized and executed an exercise where multiple 343 threat indicators were exchanged using IODEF. The transport protocol 344 used was RID. The threat information shared included incidents like 345 DDoS attacks. Malware and Spear-Phishing. As this was a proof-of- 346 concept (PoC) exercise only example information (no real threats) 347 were shared as part of the exchanges. 349 ____________ ____________ 350 | Vendor X | | Vendor Y | 351 | RID Agent |_______-------------________| RID Agent | 352 |___________| | Internet | |___________| 353 ------------- 355 ---- RID Report message ---> 356 -- carrying IODEF example -> 357 --------- over TLS --------> 359 <----- RID Ack message ----- 360 <--- in case of failure ---- 362 PoC peering topology 364 The figure above shows how RID interactions took place during the 365 PoC. Participating organizations were running RID Agent software on- 366 premises. The RID Agents formed peering relationships with other 367 participating organizations. When Entity X had a new incident to 368 exchange it would package it in IODEF and send it to Entity Y over 369 TLS in a RID Report message. In case there was an issue with the 370 message, Entity Y would send an RID Acknowledgement message back to 371 Entity X which included an application level message to describe the 372 issue. Interoperability between RID agents and the standards, 373 [RFC6545] and [RFC6546], was also proven in this exercise. 375 The first use-case included sharing of Malware Data Related to an 376 Incident between CSIRTs. After Entity X detected an incident, she 377 would put data about malware found during the incident in a backend 378 system. Entity X then decided to share the incident information with 379 Entity Y about the malware discovered. This could be a human 380 decision or part of an automated process. 382 Below are the steps followed for the malware information exchange 383 that was taking place: 385 (1) Entity X has a sharing agreement with Entity Y, and has already 386 been configured with the IP address of Entity Y's RID Agent 388 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 389 mutual authentication occurs using PKI certificates. 391 (3) Entity X pushes out a RID Report message which contains 392 information about N pieces of discovered malware. IODEF is used 393 in RID to describe the 395 (a) Hash of malware files 397 (b) Registry settings changed by the malware 399 (c) C&C Information for the malware 401 (4) Entity Y receives RID Report message, sends RID Acknowledgement 402 message 404 (5) Entity Y stores the data in a format that makes it possible for 405 the back end to know which source the data came from. 407 Another use-case was sharing Distributed Denial of Service (DDoS) as 408 explained in the following scenario: Entity X, a Critical 409 Infrastructure and Key Resource (CIKR) company detects that their 410 internet connection is saturated with an abnormal amount of traffic. 411 Further investigation determines that this is an actual DDoS attack. 412 Entity X's CSIT contacts their ISP, Entity Y, and shares information 413 with them about the attack traffic characteristics. Entitty X's ISP 414 is being overwhelmed by the amount of traffic, so it shares attack 415 signatures and IP addresses of the most prolific hosts with its 416 adjacent ISPs. 418 Below are the steps followed for a DDoS information exchange: 420 (1) Entity X has a sharing agreement with Entity Y, and has already 421 been configured with the IP address of Entity Y's RID Agent 423 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 424 mutual authentication occurs using PKI certificates. 426 (3) Entity X pushes out a RID Report message which contains 427 information about the DDoS attack. IODEF is used in RID to 428 describe the 430 (a) Start and Detect dates and times 432 (b) IP Addresses of nodes sending DDoS Traffic 433 (c) Sharing and Use Restrictions 435 (d) Traffic characteristics (protocols and ports) 437 (e) HTTP User-Agents used 439 (f) IP Addresses of C&C for a botnet 441 (4) Entity Y receives RID Report message, sends RID Acknowledgement 442 message 444 (5) Entity Y stores the data in a format that makes it possible for 445 the back end to know which source the data came from. 447 (6) Entity Y shares information with other ISP Entities it has an 448 established relationship with. 450 One more use-case was sharing spear-phishing email information as 451 explained in the following scenario: The board members of several 452 defense contractors receive an email inviting them to attend a 453 conference in San Francisco. The board members are asked to provide 454 their personally identifiable information such as their home address, 455 phone number, corporate email, etc in an attached document which came 456 with the email. The board members are also asked to click on a URL 457 which would allow them to reach the sign up page for the conference. 458 One of the recipients believes the email to be a phishing attempt and 459 forwards the email to their corporate CSIRT for analysis. The CSIRT 460 identifies the email as an attempted spear phishing incident and 461 distributes the indicators to their sharing partners. 463 Below are the steps followed for a spear-phishing information 464 exchange between CSIRTs that was part of this PoC. 466 (1) Entity X has a sharing agreement with Entity Y, and has already 467 been configured with the IP address of Entity Y's RID Agent 469 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 470 mutual authentication occurs using PKI certificates. 472 (3) Entity X pushes out a RID Report message which contains 473 information about the spear-phishing email. IODEF is used in 474 RID to describe the 476 (a) Attachment details (file Name, hash, size, malware family 478 (b) Target description (IP, domain, NSLookup) 479 (c) Email information (From, Subject, header information, date/ 480 time, digital signature) 482 (d) Confidence Score 484 (4) Entity Y receives RID Report message, sends RID Acknowledgement 485 message 487 (5) Entity Y stores the data in a format that makes it possible for 488 the back end to know which source the data came from. 490 Appendix B includes some of the incident IODEF example information 491 that was exchanged by the organizations' RID Agents as part of this 492 proof-of-concept. 494 5.3. More use-cases 496 Other use-cases of IODEF could be: 498 (1) ISP notifying a national CERT or organization when it identifies 499 and acts upon an incident and CERTs notifying ISPs when they are 500 aware of incidents. 502 (2) Suspected phishing emails could be shared amongst organizations 503 and national agencies. Automation could validate web content 504 that the suspicious emails are pointing to. Identified 505 malicious content linked in a phishing email could then be 506 shared using IODEF. Phishing campaigns could thus be subverted 507 much faster by automating information sharing using IODEF. 509 (3) When finding a certificate that should be revoked, a third-party 510 would forward an automated IODEF message to the CA with the full 511 context of the certificate and the CA could act accordingly 512 after checking its validity. Alternatively, in the event of a 513 compromise of the private key of a certificate, a third-party 514 could alert the certificate owner about the compromise using 515 IODEF. 517 6. Security Considerations 519 This document does not incur any new security issues, since it only 520 talks about the usage of IODEF, which is defined in RFC5070. 521 Nevertheless, readers of this document SHOULD refer to the security 522 consideration section of [RFC5070] and [RFC7970]. 524 7. Updates 526 [ EDNOTE: To delete during last call. ] 528 version -08 updates: 530 (1) Updated Appendix IODEFv2 examples. 532 (2) Moved Predicate logic examples in appendix. 534 (3) Syntax and grammar fixes, clarifications, wording.. 536 (4) Reorganized IODEF uses section subesections. 538 version -07 updates: 540 (1) Updated examples in Appendix A to follow IODEFv2. 542 version -06 updates: 544 (1) Updated wording in various sections to make content clearer. 546 (2) Updated Predicate Logic section to reflect the latest 547 IndicatorExpression logic in iodef-bis. 549 (3) Updated section to describe the difference between events and 550 indicators and their use in IODEF v2. 552 version -05 updates: 554 (1) Changed section title from "Restrictions in IODEF" to 555 "Disclosure level of IODEF" and added some description 557 (2) Mixed "Recommended classes to implement" section with 558 "Unnecessary Fields" section into "Minimal IODEF document" 559 section 561 (3) Added description to "Decide what IODEF will be used for" 562 section, "Implementations" section, and "Security 563 Considerations" section 565 version -04 updates: 567 (1) Expanded on the Extensions section using Take's suggestion. 569 (2) Moved Future use-cases under the Other section. 571 (3) CIF and APWG were consolidated in one "Implementation" section 572 (4) Added abstract of RFC7495 to the "External References" section 574 (5) Added Kathleen's example of malware delivery URL to "Appendix" 576 (6) Added a little description to "Recommended classes to implement" 577 section 579 version -03 updates: 581 (1) Added "Updates" section. 583 (2) Added details about the flow of information exchanges in "Inter- 584 vendor and Service Provider Exercise" section. Also updated the 585 usecases with more background information. 587 (3) Added future use-cases in the "Collective Intelligence 588 Framework" section 590 (4) Updated Perl and Python references with the actual module names. 591 Added IODEF implementation reference "implementations". 593 (5) Added Predicate logic section 595 (6) Updated Logic of watchlist of indicators section to simplify the 596 logic and include examples. 598 (7) Renamed Externally defined indicators section to Indicator 599 reference and elaborated on the use of indicator-uid and 600 indicator-set-uid attribute use. 602 version -02 updates: 604 (1) Updated the "Logic for watchlist of indications" section to 605 clarify the logic based on community feedback. 607 (2) Added "Inter-vendor and Service Provider Exercise" section. 609 (3) Added Appendix to include actual use-case IODEF examples. 611 8. References 613 8.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 621 Object Description Exchange Format", RFC 5070, 622 DOI 10.17487/RFC5070, December 2007, 623 . 625 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document 626 Class for Reporting Phishing", RFC 5901, 627 DOI 10.17487/RFC5901, July 2010, 628 . 630 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 631 RFC 6545, DOI 10.17487/RFC6545, April 2012, 632 . 634 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 635 Defense (RID) Messages over HTTP/TLS", RFC 6546, 636 DOI 10.17487/RFC6546, April 2012, 637 . 639 [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An 640 Incident Object Description Exchange Format (IODEF) 641 Extension for Structured Cybersecurity Information", 642 RFC 7203, DOI 10.17487/RFC7203, April 2014, 643 . 645 [RFC7495] Montville, A. and D. Black, "Enumeration Reference Format 646 for the Incident Object Description Exchange Format 647 (IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015, 648 . 650 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 651 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 652 November 2016, . 654 8.2. Informative References 656 [I-D.ietf-mile-implementreport] 657 Inacio, C. and D. Miyamoto, "MILE Implementation Report", 658 draft-ietf-mile-implementreport-10 (work in progress), 659 November 2016. 661 [implementations] 662 "Implementations on IODEF", 663 . 665 Appendix A. Indicator predicate logic examples 667 In the following example the EventData class evaluates as a Flow of 668 one System with source address being (10.10.10.104 OR 10.10.10.106) 669 AND target address 10.1.1.1. 671 672 673 674 675 G90823490 676 677 C2 domains 678 679 680 681 682 683
684 10.10.10.104 685
686 687 688 689 690 691 692
693 10.10.10.106 694
695 696 697 698 699 700 701 702
703 10.1.1.1 704
705 706 707 708 709 710 711 712 Similarly, the FileData Class can be an observable in an 713 IndicatorExpression. The hash values of two files can be used to 714 match against an indicator using boolean "or" logic. In the 715 following example the indicator consists of either of the two files 716 with two different hashes. 718 719 720 721 722 A4399IWQ 723 724 File hash watchlist 725 726 727 728 729 dummy.txt 730 731 732 734 735 141accec23e7e5157de60853cb1e01bc38042d 736 08f9086040815300b7fe75c184 737 738 739 740 741 742 743 744 745 746 dummy2.txt 747 748 749 751 752 141accec23e7e5157de60853cb1e01bc38042d 753 08f9086040815300b7fe75c184 754 755 756 757 758 759 760 761 762 763 765 Appendix B. Inter-vendor and Service Provider Exercise Examples 767 Below some of the incident IODEF example information that was 768 exchanged by the vendors as part of this proof-of-concept Inter- 769 vendor and Service Provider Exercise. 771 B.1. Malware Delivery URL 773 This example indicates malware and related URL for file delivery. 775 776 780 781 782 189801 783 784 2012-12-05T12:20:00+00:00 785 2012-12-05T12:20:00+00:00 786 Malware and related indicators 787 788 789 Malware with C&C 790 791 792 793 794 example.com CSIRT 795 796 797 contact@csirt.example.com 798 799 800 801 802 803 804 805 192.0.2.200 806 807 808 /log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install 809 810 811 812 813 814 815 816 818 B.2. DDoS 820 The DDoS test exchanged information that described a DDoS including 821 protocols and ports, bad IP addresses and HTTP User-Agent fields. 823 The IODEF version used for the data representation was based on 824 [RFC7970]. 826 827 831 832 833 189701 834 835 2013-02-05T01:15:45+00:00 836 2013-02-05T00:34:45+00:00 837 2013-02-05T01:34:45+00:00 838 2013-02-05T01:15:45+00:00 839 DDoS Traffic Seen 840 841 842 DDoS Traffic 843 844 845 846 847 848 Dummy Test 849 850 contact@dummytest.com 851 852 853 854 855 856 Dummy Test sharing with ISP1 857 858 859 860 861 http://blog.spiderlabs.com/2011/01/loic-ddos- 862 analysis-and-detection.html 863 864 865 http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon 866 867 868 Low Orbit Ion Cannon User Agent 869 870 872 873 874 875 876 877 192.0.2.104 878 879 880 881 1337 882 883 884 885 886 887 192.0.2.106 888 889 890 891 1337 892 893 894 895 896 897 198.51.100.0/24 898 899 900 901 1337 902 903 904 905 906 907 2001:db8:dead:beef::1 908 909 910 911 1337 912 913 914 915 916 917 203.0.113.1 918 919 920 921 80 922 923 924 925 926 927 928 Information provided in Flow class instance is from 929 Inspection of traffic from network tap 930 931 932 933 934 935 936 937 938 G83345941 939 940 941 User-Agent string 942 943 944 945 946 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"> 947 948 949 950 951 952 953 955 B.3. Spear-Phishing 957 The Spear-Phishing test exchanged information that described a Spear- 958 Phishing email including DNS records and addresses about the sender, 959 malicious attached file information and email data. The IODEF 960 version used for the data representation was based on [RFC7970]. 962 963 969 970 971 189601 972 973 2013-01-04T08:06:12+00:00 974 2013-01-04T08:01:34+00:00 975 2013-01-04T08:31:27+00:00 976 2013-01-04T09:15:45+00:00 977 2013-01-04T09:15:45+00:00 978 979 Zeus Spear Phishing E-mail with Malware Attachment 980 981 982 983 984 Malware with Command and Control Server and System Changes 985 986 987 988 989 example.com CSIRT 990 991 contact@csirt.example.com 992 993 994 995 996 Targeting Defense Contractors, 997 specifically board members attending Dummy Con 998 999 1000 1001 Zeus 1002 1003 1004 1005 1006 1007 1008 http://www.zeusevil.example.com 1009 1010 1011 192.0.2.166 1012 1013 1014 65535 1015 1016 1018 EXAMPLE-AS - University of Example" 1019 1020 1022 192.0.2.0/24 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 mail1.evildave.example.com 1033 1034 1035 198.51.100.6 1036 1037 1038 65534 1039 1040 1042 EXAMPLE-AS - University of Example 1043 1044 1045 evildave.example.com 1046 2013-01-04T09:10:24+00:00 1047 1048 1049 1050 evildave.example.com MX prefernce = 10, mail exchanger 1051 = mail1.evildave.example.com 1052 1053 1054 mail1.evildave.example.com 1055 internet address = 198.51.100.6 1056 1057 1058 zuesevil.example.com. IN TXT \"v=spf1 a mx -all\" 1059 1060 1061 1062 1063 1064 Sending phishing mails 1066 1067 1068 1069 1070 1071 emaildave@evildave.example.com 1072 1073 1074 Join us at Dummy Con 1075 1076 1077 StormRider 4.0 1078 1079 1080 1081 1082 1083 1084 1085 203.0.113.2 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 Dummy Con Sign Up Sheet.txt 1097 1098 1099 152 1100 1101 1102 1103 1105 1106 141accec23e7e5157de60853cb1e01bc38042d 1107 08f9086040815300b7fe75c184 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 FakeCA 1120 1121 1122 57482937101 1123 1124 1125 EvilDaveExample 1126 1127 1128 1129 1130 1131 1132 1133 1134 1136 B.4. Malware 1138 In this test, malware information was exchanged using RID and IODEF. 1139 The information included file hashes, registry setting changes and 1140 the C&C servers the malware uses. 1142 1143 1148 1149 1150 189234 1151 1152 2013-03-07T16:14:56.757+05:30 1153 2013-03-07T16:14:56.757+05:30 1154 1155 Malware and related indicators identified 1156 1157 1158 1159 1160 Malware with Command and Control Server and System Changes 1161 1163 1164 1165 1166 example.com CSIRT 1167 1168 contact@csirt.example.com 1169 1170 1171 1172 1173 1174 1175 http://www.threatexpert.example.com/report.aspx? 1176 md5=e2710ceb088dacdcb03678db250742b7 1177 1178 Zeus 1179 1180 1181 1182 1183 1184 1185 203.0.113.200 1186 1187 1188 http://zeus.556677889900.example.com/log-bin/ 1189 lunch_install.php?aff_id=1&amp; 1190 lunch_id=1&amp;maddr=&amp; 1191 action=install 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJFREZG 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA== 1216 1217 1218 1219 1220 1221 1222 1223 1224 HKLM\Software\Microsoft\Windows\ 1225 CurrentVersion\Run\tamg 1226 1227 1228 ?\?\?%System%\wins\mc.exe\?\?? 1229 1230 1231 1232 HKLM\Software\Microsoft\ 1233 Windows\CurrentVersion\Run\dqo 1234 1235 "\"\"%Windir%\Resources\ 1236 Themes\Luna\km.exe\?\?" 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 http://www.threatexpert.example.com/report.aspx? 1248 md5=c3c528c939f9b176c883ae0ce5df0001 1249 1250 Cridex 1251 1252 1253 1254 1255 1256 1257 203.0.113.100 1258 1260 1261 1262 1263 8080 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM1ODVFMzQzRTcxNDFD 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw== 1288 1289 1290 1291 1292 1293 1294 1295 1296 HKLM\Software\Microsoft\Windows\ 1297 CurrentVersion\Run\KB00121600.exe 1298 1299 1300 \?\?%AppData%\KB00121600.exe\?\? 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 ind-91011 1311 1312 1313 evil c2 server, file hash, and registry key 1314 1315 1316 1317 1318 1319 http://foo.example.com:12345/evil/cc.php 1320 1321 1322 1323 1324 192.0.2.1 1325 1326 1327 1328 1329 198.51.100.1 1330 1331 1332 1333 1334 2001:db8:dead:beef::1 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184 1350 1351 1352 1353 1354 1355 1356 1357 1358 1360 1361 HKLM\SYSTEM\CurrentControlSet\ 1362 Services\.Net CLR 1363 1364 1365 1367 1368 HKLM\SYSTEM\CurrentControlSet\ 1369 Services\.Net CLR\Parameters 1370 1371 1372 \"\"%AppData%\KB00121600.exe\"\" 1373 1374 1375 1377 1378 HKLM\SYSTEM\CurrentControlSet\Services\ 1379 .Net CLR\Parameters\ServiceDll 1380 1381 C:\bad.exe 1382 1383 1385 1386 HKLM\SYSTEM\CurrentControlSet\ 1387 Services\.Net CLR\Parameters\Bar 1388 1389 Baz 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1413 Authors' Addresses 1415 Panos Kampanakis 1416 Cisco Systems 1418 Email: pkampana@cisco.com 1420 Mio Suzuki 1421 NICT 1422 4-2-1, Nukui-Kitamachi 1423 Koganei, Tokyo 184-8795 1424 JP 1426 Email: mio@nict.go.jp