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