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