wdiff rfc8953.original rfc8953.txt

Internet Engineering Task Force

Independent Submission K. Moriarty
Internet-Draft Dell Technologies
Intended status:
Request for Comments: 8953 Center for Internet Security
Category: Informational 9 October December 2020
Expires: 12 April 2021
ISSN: 2070-1721

Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop
Report
draft-moriarty-caris2-04

Abstract

The Coordinating Attack Response at Internet Scale (CARIS) 2
workshop, sponsored by the Internet Society, took place on 28
February and 1 March 2019 in Cambridge, Massachusetts, USA.
Participants spanned regional, national, international, and
enterprise CSIRTs, Computer Security Incident Response Teams (CSIRTs),
operators, service providers, network and security operators,
transport operators and researchers, incident response researchers,
vendors, and participants from standards communities. This workshop
continued the work started at the first CARIS workshop, with a focus
for CARIS 2
on scaling incident prevention and detection as the Internet industry
moves to a stronger and a more ubiquitous deployment of session
encryption.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 12 April 2021.
https://www.rfc-editor.org/info/rfc8953.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Accepted Papers . . . . . . . . . . . . . . . . . . . . . . . 3
3. CARIS2 Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop Collaboration . . . . . . . . . . . . . . . . . . . 5
4.1. Breakout 1 Results: Standardization and Adoption . . . . 5
4.1.1. Wide adoption: . . . . . . . . . . . . . . . . . . . 6 Adoption
4.1.2. Limited Adoption . . . . . . . . . . . . . . . . . . 6
4.2. Breakout 2 Results:Preventative Results: Preventative Protocols and Scaling
Defense . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Breakout 3 Results: Incident Response Coordination . . . 9
4.4. Breakout 4 Results: Monitoring and Measurement . . . . . 11
4.4.1. IP Address Reputation . . . . . . . . . . . . . . . . 11
4.4.2. Server Name Authentication Reputation C (SNARC) . . . 12
4.4.3. Logging . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.4. Fingerprinting . . . . . . . . . . . . . . . . . . . 12
4.5. Taxonomy and Gaps Session . . . . . . . . . . . . . . . . 13
5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1.
9.1. Informative References . . . . . . . . . . . . . . . . . 15
10.2. URL References . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction

The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop
workshop
[CARISEvent], sponsored by the Internet Society, took place on 28
February and 1 March 2019 in Cambridge, Massachusetts, USA.
Participants spanned regional, national, international, and
enterprise Computer Security Incident Response Teams (CSIRT), (CSIRTs),
operators, service providers, network and security operators,
transport operators and researchers, incident response researchers,
vendors, and participants from standards communities. This workshop
continued the work started at the first CARIS workshop [RFC8073],
with a focus for CARIS 2 on scaling incident prevention and detection as the
Internet industry moves to a stronger and a more ubiquitous
deployment of session encryption. Considering the related initiative
to form a research group [SMART] (Stopping Malware and Researching Threats
[SMART]) in the Internet Research Task Force
(IRTF) (IRTF), the focus on
prevention included consideration of research opportunities to
improve protocols and determine if there are ways to improve attack
detection devleoped during the protocol design phase that could later influence
protocol development in the IETF. This is one way to think about
scaling response, through prevention and allowing for new methods to
evolve for detection in a post-encrypted world. Although the
proposed SMART Research Group has not yet progressed, the work to
better scale incident response continues through the projects
proposed at CARIS2 as well as in future CARIS workshops.

2. Accepted Papers

Researchers from around the world submitted position and research
papers summarizing key aspects of their work to help form the shared
content of the workshop. The accepted papers may be found at
workshop [CARISEvent],
[CARISEvent] and include:

* Visualizing Security Automation: Takeshi Takahashi, NICT, Japan

* Automating Severity Determination: Hideaki Kanehara, NICT, Japan

* OASIS's OpenC2, OpenC2: Draper and DoD

* Automated IoT Security (PASC and PAVA): Security: Oscar Garcia-Morchon and Thorsten Dahm

* Taxonomies and Gaps: Kirsty P., UK NCSC

* FIRST: Thomas Schreck, Siemens

* NetSecWarriors: Tim April, Akamai

* Measured Approaches to IPv6 Address Anonymization and Identity
Association: Dave Plonka and Arthur Berger, Akamai

