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