idnits 2.17.1 draft-ietf-mile-iodef-guidance-11.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 : ---------------------------------------------------------------------------- ** There are 40 instances of too long lines in the document, the longest one being 53 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2017) is 2420 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: March 11, 2018 NICT 6 September 7, 2017 8 Incident Object Description Exchange Format Usage Guidance 9 draft-ietf-mile-iodef-guidance-11 11 Abstract 13 The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) 14 defines a data representation that provides a framework for sharing 15 information about computer security incidents commonly exchanged by 16 Computer Security Incident Response Teams (CSIRTs) . 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 leverage IODEF for 20 incident sharing. This document provides guidelines for IODEF 21 implementers. It addresses how common security indicators can be 22 represented in IODEF and use-cases of how IODEF is being used. This 23 document aims to make IODEF's adoption by vendors easier and 24 encourage faster and wider adoption of the model by CSIRTs around the 25 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 https://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 March 11, 2018. 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 (https://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. IODEF usage 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. Indicator predicate logic examples . . . . . . . . . 13 82 Appendix B. Inter-vendor and Service Provider Exercise Examples 16 83 B.1. Malware Delivery URL . . . . . . . . . . . . . . . . . . 16 84 B.2. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 B.3. Spear-Phishing . . . . . . . . . . . . . . . . . . . . . 20 86 B.4. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 B.5. IoT Malware . . . . . . . . . . . . . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 90 1. Introduction 92 The Incident Object Description Exchange Format (IODEF) v2 [RFC7970] 93 defines a data representation that provides a framework for sharing 94 computer security incident information commonly exchanged by Computer 95 Security Incident Response Teams (CSIRTs). The IODEF data model 96 consists of multiple classes and data types that are defined in the 97 IODEF XML schema. 99 The IODEF schema was designed to describe all the possible fields 100 needed in a security incident exchange. Thus, IODEF contains a 101 plethora of data constructs which could make it hard for IODEF 102 implementers to decide which are important. Additionally, in the 103 IODEF schema, there exist multiple fields and classes which do not 104 necessarily need to be used in every possible data exchange. 105 Moreover, some IODEF classes are useful only in rare circumstances. 106 This document tries to address these concerns. It also presents how 107 common security indicators can be represented in IODEF. It points 108 out the most important IODEF classes for an implementer and describes 109 other ones that are not as important. Also, it presents some common 110 pitfalls for IODEF implementers and how to address them. The end 111 goal of this document is to make IODEF's use by vendors easier and 112 encourage wider adoption of the model by CSIRTs around the world. 114 Section 3 discusses the recommended classes and how an IODEF 115 implementer should choose the classes to implement. Section 4 116 presents common considerations a practitioner will come across and 117 how to address them. Section 5 goes over some common uses of IODEF. 119 2. Terminology 121 The terminology used in this document follows the one defined in 122 [RFC7970] and [RFC7203]. 124 3. Implementation and Use Strategy 126 It is important for IODEF implementers to distinguish how the IODEF 127 classes will be used in incident information exchanges. It is also 128 important to understand the most common IODEF classes that describe 129 common security incidents or indicators. This section describes the 130 most important classes and factors an IODEF practitioner should take 131 into consideration before using IODEF or designing an implementation. 133 3.1. Minimal IODEF document 135 An IODEF document must include at least an Incident class, an 136 xml:lang attribute that defines the supported language and the IODEF 137 version attribute. An Incident must contain a purpose attribute and 138 three mandatory-to-implement elements. These elements are Generation 139 time class that describes the time of the incident, an IncidentID 140 class and at least one Contact class. The structure of the minimal 141 IODEF-Document is shown in Figure 1. 143 +---------------+ +--------------+ 144 |IODEF-Document | | Incident | 145 +---------------+ +--------------+ +----------------+ 146 |STRING version |<>--{1..*}--| ENUM purpose |<>----------| IncidentID | 147 |ENUM xml:lang | | | +----------------+ 148 | | | | | STRING name | 149 +---------------+ | | +----------------+ 150 | | 151 | |<>----------[ GenerationTime ] 152 | | 153 | | +----------------+ 154 | |<>--{1..*}--[ Contact | 155 +--------------+ +----------------+ 156 | ENUM role | 157 | ENUM type | 158 +----------------+ 160 Figure 1: Minimal IODEF-Document class 162 The IncidentID class must contain at least a name attribute. 164 In turn, the Contact class requires the type and role attributes, but 165 no elements are required by the IODEF v2 specification. 166 Nevertheless, at least one of the elements in the Contact class, such 167 as an Email class, should be implemented so that the IODEF document 168 is useful. 170 Section 7.1 of [RFC7970] presents a minimal IODEF document with only 171 the mandatory classes and attributes. Implementers can also refer to 172 Section 7 of [RFC7970] and Appendix B for example IODEF v2 documents. 174 3.2. Information represented 176 There is no need for a practitioner to use or implement IODEF classes 177 and fields other than the minimal ones (Section 3.1) and the ones 178 necessary for her use-cases. The implementer should carefully look 179 into the schema and decide which classes to implement (or 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 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 will be implemented instead of the EventData 197 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 202 unnecessary. Other external schemata can also be used in IODEF to 203 describe incidents or indicators. External schemata should be parsed 204 accordingly only if the implementer's IODEF use-cases require 205 external schema information. But even when an IODEF implementation 206 cannot parse an external schema, the IODEF report can still be 207 valuable to an incident response team. The information can also be 208 useful when shared further with content consumers able to parse this 209 information. 211 IODEF supports multiple language translations of free-form, ML_STRING 212 text in all classes [RFC7970]. That way, text in Description 213 elements can be translated to different languages by using a 214 translation identifier in the class. Implementers should be able to 215 parse iodef:MLStringType classes and extract only the information 216 relevant to languages of interest. 218 3.3. IODEF Classes 220 [RFC7970] contains classes that can describe attack Methods, Events, 221 Incidents, Indicators, how they were discovered and the Assessment of 222 the repercussions for the victim. It is important for IODEF users to 223 know the distinction between these classes in order to decide which 224 ones fulfill their use-cases. 226 An IndicatorData class depicts a threat indicator or observable that 227 could be used to describe a threat that resulted in an attempted 228 attack. For example, we could see an attack happening but it might 229 have been prevented and not have resulted in an incident or security 230 event. On the other hand, an EventData class usually describes a 231 security event and can be considered as a report of something that 232 took place. 234 Classes like Discovery, Assessment, Method, and RecoveryTime are used 235 in conjunction with EventData as they related to the incident report 236 described in the EventData. The RelatedActivity class can reference 237 an incident, an indicator or other related threat activity. 239 While deciding what classes are important for the needed use-cases, 240 IODEF users should carefully evaluate the necessary classes and how 241 these are used in order to avoid unnecessary work. For example, if 242 we want to only describe indicators in IODEF, the implementation of 243 Method or Assessment might not be important. 245 4. IODEF usage considerations 247 Implementers need to consider some common, standardized options for 248 their IODEF use strategy. 250 4.1. External References 252 The IODEF format includes the Reference class used for externally 253 defined information such as a vulnerability, Intrusion Detection 254 System (IDS) alert, malware sample, advisory, or attack technique. 255 To facilitate the exchange of information, the Reference class was 256 extended to the Enumeration Reference Format [RFC7495]. The 257 Enumeration Reference Format specifies a means to use external 258 enumeration specifications (e.g. CVE) that could define an 259 enumeration format, specific enumeration values, or both. As 260 external enumerations can vary greatly, implementers should only 261 support the ones expected to describe their specific use-cases. 263 4.2. Extensions 265 The IODEF data model ([RFC7970]) is extensible. Many attributes with 266 enumerated values can be extended using the "ext-*" prefix. 267 Additional classes can also be defined by using the AdditionalData 268 and RecordItem classes. An extension to the AdditionalData class for 269 reporting Phishing emails is defined in [RFC5901]. Information about 270 extending IODEF class attributes and enumerated values can be found 271 in Section 5 of [RFC7970]. 273 Additionally, IODEF can import existing schemata by using an 274 extension framework defined in [RFC7203]. The framework enables 275 IODEF users to embed XML data inside an IODEF document using external 276 schemata or structures defined by external specifications. Examples 277 include CVE, CVRF and OVAL. [RFC7203] enhances the IODEF 278 capabilities without further extending the data model. 280 IODEF implementers should not use their own IODEF extensions unless 281 data cannot be represented using existing standards or importing them 282 in an IODEF document using [RFC7203] is not a suitable option. 284 4.3. Indicator predicate logic 286 An IODEF [RFC7970] document can describe incident reports and 287 indicators. The Indicator class can include references to other 288 indicators, observables and more classes that contain details about 289 the indicator. When describing security indicators, it is often 290 common to need to group them together in order to form a group of 291 indicators that constitute a security threat. For example, a botnet 292 might have multiple command and control servers. For that reason, 293 IODEF v2 introduced the IndicatorExpression class that is used to add 294 the indicator predicate logic when grouping more than one indicators 295 or observables. 297 Implementations must be able to parse and apply the Boolean logic 298 offered by an IndicatorExpression in order to evaluate the existence 299 of an indicator. As explained in Section 3.29.5 of [RFC7970] the 300 IndicatorExpression element operator defines the operator applied to 301 all the child element of the IndicatorExpression. If no operator is 302 defined "and" should be assumed. IndicatorExpressions can also be 303 nested together. Child IndicatorExpressions should be treated as 304 child elements of their parent and they should be evaluated first 305 before evaluated with the operator of their parent. 307 Users can refer to Appendix A for example uses of the 308 IndicatorExpressions in an IODEF v2. 310 4.4. Disclosure level 312 Access to information in IODEF documents should be tightly locked 313 since the content may be confidential. IODEF has a common attribute, 314 called "restriction", which indicates the disclosure guideline to 315 which the sender expects the recipient to adhere to for the 316 information represented in the class and its children. That way, the 317 sender can express the level of disclosure for each component of an 318 IODEF document. Appropriate external measures could be implemented 319 based on the restriction level. One example is when Real-time Inter- 320 network Defense (RID) [RFC6545] is used to transfer the IODEF 321 documents, it can provide policy guidelines for handling IODEF 322 documents by using the RIDPolicy class. 324 The enforcement of the disclosure guidelines is out of scope for 325 IODEF. The recipient of the IODEF document needs to follow the 326 guidelines, but these guidelines themselves do not provide any 327 enforcement measures. For that purpose, implementers should consider 328 appropriate privacy control measures, technical or operational for 329 their implementation. 331 5. IODEF Uses 333 IODEF is currently used by various organizations in order to 334 represent security incidents and share incident and threat 335 information between security operations organizations. 337 5.1. Implementations 339 In order to use IODEF, tools like IODEF parsers are necessary. 340 [RFC8134] describes a set of IODEF implementations and uses by 341 various vendors and Computer Emergency Readiness Team (CERT) 342 organizations. The document does not specify any specific mandatory 343 to implement (MTI) IODEF classes but provides a list of real world 344 uses. Perl and Python modules (XML::IODEF, Iodef::Pb, iodeflib) are 345 some examples. Moreover, implementers are encouraged to refer to 346 Section 7 of [RFC8134] practical IODEF usage guidelines. 347 [implementations], on the other hand, includes various vendor 348 incident reporting products that can consume and export in IODEF 349 format. 351 5.2. Inter-vendor and Service Provider Exercise 353 As an interoperability exercise, in 2013 a limited number of vendors 354 organized and executed threat indicators exchanges in IODEF. The 355 transport protocol used was RID. The threat information shared 356 included indicators from DDoS attacks; and Malware incidents and 357 Spear-Phishing that targets specific individuals after harvesting 358 information about them. The results served as proof-of-concept (PoC) 359 about how seemingly competing entities could use IODEF to exchange 360 sanitized security information. As this was a PoC exercise only 361 example information (no real threats) were shared as part of the 362 exchanges. 364 ____________ ____________ 365 | Vendor X | | Vendor Y | 366 | RID Agent |_______-------------________| RID Agent | 367 |___________| | Internet | |___________| 368 ------------- 370 ---- RID Report message ---> 371 -- carrying IODEF example -> 372 --------- over TLS --------> 374 <----- RID Ack message ----- 375 <--- in case of failure ---- 377 Figure 2: PoC peering topology 379 Figure 2 shows how RID interactions took place during the PoC. 380 Participating organizations were running RID Agent software on- 381 premises. The RID Agents formed peering relationships with other 382 participating organizations. When Entity X had a new incident to 383 exchange it would package it in IODEF and send it to Entity Y over 384 TLS in a RID Report message. In case there was an issue with the 385 message, Entity Y would send an RID Acknowledgement message back to 386 Entity X which included an application level message to describe the 387 issue. Interoperability between RID agents implementing [RFC6545] 388 and [RFC6546] was also confirmed. 390 The first use-case included sharing of Malware Data Related to an 391 Incident between CSIRTs. After Entity X detected an incident, she 392 would put data about malware found during the incident in a backend 393 system. Entity X then decided to share the incident information with 394 Entity Y about the malware discovered. This could be a human 395 decision or part of an automated process. 397 Below are the steps followed for the malware information exchange 398 that was taking place: 400 (1) Entity X has a sharing agreement with Entity Y, and has already 401 been configured with the IP address of Entity Y's RID Agent. 403 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 404 mutual authentication occurs using PKI digital certificates. 406 (3) Entity X pushes out a RID Report message which contains 407 information about N pieces of discovered malware. IODEF is used 408 in RID to describe the 410 (a) Hash of malware files 412 (b) Registry settings changed by the malware 414 (c) C&C Information for the malware 416 (4) Entity Y receives RID Report message, sends RID Acknowledgement 417 message 419 (5) Entity Y stores the data in a format that makes it possible for 420 the back end to know which source the data came from. 422 Another use-case was sharing a DDoS attack as explained in the 423 following scenario: Entity X, a Critical Infrastructure and Key 424 Resource (CIKR) company detects that their internet connection is 425 saturated with an abnormal amount of traffic. Further investigation 426 determines that this is an actual DDoS attack. Entity X's CSIT 427 contacts their ISP, Entity Y, and shares information with them about 428 the attack traffic characteristics. Entity X's ISP is being 429 overwhelmed by the amount of traffic, so it shares attack signatures 430 and IP addresses of the most prolific hosts with its adjacent ISPs. 432 Below are the steps followed for a DDoS information exchange: 434 (1) Entity X has a sharing agreement with Entity Y, and has already 435 been configured with the IP address of Entity Y's RID Agent. 437 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 438 mutual authentication occurs using PKI digital certificates. 440 (3) Entity X pushes out a RID Report message which contains 441 information about the DDoS attack. IODEF is used in RID to 442 describe the 444 (a) Start and Detect dates and times 446 (b) IP Addresses of nodes sending DDoS Traffic 448 (c) Sharing and Use Restrictions 450 (d) Traffic characteristics (protocols and ports) 452 (e) HTTP User-Agents used 454 (f) IP Addresses of C&C for a botnet 456 (4) Entity Y receives RID Report message, sends RID Acknowledgement 457 message 459 (5) Entity Y stores the data in a format that makes it possible for 460 the back end to know which source the data came from. 462 (6) Entity Y shares information with other ISP Entities it has an 463 established relationship with. 465 One more use-case was sharing spear-phishing email information as 466 explained in the following scenario: The board members of several 467 defense contractors receive a targeted email inviting them to attend 468 a conference in San Francisco. The board members are asked to 469 provide their personally identifiable information such as their home 470 address, phone number, corporate email, etc in an attached document 471 which came with the email. The board members are also asked to click 472 on a URL which would allow them to reach the sign up page for the 473 conference. One of the recipients believes the email to be a 474 phishing attempt and forwards the email to their corporate CSIRT for 475 analysis. The CSIRT identifies the email as an attempted spear 476 phishing incident and distributes the indicators to their sharing 477 partners. 479 Below are the steps followed for a spear-phishing information 480 exchange between CSIRTs that was part of this PoC. 482 (1) Entity X has a sharing agreement with Entity Y, and has already 483 been configured with the IP address of Entity Y's RID Agent. 485 (2) Entity X's RID Agent connects to Entity Y's RID Agent, and 486 mutual authentication occurs using PKI digital certificates. 488 (3) Entity X pushes out a RID Report message which contains 489 information about the spear-phishing email. IODEF is used in 490 RID to describe the 492 (a) Attachment details (file Name, hash, size, malware family 494 (b) Target description (IP, domain, NSLookup) 496 (c) Email information (From, Subject, header information, date/ 497 time, digital signature) 499 (d) Confidence Score 501 (4) Entity Y receives RID Report message, sends RID Acknowledgement 502 message 504 (5) Entity Y stores the data in a format that makes it possible for 505 the back end to know which source the data came from. 507 Appendix B includes some of the incident IODEF example information 508 that was exchanged by the organizations' RID Agents as part of this 509 proof-of-concept. 511 5.3. Use-cases 513 Other use-cases of IODEF, other than the ones described above, could 514 be: 516 (1) ISP notifying a national CERT or organization when it identifies 517 and acts upon an incident and CERTs notifying ISPs when they are 518 aware of incidents. 520 (2) Suspected phishing emails could be shared amongst organizations 521 and national agencies. Automation could validate web content 522 that the suspicious emails are pointing to. Identified 523 malicious content linked in a phishing email could then be 524 shared using IODEF. Phishing campaigns could thus be subverted 525 much faster by automating information sharing using IODEF. 527 (3) When finding a certificate that should be revoked, a third-party 528 would forward an automated IODEF message to the CA with the full 529 context of the certificate and the CA could act accordingly 530 after checking its validity. Alternatively, in the event of a 531 compromise of the private key of a certificate, a third-party 532 could alert the certificate owner about the compromise using 533 IODEF. 535 6. IANA Considerations 537 This memo does not require any IANA actions. 539 7. Security Considerations 541 This document does not incur any new security issues, since it only 542 talks about the usage of IODEFv2 defined RFC7970. Nevertheless, 543 readers of this document should refer to the Security Considerations 544 section of [RFC7970]. 546 8. References 548 8.1. Normative References 550 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document 551 Class for Reporting Phishing", RFC 5901, 552 DOI 10.17487/RFC5901, July 2010, 553 . 555 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 556 RFC 6545, DOI 10.17487/RFC6545, April 2012, 557 . 559 [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An 560 Incident Object Description Exchange Format (IODEF) 561 Extension for Structured Cybersecurity Information", 562 RFC 7203, DOI 10.17487/RFC7203, April 2014, 563 . 565 [RFC7495] Montville, A. and D. Black, "Enumeration Reference Format 566 for the Incident Object Description Exchange Format 567 (IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015, 568 . 570 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 571 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 572 November 2016, . 574 8.2. Informative References 576 [implementations] 577 "Implementations on IODEF", 578 . 580 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 581 Defense (RID) Messages over HTTP/TLS", RFC 6546, 582 DOI 10.17487/RFC6546, April 2012, 583 . 585 [RFC8134] Inacio, C. and D. Miyamoto, "Management Incident 586 Lightweight Exchange (MILE) Implementation Report", 587 RFC 8134, DOI 10.17487/RFC8134, May 2017, 588 . 590 Appendix A. Indicator predicate logic examples 592 In the following example the EventData class evaluates as a Flow of 593 one System with source address being (192.0.2.104 OR 192.0.2.106) AND 594 target address 198.51.100.1. 596 597 598 599 600 G90823490 601 602 C2 domains 603 604 605 606 607 608
609 192.0.2.104 610
611 612 613 614 615 616 617
618 192.0.2.106 619
620 621 622 623 624 625 626 627
628 198.51.100.1 629
630 631 632 633 634 635 636 638 Similarly, the FileData Class can be an observable in an 639 IndicatorExpression. The hash values of two files can be used to 640 match against an indicator using Boolean "or" logic. In the 641 following example the indicator consists of either of the two files 642 with two different hashes. 644 645 646 647 648 A4399IWQ 649 650 File hash watchlist 651 652 653 654 655 dummy.txt 656 657 658 660 661 141accec23e7e5157de60853cb1e01bc38042d 662 08f9086040815300b7fe75c184 663 664 665 666 667 668 669 670 671 672 dummy2.txt 673 674 675 677 678 141accec23e7e5157de60853cb1e01bc38042d 679 08f9086040815300b7fe75c184 680 681 682 683 684 685 686 687 688 689 691 Appendix B. Inter-vendor and Service Provider Exercise Examples 693 Below some of the incident IODEF example information that was 694 exchanged by the vendors as part of this proof-of-concept Inter- 695 vendor and Service Provider Exercise. 697 B.1. Malware Delivery URL 699 This example indicates malware and related URL for file delivery. 701 702 706 707 708 189801 709 710 2012-12-05T12:20:00+00:00 711 2012-12-05T12:20:00+00:00 712 Malware and related indicators 713 714 715 Malware with C&C 716 717 718 719 720 example.com CSIRT 721 722 723 contact@csirt.example.com 724 725 726 727 728 729 730 731 192.0.2.200 732 733 734 /log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install 735 736 737 738 739 740 741 742 744 B.2. DDoS 746 The DDoS test exchanged information that described a DDoS including 747 protocols and ports, bad IP addresses and HTTP User-Agent fields. 749 The IODEF version used for the data representation was based on 750 [RFC7970]. 752 753 757 758 759 189701 760 761 2013-02-05T01:15:45+00:00 762 2013-02-05T00:34:45+00:00 763 2013-02-05T01:34:45+00:00 764 2013-02-05T01:15:45+00:00 765 DDoS Traffic Seen 766 767 768 DDoS Traffic 769 770 771 772 773 774 Dummy Test 775 776 contact@dummytest.com 777 778 779 780 781 782 Dummy Test sharing with ISP1 783 784 785 786 787 http://blog.spiderlabs.com/2011/01/loic-ddos- 788 analysis-and-detection.html 789 790 791 http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon 792 793 794 Low Orbit Ion Cannon User Agent 795 796 798 799 800 801 802 803 192.0.2.104 804 805 806 807 1337 808 809 810 811 812 813 192.0.2.106 814 815 816 817 1337 818 819 820 821 822 823 198.51.100.0/24 824 825 826 827 1337 828 829 830 831 832 833 2001:db8:dead:beef::1 834 835 836 837 1337 838 839 840 841 842 843 203.0.113.1 844 845 846 847 80 848 849 850 851 852 853 854 Information provided in Flow class instance is from 855 Inspection of traffic from network tap 856 857 858 859 860 861 862 863 864 G83345941 865 866 867 User-Agent string 868 869 870 871 872 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"> 873 874 875 876 877 878 879 881 B.3. Spear-Phishing 883 The Spear-Phishing test exchanged information that described a Spear- 884 Phishing email including DNS records and addresses about the sender, 885 malicious attached file information and email data. The IODEF 886 version used for the data representation was based on [RFC7970]. 888 889 895 896 897 189601 898 899 2013-01-04T08:06:12+00:00 900 2013-01-04T08:01:34+00:00 901 2013-01-04T08:31:27+00:00 902 2013-01-04T09:15:45+00:00 903 2013-01-04T09:15:45+00:00 904 905 Zeus Spear Phishing E-mail with Malware Attachment 906 907 908 909 910 Malware with Command and Control Server and System Changes 911 912 913 914 915 example.com CSIRT 916 917 contact@csirt.example.com 918 919 920 921 922 Targeting Defense Contractors, 923 specifically board members attending Dummy Con 924 925 926 927 Zeus 928 929 930 931 932 933 934 http://www.zeusevil.example.com 935 936 937 192.0.2.166 938 939 940 65535 941 942 944 EXAMPLE-AS - University of Example" 945 946 948 192.0.2.0/24 949 950 951 952 953 954 955 956 957 958 mail1.evildave.example.com 959 960 961 198.51.100.6 962 963 964 65534 965 966 968 EXAMPLE-AS - University of Example 969 970 971 evildave.example.com 972 2013-01-04T09:10:24+00:00 973 974 975 976 evildave.example.com MX prefernce = 10, mail exchanger 977 = mail1.evildave.example.com 978 979 980 mail1.evildave.example.com 981 internet address = 198.51.100.6 982 983 984 zuesevil.example.com. IN TXT \"v=spf1 a mx -all\" 985 986 987 988 989 990 Sending phishing mails 992 993 994 995 996 997 emaildave@evildave.example.com 998 999 1000 Join us at Dummy Con 1001 1002 1003 StormRider 4.0 1004 1005 1006 1007 1008 1009 1010 1011 203.0.113.2 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 Dummy Con Sign Up Sheet.txt 1023 1024 1025 152 1026 1027 1028 1029 1031 1032 141accec23e7e5157de60853cb1e01bc38042d 1033 08f9086040815300b7fe75c184 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 FakeCA 1046 1047 1048 57482937101 1049 1050 1051 EvilDaveExample 1052 1053 1054 1055 1056 1057 1058 1059 1060 1062 B.4. Malware 1064 In this test, malware information was exchanged using RID and IODEF. 1065 The information included file hashes, registry setting changes and 1066 the C&C servers the malware uses. 1068 1069 1074 1075 1076 189234 1077 1078 2013-03-07T16:14:56.757+05:30 1079 2013-03-07T16:14:56.757+05:30 1080 1081 Malware and related indicators identified 1082 1083 1084 1085 1086 Malware with Command and Control Server and System Changes 1087 1089 1090 1091 1092 example.com CSIRT 1093 1094 contact@csirt.example.com 1095 1096 1097 1098 1099 1100 1101 http://www.threatexpert.example.com/report.aspx? 1102 md5=e2710ceb088dacdcb03678db250742b7 1103 1104 Zeus 1105 1106 1107 1108 1109 1110 1111 203.0.113.200 1112 1113 1114 http://zeus.556677889900.example.com/log-bin/ 1115 lunch_install.php?aff_id=1&amp; 1116 lunch_id=1&amp;maddr=&amp; 1117 action=install 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJFREZG 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA== 1142 1143 1144 1145 1146 1147 1148 1149 1150 HKLM\Software\Microsoft\Windows\ 1151 CurrentVersion\Run\tamg 1152 1153 1154 ?\?\?%System%\wins\mc.exe\?\?? 1155 1156 1157 1158 HKLM\Software\Microsoft\ 1159 Windows\CurrentVersion\Run\dqo 1160 1161 "\"\"%Windir%\Resources\ 1162 Themes\Luna\km.exe\?\?" 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 http://www.threatexpert.example.com/report.aspx? 1174 md5=c3c528c939f9b176c883ae0ce5df0001 1175 1176 Cridex 1177 1178 1179 1180 1181 1182 1183 203.0.113.100 1184 1186 1187 1188 1189 8080 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM1ODVFMzQzRTcxNDFD 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw== 1214 1215 1216 1217 1218 1219 1220 1221 1222 HKLM\Software\Microsoft\Windows\ 1223 CurrentVersion\Run\KB00121600.exe 1224 1225 1226 \?\?%AppData%\KB00121600.exe\?\? 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 ind-91011 1237 1238 1239 evil c2 server, file hash, and registry key 1240 1241 1242 1243 1244 1245 http://foo.example.com:12345/evil/cc.php 1246 1247 1248 1249 1250 192.0.2.1 1251 1252 1253 1254 1255 198.51.100.1 1256 1257 1258 1259 1260 2001:db8:dead:beef::1 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184 1276 1277 1278 1279 1280 1281 1282 1283 1284 1286 1287 HKLM\SYSTEM\CurrentControlSet\ 1288 Services\.Net CLR 1289 1290 1291 1293 1294 HKLM\SYSTEM\CurrentControlSet\ 1295 Services\.Net CLR\Parameters 1296 1297 1298 \"\"%AppData%\KB00121600.exe\"\" 1299 1300 1301 1303 1304 HKLM\SYSTEM\CurrentControlSet\Services\ 1305 .Net CLR\Parameters\ServiceDll 1306 1307 C:\bad.exe 1308 1309 1311 1312 HKLM\SYSTEM\CurrentControlSet\ 1313 Services\.Net CLR\Parameters\Bar 1314 1315 Baz 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1339 B.5. IoT Malware 1341 The IoT Malware test exchanged information that described a bad IP 1342 address of IoT malware and its scanned ports. This example 1343 information is extracted from alert messages of a Darknet monitoring 1344 system referred in [RFC8134]. The IODEF version used for the data 1345 representation was based on [RFC7970]. 1347 1348 1352 1353 1354 189802 1355 1356 2017-03-01T01:15:00+09:00 1357 2017-03-01T01:15:00+09:00 1358 IoT Malware and related indicators 1359 1360 1361 IoT Malware is scanning other hosts 1362 1363 1364 1365 1366 example.com CSIRT 1367 1368 1369 contact@csirt.example.com 1370 1371 1372 1373 1374 1375 1376 Detected by darknet monitoring 1377 1379 1380 1381 1382 1383 1384 192.0.2.210 1385 1386 1387 1388 1389 23 1390 1391 1392 1393 Example Surveillance Camera OS 2.1.1 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 198.51.100.1 1404 1405 1406 1407 1408 23 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 198.51.100.94 1419 1420 1421 1422 1423 23 1424 1425 1426 1428 1429 1430 1431 1432 1433 1434 198.51.100.237 1435 1436 1437 1438 1439 2323 1440 1441 1442 1443 1444 1445 1446 1448 Authors' Addresses 1450 Panos Kampanakis 1451 Cisco Systems 1453 Email: pkampana@cisco.com 1455 Mio Suzuki 1456 NICT 1457 4-2-1, Nukui-Kitamachi 1458 Koganei, Tokyo 184-8795 1459 JP 1461 Email: mio@nict.go.jp