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