The program committee worked to fill in the agenda with meaningful
and complementary sessions to round out the theme and encourage
collaboration to advance research towards toward the goals of the workshop.
These sessions included:

* Manufacturer Usage Description (MUD) [RFC8520]: Eliot Lear, Cisco

* TF-CSIRT: Mirjam Kuhne, Kühne, RIPE NCC

* M2M Sharing Revolution, Revolution: Scott Pinkerton, DoE ANL

* Comparing OpenC2 with existing efforts, e.g. e.g., I2NSF [I2NSF]: Chris
Inacio

* Alternate Sharing and Mitigation Models: Kathleen Moriarty,
DellEMC Dell
EMC

The presentations provided interesting background to familiarize
workshop attendees with current research work, challenges that
require addressing must
be addressed for forward progress, and opportunities to collaborate
in the desire to better scale attack response and prevention.

3. CARIS2 Goals

The goal of each CARIS workshop has been to focus on the challenge of
improving the overall security posture. The approach has been to
identify intrinsic or built-in protection capabilities for improved
defense, automation, and scaling attack response through
collaboration and improved architectural patterns. It has been
assumed that it is unlikely that additional training will likely not address the lack of
information security professionals to fill the job gap. Currently,
there is approximately a 3 million person three-million-person deficit
[defecit] [deficit] for
security professionals worldwide worldwide, and it's that is only expected to grow.
In preparing for the workshop, the chair and programme program committee
considered that this gap cannot be filled through training, training but the gap
requires measures to reduce the number of information security
professionals needed through new architectures and research
towards toward
attack prevention. CARIS 2 CARIS2 was specifically focused on the industry
shift towards toward the increased use of stronger session encryption
(TLSv1.3 [RFC8446], QUIC [I-D.ietf-quic-transport],
TCPcrypt [QUIC], tcpcrypt [RFC8548], etc.) and how
prevention and detection can advance in this new paradigm. As such such,
the goals for this workshop included:

* Scale attack response, including ways to improve prevention, as
the Internet shifts to use of stronger and more ubiquitous
encryption.

- Determine research opportunities

- Consider methods to improve protocols/provide protocols and provide guidance
toward goal. For instance, are there ways to build detection
of threats into protocols protocols, since they cannot be monitored on
the wire in the future?

* Identify promising research ideas to seed a research agenda to
input to the proposed IRTF SMART research group. Research Group.

4. Workshop Collaboration

Both CARIS workshops brought together a set of individuals who had
not previously collaborated toward the goals of scaling attack
response. This is important as the participants span various areas
of Internet technology work, conduct research, provide a global
perspective, have access to varying data sets and infrastructure, and
are influential in their area of expertise. The specific goals of the
CARIS 2 workshop, goals,
contributions, and the participants of the CARIS2 workshop were all
considered in the design of the breakout sessions to both identify
and advance research through collaboration. The breakout sessions
varied in format to keep attendees engaged and collaborating,
involving collaborating; some
involved the full set of attendees and breakout while others utilized groups.

The Workshop workshop focused in trying to help identify on identifying potential areas for collaboration
and advance advancing research. To do this, the workshop
included 5 different breakout sessions focused on:

1. Standardization and adoption: Adoption: identify widely adopted and
pervasive standard protocols and data formats as well as those
that failed.

2. Preventative Protocols and Scaling Defense: identify protocols to
address automation at scale.

3. Incident Response Coordination: brainstorm on what potential areas
of research or future workshops could be held to improve on the
scalability of incident response.

4. Monitoring and Measurement:brainstorm on Measurement: brainstorm methods to perform
monitoring and measurement with the heightened need and
requirement to address privacy.

5. Taxonomy and Gaps: brainstorm on away a way forward for the proposed
SMART group Research Group.

4.1. Breakout 1 Results: Standardization and Adoption

This breakout session considered points raised in the preceding talks
on hurdles for automating security controls, detection, and response
as response;
the teams presenting noted several challenges they still face today.
The breakout session worked toward identifying standard protocols and
data formats that succeeded in achieving adoption as well as several
that failed or only achieved limited adoption. The results from the
evaluation were interesting and could aid in achieving greater
adoption when new work areas are developed. The results follow: following
subsections detail the results.

4.1.1. Wide adoption:

