idnits 2.17.1 draft-moriarty-caris2-03.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 (19 May 2020) is 1428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 Summary: 0 errors (**), 0 flaws (~~), 2 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 19 May 2020 5 Expires: 20 November 2020 7 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop 8 Report 9 draft-moriarty-caris2-03 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 20 November 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 17 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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 detect attacks using protocol design ideas that could later influence 99 protocol development in the IETF. This is one way to think about 100 scaling response, through prevention and allowing for new methods to 101 evolve for detection in a post-encrypted world. Although SMART has 102 not progressed, the work to better scale incident response continues 103 through the projects proposed at CARIS2 as well in future CARIS 104 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 protection capabilities for improved defense, 158 automation, and scaling attack response through collaboration and 159 improved architectural patterns. It has been assumed that it is 160 unlikely that additional training will address the lack of 161 information security professionals to fill the job gap. the lack of 162 information security professionals to fill the job gap. Currently, 163 there is approximately a 3 million person deficit [defecit] for 164 security professionals worldwide and it's only expected to grow. In 165 preparing for the workshop, the chair and program committee 166 considered that this gap cannot be filled through training, but the 167 gap requires measures to reduce the number of information security 168 professionals needed through new architectures and research towards 169 attack prevention. CARIS 2 was specifically focused on the industry 170 shift towards the increased use of stronger session encryption 171 (TLSv1.3 [RFC8446], QUIC [I-D.ietf-quic-transport], TCPcrypt 172 [RFC8548], etc.) and how prevention and detection can advance in this 173 new paradigm. As such the goals for this workshop 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: brainstormon what potential areas 215 of research or future workshops could be held to improve on the 216 scalability of incident response. 218 4. Monitoring and Measurement:brainstorm on methods to perform 219 monitoring and measurement with the heightenedneed 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) [RFC6101], now replaced by Transport Layer 239 Security (TLS) protocol [RFC8446]. 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) [RFC3410] enables 248 configuration management of devices with extension points for private 249 configuration and management settings. SNMP is widely adopted and is 250 only now after decades being replaced by a newer alternative, YANG (a 251 data modeling language) facilitating configuration management via 252 NETCONF or RESTCONF. The SNMP protocol facilitated an answer to a 253 needed problem set: configuration, telemetry, and network management. 254 It's development considered the connection between the user, vendor, 255 and 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) [RFC7011] was identified as 261 achieving wide adoption for several reasons. The low cost of entry, 262 wide vendor support, diverse user base, and the wide set of use cases 263 spanning multiple technology areas were some of the key drivers 264 cited. 266 X.509 [RFC5280] was explored for its success in gaining adoption. 267 The solution being abstract from crypto, open, customizable, and 268 extensible were some of the reasons cited for its successful 269 adoption. The team deemed it a good solution to a good problem and 270 observed that government adoption aided its success. 272 4.1.2. Limited Adoption 274 Next each team evaluated solutions that have not enjoyed wide 275 adoption. 277 Although [STIX] and IODEF [RFC7970] are somewhat similar in their 278 goals, the standards were selected for evaluation by two separate 279 groups with some common findings. 281 *Structured Threat Information eXpression (STIX)* has had limited 282 adoption by the financial sector, but no single, definitive end user. 283 The standard is still in development with the US government as the 284 primary developer in partnership with OASIS. There is interest in 285 using STIX to manage content, but users don't really care about what 286 technology is used for the exchange. The initial goals may not wind 287 up matching the end result for STIX as managing content may be the 288 primary use case. 290 Incident Object Description Exchange Format (IODEF) was specified by 291 national research and education networks (NREN) and computer security 292 incident response teams (CSIRT) and formalized in the IETF. The user 293 is the security operations center (SOC). While there are several 294 implementations, it is not widely adopted. In terms of exchange, 295 users are more interested in indicators than full event information 296 and this applies to STIX as well. Sharing and trust are additional 297 hurdles as many are not willing to disclose information. 299 DNS-based Authentication of Named Entities (DANE) [RFC7671] has 300 DNSsec [RFC4033] as a dependency, which is a hurdle towards adoption 301 (too many dependencies). It has a roll-your-own adoption model, 302 which is risky. While there are some large pockets of adoption, 303 there is still much work to do to gain widespread adoption. A 304 regulatory requirement gave rise to partial adoption in Germany, 305 which naturally resulted in production of documentation written in 306 German - possibly giving rise to further adoption in German-speaking 307 countries. There has also been progress made in the Netherlands 308 through the creation of a website, internet.nl. The website allows 309 you you to test your website for a number of standards (IPv6, DNSSEC, 310 DANE etc.). Internet.nl is a collaboration of industry 311 organizations, companies, and the government in the Netherlands, and 312 is available for worldwide use. 314 IP version 6 (IPv6) [RFC8200] has struggled and the expense of 315 running a dual stack was one of the highest concerns on the list 316 discussed in the workshop breakout. The end user for IPv6 is 317 everyone and the breakout team considered it too ambiguous. Too many 318 new requirements have been added over its 20 year life. The scope of 319 necessary adoption is large with many peripheral devices. Government 320 requirements for support have helped somewhat with improved 321 interoperability and adoption, but features like NAT being added to 322 IPv4 [RFC0791] slowed adoption. With no new features being added to 323 IPv4 and lessons learned, there's still a possibility for success. 325 4.2. Breakout 2 Results:Preventative Protocols and Scaling Defense 327 This next breakout followed the sessions on MUD [RFC8520] which have 328 themes of automation at scale. MUD was designed for IoT and as such, 329 scaling was a major consideration. The PAVA and PASC work builds off 330 of MUD and maintains some of the same themes. This next breakout was 331 focused on groups brainstorming on preventative measures and enabling 332 vendors to deploy mitigations. 334 One group dove a bit deeper into MUD and layer 2 (L2) discovery. MUD 335 shifts sets of filtering control management to the vendor or 336 intermediary MUD vendors for a predictable platform that scales well. 337 While the overall value of MUD is clear, the use of MUD and what 338 traffic is expected for a particular device should be considered 339 sensitive information as it could be used to exploit a device. MUD 340 has an option of using L2 discovery to share MUD files. L2 341 discovery, like the dynamic host configuration protocol (DHCP) 342 [RFC2131] is not encrypted from the local client to the DHCP server 343 at this point in time (there is some interest to correct this, but it 344 hasn't received enough support yet). As a result, it is possible to 345 leak information and reveal data about the devices for which the MUD 346 files would be applied. This could multicast out information such as 347 network characteristics, firmware versions, manufacturer, etc. There 348 was some discussion on the use of 802.11 to improve connections. 349 Several participants from this group planned to research this further 350 and identify options to prevent information leakage while achieving 351 the stated goals of MUD. 353 The next group discussed a proposal one of the participants had 354 already begun developing, namely privacy for rendezvous service. The 355 basic idea was to encrypt SNI using DNS to obtain public keys. The 356 suffix on server IPv6 would be unique to a TLS session (Information 357 missing). The discussion on this proposal was fruitful as the full 358 set of attendees engaged, with special interest from the incident 359 responders to be involved in early review cycles. Incident 360 responders are very interested to understand how protocols will 361 change and to assess the overall impact of changes on privacy and 362 security operations. Even if there are no changes to the protocol 363 proposals stemming from this review, the group discussion landed on 364 this being a valuable exchange to understand early the impacts of 365 changes for incident detection and mitigation, to devise new 366 strategies and to provide assessments on the impact of protocol 367 changes on security in the round. 369 The third group reported back on trust exchanges relying heavily on 370 relationships between individuals. They were concerned with scaling 371 the trust model and finding ways to do that better. The third 372 breakout dove deeper into this topic. 374 The fourth breakout group discussed useful data for incident 375 responders. This built on the first breakout session. The group 376 determined that indicators of compromise (IOCs) are what most 377 organizations and groups are able to successfully exchange. Ideally, 378 these would be fixed and programmable. They discussed developing a 379 richer event threat sharing format. When reporting back to the 380 group, a successful solution used in the EU was mentioned, Malware 381 Information Sharing Platform (MISP) [MISP]. This will be considered 382 in their review of existing efforts to determine if anything new is 383 needed. 385 4.3. Breakout 3 Results: Incident Response Coordination 387 Incident response coordination currently does not scale. This 388 breakout session focused on brainstorming on incident response and 389 coordination, looking specifically at what works well for teams 390 today, what is holding them back, and what risks loom ahead. Output 391 from this session could be used to generate research and to dive 392 deeper in a dedicated workshop on these topics. 394 Supporting: 396 * Trust betwen individuals in incident response teams 398 * Volume of strong signals and automated discovery 400 * Need to protect network as a forcing function 402 * Law and legal catalyst, motivator to stay on top 404 * Current efforts supported by profit and company interests, but 405 those may shift 407 * Fear initially provides activity or in terms of the diagram used, 408 a burst of wind, but eventually leads to complacency 410 Creating Drag: 412 * Lack of clear KPIs 414 * Too many standards 416 * Regional border impact data flows 418 * Ease of use for end users 420 * Speed to market without security considerations 421 * Legal framework slow to adapt 423 * Disconnect in actual/perceived risk 425 * Regulatory requirements preventing data sharing 427 * Lack of clarity in shared information 429 * Behind the problem/reactionary 431 * Lack of resources/participation 433 * Monoculture narrows focus 435 Looming problems: 437 * Dynamic threat landscape 439 * Liability 441 * Vocabulary collision 443 * Lack of target/adversary clarity 445 * Bifurcation of Internet 447 * Government regulation 449 * Confusion around metrics 451 * Sensitivity of intelligence (trust) 453 * Lack of skilled analysts 455 * Lack of "fraud loss" data sharing 457 * Stakeholder/leader confusion 459 * Unknown impact of emerging technologies 461 * Over-centralization of the Internet 463 * New technologies and protocols 465 * Changes in application layer configurations (e.g. browser 466 resolvers) 468 4.4. Breakout 4 Results: Monitoring and Measurement 470 The fourth breakout followed Dave Plonka's talk on IPv6 aggregation 471 to provide privacy for IPv6 sessions. Essentially, IPv6 provides 472 additional capabilities for monitoring sessions end-to-end. Dave and 473 his co-author Arthur Berger primarily focus on measurement research, 474 but found a way to aggregate sessions to assist with maintaining user 475 privacy. If you can devise methods to perform management and 476 measurement, or even perform security functions, while accommodating 477 methods to protect privacy, a stronger result is likely. This also 478 precludes the need for additional pro-privacy work to defeat 479 measurement objectives. 481 This breakout was focused on devising methods to perform monitoring 482 and measurement, coupled with advancing privacy considerations. The 483 full group listed out options for protocols to explore and ranked 484 them, with the 4 highest then explored by the breakout groups. 485 Groups agreed to work further on the proposed ideas. 487 4.4.1. IP Address Reputation 489 There is a need to understand address assignment and configuration 490 for hosts and services, especially with IPv6 [PlonkaBergerCARIS2] in 491 (1) sharing IP address-related information to inform attack response 492 efforts, while still protecting the privacy of victims and possible 493 attackers, and (2) mitigating abuse by altering the treatment, e.g., 494 dropping or rate-limiting, of packets. Currently, there is no 495 database for analysts and researchers can consult to, for instance, 496 determine to lifetimes of IPv6 addresses or the prefix length at 497 which the address is expected to be stable over time. The researhers 498 propose either introduce a new database (compare PeerdingDB) or 499 extending existing databases (e.g., the RIRs'), to contain such 500 information and allowing arbitrary queries. The prefix information 501 would either be provided by networks, who are willing, or based on 502 measurement algorithms that reverse-engineer reasonable values based 503 on Internet measurements [PlonkaBergerKIP]. In the former case, the 504 incentive of networks to provide such information is to so that 505 privacy of their users is respected and to limit collateral damage 506 caused by access control lists affecting more of that network's 507 addresses than necessary, e.g., in the face of abuse. This is an 508 early idea, the lead to contact if interested to help develop this 509 further is Dave Plonka. 511 4.4.2. Server Name Authentication Reputation C (SNARC) 513 SNARC is a mechanism to assign value to trust indicators, used to 514 make decisions about good or bad actors. The mechanism would be able 515 to distinguish between client and server in connections, would be 516 human readable, builds on zero trust networking, and avoids 517 consolidation supporting legitimate new players. The group planned 518 to research visual aspects and underlying principles as they begin 519 work on this idea. SNARC has a similar theme to the IP reputation/ 520 BGP ranking idea mentioned above. An RFC would help customers and 521 design team on existing solutions. They planned to begin work in 522 several stages, researching "trust" indicators, "trust" value 523 calculations, and research actions to apply to "trust". The 524 overarching goal is to address blind trust, one of the challenges 525 identified with information/incident exchanges. If interested to 526 work further with this team, the lead contact is: Trent Adams. 528 4.4.3. Logging 530 The breakout group presented the possibility of injecting logging 531 capabilities at compile time for applications, resulting in a more 532 consistent set of logs, covering an agreed set of conditions. If the 533 log-injecting compiler were used this would increase logging for 534 those applications and improve the uniformity of logged activity. 535 Increasing logging capabilities at the endpoint is necessary as the 536 shift towards increased use of encrypted transport continues. The 537 lead for contact if interested to develop this further is Nalini 538 Elkins. 540 4.4.4. Fingerprinting 542 Fingerprinting has been used for numerous applications on the web, 543 including security, and will become of increasing importance with the 544 deployment of stronger encryption. This provides a method to 545 identify traffic without using decryption. The group discussed 546 privacy considerations and balancing how you achieve the security 547 benefits (identifying malicious traffic, information leakage, threat 548 indicators, etc.). They are interested to derive methods to validate 549 the authenticity without identifying the source of traffic. They are 550 also concerned with scaling issues. If interested to work further 551 with this team, the lead contact is: William Weinstein. 553 4.5. Taxonomy and Gaps Session 555 At the start of day 2, Kirsty Paine and Mirjam Kuhne prepared and 556 Kirsty led a workshop style session to discuss taxonomies used in 557 incident response, attacks, and threat detection, comparing solutions 558 and identifying gaps. The primary objective was to determine a path 559 forward selecting language to be used in the proposed SMART group. 560 Several taxonomies were presented for review and discussion. The 561 topic remains open, the following key points were highlighted by 562 participants: 564 * A single taxonomy might not be the way to go, because which 565 taxonomy you use depends on what problem you are trying to solve; 566 e.g. attribution of the attack, mitigation steps, technical 567 features or organizational impact measurements. 569 * A tool to map between taxonomies should be automated as there are 570 requirements within groups or nations to use specific taxonomies. 572 * The level of detail needed for reporting to management and for the 573 analyst investigating the incident can be very different. At the 574 workshop, one attendee mentioned that for management reporting 575 they only use 8 categories to lighten the load on analysts, 576 whereas some of the taxonomies contain 52 categories. 578 * How you plan to use the taxonomy matters and may vary between use 579 cases. Take for instance sharing data with external entities 580 versus internal only. The taxonomy selected depends on what you 581 plan to do with it. Some stated a need for attribute-based 582 dynamic anthologies as opposed to rigid taxonomies used by others. 583 A rigid taxonomy did not work for many from feedback in the 584 session. 586 * [RFC4949] was briefly discussed as a possibility, however there is 587 a clear need to update terminology in this publication around this 588 space in particular. This is likely to be raised in SAAG, 589 hopefully with proposed new definitions to demonstrate the issue 590 and evolution of terms over time. 592 * Within a taxonomy, prioritization matters to understand the impact 593 of threats or an attack. How do you map that between differing 594 taxonomies? (problem to be solved; possible tooling required) 596 * Attack attribution had varying degrees of interest. Some felt the 597 public sector cared more about attribution; not about individuals, 598 but the possible motivations behind an attack and likely other 599 victims based on these motivations. Understanding if the source 600 was an individual actor, organized crime, or a nation state 601 mattered. 603 The result of this discussion was not to narrow down to one taxonomy, 604 but to think about mappings between taxonomies and the use cases for 605 exchanging or sharing information, eventually giving rise to a common 606 method to discuss threats and attacks. Researchers need a common 607 vocabulary, not necessarily a common taxonomy. 609 5. Next Steps 611 The next steps from the CARIS2 workshop are twofold. 613 * The research initiatives spawned from the second CARIS require 614 further exploration and development. Fostering this development 615 and creating communities around each proposed project is the first 616 step, with reports back out to the SMART mailing list. 618 * The second initiative will be planning for the next CARIS 619 workshop. 621 6. Summary 623 Wrapping up the workshop, we reviewed the list of agreed projects to 624 get a feel for actual interest as a follow up. Through the course of 625 the 2-day workshop, a larger set of potential research items had been 626 generated, and this gave participants a chance to reassess 627 commitments to better have them match expected outcomes. The highest 628 ranking projects in terms of interest to drive the ideas forward 629 included the following: 631 * Traffic fingerprinting 633 * SNARC 635 * Attack coordination solutions/automated security 637 * Cryptographic Rendezvous 639 * L2 discovery 641 7. Security Considerations 643 There are no security considerations as this is an informational 644 workshop summary report. 646 8. IANA Considerations 648 This memo includes no request to IANA. 650 9. Acknowledgements 652 Thank you to each of the CARIS2 participants who brought their ideas, 653 energy and willingness to collaborate to advance attack response at 654 Internet scale. 656 A big thank you to each member of the program committee for your 657 review of program materials, papers, and guidance on the workshop 658 format: Mat Ford, Internet Society, UK, Jamie Gillespie, APNIC, AU, 659 Chris Inacio, CERT/CC, US, Mirja Kuhlewind, ETH Zurich, CH, Mirjam 660 Kuhne, RIPE NCC, NL, Carlos Martinez, LACNIC, UY, Kathleen M. 661 Moriarty, Dell EMC (Chair), Kirsty Paine, NCSC, UK, and Takeshi 662 Takahashi, NICT, JP. 664 Thank you to Megan Hyland, DellEMC, for her review and guidance on 665 the breakout session format and tools to enable successful 666 collaboration. 668 Thank you to the minute takers, Akashaya Khare and Thinh Nguyen, 669 DellEMC OCTO Cambridge Dojo team. 671 10. References 673 10.1. 674 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 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 700 (IPv6) Specification", STD 86, RFC 8200, 701 DOI 10.17487/RFC8200, July 2017, 702 . 704 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 705 Rose, "DNS Security Introduction and Requirements", 706 RFC 4033, DOI 10.17487/RFC4033, March 2005, 707 . 709 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 710 Authentication of Named Entities (DANE) Protocol: Updates 711 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 712 October 2015, . 714 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 715 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 716 November 2016, . 718 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 719 Housley, R., and W. Polk, "Internet X.509 Public Key 720 Infrastructure Certificate and Certificate Revocation List 721 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 722 . 724 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 725 DOI 10.17487/RFC0791, September 1981, 726 . 728 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 729 "Introduction and Applicability Statements for Internet- 730 Standard Management Framework", RFC 3410, 731 DOI 10.17487/RFC3410, December 2002, 732 . 734 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 735 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 736 DOI 10.17487/RFC6101, August 2011, 737 . 739 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 740 "Specification of the IP Flow Information Export (IPFIX) 741 Protocol for the Exchange of Flow Information", STD 77, 742 RFC 7011, DOI 10.17487/RFC7011, September 2013, 743 . 745 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 746 RFC 2131, DOI 10.17487/RFC2131, March 1997, 747 . 749 [I-D.ietf-quic-transport] 750 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 751 and Secure Transport", Work in Progress, Internet-Draft, 752 draft-ietf-quic-transport-27, 21 February 2020, 753 . 756 10.2. 757 URL References 759 [CARISEvent] 760 Internet Society, "CARIS Event Information and Accepted 761 Papers https://www.internetsociety.org/events/caris2", 762 2019. 764 [MISP] MISP-project.org, "Malware Information Sharing Platform 765 https://www.misp-project.org/", 2019. 767 [SMART] IRTF, "Stopping Malware and Researching Threats 768 https://datatracker.ietf.org/group/smart/about/", 2019. 770 [PlonkaBergerCARIS2] 771 CARIS2, "CARIS2 Paper Submission,", 2019. 773 [PlonkaBergerKIP] 774 Plonka, B., "kIP: a Measured Approach to IPv6 Address 775 Anonymization https://arxiv.org/abs/1707.03900", 2017. 777 [I2NSF] IETF, "Interface to Network Security Functions (i2nsf) 778 https://datatracker.ietf.org/wg/i2nsf/about". 780 [defecit] Morgan, S., "Cybersecurity Talent Crunch To Create 3.5 781 Million Unfilled Jobs Globally By 2021 782 https://cybersecurityventures.com/jobs/". 784 [STIX] al., B. J. E., "STIX™ Version 2.0. Part 1: STIX Core 785 Concepts http://docs.oasis-open.org/cti/stix/v2.0/cs01/ 786 part1-stix-core/stix-v2.0-cs01-part1-stix-core.pdf". 788 Author's Address 790 Kathleen M Moriarty 791 Dell Technologies 792 176 South Street 793 Hopkinton, MA 01748 794 United States 796 Email: kathleen.moriarty.ietf@gmail.com