idnits 2.17.1 draft-moriarty-carisreport-02.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2016) is 2891 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-mile-rolie-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network K. Moriarty 3 Internet-Draft EMC Corporation 4 Intended status: Informational M. Ford 5 Expires: November 20, 2016 Internet Society 6 May 19, 2016 8 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report 9 draft-moriarty-carisreport-02 11 Abstract 13 The Internet Architecture Board (IAB) and the Internet Society (ISOC) 14 hosted a day-long Coordinating Attack Response at Internet Scale 15 (CARIS) workshop on 18 June 2015 in coordination with the Forum for 16 Incident Response and Security Teams (FIRST) Conference in Berlin. 17 The workshop included members of the FIRST community, attack response 18 working group representatives, network and security operators, 19 Regional Internet Registry (RIR) representatives, researchers, 20 vendors, and representatives from standardisation communities. Key 21 goals of the workshop were to improve mutual awareness, 22 understanding, and coordination among the diverse participating 23 organizations and their representatives. The workshop also aimed to 24 provide the attendees with greater awareness of existing efforts to 25 mitigate specific types of attacks, and greater understanding of the 26 options available to collaborate and engage with these efforts. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 20, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Sessions and Panel Groups . . . . . . . . . . . . . . . . . . 4 64 2.1. Coordination between CSIRTs and Attack Response 65 Mitigation Efforts . . . . . . . . . . . . . . . . . . . 4 66 2.2. Scaling Response to DDoS and Botnets Effectively and 67 Safely . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.3. DNS & RIRs: Attack Response and Mitigation . . . . . . . 8 69 2.4. Trust Privacy and Data Markings Panel . . . . . . . . . . 9 70 3. Workshop Themes . . . . . . . . . . . . . . . . . . . . . . . 11 71 4. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. RIR and DNS Provider Resources . . . . . . . . . . . . . 11 73 4.2. Education and Guidance . . . . . . . . . . . . . . . . . 11 74 4.3. Transport Options . . . . . . . . . . . . . . . . . . . . 11 75 4.4. Updated Template for Information Exchange Groups . . . . 12 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. Informative References . . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 79 Appendix B. Workshop Attendees . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 The Internet Architecture Board (IAB) and the Internet Society (ISOC) 85 hosted a day-long Coordinating Attack Response at Internet Scale 86 (CARIS) workshop on 18 June 2015 in coordination with the Forum for 87 Incident Response and Security Teams (FIRST) Conference in Berlin. 88 The workshop included members of the FIRST community, attack response 89 working group representatives, network and security operators, 90 Regional Internet Registry (RIR) representatives, researchers, 91 vendors, and representatives from standardisation communities. Key 92 goals of the workshop were to improve mutual awareness, 93 understanding, and coordination among the diverse participating 94 organizations. The workshop also aimed to provide the attendees with 95 greater awareness of existing efforts to mitigate specific types of 96 attacks, and greater understanding of the options available to 97 collaborate and engage with these efforts. 99 The day-long workshop included a mix of invited talks and panel 100 discussion sessions with opportunities to collaborate throughout, 101 taking full advantage of the tremendous value of having these diverse 102 communities with common goals in one room. There were approximately 103 50 participants engaged in the CARIS workshop. 105 Attendance at the workshop was by invitation only. Prior to the 106 workshop, existing attack-mitigation working groups were asked to 107 complete a survey. The data gathered through this questionnaire, 108 including how third parties can participate in or contribute to the 109 attack-mitigation working group, was shared with all of the 110 participants at the workshop to better enable collaboration [ISOC]. 111 Attendees were also selected from submissions of 2-page position 112 papers that included some key insight or challenge relevant to the 113 broader group. Paper topics included research topics related to 114 attack mitigation or information sharing/exchange, success stories, 115 lessons learned, and more in-depth studies on specific topics such as 116 privacy or trust. 118 The program committee received 25 papers and 20 template submissions. 119 The template submissions will be maintained by the Internet Society 120 and as a result of the workshop they will be amended to provide 121 additional value to the computer security incident response teams 122 (CSIRTs) and attack response communities/operators on their 123 information exchange capabilities. The CARIS participants found the 124 template submissions to be very useful in coordinating their future 125 attack mitigation efforts. This is a new initiative and is open for 126 the global community and hosted in a neutral location. All 127 submissions are available online and linked from the agenda [AGENDA]. 129 The workshop talks and panels involved full participation from 130 attendees who were required to read all the submitted materials. The 131 panels were organized to spur conversation between specific groups to 132 see if progress could be made towards more efficient and effective 133 attack mitigation efforts. See [KME1] paper and [KME2] for 134 additional information on possible approaches to accomplish more 135 effective attack response and information exchanges with methods that 136 require fewer analysts. 138 The workshop was run under the Chatham House Rule to facilitate the 139 exchange of sensitive information involved with incident response. 140 As such, there was no recording, but minutes were taken and used to 141 aid in the generation of this report. Comments will not be 142 attributed to any particular attendee, nor will organizations be 143 named in association with any discussion topics that were not made 144 public through submission templates or papers by the submitter and 145 organization. 147 2. Sessions and Panel Groups 149 After an initial presentation to set the stage and elaborate the 150 goals of the workshop, the day was divided into five sessions as 151 follows. 153 1. Coordination between CSIRTs and attack response mitigation 154 efforts 156 2. Scaling response to DDoS and Botnets effectively and safely 158 3. Infrastructure: DNS and RIR providers and researchers 160 4. Trust and Privacy with the exchange of potentially sensitive 161 information 163 5. Implications for Internet architecture and next steps 165 The remainder of this report will provide more detail on each of 166 these sessions. 168 2.1. Coordination between CSIRTs and Attack Response Mitigation Efforts 170 The first panel session on Coordination between CSIRTs and attack 171 mitigation efforts included representatives from several 172 organizations that submitted templates describing their 173 organization's attack mitigation efforts. This panel was 174 purposefully a cross section of organizations attending to see if 175 there were new opportunities to collaborate and improve efficiency 176 thereby better scaling attack mitigation. The panelists described 177 their efforts with the following questions in mind: 179 o What is the use case for their organization? 181 o Where are they focusing their efforts? 183 o How can others engage with their organization? 185 o Who participates in their organization today? 187 For each of the following organizations, additional information can 188 be found in their template submissions [ISOC]. 190 The following summaries are to be read in the context of the workshop 191 and not as stand alone descriptions for each organization. These 192 summaries are a result of the workshop discussions. 194 o ENISA is the European Network and Information Security Agency 195 [ENISA]. While ENISA provides support for the community in the 196 form of education, training and collaboration on security and 197 attack mitigation, it does not offer a service for attack response 198 or mitigation. 200 o The Anti-Phishing Working Group (APWG) offered examples of 201 operator driven exchanges focused on specific use cases that 202 involve hundreds of participating organizations daily. The APWG 203 operates a data clearinghouse and provides infrastructure to 204 support meaningful data exchanges and maintains a current set of 205 data through these interactions. More can be learned on the APWG 206 web site [APWG] in addition to their template submission. 208 o The Research and Education Networking Information Sharing and 209 Analysis Center (Ren-ISAC) employs an interesting operational 210 model that scales well through automation, exchanging actionable 211 information between 500 universities and automatically 212 implementing controls. Since many universities cannot respond to 213 incidents in real-time due to a scarcity of resources, REN-ISAC 214 leverage a small number of analysts to accomplish the task of 215 protecting many universities through automation. The key to the 216 success of their project is providing tools that allow 217 organizations to make use of incident data operationally. They 218 are currently working to develop open-source tools to track 219 metrics more formally [REN-ISAC]. 221 o CERT.br is the Brazilian Computer Emergency Response Team (CERT) 222 and they have made impressive progress in a short amount of time. 223 CERT.br is the national focal point for incident reporting, 224 collection and dissemination of threat and attack trend 225 information in Brazil. CERT.br works to increase awareness and 226 incident-handling capabilities in country as well as assisting to 227 establish new CSIRTs. In addition to providing training and 228 awareness campaigns, they distribute network security honeypots 229 and have a primary focus on network monitoring. CERT.br requires 230 active participation from third parties wishing to collaborate and 231 exchange data with them [CERT.BR]. 233 o MyCERT's mission is to address the security concerns of Malaysian 234 Internet users and reduce the probability of successful attacks 235 [MYCERT]. They have been operational since 1997. MyCERT is 236 responsible for incident handling of unauthorised intrusions, 237 identity theft, DDoS attacks, etc. MyCERT handles computer 238 security incidents in Malaysia, provides malware research, and 239 technical coordination. In addition to incident response and 240 coordination activities, MyCERT members provide talks and 241 training, as well as local and regional security exercises. 242 MyCERT also provides incident alerts and advisories on 243 vulnerabilities, breaches, etc. 245 o The CERT Coordination Center (CERT/CC) has been operational since 246 1998 on an international and national scale [CERTCC]. They have 247 long been known for their software vulnerability work and the 248 national vulnerability database in the US (Common Vulnerabilities 249 and Exposures - CVEs) and informing organizations of 250 vulnerabilities. CERT/CC helps to coordinate between vendors and 251 researchers for improved collaborations. CERT/CC provides 252 guidance on dealing with the aftermath of incidents, risk 253 assessment best practice, bug bounties, and other incident related 254 areas. 256 Highlights from the panel discussion: 258 o Passive surveillance by state actors has impacted incident 259 response activities due to the erosion of trust between 260 communities 262 o Government involvement in information exchange efforts hasn't been 263 productive, lots of talk without useful exchanges 265 o There is more interest in consuming feeds of information than 266 sharing information 268 o Ego has been a big issue for improving data sharing, as have 269 reputation-related concerns when sharing or receiving data 271 o There is a perception of weakness around organizations who do 272 share attack information in some regions 274 o Sharing in isolation doesn't help, it must lead to operational 275 return on investment 277 o Language barriers have been an issue for some national CSIRTs 279 o Sharing too much information leads to capacity and resource issues 280 for receiving organizations. Organizations directly receiving 281 feeds can often misinterpret data and think they are under attack 282 when it is not the case. Operational models are preferred where 283 data exchanges have a direct impact on improving the efficiency of 284 a small number of analysts to impact many. 286 o Privacy regulations restricting some organizations from sharing IP 287 address information have had an impact on the effectiveness of 288 incident data exchanges. ENISA is currently running a study on 289 this impact (this point was raised by several attendees). 291 o Too many efforts are using data just for blocking attacks and not 292 for operational mitigation and elimination of vulnerabilities as 293 part of their incident response effort. Note: Operational efforts 294 stand out in that they do eliminate threats and update data 295 warehouses. 297 o Involvement of vendors is needed to better scale attack response. 298 This is not seen as a need by all groups, but some sharing groups 299 with an operational focus are looking for improved efficiencies to 300 leverage a small number of analysts more productively. Analysts 301 are a limited resource in this technical area of expertise. 303 o Enterprises don't want more security boxes in their networks as 304 they don't have the resources to manage them, so involving vendors 305 doesn't mean deploying more equipment, but improving automated 306 controls and the elimination of threats wherever possible. False 307 positives are still an issue, which can be problematic for some 308 automation activities. 310 2.2. Scaling Response to DDoS and Botnets Effectively and Safely 312 The first invited talk at the workshop provided an interesting 313 history of Distributed Denial of Service (DDoS) attacks and the 314 evolution of Botnets as well as the methods to combat these threats. 315 The paper by Dave Dittrich [DD1] is available to learn more of this 316 history: this section of the report will focus on the workshop 317 discussion in an effort to benefit from the workshop attendees 318 thoughts concerning how to better scale our response to these 319 threats. 321 Key points from the discussion: 323 o Of the attack types discussed, DDoS and Botnets appear to be the 324 furthest along in terms of efficient and effective response. 325 Other efforts can learn from this experience. There has not been 326 any interaction between these two attack types that may benefit 327 from information exchange tied to remediation activities since 328 Botnets can be the source of DDoS attacks. 330 o There is a disparity between short-term mitigation goals and 331 actual eradication of DDoS and Botnet threats. The question was 332 raised: how do we normalize the same data in different ways to 333 serve different goals? In other words, DDoS traffic is often the 334 result of Botnets, but the data is not shared between the service 335 providers and vendors responding to DDoS threats and those 336 actively mitigating and eradicating Botnets. 338 o There are ad-hoc trust groups within the OpSec community today: 339 CRAG is one example. 341 o Filtering and triage is an issue, but this is a solvable problem. 343 o The IETF DOTS working group was discussed and compared to a 344 previous effort, Real-time Inter-network defense (RID) [RFC6545]. 345 It was stated that the two are similar, except DOTS makes use of 346 current data formats and protocols and has the support of multiple 347 DDoS vendors. One of the goals of DOTS is to have this solution 348 be the "glue" between vendors to communicate shared data using 349 standard formats and protocols developed in open source tools. 351 o The IETF I2NSF effort was discussed to explore ways to leverage 352 infrastructure to combat DDoS attacks. 354 o Vendors discussed existing capabilities for DDoS mitigation, while 355 data sharing groups discussed their mitigation activities related 356 to Botnets (see the submissions under the heading 'Panel on 357 Scaling Attack Response for DDoS and BotNets' in the workshop 358 agenda [AGENDA]). 360 o Trust and reputation of data sources is still a concern. 362 o One of the exchange groups has a goal of "automated takedowns" for 363 Botnets. However, they think they will always have a need for 364 manual intervention. 366 o The need for multiple levels of trust seemed to be prevalent among 367 those participating in the panel discussion. Intelligence 368 agencies erode trust (this was also mentioned in the first panel 369 in terms of surveillance activities from governments). 371 o Although trust was discussed in this panel and there are concerns, 372 it was noted that trust is not as big a barrier for DDoS and 373 botnet mitigation and this is likely due to the operational 374 experience of the participants. 376 2.3. DNS & RIRs: Attack Response and Mitigation 378 This session was a shift from other sessions in the day as the 379 panelists were infrastructure providers for those combating attacks. 380 This session was of interest to see how attack and incident 381 responders could better collaborate with DNS infrastructure 382 organisations and RIRs. These groups have not interacted in the past 383 and it was interesting to see the collaboration opportunities since 384 the workshop participants rely on these services to do their jobs. 385 From the panelists perspective, DNS and RIRs are separate worlds, 386 where they spend a lot of time trying to educate policymakers about 387 how they work together to make the Internet work. 389 Key discussion points: 391 o The use of passive DNS in attack mitigation was described. 393 o RIRs discussed the data they maintain and provide, including 394 worldwide BGP update data and root DNS server data. These 395 datasets are available to share with researchers and could be of 396 interest to those working on attack response. The current way the 397 data is made available does not scale and ideas were discussed in 398 the workshop to improve the scalability should this become a more 399 widely used resource. 401 o Some of the global RIRs already actively coordinate with incident 402 responders in their region. In some cases they do facilitate 403 information sharing as well as provide education and training. 404 Data shared out by RIRs is anonymized. 406 o A concern was raised regarding overlapping efforts and a request 407 was made for the IETF and ISOC to pay attention to this and help. 408 This workshop was one step toward that in bringing together this 409 diverse community. The participants wished to see this type of 410 event repeated for future cross area collaboration between the 411 diverse set of groups that often only meet within their silo. 413 o Standards for APIs to access data consistently from RIRs and 414 scoring methods were discussed as possible ways to scale trust. 415 Questions were raised as to how this might be possible. One might 416 receive unverifiable data about a network. They may be able to 417 verify the source's identity, verify route origins, but won't be 418 able to verify the provenance of data. 420 2.4. Trust Privacy and Data Markings Panel 422 Why don't organizations share data? It seems to be a mix of privacy, 423 legal, technical/mundane, cultural, and communication issues. There 424 are also concerns about sharing proprietary data with competitors. 425 Having said that, most of these reasons were dismissed as bogus by 426 the more operationally focused participants in the workshop. Lawyers 427 need contextual education for the intersection of law and technology. 428 Sensitive data is still an issue as one can't control what others do 429 with data once it is shared. 431 Key points from the panel discussion: 433 o Operationally focused groups do retain/rate/re-mark confidence 434 levels based upon the submitter's reputation. 436 o The Traffic Light Protocol (TLP) [TLP] was discussed. While TLP 437 is useful to some groups who exchange data, others find that it is 438 not granular enough for their needs. 440 o In many cases when data is shared the user never knows, and there 441 is no way to manage that disclosure. 443 o Trust is personal. When sharing circles get too large, trust 444 breaks down. The personal relationship aspect of information 445 sharing communities was emphasized by several who are actively 446 exchanging data. This was a very prevalent theme. 448 o A point of comparison was made with consumer goods and it was 449 observed that trademarks are a byproduct of the Industrial 450 Revolution. The question was raised: does trust need branding? 452 o Participants observing noted that there appear to be cabals 453 operating the groups based on the current trust notions. This was 454 not disputed. 456 o Transparency is vital to maintain trust. 458 o Participants working on automation have found a need to share with 459 organizations of all sizes as well as a need to share both 460 synchronously and asynchronously. In an automated model, they 461 must ensure data sources are 'authorized' and these efforts have 462 encountered questions about anonymization as well as regional 463 regulatory perspectives as they vary. 465 o Another automation effort found that people have different upper 466 limits for trust group scale, which is sometimes based on 467 individualized knowledge of other participants and having a 468 comfort level with them. Social interaction (beer) is a common 469 thread amongst sharing partners to build trust relationships. The 470 relationships are formed between individuals and not necessarily 471 between organizations. 473 o It's rare for any single piece of information to be clearly 474 identifiable as private or public. The temptation is to say 475 information isn't personally identifiable information (PII). In 476 aggregate, however, non-PII can become PII. 478 o There was common agreement that reputation is fundamental. 480 3. Workshop Themes 482 During the course of the day, a couple of themes recurred in the 483 discussions. Firstly, in order to better scale attack response 484 through improvements to the efficiency and effectiveness of 485 information exchanges: 487 1. Data exchanges should not be just for the purpose of creating 488 blacklists that could be redundant efforts. 490 2. Involving service providers and vendors to better coordinate and 491 scale response is key. 493 Secondly, information security practitioners are a scarce resource: 495 1. Training and education was discussed to improve this gap, both to 496 train information security professionals and others in IT on 497 basic network and system hygiene. 499 2. Leveraging resources to better scale response, using fewer 500 resources is critical. 502 4. Next Steps 504 4.1. RIR and DNS Provider Resources 506 Workshop participants expressed an interest in expanded information 507 on the resources and assistance offered by the RIRs and DNS 508 providers. Participants are going to define what is needed. 510 4.2. Education and Guidance 512 Another reccurring theme was the lack of knowledge in the community 513 of basic security principles such as ingress and egress filtering 514 explained in BCP38 [RFC2827]. The CSIRTS, operators, and vendors of 515 attack mitigation tools found this particularly frustrating. As a 516 result, follow up activities may include determining if security 517 guidance BCPs require updates or to determine whether there are 518 opportunities to educate people on these basic principles already 519 documented by the IETF. 521 4.3. Transport Options 523 One of the more lively discussions was the need for better transports 524 for information exchange. Real-time Inter-network Defense (RID) 525 [RFC6545] was written more than 10 years ago. While the patterns 526 established in RID still show promise, there are updated solutions 527 being worked on. One such solution is in the IETF DOTS working 528 group, that has an approach similar to RID with updated formats and 529 protocols to meet the demands of todays DDoS attacks. While TAXII 530 (another transport option) is just in transition to OASIS, its base 531 is similar to RID in its use of SOAP-like messaging, which will 532 likely prevent it from scaling to the demands of the Internet. 533 Vendors also cited several interoperability challenges of TAXII in 534 workshop discussions. Alternatively, XMPP-Grid has been proposed in 535 the IETF SACM working group and it offers promise as the data 536 exchange protocol for deployment at scale. XMPP [RFC6120] inherently 537 meets the requirements for today's information exchanges with 538 features such as publish/subscribe, federation, and use of a control 539 channel. XMPP-Grid is gaining traction with at least 10 vendors 540 using it in their products and several more planning to add support 541 [I-D.appala-mile-xmpp-grid]. Review and discussion of this draft 542 would be helpful as it transitions to the MILE working group as an 543 outcome of the workshop. REST was also brought up as a needed 544 interface because of the low barrier to use [REST]. The IETF MILE 545 Working Group has discussed a draft detailing a common RESTful 546 interface (ROLIE) that could be used with any data format and this 547 may also be of interest [I-D.ietf-mile-rolie]. 549 4.4. Updated Template for Information Exchange Groups 551 One of the submission options was for organizations actively 552 exchanging data to submit a form describing their work to reduce 553 computer security incidents. The CSIRTs, in particular, liked having 554 access to this information in a neutral location like the Internet 555 Society. However, they wanted to see amendments to the format to 556 improve its usefulness. There was a desire to have this used by 557 additional information exchange groups, thereby creating a living 558 library to improve awareness of how to become a member, benefit from, 559 or contribute to the success of the attack response and CSIRT 560 information exchange platforms. 562 5. Security Considerations 564 The CARIS workshop was focused on security and methods to improve the 565 effectiveness and efficiency of attack response to enable better 566 scaling. This report provides a summary of the workshop discussions 567 and identifies some outcomes to improve security. As such, no 568 additional considerations are provided in this section. 570 6. Informative References 572 [AGENDA] "Agenda: Coordinating Attack Response at Internet Scale 573 (CARIS) Workshop", 2015, 574 . 576 [APWG] "APWG Homepage", 2015, . 578 [CERT.BR] "Brazilian National Computer Emergency Response Team 579 Homepage", 2015, . 581 [CERTCC] "CERT Coordination Center Homepage", 2015, 582 . 584 [DD1] Dittrich, D., "Taking Down Botnets - Background", April 585 2015, . 588 [ENISA] "European Union Agency for Network and Information 589 Security Homepage", 2015, . 591 [I-D.appala-mile-xmpp-grid] 592 Cam-Winget, N., Appala, S., and S. Pope, "XMPP Protocol 593 Extensions for Use with IODEF", draft-appala-mile-xmpp- 594 grid-00 (work in progress), October 2015. 596 [I-D.ietf-mile-rolie] 597 Field, J., "Resource-Oriented Lightweight Indicator 598 Exchange", draft-ietf-mile-rolie-01 (work in progress), 599 December 2015. 601 [ISOC] "CARIS Workshop Template Submissions", 2015, 602 . 605 [KME1] Moriarty, K., "Transforming Expectations for Threat- 606 Intelligence Sharing", August 2013, 607 . 610 [KME2] Moriarty, K., "Kathleen Moriarty Blog Series", July 2015, 611 . 613 [MYCERT] "Malaysia Computer Emergency Response Team Homepage", 614 2015, . 616 [REN-ISAC] 617 "Research and Education Networking Information Sharing and 618 Analysis Center Homepage", 2015, . 620 [REST] Fielding, R., "Architectural Styles and the Design of 621 Network-based Software Architectures", Ph.D. Dissertation, 622 University of California, Irvine, 2000, 623 . 626 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 627 Defeating Denial of Service Attacks which employ IP Source 628 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 629 May 2000, . 631 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 632 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 633 March 2011, . 635 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 636 RFC 6545, DOI 10.17487/RFC6545, April 2012, 637 . 639 [TLP] "Traffic Light Protocol (TLP) Matrix and Frequently Asked 640 Questions", 2015, . 642 Appendix A. Acknowledgements 644 Thanks are due to the members of the program committee (in 645 alphabetical order) for their efforts to make the CARIS workshop 646 possible and a productive session with cross area expertise: Matthew 647 Ford (Internet Society, UK), Ted Hardie (Google, USA), Joe Hildebrand 648 (Cisco, USA), Eliot Lear (Cisco, Switzerland), Kathleen M. Moriarty 649 (EMC Corporation, USA), Andrew Sullivan (Dyn, USA), Brian Trammell 650 (ETH Zurich, Switzerland). 652 Thanks are also due to the CARIS workshop sponsors: 654 o FIRST provided a room and excellent facilities in partnership with 655 their annual conference in Berlin. 657 o The Internet Society hosted the social event, a boat ride through 658 the canals of Berlin. 660 o EMC Corporation provided lunch, snacks and coffee throughout the 661 day to keep the attendees going. 663 Appendix B. Workshop Attendees 665 In alphabetical order by first name, workshop attendees were: Adli 666 Wahid, Alexey Melnikov, Andrew Sullivan, Arnold Sykosch, Brian 667 Trammell, Chris Morrow, Cristine Hoepers, Dario Forte, Dave Cridland, 668 Dave Dittrich, Eliot Lear, Foy Shiver, Frank Xialiang, Graciella 669 Martinez, Jessica Stienberger, Jim Duncan, Joe Hildebrand, John Bond, 670 John Graham-Cummings, John Kristoff, Kathleen Moriarty, Klaus 671 Steding-Jessen, Linda Dunbar, Marco Obiso, Martin Stiemerling, Mat 672 Ford, Merike Kaeo, Michael Daly, Mio Suzuki, Mirjam Kuehne, Mr. Fu 673 TianFu , Nancy Cam-Winget, Nik Teague, Pat Cain, Roland Dobbins, 674 Roman Danyliw, Rosella Mattioli, Sandeep Bhatt , Scott Pinkerton, 675 Sharifah Roziah Mohd Kassim, Stuart Murdoch, Takeshi Takahashi, Ted 676 Hardie, Tobias Gondrom, Tom Millar, Tomas Sander, Ulrich 677 Seldeslachts, Valerie Duncan, Wes Young 679 Authors' Addresses 681 Kathleen M. Moriarty 682 EMC Corporation 683 176 South Street 684 Hopkinton, MA 685 United States 687 Email: Kathleen.Moriarty@emc.com 689 Mat Ford 690 Internet Society 691 Galerie Jean-Malbuisson 15 692 Geneva 693 Switzerland 695 Email: ford@isoc.org