Secure Sockets Layer (SSL), now replaced by Adoption

The Transport Layer Security (TLS) protocol has replaced the Secure
Sockets Layer (SSL) protocol.

Observations: There was a clear need for session encryption at the
transport layer to protect application data. eCommerce E-commerce was a
driving force at the time with a downside to those who did not adopt.
Other positive attributes that aided adoption were modular design,
clean interfaces, and being first to market.

The Simple Network Management Protocol (SNMP) enables configuration
management of devices with extension points for private configuration
and management settings. SNMP is widely adopted and is only now now,
after decades decades, being replaced by a newer alternative, YANG (a data
modeling language) facilitating that facilitates configuration management via NETCONF the
Network Configuration Protocol (NETCONF) or RESTCONF. The SNMP protocol
facilitated an answer to a needed problem set: configuration,
telemetry, and network management. It's Its development considered the
connection between the user, vendor, and developers. Challenges did
surface for adoption from SNMPv1.1 to 1.2, as there was no compelling
reason for adoption. SNMPv3 gained adoption due to its resilience to
attacks by providing protection through improved authentication and
encryption.

IP Flow Information Export (IPFix) (IPFIX) was identified as achieving wide
adoption for several reasons. The low cost of entry, wide vendor
support, diverse user base, and the wide set of use cases spanning
multiple technology areas were some of the key drivers cited.

X.509 was explored for its success in gaining adoption. The solution
being abstract from crypto, open, customizable, and extensible were
some of the reasons cited for its successful adoption. The team
deemed it a good solution to a good problem and observed that
government adoption aided its success.

4.1.2. Limited Adoption

Next, each team evaluated solutions that have not enjoyed wide
adoption.

Although STIX Structured Threat Information eXpression (STIX) and IODEF the
Incident Object Description Exchange Format (IODEF) are somewhat
similar in their goals, the standards were selected for evaluation by
two separate groups with some common findings.

*Structured Threat Information eXpression (STIX)*

STIX has had limited adoption by the financial sector, sector but no single,
definitive end user. The standard is still in development with the
US government as the primary developer in partnership with OASIS.
There is interest in using STIX to manage content, but users don't
really care about what technology is used for the exchange. The
initial goals may not wind up matching the end result for STIX STIX, as
managing content may be the primary use case.

Incident Object Description Exchange Format (IODEF)

IODEF was specified by
national research National Research and education networks (NREN) Education Networks
(NRENs) and computer security
incident response teams (CSIRT) Computer Security Incident Response Teams (CSIRTs) and
formalized in the IETF. IETF [RFC7970]. The user is the security
operations center (SOC). While there are several implementations, it
is not widely adopted. In terms of exchange, users are more
interested in indicators than full event information information, and this
applies to STIX as well. Sharing and trust are additional hurdles as
many are not willing to disclose information.

DNS-based

DNS-Based Authentication of Named Entities (DANE) has DNSsec DNSSEC as a
dependency, which is a hurdle towards toward adoption (too many
dependencies). It has a roll-your-own adoption model, which is
risky. While there are some large pockets of adoption, there is
still much work to do to gain widespread adoption. A regulatory
requirement gave rise to partial adoption in Germany, which naturally
resulted in production of documentation written in German - -- possibly
giving rise to further adoption in German-speaking countries. There
has also been progress made in the Netherlands through the creation
of a website, internet.nl. website: <internet.nl>. The website allows you you to test your
website for a number of standards (IPv6, DNSSEC, DANE DANE, etc.).
Internet.nl
<internet.nl> is a collaboration of industry organizations,
companies, and the government in the Netherlands, Netherlands and is available for
worldwide use.

IP version 6 (IPv6) has struggled struggled, and the expense of running a dual
stack was one of the highest concerns on the list discussed in the
workshop breakout. The end user for IPv6 is everyone everyone, and the
breakout team considered it too ambiguous. Too many new requirements
have been added over its 20 year 20-year life. The scope of necessary
adoption is large with many peripheral devices. Government
requirements for support have helped somewhat with improved
interoperability and adoption, but features like NAT being added to
IPv4 slowed adoption. With no new features being added to IPv4 and
lessons learned, there's still a possibility for success.

4.2. Breakout 2 Results:Preventative Results: Preventative Protocols and Scaling Defense

