idnits 2.17.1 draft-moriarty-caris2-00.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 abstract seems to contain references ([CARISEvent]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2019) is 1808 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CARISEvent' is mentioned on line 647, but not defined == Missing Reference: 'SMART' is mentioned on line 655, but not defined == Missing Reference: 'MISP' is mentioned on line 652, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Moriarty 3 Internet-Draft DellEMC 4 Intended status: Informational May 14, 2019 5 Expires: November 15, 2019 7 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop 8 Report 9 draft-moriarty-caris2-00 11 Abstract 13 The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop 14 workshop [CARISEvent], sponsored by the Internet Society, took place 15 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. 16 Participants spanned regional, national, international, and 17 enterprise CSIRTs, operators, service providers, network and security 18 operators, transport operators and researchers, incident response 19 researchers, vendors, and participants from standards communities. 20 This workshop continued the work started at the first CARIS workshop, 21 with a focus for CARIS 2 on scaling incident prevention and detection 22 as the Internet industry moves to stronger and a more ubiquitous 23 deployment of session encryption. 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 https://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 November 15, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 (https://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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Accepted Papers . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. CARIS2 Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Workshop Collaboration . . . . . . . . . . . . . . . . . . . 4 64 5.1. Breakout 1 Results: Standardization and Adoption . . . . 5 65 5.2. Breakout 2 Results:Preventative Protocols and Scaling 66 Defense . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.3. Breakout 3 Results: Incident Response Coordination . . . 8 68 5.4. Breakout 4 Results: Monitoring and Measurement . . . . . 10 69 5.5. Taxonomy and Gaps Session . . . . . . . . . . . . . . . . 11 70 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11.1. Informative References . . . . . . . . . . . . . . . . . 14 77 11.2. URL References . . . . . . . . . . . . . . . . . . . . . 14 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 79 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 The Coordinating Attack Response at Internet Scale (CARIS) 2 85 workshop, sponsored by the Internet Society, took place 28 February ? 86 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned 87 regional, national, international, and enterprise CSIRTs, operators, 88 service providers, network and security operators, transport 89 operators and researchers, incident response researchers, vendors, 90 and participants from standards communities. This workshop continued 91 the work started at the first CARIS workshop RFC8073 [RFC8073], with 92 a focus for CARIS 2 on scaling incident prevention and detection as 93 the Internet industry moves to stronger and a more ubiquitous 94 deployment of session encryption. Considering the related initiative 95 to from a research group SMART [SMART] in the Internet Research Task 96 Force (IRTF) the focus on prevention included consideration of 97 research opportunities to improve protocols and determine if there 98 are ways to detect attacks using protocol design ideas that could 99 later influence protocol development in the IETF. This is one way to 100 think about scaling response, through prevention and allowing for new 101 methods to evolve for detection in a post-encrypted world. 103 2. Conventions 105 3. Accepted Papers 107 Researchers from around the world submitted position and research 108 papers summarizing key aspects of their work to help form the shared 109 content of the workshop. The accepted papers included: 111 Visualizing Security Automation: Takeshi Takahashi, NICT, Japan 113 Automating Severity Determination: Hideaki Kanehara, NICT, Japan 115 OASIS's OpenC2, Draper and DoD 117 Automated IoT Security (PASC and PAVA): Oscar Garcia-Morchon and 118 Thorsten Dahm 120 Taxonomies and Gaps: Kirsty P., UK NCSC 122 FIRST: Thomas Schreck, Siemens 124 NetSecWarriors: Tim April, Akamai 126 Measured Approaches to IPv6 Address Anonymization and Identity 127 Association: Dave Plonka and Arthur Berger, Akamai 129 The program committee worked to fill in the agenda with meaningful 130 and complementary sessions to round out the theme and encourage 131 collaboration to advance research towards the goals of the workshop. 132 These sessions included: 134 Manufacturer Usage Description (MUD) [RFC8520]: Eliot Lear, Cisco 136 TF-CSIRT: Mirjam Kuhne, RIPE NCC 138 M2M Sharing Revolution, Scott Pinkerton, DoE ANL 140 Comparing OpenC2 with existing efforts, e.g. I2NSF: Chris Inacio 142 Alternate Sharing and Mitigation Models: Kathleen Moriarty, 143 DellEMC 145 The presentations provided interesting background to familiarize 146 workshop attendees with current research work, challenges that 147 require addressing for forward progress, and opportunities to 148 collaborate in the desire to better scale attack response and 149 prevention. 151 4. CARIS2 Goals 153 The goal of each CARIS workshop has been to focus on the challenge of 154 scaling attack response because of the overall concern in industry on 155 the lack of information security professionals to fill the job gap. 156 Currently, there is a 2 million person deficit for security 157 professionals worldwide and it's only expected to grow. The chair's 158 belief is that this gap cannot be filled through training, but the 159 gap requires measures to reduce the number of information security 160 professionals needed through new architectures and research towards 161 attack prevention. CARIS 2 was specifically focused on the industry 162 shift towards the increased use of stronger session encryption 163 (TLSv1.3, QUIC, TCPcrypt, etc.) and how prevention and detection can 164 advance in this new paradigm. As such the goals for this workshop 165 included: 167 o Scale attack response, including ways to improve prevention, as 168 the Internet shifts to use of stronger and more ubiquitous 169 encryption. 171 o 173 * Determine research opportunities 175 * Consider methods to improve protocols/provide guidance toward 176 goal. For instance, are there ways to build detection of 177 threats into protocols since they cannot be monitored on the 178 wire in the future? 180 o Identify promising research ideas to seed a research agenda to 181 input to the proposed IRTF SMART research group. 183 5. Workshop Collaboration 185 Both CARIS workshops have brought together a unique set of 186 individuals who have not previously had the chance to be in the same 187 room or collaborate toward the goals of scaling attack response. 188 This is important as the participants span various areas of Internet 189 technology work, research, provide a global perspective, have access 190 to varying data sets and infrastructure, and are influential in their 191 area of expertise. The specific goals of the CARIS 2 workshop, 192 contributions, and the participants were all considered in the design 193 of the breakout sessions to both identify and advance research 194 through collaboration. The breakout sessions varied in format to 195 keep attendees engaged and collaborating, involving the full set of 196 attendees and breakout groups. 198 5.1. Breakout 1 Results: Standardization and Adoption 200 The goal of this session was to consider points raised in the talks 201 that preceded the breakout on hurdles for automating security 202 controls, detection, and response as the teams presenting noted 203 several challenges they still face today. The collaborative session 204 worked toward identifying standard protocols and data formats that 205 succeeded in achieving adoption and several that have failed or only 206 achieved limited adoption. The breakout teams selected protocols 207 that failed and were successful for group discussion and the results 208 from their evaluation were interesting and could help advance work in 209 these or related areas if considered further. 211 Wide adoption: 213 Secure Sockets Layer (SSL), now replaced by Transport Layer Security 214 (TLS) protocol. 216 Observations: There was a clear need for session encryption at the 217 transport layer to protect application data. eCommerce was a driving 218 force at the time with a downside to those who did not adopt. Other 219 positive attributes that aided adoption were modular design, clean 220 interfaces, and being first to market. 222 Simple Network Management Protocol (SNMP) enables configuration 223 management of devices with extension points for private configuration 224 and management settings. SNMP is widely adopted and is only now 225 after decades being replaced by a newer alternative, YANG. SNMP was 226 also first to market, with no competition. The protocol facilitated 227 an answer to a needed problem set: configuration, telemetry, and 228 network management. It's development considered the connection 229 between the user, vendor, and developers. Challenges did surface for 230 adoption of SNMPv1.1 and 1.2, there was no compelling reason for 231 adoption. SNMPv3 gained adoption due to its resilience to attacks by 232 providing protection through improved authentication and encryption. 234 IP Flow Information Export (IPFix) was identified as achieving wide 235 adoption for several reasons. The low cost of entry, wide vendor 236 support, diverse user base, and the wide set of use cases spanning 237 multiple technology areas were some of the key drivers cited. 239 X.509 was explored for its success in gaining adoption. The solution 240 being abstract from crypto, open, customizable, and extensible were 241 some of the reasons cited for its successful adoption. The team 242 deemed it a good solution to a good problem and observed that 243 government adoption aided its success. 245 Next each team evaluated solutions that have not enjoyed wide 246 adoption. 248 Although STIX and IODEF are somewhat similar in their goals, the 249 standards were selected for evaluation by two separate groups with 250 some common findings. 252 STIX has had limited adoption by the financial sector, but no single, 253 definitive end user. The standard is still in development with the 254 US government as the primary developer in partnership with OASIS. 255 There is interest in using STIX to manage content, but users don't 256 really care about what technology is used for the exchange. The 257 initial goals may not wind up matching the end result for STIX as 258 managing content may be the primary use case. 260 Incident Object Description Exchange Format (IODEF) was specified by 261 NRENs and CSIRTs and formalized in the IETF. The user is the 262 Security Operations Center (SOC). While there are several 263 implementations, it is not widely adopted. In terms of exchange, 264 users are more interested in indicators than full event information 265 and this applies to STIX as well. Sharing and trust are additional 266 hurdles as many are not willing to disclose information. 268 DNS-based Authentication of Named Entities (DANE) has DNSsec as a 269 dependency, which is a hurdle towards adoption (too many 270 dependencies). It has a roll-your-own adoption model, which is 271 risky. While there are some large pockets of adoption, there is 272 still much work to do to gain widespread adoption. A regulatory 273 requirement gave rise to partial adoption in Germany, which naturally 274 resulted in production of documentation written in German - possibly 275 giving rise to further adoption in German-speaking countries. There 276 has also been progress made in the Netherlands through the creation 277 of a website, internet.nl. The website allows you you to test your 278 website for a number of standards (IPv6, DNSSEC, DANE etc.). 279 Internet.nl is a collaboration of industry organizations, companies, 280 and the government in the Netherlands, and is available for worldwide 281 use. 283 IP version 6 (IPv6) has struggled and the expense of running a dual 284 stack was one of the highest concerns on the list. The end user 285 being everyone was too ambiguous. Too many new requirements have 286 been added over its 20 year life. The scope of necessary adoption is 287 large with many peripheral devices. Government requirements for 288 support have helped somewhat with improved interoperability and 289 adoption, but features like NAT being added to IPv4 slowed adoption. 290 With no new features being added to IPv4 and lessons learned, there's 291 still a possibility for success. 293 5.2. Breakout 2 Results:Preventative Protocols and Scaling Defense 295 This next breakout followed the sessions on MUD, PAVA (Protocol for 296 Automated Vulnerability Assessment), and PASC (Protocol for Automatic 297 Security Configuration) which have themes of automation at scale. 298 MUD was designed for IoT and as such, scaling was a major 299 consideration. The PAVA and PASC work builds off of MUD and 300 maintains some of the same themes. This next breakout was focused on 301 groups brainstorming on preventative measures and enabling vendors to 302 deploy mitigations. 304 One group dove a bit deeper into MUD and layer 2 (L2) discovery. 305 While the overall value of MUD, shifting the majority of control 306 management to the vendor for a predictable platform scales well, the 307 use of MUD and what traffic is expected for a particular device is 308 sensitive information as it could be used to exploit a device. MUD 309 has an option of using L2 discovery to share MUD files. L2 310 discovery, like the dynamic host configuration protocol (DHCP) is not 311 encrypted from the local client to the DHCP server at this point in 312 time (there is some interest to correct this, but it hasn't received 313 enough support yet). As a result, it is possible to leak information 314 and reveal data about the devices for which the MUD files would be 315 applied. This could multicast out information such as network 316 characteristics, firmware versions, manufacturer, etc. There was 317 some discussion on the use of 802.11 to improve connections. Several 318 participants from this group planned to research this further and 319 identify options to prevent information leakage while achieving the 320 stated goals of MUD. 322 The next group discussed a proposal one of the participants had 323 already begun developing, namely privacy for rendezvous service. The 324 basic idea was to encrypt SNI using DNS to obtain public keys. The 325 suffix on server IPv6 would be unique to a TLS session (Information 326 missing). The discussion on this proposal was fruitful as the full 327 set of attendees engaged, with special interest from the incident 328 responders to be involved in early review cycles. Incident 329 responders are very interested to understand how protocols will 330 change and to assess the overall impact of changes on privacy and 331 security operations. Even if there are no changes to the protocol 332 proposals stemming from this review, the group discussion landed on 333 this being a valuable exchange to understand early the impacts of 334 changes for incident detection and mitigation, to devise new 335 strategies and to provide assessments on the impact of protocol 336 changes on security in the round. 338 The third group reported back on trust exchanges relying heavily on 339 relationships between individuals. They were concerned with scaling 340 the trust model and finding ways to do that better. The third 341 breakout dove deeper into this topic. 343 The forth breakout group discussed useful data for incident 344 responders. This built on the first breakout session. The group 345 determined that indicators of compromise (IOCs) are what most 346 organizations and groups are able to successfully exchange. Ideally, 347 these would be fixed and programmable. They discussed developing a 348 richer event threat sharing format. When reporting back to the 349 group, a successful solution used in the EU was mentioned, Malware 350 Information Sharing Platform (MISP) [MISP]. This will be considered 351 in their review of existing efforts to determine if anything new is 352 needed. 354 5.3. Breakout 3 Results: Incident Response Coordination 356 Incident response coordination currently does not scale. This 357 breakout session focused on brainstorming on incident response and 358 coordination, looking specifically at what works well for teams 359 today, what is holding them back, and what risks loom ahead. Output 360 from this session could be used to generate research and to dive 361 deeper in a dedicated workshop on these topics. 363 Supporting: 365 o Trust in incident response teams 367 o Volume of strong signals and automated discovery 369 o Need to protect network as a forcing function 371 o Law and legal catalyst, motivator to stay on top 373 o Current efforts supported by profit and company interests, but 374 those may shift 376 o FEAR provides an initially a burst of wind, but eventually leads 377 to complacency 379 Creating Drag: 381 o Lack of clear KPIs 383 o Too many standards 385 o Regional border impact data flows 386 o Ease of use for end users 388 o Speed to market without security considerations 390 o Legal framework slow to adapt 392 o Disconnect in actual/perceived risk 394 o Regulatory requirements preventing data sharing 396 o Lack of clarity in shared information 398 o Behind the problem/reactionary 400 o Lack of resources/participation 402 o Monoculture narrows focus 404 Looming problems: 406 o Dynamic threat landscape 408 o Liability 410 o Vocabulary collision 412 o Lack of target/adversary clarity 414 o Bifurcation of Internet 416 o Government regulation 418 o Confusion around metrics 420 o Sensitivity of intelligence (trust) 422 o Lack of skilled analysts 424 o Lack of "fraud loss" data sharing 426 o Stakeholder/leader confusion 428 o Unknown impact of emerging technologies 430 o Over-centralization of the Internet 432 o New technologies and protocols 433 o Changes in application layer configurations (e.g. browser 434 resolvers) 436 5.4. Breakout 4 Results: Monitoring and Measurement 438 The fourth breakout followed Dave Plonka's talk on IPv6 aggregation 439 to provide privacy for IPv6 sessions. Essentially, IPv6 provides 440 additional capabilities for monitoring sessions end-to-end. Dave and 441 his co-author Arthur Berger primarily focus on measurement research, 442 but found a way to aggregate sessions to assist with maintaining user 443 privacy. If you can devise methods to perform management and 444 measurement, or even perform security functions, while accommodating 445 methods to protect privacy, a stronger result is likely. This also 446 precludes the need for additional pro-privacy work to defeat 447 measurement objectives. 449 This breakout was focused on devising methods to perform monitoring 450 and measurement, coupled with advancing privacy considerations. The 451 full group listed out options for protocols to explore and ranked 452 them, with the 4 highest then explored by the breakout groups. 453 Groups agreed to work further on the proposed ideas, hopefully 454 bringing ongoing work into the proposed SMART [SMART] research group 455 effort. 457 IP Reputation 459 This idea would be based on IP reputation for IPv6 addresses, where 460 you could have end-to-end visibility. Although the team agreed this 461 idea is complicated, it is one they wanted to pursue. One 462 participant had an identified need for this service, which is needed 463 to drive the idea forward. They also have access to data to help 464 make this possible. There are clear gaps in visibility that present 465 challenges, some include mobile networks and blocked regions such as 466 China. An audit requirement and ability to correct entries would be 467 necessary. BGP rankings could be part of this solution. This is an 468 early idea, the lead to contact if interested to help develop this 469 further is Dave Plonka. 471 Server Name Authentication Reputation C (SNARC) 473 SNARC is a mechanism to assign value to trust indicators, used to 474 make decisions about good or bad actors. The mechanism would be able 475 to distinguish between client and server in connections, would be 476 human readable, builds on zero trust networking, and avoids 477 consolidation supporting legitimate new players. The group planned 478 to research visual aspects and underlying principles as they begin 479 work on this idea. SNARC has a similar theme to the IP reputation/ 480 BGP ranking idea mentioned above. An RFC would help customers and 481 design team on existing solutions. They planned to begin work in 482 several stages, researching "trust" indicators, "trust" value 483 calculations, and research actions to apply to "trust". The 484 overarching goal is to address blind trust, one of the challenges 485 identified with information/incident exchanges. If interested to 486 work further with this team, the lead contact is: Trent Adams. 488 Logging 490 The breakout group presented the possibility of injecting logging 491 capabilities at compile time for applications, resulting in a more 492 consistent set of logs, covering an agreed set of conditions. If the 493 log-injecting compiler were used this would increase logging for 494 those applications and improve the uniformity of logged activity. 495 Increasing logging capabilities at the endpoint is necessary as the 496 shift towards increased use of encrypted transport continues. The 497 lead for contact if interested to develop this further is Nalini 498 Elkins. 500 Fingerprinting 502 Fingerprinting has been used for numerous applications on the web, 503 including security, and will become of increasing importance with the 504 deployment of stronger encryption. This provides a method to 505 identify traffic without using decryption. The group discussed 506 privacy considerations and balancing how you achieve the security 507 benefits (identifying malicious traffic, information leakage, threat 508 indicators, etc.). They are interested to derive methods to validate 509 the authenticity without identifying the source of traffic. They are 510 also concerned with scaling issues. If interested to work further 511 with this team, the lead contact is: William Weinstein. 513 5.5. Taxonomy and Gaps Session 515 At the start of day 2, Kirsty Paine and Mirjam Kuhne prepared and 516 Kirsty led a workshop style session to discuss taxonomies used in 517 incident response, attacks, and threat detection, comparing solutions 518 and identifying gaps. The primary objective was to determine a path 519 forward selecting language to be used in the proposed SMART group. 520 Several taxonomies were presented for review and discussion. The 521 topic remains open, the following key points were highlighted by 522 participants: 524 o A single taxonomy might not be the way to go, because which 525 taxonomy you use depends on what problem you are trying to solve; 526 e.g. attribution of the attack, mitigation steps, technical 527 features or organizational impact measurements. 529 o A tool to map between taxonomies should be automated as there are 530 requirements within groups or nations to use specific taxonomies. 532 o The level of detail needed for reporting to management and for the 533 analyst investigating the incident can be very different. At the 534 workshop, one attendee mentioned that for management reporting 535 they only use 8 categories to lighten the load on analysts, 536 whereas some of the taxonomies contain 52 categories. 538 o How you plan to use the taxonomy matters and may vary between use 539 cases. Take for instance sharing data with external entities 540 versus internal only. The taxonomy selected depends on what you 541 plan to do with it. Some stated a need for attribute-based 542 dynamic anthologies as opposed to rigid taxonomies used by others. 543 A rigid taxonomy did not work for many from feedback in the 544 session. 546 o RFC4949 was briefly discussed as a possibility, however there is a 547 clear need to update terminology in this publication around this 548 space in particular. This is likely to be raised in SAAG, 549 hopefully with proposed new definitions to demonstrate the issue 550 and evolution of terms over time. 552 o Within a taxonomy, prioritization matters to understand the impact 553 of threats or an attack. How do you map that between differing 554 taxonomies? (problem to be solved; possible tooling required) 556 o Attack attribution had varying degrees of interest. Some felt the 557 public sector cared more about attribution; not about individuals, 558 but the possible motivations behind an attack and likely other 559 victims based on these motivations. Understanding if the source 560 was an individual actor, organized crime, or a nation state 561 mattered. 563 The result of this discussion was not to narrow down to one taxonomy, 564 but to think about mappings between taxonomies and the use cases for 565 exchanging or sharing information, eventually giving rise to a common 566 method to discuss threats and attacks. Researchers need a common 567 vocabulary, not necessarily a common taxonomy. 569 6. Next Steps 571 The next steps from the CARIS workshop are twofold. The research 572 initiatives spawned from the second CARIS require further exploration 573 and development. Fostering this development and creating communities 574 around each proposed project is the first step, with reports back out 575 to the IRTF SMART mailing list and in a proposed research group. 577 The second initiative will be planning for the next CARIS workshop. 578 This is likely to be coupled with the FIRST Conference in 2020 geared 579 around a topic important to incident responders to assist with scale 580 as it relates directly to problems of interest to that community. 582 7. Summary 584 Wrapping up the workshop, we reviewed the list of agreed projects to 585 get a feel for actual interest in follow up now that a larger set had 586 been generated, giving participants a chance to reassess commitments 587 to better have them match actual outcomes. The highest ranking 588 projects in terms of interest to drive the ideas forward included the 589 following: 591 o Traffic fingerprinting 593 o SNARC 595 o Attack coordination solutions/automated security 597 o Cryptographic Rendezvous 599 o L2 discovery 601 8. Security Considerations 603 There are no security considerations as this is an informational 604 workshop summary report. 606 9. IANA Considerations 608 This memo includes no request to IANA. 610 10. Contributors 612 Thank you to each of the CARIS participants who brought their ideas, 613 energy and willingness to collaborate to advance attack response at 614 Internet scale. 616 A big thank you to each member of the program committee for your 617 review of program materials, papers, and guidance on the workshop 618 format: Mat Ford, Internet Society, UK, Jamie Gillespie, APNIC, AU, 619 Chris Inacio, CERT/CC, US, Mirja Kuhlewind, ETH Zurich, CH, Mirjam 620 Kuhne, RIPE NCC, NL, Carlos Martinez, LACNIC, UY, Kathleen M. 621 Moriarty, Dell EMC (Chair), Kirsty Paine, NCSC, UK, and Takeshi 622 Takahashi, NICT, JP. 624 Thank you to Megan Hyland, DellEMC, for her review and guidance on 625 the breakout session format and tools to enable successful 626 collaboration. 628 Thank you to the minute takers, Akashaya Khare and Thinh Nguyen, 629 DellEMC OCTO Cambridge Dojo team. 631 11. References 633 11.1. Informative References 635 [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at 636 Internet Scale (CARIS) Workshop Report", RFC 8073, 637 DOI 10.17487/RFC8073, March 2017, 638 . 640 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 641 Description Specification", RFC 8520, 642 DOI 10.17487/RFC8520, March 2019, 643 . 645 11.2. URL References 647 [CARISEvent] 648 Internet Society, "CARIS Event Information and Accepted 649 Papers https://www.internetsociety.org/events/caris2", 650 2019. 652 [MISP] MISP-project.org, "Malware Information Sharing Platform 653 https://www.misp-project.org/". 655 [SMART] IRTF, "Stopping Malware and Researching Threats 656 https://datatracker.ietf.org/group/smart/about/", 2019. 658 Appendix A. Change Log 660 Note to RFC Editor: if this document does not obsolete an existing 661 RFC, please remove this appendix before publication as an RFC. 663 Appendix B. Open Issues 665 Note to RFC Editor: please remove this appendix before publication as 666 an RFC. 668 Author's Address 670 Kathleen M Moriarty 671 DellEMC 672 176 South Street 673 Hopkinton 674 United States 676 EMail: kathleen.moriarty.ietf@gmail.com