idnits 2.17.1
draft-iab-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 (January 05, 2017) is 2660 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: July 9, 2017 Internet Society
6 January 05, 2017
8 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report
9 draft-iab-carisreport-02
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 July 9, 2017.
42 Copyright Notice
44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . 12
72 4.4. Updated Template for Information Exchange Groups . . . . 12
73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
74 6. Informative References . . . . . . . . . . . . . . . . . . . 13
75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
76 Appendix B. Workshop Attendees . . . . . . . . . . . . . . . . . 15
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] and [KME2] for additional
131 information on possible approaches to accomplish more effective
132 attack response and information exchanges with methods that require
133 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 leverages 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, despite lots of discussion there have not been useful
262 outcomes.
264 o There is more interest in consuming feeds of information than
265 sharing information.
267 o Ego has been a big issue for improving data sharing, as have
268 reputation-related concerns when sharing or receiving data.
270 o There is a perception of weakness around organizations who do
271 share attack information in some regions.
273 o Sharing in isolation doesn't help, it must lead to operational
274 return on investment.
276 o Language barriers have been an issue for some national CSIRTs.
278 o Sharing too much information leads to capacity and resource issues
279 for receiving organizations. Organizations directly receiving
280 feeds can often misinterpret data and think they are under attack
281 when it is not the case. Operational models are preferred where
282 data exchanges have a direct impact on improving the efficiency of
283 a small number of analysts to impact many.
285 o Privacy regulations restricting some organizations from sharing IP
286 address information have had an impact on the effectiveness of
287 incident data exchanges. ENISA is currently running a study on
288 this impact (this point was raised by several attendees).
290 o Too many efforts are using data just for blocking attacks and not
291 for operational mitigation and elimination of vulnerabilities as
292 part of their incident response effort. Note: Operational efforts
293 stand out in that they do eliminate threats and update data
294 warehouses.
296 o Involvement of vendors is needed to better scale attack response.
297 This is not seen as a need by all groups, but some sharing groups
298 with an operational focus are looking for improved efficiencies to
299 leverage a small number of analysts more productively. Analysts
300 are a limited resource in this technical area of expertise.
302 o Enterprises don't want more security boxes in their networks as
303 they don't have the resources to manage them, so involving vendors
304 doesn't mean deploying more equipment, but improving automated
305 controls and the elimination of threats wherever possible. False
306 positives are still an issue, which can be problematic for some
307 automation activities.
309 2.2. Scaling Response to DDoS and Botnets Effectively and Safely
311 The first invited talk at the workshop provided an interesting
312 history of Distributed Denial of Service (DDoS) attacks and the
313 evolution of botnets as well as the methods to combat these threats.
314 The paper by Dave Dittrich [DD1] is available to learn more of this
315 history: this section of the report will focus on the workshop
316 discussion in an effort to benefit from the workshop attendees'
317 thoughts concerning how to better scale our response to these
318 threats.
320 Key points from the discussion:
322 o Of the attack types discussed, DDoS and botnets appear to be the
323 furthest along in terms of efficient and effective response.
324 Other efforts can learn from this experience. There has not been
325 any interaction between these two attack types that may benefit
326 from information exchange tied to remediation activities since
327 botnets can be the source of DDoS attacks.
329 o There is a disparity between short-term mitigation goals and
330 actual eradication of DDoS and botnet threats. The question was
331 raised: how do we normalize the same data in different ways to
332 serve different goals? In other words, DDoS traffic is often the
333 result of botnets, but the data is not shared between the service
334 providers and vendors responding to DDoS threats and those
335 actively mitigating and eradicating botnets.
337 o There are ad-hoc trust groups within the OpSec community today:
338 the Cybercrime Response Advisory Group (CRAG) is one example.
340 o Filtering and triage is an issue, but this is a solvable problem.
342 o The IETF DDOS Open Threat Signaling (DOTS) working group was
343 discussed and compared to a previous effort, Real-time Inter-
344 network defense (RID) [RFC6545]. It was stated that the two are
345 similar, except DOTS makes use of current data formats and
346 protocols and has the support of multiple DDoS vendors. One of
347 the goals of DOTS is to have this solution be the "glue" between
348 vendors to communicate shared data using standard formats and
349 protocols developed in open source tools.
351 o The IETF Interface to Network Security Functions (I2NSF) effort
352 was discussed to explore ways to leverage infrastructure to combat
353 DDoS attacks.
355 o Vendors discussed existing capabilities for DDoS mitigation, while
356 data sharing groups discussed their mitigation activities related
357 to botnets (see the submissions under the heading 'Panel on
358 Scaling Attack Response for DDoS and BotNets' in the workshop
359 agenda [AGENDA]).
361 o Trust and reputation of data sources is still a concern.
363 o One of the exchange groups has a goal of "automated takedowns" for
364 botnets. However, they think they will always have a need for
365 manual intervention.
367 o The need for multiple levels of trust seemed to be prevalent among
368 those participating in the panel discussion. Intelligence
369 agencies erode trust (this was also mentioned in the first panel
370 in terms of surveillance activities from governments).
372 o Although trust was discussed in this panel and there are concerns,
373 it was noted that trust is not as big a barrier for DDoS and
374 botnet mitigation and this is likely due to the operational
375 experience of the participants.
377 2.3. DNS & RIRs: Attack Response and Mitigation
379 This session was a shift from other sessions in the day as the
380 panelists were infrastructure providers for those combating attacks.
381 This session was of interest to see how attack and incident
382 responders could better collaborate with DNS infrastructure
383 organisations and RIRs. These groups have not interacted in the past
384 and it was interesting to see the collaboration opportunities since
385 the workshop participants rely on these services to do their jobs.
386 From the panelists' perspective, DNS and RIRs are separate worlds,
387 where they spend a lot of time trying to educate policymakers about
388 how they work together to make the Internet work.
390 Key discussion points:
392 o The use of passive DNS in attack mitigation was described.
394 o RIRs discussed the data they maintain and provide, including
395 worldwide BGP update data and root DNS server data. These
396 datasets are available to share with researchers and could be of
397 interest to those working on attack response. The current way the
398 data is made available does not scale and ideas were discussed in
399 the workshop to improve the scalability should this become a more
400 widely used resource.
402 o Some of the global RIRs already actively coordinate with incident
403 responders in their region. In some cases they do facilitate
404 information sharing as well as provide education and training.
405 Data shared out by RIRs is anonymized.
407 o A concern was raised regarding overlapping efforts and a request
408 was made for the IETF and ISOC to pay attention to this and help.
409 This workshop was one step toward that in bringing together this
410 diverse community. The participants wished to see this type of
411 event repeated for future cross area collaboration between the
412 diverse set of groups that often only meet within their silo.
414 o Standards for APIs to access data consistently from RIRs and
415 scoring methods were discussed as possible ways to scale trust.
416 Questions were raised as to how this might be possible. One might
417 receive unverifiable data about a network. They may be able to
418 verify the source's identity, verify route origins, but won't be
419 able to verify the provenance of data.
421 2.4. Trust Privacy and Data Markings Panel
423 Why don't organizations share data? It seems to be a mix of privacy,
424 legal, technical/mundane, cultural, and communication issues. There
425 are also concerns about sharing proprietary data with competitors.
426 Having said that, most of these reasons were dismissed as bogus by
427 the more operationally focused participants in the workshop. Lawyers
428 need contextual education for the intersection of law and technology.
430 Sensitive data is still an issue as one can't control what others do
431 with data once it is shared.
433 Key points from the panel discussion:
435 o Operationally focused groups do retain/rate/re-mark confidence
436 levels based upon the submitter's reputation.
438 o The Traffic Light Protocol (TLP) [TLP] was discussed. While TLP
439 is useful to some groups who exchange data, others find that it is
440 not granular enough for their needs.
442 o In many cases when data is shared the user never knows, and there
443 is no way to manage that disclosure.
445 o Trust is personal. When sharing circles get too large, trust
446 breaks down. The personal relationship aspect of information
447 sharing communities was emphasized by several who are actively
448 exchanging data. This was a very prevalent theme.
450 o A point of comparison was made with consumer goods and it was
451 observed that trademarks are a byproduct of the Industrial
452 Revolution. The question was raised: does trust need branding?
454 o Participants observing noted that there appear to be cabals
455 operating the groups based on the current trust notions. This was
456 not disputed.
458 o Transparency is vital to maintain trust.
460 o Participants working on automation have found a need to share with
461 organizations of all sizes as well as a need to share both
462 synchronously and asynchronously. In an automated model, they
463 must ensure data sources are 'authorized' and these efforts have
464 encountered questions about anonymization as well as regional
465 regulatory perspectives as they vary.
467 o Another automation effort found that people have different upper
468 limits for trust group scale, which is sometimes based on
469 individualized knowledge of other participants and having a
470 comfort level with them. Social interaction (beer) is a common
471 thread amongst sharing partners to build trust relationships. The
472 relationships are formed between individuals and not necessarily
473 between organizations.
475 o It's rare for any single piece of information to be clearly
476 identifiable as private or public. The temptation is to say
477 information isn't personally identifiable information (PII). In
478 aggregate, however, non-PII can become PII.
480 o There was common agreement that reputation is fundamental.
482 3. Workshop Themes
484 During the course of the day, a couple of themes recurred in the
485 discussions. Firstly, in order to better scale attack response
486 through improvements to the efficiency and effectiveness of
487 information exchanges:
489 1. Data exchanges should not be just for the purpose of creating
490 blacklists that could be redundant efforts.
492 2. Involving service providers and vendors to better coordinate and
493 scale response is key.
495 Secondly, information security practitioners are a scarce resource:
497 1. Training and education was discussed to improve this gap, both to
498 train information security professionals and others in IT on
499 basic network and system hygiene.
501 2. Leveraging resources to better scale response, using fewer
502 resources is critical.
504 4. Next Steps
506 4.1. RIR and DNS Provider Resources
508 Workshop participants expressed an interest in expanded information
509 on the resources and assistance offered by the RIRs and DNS
510 providers. Participants are going to define what is needed.
512 4.2. Education and Guidance
514 Another recurring theme was the lack of knowledge in the community of
515 basic security principles such as ingress and egress filtering
516 explained in BCP38 [RFC2827]. The CSIRTs, operators, and vendors of
517 attack mitigation tools found this particularly frustrating. As a
518 result, follow up activities may include determining if security
519 guidance BCPs require updates or to determine whether there are
520 opportunities to educate people on these basic principles already
521 documented by the IETF.
523 4.3. Transport Options
525 One of the more lively discussions was the need for better transports
526 for information exchange. Real-time Inter-network Defense (RID)
527 [RFC6545] was written more than 10 years ago. While the patterns
528 established in RID still show promise, there are updated solutions
529 being worked on. One such solution is in the IETF DOTS working
530 group, that has an approach similar to RID with updated formats and
531 protocols to meet the demands of today's DDoS attacks. While Trusted
532 Automated eXchange of Indicator Information (TAXII - another
533 transport option) is just in transition to OASIS, its base is similar
534 to RID in its use of SOAP-like messaging, which will likely prevent
535 it from scaling to the demands of the Internet. Vendors also cited
536 several interoperability challenges of TAXII in workshop discussions.
537 Alternatively, XMPP-Grid has been proposed in the IETF Security
538 Automation and Continuous Monitoring (SACM) working group and it
539 offers promise as the data exchange protocol for deployment at scale.
540 XMPP [RFC6120] inherently meets the requirements for today's
541 information exchanges with features such as publish/subscribe,
542 federation, and use of a control channel. XMPP-Grid is gaining
543 traction with at least 10 vendors using it in their products and
544 several more planning to add support [I-D.appala-mile-xmpp-grid].
545 Review and discussion of this draft would be helpful as it
546 transitions to the Managed Incident Lightweight Exchange (MILE)
547 working group as an outcome of the workshop. REST was also brought
548 up as a needed interface because of the low barrier to use [REST].
549 The IETF MILE Working Group has discussed a draft detailing a common
550 RESTful interface (ROLIE) that could be used with any data format and
551 this may also be of interest [I-D.ietf-mile-rolie].
553 4.4. Updated Template for Information Exchange Groups
555 One of the submission options was for organizations actively
556 exchanging data to submit a form describing their work to reduce
557 computer security incidents. The CSIRTs, in particular, liked having
558 access to this information in a neutral location like the Internet
559 Society. However, they wanted to see amendments to the format to
560 improve its usefulness. There was a desire to have this used by
561 additional information exchange groups, thereby creating a living
562 library to improve awareness of how to become a member, benefit from,
563 or contribute to the success of the attack response and CSIRT
564 information exchange platforms.
566 5. Security Considerations
568 The CARIS workshop was focused on security and methods to improve the
569 effectiveness and efficiency of attack response to enable better
570 scaling. This report provides a summary of the workshop discussions
571 and identifies some outcomes to improve security. As such, no
572 additional considerations are provided in this section.
574 6. Informative References
576 [AGENDA] "Agenda: Coordinating Attack Response at Internet Scale
577 (CARIS) Workshop", 2015,
578 .
580 [APWG] "APWG Homepage", 2015, .
582 [CERT.BR] "Brazilian National Computer Emergency Response Team
583 Homepage", 2015, .
585 [CERTCC] "CERT Coordination Center Homepage", 2015,
586 .
588 [DD1] Dittrich, D., "Taking Down Botnets - Background", April
589 2015, .
592 [ENISA] "European Union Agency for Network and Information
593 Security Homepage", 2015, .
595 [I-D.appala-mile-xmpp-grid]
596 Cam-Winget, N., Appala, S., and S. Pope, "XMPP Protocol
597 Extensions for Use with IODEF", draft-appala-mile-xmpp-
598 grid-00 (work in progress), October 2015.
600 [I-D.ietf-mile-rolie]
601 Field, J., Banghart, S., and D. Waltermire, "Resource-
602 Oriented Lightweight Information Exchange", draft-ietf-
603 mile-rolie-03 (work in progress), July 2016.
605 [ISOC] "CARIS Workshop Template Submissions", 2015,
606 .
609 [KME1] Moriarty, K., "Transforming Expectations for Threat-
610 Intelligence Sharing", August 2013,
611 .
614 [KME2] Moriarty, K., "Kathleen Moriarty Blog Series", July 2015,
615 .
617 [MYCERT] "Malaysia Computer Emergency Response Team Homepage",
618 2015, .
620 [REN-ISAC]
621 "Research and Education Networking Information Sharing and
622 Analysis Center Homepage", 2015, .
624 [REST] Fielding, R., "Architectural Styles and the Design of
625 Network-based Software Architectures", Ph.D. Dissertation,
626 University of California, Irvine, 2000,
627 .
630 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
631 Defeating Denial of Service Attacks which employ IP Source
632 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
633 May 2000, .
635 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
636 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
637 March 2011, .
639 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
640 6545, DOI 10.17487/RFC6545, April 2012,
641 .
643 [TLP] "Traffic Light Protocol (TLP) Matrix and Frequently Asked
644 Questions", 2015, .
646 Appendix A. Acknowledgements
648 Thanks are due to the members of the program committee (in
649 alphabetical order) for their efforts to make the CARIS workshop
650 possible and a productive session with cross area expertise: Matthew
651 Ford (Internet Society, UK), Ted Hardie (Google, USA), Joe Hildebrand
652 (Cisco, USA), Eliot Lear (Cisco, Switzerland), Kathleen M. Moriarty
653 (EMC Corporation, USA), Andrew Sullivan (Dyn, USA), Brian Trammell
654 (ETH Zurich, Switzerland).
656 Thanks are also due to the CARIS workshop sponsors:
658 o FIRST provided a room and excellent facilities in partnership with
659 their annual conference in Berlin.
661 o The Internet Society hosted the social event, a boat ride through
662 the canals of Berlin.
664 o EMC Corporation provided lunch, snacks and coffee throughout the
665 day to keep the attendees going.
667 Appendix B. Workshop Attendees
669 In alphabetical order by first name, workshop attendees were: Adli
670 Wahid, Alexey Melnikov, Andrew Sullivan, Arnold Sykosch, Brian
671 Trammell, Chris Morrow, Cristine Hoepers, Dario Forte, Dave Cridland,
672 Dave Dittrich, Eliot Lear, Foy Shiver, Frank Xialiang, Graciella
673 Martinez, Jessica Stienberger, Jim Duncan, Joe Hildebrand, John Bond,
674 John Graham-Cummings, John Kristoff, Kathleen Moriarty, Klaus
675 Steding-Jessen, Linda Dunbar, Marco Obiso, Martin Stiemerling, Mat
676 Ford, Merike Kaeo, Michael Daly, Mio Suzuki, Mirjam Kuehne, Mr. Fu
677 TianFu , Nancy Cam-Winget, Nik Teague, Pat Cain, Roland Dobbins,
678 Roman Danyliw, Rosella Mattioli, Sandeep Bhatt , Scott Pinkerton,
679 Sharifah Roziah Mohd Kassim, Stuart Murdoch, Takeshi Takahashi, Ted
680 Hardie, Tobias Gondrom, Tom Millar, Tomas Sander, Ulrich
681 Seldeslachts, Valerie Duncan, Wes Young
683 Authors' Addresses
685 Kathleen M. Moriarty
686 Dell EMC Corporation
687 176 South Street
688 Hopkinton, MA
689 United States
691 Email: Kathleen.Moriarty@dell.com
693 Mat Ford
694 Internet Society
695 Galerie Jean-Malbuisson 15
696 Geneva
697 Switzerland
699 Email: ford@isoc.org