This next breakout session followed the sessions on MUD, PAVA (Protocol Protocol for
Automated Vulnerability Assessment), Assessment (PAVA), and PASC (Protocol Protocol for Automatic
Security Configuration) Configuration (PASC), which have themes of automation at
scale. MUD was designed for IoT Internet of Things (IoT), and as such,
scaling was a major consideration. The PAVA and PASC work builds off
of MUD and maintains some of the same themes. This next breakout session
was focused on groups brainstorming on preventative measures and
enabling vendors to deploy mitigations.

One group dove a bit deeper into MUD and layer 2 (L2) discovery. MUD
changes sets of filtering control management to the vendor or
intermediary MUD vendors for a predictable platform that scales well.
While the overall value of MUD is clear, the use of MUD and what
traffic is expected for a particular device should be considered
sensitive information information, as it could be used to exploit a device. MUD
has an option of using L2 discovery to share MUD files. L2
discovery, like the dynamic host configuration protocol (DHCP) Dynamic Host Configuration Protocol (DHCP), is
not encrypted from the local client to the DHCP server at this point
in time (there is some interest to correct this, but it hasn't
received enough support yet). As a result, it is possible to leak
information and reveal data about the devices for which the MUD files
would be applied. This could multicast out information such as
network characteristics, firmware versions, manufacturer, manufacturers, etc.
There was some discussion on the use of 802.11 to improve connections. connections
[IEEE802.11]. Several participants from this group planned plan to research
this further and identify options to prevent information leakage
while achieving the stated goals of MUD.

The next group discussed a proposal one of the participants had
already begun developing, namely privacy for rendezvous service. The
basic idea was to encrypt SNI Server Name Indication (SNI) using DNS to
obtain public keys. The suffix on server IPv6 would be unique to a
TLS session (Information (information missing). The discussion on this proposal
was fruitful fruitful, as the full set of attendees engaged, with special
interest from the incident responders to be involved in early review
cycles. Incident responders are very interested to understand how
protocols will change and to assess the overall impact of changes on
privacy and security operations. Even if there are no changes to the
protocol proposals stemming from this review, the group discussion
landed on this being a valuable exchange to understand early the
impacts of changes for incident detection and mitigation, to devise
new
strategies strategies, and to provide assessments on the impact of protocol
changes on security in the round.

The third group reported back on trust exchanges relying heavily on
relationships between individuals. They were concerned with scaling
the trust model and finding ways to do that better. The third
breakout group dove
deeper into this topic.

The fourth breakout group discussed useful data for incident responders. This
built on the first breakout session. session (Section 4.1). The group
determined that indicators of compromise (IOCs) (IoCs) are what most
organizations and groups are able to successfully exchange. Ideally,
these would be fixed and programmable. They discussed developing a
richer event threat format for sharing format. event threats. When reporting back to the
group, a successful solution used in the EU was mentioned, mentioned: the
Malware Information Sharing Platform (MISP) [MISP]. This will be
considered in their the review of existing efforts to determine if anything
new is needed.

4.3. Breakout 3 Results: Incident Response Coordination

Incident response coordination currently does not scale. This
breakout session focused on brainstorming on incident response and
coordination, looking specifically at what works well for teams
today, what is holding them back, and what risks loom ahead. Output
from this session could be used to generate research and to dive
deeper in a dedicated workshop on these topics.

Supporting:

* Trust between individuals in incident response teams

* Volume of strong signals and automated discovery

* Need to protect network as a forcing function

* Law and legal catalyst, motivator to stay on top

* Current efforts supported by profit and company interests, but
those may shift

* Fear initially results in activity or in terms of the diagram
used, a burst of wind, but eventually leads to complacency

Creating Drag:

What creates drag:

* Lack of clear KPIs Key Performance Indicators (KPIs)

* Too many standards

* Regional border Potential for regional borders to impact data flows

* Ease of use for end users

* Speed to market without security considerations

* Legal framework slow to adapt

* Disconnect in actual/perceived risk

* Regulatory requirements preventing data sharing

* Lack of clarity in shared information

* Behind the problem/reactionary

* Lack of resources/participation

* Monoculture narrows focus

Looming problems:

* Dynamic threat landscape

* Liability

* Vocabulary collision

* Lack of target/adversary clarity

* Bifurcation of Internet

* Government regulation

* Confusion around metrics

* Sensitivity of intelligence (trust)

* Lack of skilled analysts

* Lack of "fraud loss" data sharing

* Stakeholder/leader confusion

* Unknown impact of emerging technologies

* Over-centralization Overcentralization of the Internet

* New technologies and protocols

* Changes in application layer application-layer configurations (e.g. (e.g., browser
resolvers)

4.4. Breakout 4 Results: Monitoring and Measurement

The fourth breakout session followed Dave Plonka's talk on IPv6
aggregation to provide privacy for IPv6 sessions. Essentially, IPv6
provides additional capabilities for monitoring sessions end-to-end. end to end.
Dave and his co-author coauthor, Arthur Berger Berger, primarily focus on measurement research,
research but found a way to aggregate sessions to assist with
maintaining user privacy. If you can devise methods to perform
management and measurement, or even perform security functions, while
accommodating methods to protect privacy, a stronger result is
likely. This also precludes the need for additional privacy
improvement work to defeat measurement objectives.

This breakout session was focused on devising methods to perform
monitoring and measurement, coupled with advancing privacy
considerations. The full group listed out options for protocols to
explore and ranked them, with the 4 four highest then explored by the
breakout groups. Groups agreed to work further on the proposed
ideas.

4.4.1. IP Address Reputation

There is a need to understand address assignment and configuration
for hosts and services, especially with IPv6 [PlonkaBergerCARIS2] in
(1) sharing IP address-related IP-address-related information to inform attack response
efforts,
efforts while still protecting the privacy of victims and possible
attackers,
attackers and (2) mitigating abuse by altering the treatment, e.g.,
dropping or rate-limiting, of packets. Currently, there is no
database for that analysts and researchers can consult to, for instance,
determine to the lifetimes of IPv6 addresses or the prefix length at
which the address is expected to be stable over time. The
researchers propose either introduce introducing a new database (compare
PeerdingDB)
PeeringDB) or extending existing databases (e.g., the RIRs'), regional
Internet registries (RIRs)) to contain such information and allowing
arbitrary queries. The prefix information would either be provided
by networks, who networks that are willing, willing or based on measurement algorithms that
reverse-engineer reasonable values based on Internet measurements
[PlonkaBergerKIP]. In the former case, the incentive of networks to
provide such information is to so ensure that privacy of their users is
respected and to limit collateral damage caused by access control
lists affecting more of that network's addresses than necessary,
e.g., in the face of abuse. This is an early idea, idea; Dave Plonka is
the lead to contact if for those interested in helping to help develop this further is Dave Plonka.
further.

4.4.2. Server Name Authentication Reputation C (SNARC)

SNARC is a mechanism to assign value to trust indicators, used to
make decisions about good or bad actors. The mechanism would be able
to distinguish between client and server in connections, connections and would be
human readable, readable. In addition, it builds on zero trust networking, networking and
avoids
consolidation consolidation, thus supporting legitimate new players. The group planned
to research visual aspects and underlying principles as they begin
work on this idea. SNARC
has a similar theme to the IP reputation/
BGP reputation/BGP ranking idea mentioned
above. An SNARC is not currently defined by an RFC; however, such an
RFC would help customers and design team teams on existing solutions. The
group plans to research visual aspects and underlying principles as
they begin work on this idea. They planned plan to begin work in several
stages, researching "trust" indicators, "trust" value calculations,
and research actions to apply to "trust". The overarching goal is to
address blind trust, one of the challenges identified with
information/incident exchanges. If interested to
work further with this team, Trent Adams is the lead contact is: Trent Adams. for
those interested in working with this team.

4.4.3. Logging

The breakout group presented the possibility of injecting logging capabilities
at compile time for applications, resulting in a more consistent set
of logs, covering an agreed set of conditions. If the Using a log-injecting
compiler were used this would increase logging for those applications and improve
the uniformity of logged activity. Increasing logging capabilities
at the endpoint is necessary as the shift towards toward increased use of
encrypted transport continues. The Nalini Elkins is the lead for contact if for
those interested to develop in developing this further is Nalini
Elkins. further.

4.4.4. Fingerprinting

Fingerprinting has been used for numerous applications on the web, Web,
including security, and will become of increasing importance with the
deployment of stronger encryption. This Fingerprinting provides a method
to identify traffic without using decryption. The group discussed
privacy considerations and balancing how you achieve the security
benefits (identifying malicious traffic, information leakage, threat
indicators, etc.). They are interested to derive in deriving methods to
validate the authenticity without identifying the source of traffic.
They are also concerned with scaling issues. If interested to work further
with this team, William Weinstein is
the lead contact is: William Weinstein. for those interested in working with this team.

4.5. Taxonomy and Gaps Session

At the start of the second day 2, of the workshop, Kirsty Paine and
Mirjam Kuhne Kühne prepared and (and Kirsty led led) a workshop style workshop-style session to
discuss taxonomies used in incident response, attacks, and threat
detection, comparing solutions and identifying gaps. The primary
objective was to determine a path forward by selecting the language
to be used in the proposed SMART group. Research Group. Several taxonomies
were presented for review and discussion. The topic remains open,
but the following key points were highlighted by participants:

* A single taxonomy might not be the way to go, because which
taxonomy you use depends on what problem you are trying to solve;
e.g. solve,
e.g., attribution of the attack, mitigation steps, technical
features
features, or organizational impact measurements.

* A tool to map between taxonomies should be automated automated, as there are
requirements within groups or nations to use specific taxonomies.

* The level of detail needed for reporting to management and for the
analyst investigating the incident can be very different. At the
workshop, one attendee mentioned that that, for management reporting reporting,
they only use 8 categories to lighten the load on analysts,
whereas some of the taxonomies contain 52 categories.

* How you plan to use the taxonomy matters and may vary between use
cases. Take Take, for instance instance, sharing data with external entities
versus internal only. The taxonomy selected depends on what you
plan to do with it. Some stated a need for attribute-based
dynamic anthologies as opposed to rigid taxonomies used by others.
A rigid taxonomy did not work for many from feedback in the
session.

* [RFC4949] was briefly discussed as a possibility, however possibility; however, there
is a clear need to update terminology in this publication around
this space in particular. This is likely to be raised in SAAG the
Security Area Advisory Group (SAAG) during the open mic, mic session,
hopefully with proposed new definitions to demonstrate the issue
and evolution of terms over time.

* Within a taxonomy, prioritization matters to understand the impact
of threats or an attack. How do you map that between differing
taxonomies? (problem What is the problem to be solved; possible solved, and what tooling required) is
required?

* Attack attribution had varying degrees of interest. Some felt the
public sector cared more about attribution; attribution, not about individuals,
but the individuals.
They were interested in possible motivations behind an attack and likely
determining if there were other likely victims based on these
motivations. Understanding if the source was an individual actor,
organized crime, or a nation state mattered.

The result of this discussion was not to narrow down to one taxonomy, taxonomy
but to think about mappings between taxonomies and the use cases for
exchanging or sharing information, eventually giving rise to a common
method to discuss threats and attacks. Researchers need a common
vocabulary, not necessarily a common taxonomy.

5. Next Steps

The next steps from the CARIS2 workshop are twofold.

* twofold:

1. The research initiatives spawned from the second CARIS workshop
require further exploration and development. Fostering this
development and creating communities around each proposed project
is the first step, with reports back out to the SMART mailing
list.

2. The second initiative will be planning for the next CARIS
workshop.

6. Summary

Wrapping

When wrapping up the workshop, we reviewed the list of agreed
projects to get a feel for actual interest as a follow up. Through
the course of the 2-day two-day workshop, a larger set of potential
research items had been generated, and this gave participants a
chance to reassess commitments to better have them match expected
outcomes. The highest ranking projects in terms of interest to drive
the ideas forward included the following:

* Traffic fingerprinting

* SNARC

* Attack coordination solutions/automated solutions and automated security

* Cryptographic Rendezvous rendezvous

* L2 discovery

7. Security Considerations

There are no security considerations considerations, as this is an informational
workshop summary report.

8. IANA Considerations

This memo includes document has no request to IANA. IANA actions.

9. References

9.1. Informative References

[CARISEvent]
Internet Society, "CARIS2: Coordinating Attack Response at
Internet Scale", February 2019,
<https://www.internetsociety.org/events/caris2>.

[deficit] Morgan, S., "Cybersecurity Talent Crunch To Create 3.5
Million Unfilled Jobs Globally By 2021", October 2019,
<https://cybersecurityventures.com/jobs/>.

[I2NSF] IETF, "Interface to Network Security Functions (i2nsf)",
<https://datatracker.ietf.org/wg/i2nsf/about>.

[IEEE802.11]
IEEE, "IEEE 802.11 WIRELESS LOCAL AREA NETWORKS",
<https://www.ieee802.org/11/>.

[MISP] MISP, "Malware Information Sharing Platform",
<https://www.misp-project.org/>.

[PlonkaBergerCARIS2]
Plonka, D. and A. Berger, "Measured Approaches to IPv6
Address Anonymization and Identity Association", CARIS2
Paper Submission, March 2019,
<https://www.internetsociety.org/events/caris2>.

[PlonkaBergerKIP]
Plonka, D. and A. Berger, "kIP: a Measured Approach to
IPv6 Address Anonymization", July 2017,
<https://arxiv.org/abs/1707.03900>.

[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-33, 13 December 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
33>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.

[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.

[RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at
Internet Scale (CARIS) Workshop Report", RFC 8073,
DOI 10.17487/RFC8073, March 2017,
<https://www.rfc-editor.org/info/rfc8073>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.

[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>.

[SMART] IRTF, "Stopping Malware and Researching Threats (smart)",
<https://datatracker.ietf.org/group/smart/about/>.

Acknowledgements

Thank you to each of the CARIS2 workshop participants who brought
their ideas,
energy energy, and willingness to collaborate to advance attack
response at Internet scale.

A big thank you to each member of the program committee for your
review of program materials, papers, and guidance on the workshop
format: Mat Ford, Internet Ford (Internet Society, UK, UK); Jamie Gillespie, APNIC, AU, Gillespie (APNIC, AU);
Chris Inacio, CERT/CC, US, Inacio (CERT/CC, US); Mirja Kuhlewind, ETH Kühlewind (ETH Zurich, CH, CH); Mirjam
Kuhne, RIPE
Kühne (RIPE NCC, NL, NL); Carlos Martinez, LACNIC, UY, Martinez (LACNIC, UY); Kathleen
M. Moriarty, Dell EMC (Chair), Chair (Dell EMC); Kirsty Paine, NCSC, UK, Paine (NCSC, UK); and Takeshi
Takahashi, NICT, JP.
Takahashi (NICT, JP).

Thank you to Megan Hyland, DellEMC, Hyland (Dell EMC) for her review and guidance on
the breakout session format of breakout sessions and tools to enable successful
collaboration.

Thank you to the minute takers, Akashaya Khare and Thinh Nguyen,
DellEMC Nguyen (Dell
EMC OCTO Cambridge Dojo team.

10. References

10.1. Informative References

[RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at
Internet Scale (CARIS) Workshop Report", RFC 8073,
DOI 10.17487/RFC8073, March 2017,
<https://www.rfc-editor.org/info/rfc8073>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.

[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-31, 24 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
31>.

10.2. URL References

[CARISEvent]
Internet Society, "CARIS Event Information and Accepted
Papers https://www.internetsociety.org/events/caris2",
2019.

[I2NSF] IETF, "Interface to Network Security Functions (i2nsf)
https://datatracker.ietf.org/wg/i2nsf/about".

[defecit] Morgan, S., "Cybersecurity Talent Crunch To Create 3.5
Million Unfilled Jobs Globally By 2021
https://cybersecurityventures.com/jobs/".

[MISP] MISP-project.org, "Malware Information Sharing Platform
https://www.misp-project.org/", 2019.

[SMART] IRTF, "Stopping Malware and Researching Threats
https://datatracker.ietf.org/group/smart/about/", 2019.

[PlonkaBergerCARIS2]
CARIS2, "CARIS2 Paper Submission,", 2019.

[PlonkaBergerKIP]
Arxiv, "kIP: a Measured Approach to IPv6 Address
Anonymization https://arxiv.org/abs/1707.03900", 2017. team).

Author's Address

Kathleen M M. Moriarty
Dell Technologies
176 South Street
Hopkinton, MA 01748
Center for Internet Security
31 Tech Valley Drive
East Greenbush, NY 12061
United States of America

Email: kathleen.moriarty.ietf@gmail.com