[要約] RFC 8953 - Coordinating Attack Response at Internet Scale 2 (CARIS2) ワークショップレポートは、インターネット規模での攻撃対応の調整に関する議論と提案をまとめたものです。この文書の目的は、異なる組織間での情報共有と協力を促進し、より効果的な攻撃対応戦略を開発することにあります。利用場面としては、セキュリティ専門家や組織が攻撃への対応計画を立てる際、またはセキュリティポリシーや手順を策定する際に参照されます。

Independent Submission                                       K. Moriarty
Request for Comments: 8953                  Center for Internet Security
Category: Informational                                    December 2020
ISSN: 2070-1721
        

Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report

インターネットスケール2(CARIS2)ワークショップレポートにおける攻撃対応調整

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 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 on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption.

インターネット社会が主催するインターネットスケール(CARIS)2ワークショップでの調整攻撃対応は、2019年2月28日と2019年3月1日に開催されました。参加者は、地域、国内、国際、および企業のコンピュータのセキュリティインシデントのインシデントのインシデントチーム(CSIRT)、事業者、サービスプロバイダー、ネットワークおよびセキュリティ事業者、輸送事業者、研究者、インシデント対応研究者、ベンダー、および標準コミュニティからの参加者。このワークショップは、インターネット業界がセッション暗号化のより強く、よりユビキタスの展開に移行するため、最初のCaris Workshopで開始された作業を続けました。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8953.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8953で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(C)2020 IETFの信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.

この文書は、この文書の公開日に有効なIETF文書(https://truste.ietf.org/License-info)に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

Table of Contents

目次

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

The Coordinating Attack Response at Internet Scale (CARIS) 2 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 (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 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 (Stopping Malware and Researching Threats [SMART]) in the Internet Research Task Force (IRTF), the focus on prevention included consideration of research opportunities to improve protocols and determine if there are ways to improve attack detection 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.

インターネット社会が主催するインターネットスケール(CARIS)2 Workshop [Carisevent]での調整攻撃対応は、2019年2月28日と2019年3月1日に開催されました。参加者は、地域、国内、国際、および企業のコンピュータのセキュリティインシデントのインシデントのインシデントチーム(CSIRT)、事業者、サービスプロバイダー、ネットワークおよびセキュリティ事業者、輸送事業者、研究者、インシデント対応研究者、ベンダー、および標準コミュニティからの参加者。このワークショップは最初のCaris Workshop [RFC8073]で始まり、インターネット業界がセッション暗号化のより強く、よりユビキタスの展開に移行するため、インシデント防止と検出をスケーリングすることに焦点を当てています。関連するイニシアチブ(マルウェアを停止し、マルウェアを停止し、脅威の研究を停止し、脅威を研究すること[SMART])を考慮して、予防に焦点を当ててプロトコルを改善し、攻撃を改善する方法があるかどうかを判断することに焦点を当てていました。 IETFのプロトコル開発に影響を与える可能性があるプロトコル設計段階中の検出。これは、スケーリング応答を予防し、暗号化された世界での検出のために新しい方法を進化させるための新しい方法を考えることを考える1つの方法です。提案されているスマートリサーチグループはまだ進歩していませんが、スケールインシデント対応のための作業は、CARIS2で提案されたプロジェクトと将来のCarisワークショップで継続しています。

2. Accepted Papers
2. 受け入れられた論文

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 [CARISEvent] and include:

世界中の研究者は、ワークショップの共有コンテンツを形成するのを助けるために彼らの仕事の主な側面を要約する位置と研究論文を提出しました。受け入れられた論文は[CarisEvent]で見つけることができ、次のものを含めることができます。

* Visualizing Security Automation: Takeshi Takahashi, NICT, Japan

* セキュリティ自動化の可視化:高橋武、ニック、日本

* Automating Severity Determination: Hideaki Kanehara, NICT, Japan

* 重大度決定の自動化:Kanehara hideaki、NICT、日本

* OASIS's OpenC2: Draper and DoD

* OASISのOpenC2:DRAPERとDOD

* Automated IoT Security: Oscar Garcia-Morchon and Thorsten Dahm

* 自動IOTセキュリティ:オスカーガルシア - モーキョンとThorsten Dahm

* Taxonomies and Gaps: Kirsty P., UK NCSC

* 分類法とギャップ:Kirsty P.、UK NCS

* FIRST: Thomas Schreck, Siemens

* 最初:Thomas Schreck、Siemens

* NetSecWarriors: Tim April, Akamai

* NetSecwarriors:ティム4月、Akamai

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

* IPv6アドレス匿名化とアイデンティティ協会への測定アプローチ:Dave Plonkaと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 toward the goals of the workshop. These sessions included:

プログラム委員会は、テーマを四捨五入し、ワークショップの目標に向けて研究を進めるためにコラボレーションを促進するために、意味のあると補完的なセッションで議題を埋めるように働きました。これらのセッションは次のとおりです。

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

* メーカー使用状況説明(泥)[RFC8520]:Cisco Eliot Lear

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

* TF-CSIRT:MirjamKühne、RIPE NCC.

* M2M Sharing Revolution: Scott Pinkerton, DoE ANL

* M2M共有革命:Scott Pinkerton、DOE ANL

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

* OpenC2を既存の努力と比較して、i2nsf [i2nsf]:Chris Inacio

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

* 代替シェアリングと軽減モデル:Kathleen MoriAlty、Dell EMC

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

プレゼンテーションは、現在の研究作業でワークショップ参加者に興味深い背景を提供し、前進の進捗状況に対処しなければならない課題、および攻撃対応と予防のより良いスケールでコラボレーションする機会を提供しました。

3. CARIS2 Goals
3. Caris2目標

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 additional training will likely not address the lack of information security professionals to fill the job gap. Currently, there is approximately a three-million-person deficit [deficit] for security professionals worldwide, and that is only expected to grow. In preparing for the workshop, the chair and program committee considered that this gap cannot be filled through training but requires measures to reduce the number of information security professionals needed through new architectures and research toward attack prevention. CARIS2 was specifically focused on the industry shift toward the increased use of stronger session encryption (TLS 1.3 [RFC8446], QUIC [QUIC], tcpcrypt [RFC8548], etc.) and how prevention and detection can advance in this new paradigm. As such, the goals for this workshop included:

各Caris Workshopの目標は、全体的なセキュリティ姿勢を改善するという課題に焦点を当てることでした。このアプローチは、共同開発と改善された建築パターンを通じて、改善された防衛、自動化、およびスケーリング攻撃の対応のための固有または組み込み保護機能を特定することでした。追加のトレーニングは、ジョブギャップを埋めるための情報セキュリティ専門家の欠如には対処しないと考えられています。現在、世界中のセキュリティ専門家のために約300万人の赤字[赤字]、そしてそれが成長すると期待されています。ワークショップに準備する際に、議長とプログラム委員会は、このギャップを訓練を通して満たすことができないと考えられていましたが、新しい建築と攻撃防止に向けた研究と研究を行うための情報セキュリティ専門家の数を減らすための措置が必要です。 CARIS2は、より強いセッション暗号化(TLS 1.3 [RFC8446]、QUIC [QUIC]、TCPCrypt [RFC8548]など)、およびこの新しいパラダイムでの予防と検出がどのように進歩するかを業界のシフトに焦点を当てていました。そのため、このワークショップの目標は次のとおりです。

* 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 and provide guidance toward goal. For instance, are there ways to build detection of threats into 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.

* 提案されたIRTFスマートリサーチグループに入力するために研究アジェンダを播種するための有望な研究のアイデアを特定する。

4. Workshop Collaboration
4. ワークショップコラボレーション

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, contributions, and 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; some involved the full set of attendees while others utilized groups.

どちらのカリスワークショップは、攻撃応答のスケーリングの目標に以前に協力していなかった個人のセットを集めました。参加者がインターネット技術の様々な分野に及んでいるため、研究を行う、グローバルな視点を提供し、さまざまなデータセットやインフラストラクチャにアクセスできるため、専門分野に影響を与えます。CARIS2ワークショップの具体的な目標、拠出金、および参加者はすべて、共同研究を通じて識別して進歩を遂行し、識別して進歩しています。ブレイクアウトセッションは、参加者が関与してコラボレーションするための形式で変化しました。他の人がグループを利用している間には、出席者の完全なセットが含まれていました。

The workshop focused on identifying potential areas for collaboration and advancing research.

ワークショップは、コラボレーションと進歩のための潜在的な分野の特定に焦点を当てました。

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

1. 標準化と採用:広く採用された普及している標準のプロトコルとデータフォーマットとデータフォーマットを特定しました。

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

2. 予防プロトコルとスケーリング防御:スケールで自動化に対処するためのプロトコルを特定します。

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

3. インシデント応答調整:インシデント対応のスケーラビリティを向上させるために、研究や将来のワークショップの潜在的な分野を開催することができることをブレインストーミングします。

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

4. モニタリングと測定:プライバシーをアドレス指定するための必要なニーズと要件で監視と測定を実行するためのブレインストーム。

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

5. 分類法とギャップ:提案されたスマートリサーチグループのために前進するようなブレインストーミング。

4.1. Breakout 1 Results: Standardization and Adoption
4.1. ブレイクアウト1結果:標準化と採用

This breakout session considered points raised in the preceding talks on hurdles for automating security controls, detection, and 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 following subsections detail the results.

このブレイクアウトセッションは、セキュリティコントロール、検出、および応答を自動化するためのハードルに関する前の講演で提起されたポイントを検討しました。今日はまだ直面しているいくつかの課題を発表しています。ブレイクアウトセッションは、採用を達成することに成功した標準プロトコルとデータフォーマットの識別に及ぼし、失敗したか、または限られた採用のみを達成しました。評価の結果は興味深いものであり、新しい作業区域が開発されたときにより大きな採用の達成に役立ち得る。結果について詳しく説明します。

4.1.1. Wide Adoption
4.1.1. 広い採用

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

トランスポート層セキュリティ(TLS)プロトコルは、Secure Sockets Layer(SSL)プロトコルを置き換えました。

Observations: There was a clear need for session encryption at the transport layer to protect application data. 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, after decades, being replaced by a newer alternative, YANG (a data modeling language) that facilitates configuration management via the Network Configuration Protocol (NETCONF) or RESTCONF. SNMP facilitated an answer to a needed problem set: configuration, telemetry, and network management. 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.

単純なネットワーク管理プロトコル(SNMP)は、プライベート構成および管理設定の拡張ポイントを持つデバイスの構成管理を可能にします。SNMPは広く採用されており、何十年もの間にのみ、ネットワーク構成プロトコル(NETCONF)またはRESTCONFを介して構成管理を容易にする新しい代替案(データモデリング言語)に置き換えられます。SNMPは、必要な問題セットの答えを促進しました。構成、テレメトリ、ネットワーク管理。その開発は、ユーザー、ベンダー、および開発者の間の接続を考慮しました。採用のための説得力のある理由がないため、SNMPV1.1から1.2の範囲の課題は表面を表しました。SNMPv3は、認証と暗号化の向上を介して保護を提供することによって攻撃を攻撃することによる採用を獲得しました。

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

IPフロー情報エクスポート(IPFIX)は、いくつかの理由で広い採用を達成するために識別されました。低コストのエントリー、広いベンダーサポート、多様なユーザーベース、および複数の技術分野にまたがるユースケースの幅広いユースケースは、引用されています。

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.

X.509は、採用を得ることの成功のために調査されました。解決策は、Crypto、Open、Customizable、およびExtensibleから抽象化されていました。チームはそれが良い問題を良く解決し、政府の採用がその成功を支援したことを観察した。

4.1.2. Limited Adoption
4.1.2. 限られた採用

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

次に、各チームは幅広い採用を受けていないソリューションを評価しました。

Although Structured Threat Information eXpression (STIX) and 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.

構造化された脅威情報表現(STIX)と入射オブジェクト記述交換フォーマット(IODEF)は、その目標がやや類似していますが、一般的な調査結果を持つ2つの別々のグループによる評価のために規格が選択されました。

STIX has had limited adoption by the financial 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, as managing content may be the primary use case.

Stixは、金融分野による採用が限られていましたが、独身の決定的なエンドユーザーはいませんでした。標準は、米国政府がOASISと提携しているプライマリ開発者として開発されています。コンテンツを管理するためにStixを使用するには興味がありますが、ユーザーはどのテクノロジがExchangeに使用されているかを本当に気にしません。初期目標は、コンテンツを管理することが主なユースケースである可能性があるため、STIXの終了結果を一致させることはできません。

IODEF was specified by National Research and Education Networks (NRENs) and Computer Security Incident Response Teams (CSIRTs) and formalized in the 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, and this applies to STIX as well. Sharing and trust are additional hurdles as many are not willing to disclose information.

IODEFは、国家研究および教育ネットワーク(NRENS)とコンピュータセキュリティインシデント対応チーム(CSIRT)によって指定され、IETF [RFC7970]で形式化されました。ユーザーはセキュリティオペレーションセンター(SOC)です。複数の実装がありますが、広く採用されていません。交換の面では、ユーザーはフルイベント情報よりもインジケータに興味があり、これはStixにも当てはまります。共有と信頼は、多くのものが情報を開示しても構わないと思っていません。

DNS-Based Authentication of Named Entities (DANE) has DNSSEC as a dependency, which is a hurdle 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>. The website allows you to test your website for a number of standards (IPv6, DNSSEC, DANE, etc.). <internet.nl> is a collaboration of industry organizations, companies, and the government in the Netherlands and is available for worldwide use.

名前付きエンティティ(DANE)のDNSベースの認証は、依存関係としてDNSSECを持っています。これは、採用に対するハードルです(依存関係が多すぎます)。それは危険なロールあなた自身の採用モデルを持っています。採用の大きなポケットがいくつかありますが、広範囲の採用を得るためにやるべきことはまだ多くあります。規制要件はドイツで部分的な採用を引き起こし、それは当然ドイツ語で書かれた文書の生産をもたらしました - おそらくドイツ語を話す国でのさらなる採用を引き起こしました。<internet.nl>の創設を通じてオランダでも行われています。Webサイトでは、標準(IPv6、DNSSEC、デーンなど)についてWebサイトをテストできます。<internet.nl>はオランダの産業組織、会社、政府の協力であり、世界的な使用に利用可能です。

IP version 6 (IPv6) has 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, and the breakout team considered it too ambiguous. Too many new requirements have been added over its 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.

IPバージョン6(IPv6)は苦労しており、デュアルスタックを実行する費用は、ワークショップブレイクアウトで説明されているリストに対する最も高い懸念の1つでした。IPv6のためのエンドユーザーはすべての人であり、ブレイクアウトチームはそれがあまりあいまいだと見なしていました。20年の生活にあまりにも多くの新しい要件が追加されました。必要な採用の範囲は、多数の周辺機器で大きいです。支援の政府の要求は、相互運用性と採用の改善があるが、IPv4に遅くなったNATが追加されているような機能を備えています。IPv4に追加されていない機能がなくなり、学んだレッスンはまだ成功の可能性があります。

4.2. Breakout 2 Results: Preventative Protocols and Scaling Defense
4.2. ブレイクアウト2結果:予防プロトコルとスケーリング防御

This breakout session followed the sessions on MUD, Protocol for Automated Vulnerability Assessment (PAVA), and Protocol for Automatic Security Configuration (PASC), which have themes of automation at scale. MUD was designed for 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 breakout session was focused on groups brainstorming preventative measures and enabling vendors to deploy mitigations.

このブレイクアウトセッションは、泥、自動脆弱性評価のためのプロトコル、および自動化のテーマがスケールでテーマを持つ自動セキュリティ構成(PASC)のプロトコルに関するセッション。泥は物事のインターネット(IoT)のために設計されています、そしてそれ自体スケーリングは大きな考慮でした。PavaとPASCの仕事は泥から蓄積し、同じテーマのいくつかを維持します。このブレイクアウトセッションは、予防策をブレインストーミングし、ベンダーが軽減を展開することをグループ化しました。

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, 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), 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, manufacturers, etc. There was some discussion on the use of 802.11 to improve connections [IEEE802.11]. Several participants from this group plan to research this further and identify options to prevent information leakage while achieving the stated goals of MUD.

1つのグループが泥水とレイヤ2(L2)の発見に少し深く鳩を覆いました。 MUDは、スケールをする予測可能なプラットフォームのベンダーまたは中間泥のベンダーにフィルタリング制御管理のセットを変更します。 MUDの全体的な価値は明らかであるが、特定の装置に対して泥の使用および特定の装置に対してどのトラフィックが予想されるかは、装置を利用するために使用される可能性があるので、機密情報と見なされるべきである。 Mudは、泥ファイルを共有するためにL2ディスカバリーを使用するオプションがあります。 Dynamic Host Configuration Protocol(DHCP)のようなL2ディスカバリーは、この時点でローカルクライアントからDHCPサーバーに暗号化されていません(これを修正することは興味がありますが、まだ十分なサポートがありません)。その結果、情報を漏洩させ、泥ファイルが適用される装置に関するデータを明らかにすることが可能である。これは、ネットワーク特性、ファームウェアバージョン、製造業者などの情報をマルチキャストすることができ、接続を改善するための802.11の使用に関するいくつかの議論があった[IEEE802.11]。このグループからのいくつかの参加者がこれをさらに研究し、泥の述べられた目標を達成しながら情報漏洩を防ぐためのオプションを特定するための計画を計画しています。

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 Server Name Indication (SNI) using DNS to obtain public keys. The suffix on server IPv6 would be unique to a TLS session (information missing). The discussion on this proposal was 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, and to provide assessments on the impact of protocol changes on security in the round.

次のグループは、参加者の1つの提案がすでに開発を開始したこと、すなわちランデブーサービスのプライバシーを議論した。基本的なアイデアは、DNSを使用してサーバー名指示(SNI)を暗号化して公開鍵を取得することでした。サーバーIPv6のサフィックスはTLSセッションに固有のものです(情報がありません)。この提案に関する議論は、参加者の完全なセットとして、インシデント対応者からの特別な興味を早期のレビューサイクルに関与させるための特別な興味を持って実りありました。事件応答者は、プロトコビがどのように変更されるかを理解し、プライバシーとセキュリティ操作の変化の全体的な影響を評価することに非常に興味があります。このレビューから議定書の提案に変更がない場合でも、このグループディスカッションは、新しい戦略を考案し、新しい戦略を考案し、その影響に関する評価を提供するための早期に迅速な影響を理解するための貴重な交換です。ラウンドのセキュリティに対するプロトコル変更の影響

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 group dove deeper into this topic.

3番目のグループは、個人間の関係に大きく頼る信頼交換に戻った。彼らは信頼モデルのスケーリングとそれをする方法を見つけることに関係していました。グループはこのトピックをより深く様々に述べています。

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

4番目のグループは、インシデントレスポンダのための有用なデータについて説明しました。これは最初のブレークアウトセッション上に構築されています(セクション4.1)。グループは、妥協点(IOCS)の指標が、ほとんどの組織とグループが正常に交換できるものであると判断しました。理想的には、これらは固定されプログラム可能です。彼らはイベントの脅威を共有するための豊かな形式の開発について議論しました。グループに報告するときは、EUで使用されている成功したソリューションが挙げられました。マルウェア情報共有プラットフォーム(MISP)[MISP]。これは、新しいものが必要かどうかを判断するための既存の努力の見直しにおいて考慮されます。

4.3. Breakout 3 Results: Incident Response Coordination
4.3. ブレイクアウト3結果:インシデント応答調整

Incident response coordination currently does not scale. This breakout session focused on brainstorming 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

* 恐れは最初に活動をもたらす、または使用されるダイアグラム、風のバーストの観点から、そして最終的には満足している

What creates drag:

ドラッグを作成するもの

* Lack of clear Key Performance Indicators (KPIs)

* クリアキーパフォーマンスインジケータの欠如(KPIS)

* Too many standards

* 標準が多すぎます

* 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

* 新興技術の不明な影響

* Overcentralization of the Internet

* インターネットの外観

* New technologies and protocols

* 新しい技術とプロトコル

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

* アプリケーション層構成の変更(例えば、ブラウザのリゾルバ)

4.4. Breakout 4 Results: Monitoring and Measurement
4.4. ブレイクアウト4結果:監視と測定

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. Dave and his coauthor, Arthur Berger, primarily focus on measurement 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.

4番目のブレイクアウトセッションは、IPv6セッションのプライバシーを提供するために、IPv6集計に関するDave PlonkaのTalkに続いた。基本的に、IPv6はセッションを監視するための追加の機能を提供します。Daveと彼の共著者、Arthur Bergerは、主に測定研究に焦点を当てていますが、ユーザーのプライバシーの維持を支援するためにセッションを集約する方法を見つけました。プライバシーを保護する方法を保護する方法を収容しながら、管理と測定を実行する方法を考案するか、またはセキュリティ機能を実行できる場合は、より強い結果があります。これはまた、測定目標を倒すための追加のプライバシー改善作業の必要性を排除する。

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 four highest then explored by the breakout groups. Groups agreed to work further on the proposed ideas.

このブレイクアウトセッションは、プライバシーの前進に関する考慮事項と相まって、監視と測定を実行する方法の考案に焦点を当てていました。フルグループは、プロトコルがそれらを探索してランク付けするためのオプションを列挙し、4つの最上はブレイクアウトグループによって探索されました。提案されたアイデアについてさらに働くことに合意した。

4.4.1. IP Address Reputation
4.4.1. IPアドレスの評判

There is a need to understand address assignment and configuration for hosts and services, especially with IPv6 [PlonkaBergerCARIS2] in (1) sharing IP-address-related information to inform attack response efforts while still protecting the privacy of victims and possible attackers and (2) mitigating abuse by altering the treatment, e.g., dropping or rate-limiting, of packets. Currently, there is no database that analysts and researchers can consult to, for instance, determine the lifetimes of IPv6 addresses or the prefix length at which the address is expected to be stable over time. The researchers propose either introducing a new database (compare PeeringDB) or extending existing databases (e.g., the regional Internet registries (RIRs)) to contain such information and allowing arbitrary queries. The prefix information would either be provided by networks that are 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 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; Dave Plonka is the lead contact for those interested in helping to develop this further.

特にIPv6 [PLONKABERGERCARIS2]のアドレスの割り当てと設定を理解する必要があります[PlonkaberGerCaris2]は、犠牲者のプライバシーを保護しながら攻撃対応の取り組みを妨げ、可能性のある攻撃者と(2) )治療を変更することによって虐待を緩和すること、例えば、パケットの落下または率制限。現在、アナリストや研究者が、例えば、IPv6アドレスの寿命またはアドレスが経時的に安定していると予想されるプレフィックス長に相談できるデータベースはありません。研究者らは、新しいデータベースを導入するか、またはそのような情報を含む既存のデータベース(例えば、地域インターネットレジストリ(RIRS))を紹介し、任意のクエリを可能にすることを提案する。接頭辞情報は、インターネット測定値[Plonkabergerkip]に基づいて妥当な値を逆転させる測定アルゴリズムに基づいているネットワークによって提供されます。前者の場合、そのような情報を提供するためのネットワークのインセンティブは、それらのユーザのプライバシーが尊重され、必要なネットワークのアドレスのより多く、例えば虐待の直面に影響を及ぼすアクセス制御リストによって引き起こされる担保の損傷を制限することである。これは早期の考えです。 Dave Plonkaは、これをさらに発展させるのに役立つ人々のためのリードコンタクトです。

4.4.2. Server Name Authentication Reputation C (SNARC)
4.4.2. サーバー名認証レピュテーション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 connections and would be human readable. In addition, it builds on zero trust networking and avoids consolidation, thus supporting legitimate new players. SNARC has a similar theme to the IP reputation/BGP ranking idea mentioned above. SNARC is not currently defined by an RFC; however, such an RFC would help customers and design teams on existing solutions. The group plans to research visual aspects and underlying principles as they begin work on this idea. They 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. Trent Adams is the lead contact for those interested in working with this team.

SNARCは、良好または悪い俳優についての決定を下すために使用される、信頼指標に価値を割り当てるためのメカニズムです。このメカニズムは、クライアントとサーバーの接続を区別することができ、人間が読めることができます。さらに、それはゼロの信頼ネットワーキングで建てられ、統合を回避し、それによって正当な新しいプレーヤーをサポートします。SNARCは上記のIPの評価/ BGPのランキングのアイデアと同様のテーマを持っています。SNARCは現在RFCによって定義されていません。ただし、そのようなRFCは既存のソリューションに関する顧客とデザインチームを支援します。当グループは、この考えに取り組んできたときに視覚的側面と根本的な原則を研究することを計画しています。彼らはいくつかの段階で仕事を始め、「信頼」の値の計算、そして「信頼」に適用する研究行動を調査することを計画しています。包括的な目標は、盲目の信頼に対処することで、情報/入射交換で識別された課題の1つです。Trent Adamsは、このチームを扱うことに興味がある人のためのリードコンタクトです。

4.4.3. Logging
4.4.3. ロギング

The 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. Using a log-injecting compiler would increase logging for those applications and improve the uniformity of logged activity. Increasing logging capabilities at the endpoint is necessary as the shift toward increased use of encrypted transport continues. Nalini Elkins is the lead contact for those interested in developing this further.

グループは、アプリケーションのコンパイル時にロギング機能を注入する可能性を示し、合意された条件のセットをカバーする、より一貫したログセットをもたらしました。ログインジェクションコンパイラを使用すると、それらのアプリケーションのロギングが増加し、ログに記録されたアクティビティの均一性を向上させます。暗号化されたトランスポートの使用の増加に向けたシフトが続くにつれて、エンドポイントでのロギング機能の向上が必要です。Nalini Elkinsは、これをさらに発展させることに興味がある人のためのリードコンタクトです。

4.4.4. Fingerprinting
4.4.4. 指紋

Fingerprinting has been used for numerous applications on the Web, including security, and will become of increasing importance with the deployment of stronger encryption. 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 in deriving methods to validate the authenticity without identifying the source of traffic. They are also concerned with scaling issues. William Weinstein is the lead contact for those interested in working with this team.

指紋は、セキュリティを含むWeb上の多数のアプリケーションに使用されており、より強い暗号化の展開で重要性が高まっています。FingerPrintingは、復号化を使用せずにトラフィックを識別する方法を提供します。グループはプライバシーの考慮事項について議論し、セキュリティ上の利益を達成する方法(悪意のあるトラフィック、情報漏洩、脅威指標などを識別する)をどのように実現しました。それらは、トラフィックの送信元を識別せずに信頼性を検証するためのメソッドを派生させることに興味があります。彼らはまたスケーリングの問題にも関心があります。William Weinsteinは、このチームを扱うことに興味がある人のためのリードコンタクトです。

4.5. Taxonomy and Gaps Session
4.5. 分類法とギャップセッション

At the start of the second day of the workshop, Kirsty Paine and Mirjam Kühne prepared (and Kirsty led) a 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 Research Group. Several taxonomies were presented for review and discussion. The topic remains open, but the following key points were highlighted by participants:

ワークショップの2日目の開始時に、Kirsty PaineとMirjamKühneが準備された(そしてKirsty LED)、インシデント対応、攻撃、および脅威の検出、解決策を比較し、ギャップの識別で使用される分類法を議論するためのワークショップスタイルのセッション。主な目的は、提案されているスマートリサーチグループで使用される言語を選択することによって進む経路を決定することでした。審査と議論のためにいくつかの分類法が提示されました。トピックは開いたままですが、参加者によって次の主な点が強調表示されていました。

* 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., attribution of the attack, mitigation steps, technical features, or organizational impact measurements.

* 単一の分類法は、どの分類を使用しているかによって、どの分類が使用しようとしているのか、例えば、攻撃、緩和ステップ、技術的特徴、または組織的影響測定の帰属がどのような問題に依存している可能性があります。

* A tool to map between taxonomies should be 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, for management reporting, they only use 8 categories to lighten the load on analysts, whereas some of the taxonomies contain 52 categories.

* 管理への報告および事件を調査するアナリストのために必要な詳細レベルは非常に異なり得る。ワークショップでは、管理報告のために、アナリストの負荷を軽減するために8つのカテゴリを使用するだけであると述べた、1人の出席者は、アナリストの負荷を軽減するために8つのカテゴリを使用していると述べました。

* How you plan to use the taxonomy matters and may vary between use cases. Take, for 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, there is a clear need to update terminology in this publication around this space in particular. This is likely to be raised in the Security Area Advisory Group (SAAG) during the open mic session, hopefully with proposed new definitions to demonstrate the issue and evolution of terms over time.

* [RFC4949]簡単に説明した。しかしながら、特にこのスペースについてこの出版物の用語を更新することは明らかな必要性がある。これは、オープンマイクセッション中にセキュリティエリアアドバイザリーグループ(SAAG)で提起される可能性があります。

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

* 分類法の中で、脅威の影響や攻撃の影響を理解するための優先順位付けが重要です。異なる分類法の間にどのようにマッピングしますか?解決する問題は何ですか、そしてどのようなツーリングが必要か?

* Attack attribution had varying degrees of interest. Some felt the public sector cared more about attribution, not about individuals. They were interested in possible motivations behind an attack and 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 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.

この議論の結果は、1つの分類法まで絞り込まれていませんでしたが、タシンの間のマッピングと情報交換または共有のためのユースケースとの間のマッピングについて考えることは、最終的には脅威と攻撃について議論するための一般的な方法を生じさせます。研究者らは一般的な語彙を必要としており、必ずしも一般的な分類法ではありません。

5. Next Steps
5. 次のステップ

The next steps from the CARIS2 workshop are twofold:

CARIS2ワークショップからの次のステップは2倍です。

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.

1. 2番目のカリスワークショップから生まれた研究イニシアチブは、さらなる探査と開発を必要とします。この開発を育み、提案された各プロジェクトの周囲のコミュニティの作成は最初のステップであり、レポートはスマートメーリングリストに戻ります。

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

2. 2番目のイニシアチブは、次のCaris Workshopを計画します。

6. Summary
6. 概要

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 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:

ワークショップを包むとき、私たちはフォローアップとして実際の興味のための感触を得るために合意されたプロジェクトのリストを検討しました。2日間のワークショップの過程を通して、より大きな潜在的な研究項目が生成されていました、そして、これは参加者に、彼らが予想される成果に一致することを約束するための約束を再評価する機会を与えました。アイデアを推進するための興味のある最も高いランキングプロジェクトは次のものを含んでいました:

* Traffic fingerprinting

* トラフィックフィンガープリント

* SNARC

* sn

* Attack coordination solutions and automated security

* 攻撃調整ソリューションと自動セキュリティ

* Cryptographic rendezvous

* 暗号化されたランデブー

* L2 discovery

* L2発見

7. Security Considerations
7. セキュリティに関する考慮事項

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

これは情報ワークショップサマリーレポートですので、セキュリティ上の考慮はありません。

8. IANA Considerations
8. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

9. References
9. 参考文献
9.1. Informative References
9.1. 参考引用

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

[Carisevent]インターネット社会、「CARIS2:インターネットスケールでの攻撃対応調整」、<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/>.

[赤字] Morgan、S.、2019年10月、2019年10月、<https://cybersecurityures.com/jobs/>を参照してください。

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

[I2NSF] IETF、「ネットワークセキュリティ機能へのインタフェース(I2NSF)」、<https://datatracker.ietf.org/wg/i2nsf/about>。

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

[IEEE802.11] IEEE、「IEEE 802.11ワイヤレスローカルエリアネットワーク」、<https://www.ieee802.org/11/>。

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

[MISP] MISP、「マルウェア情報共有プラットフォーム」、<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>.

[PlonkabergerCaris2] Plonka、D.およびA. Berger、「IPv6アドレス匿名化およびアイデンティティ協会への測定」、CARIS2用紙提出、2019年3月、<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>.

[Plonkabergerkip] Plonka、D.およびA. Berger、「KIP:IPv6アドレス匿名化の測定アプローチ」、2017年7月、<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>.

[QUIC] Iyngar、J.およびM. Thomson、「QUIC:UDPベースの多重化および安全な輸送」、進行中の作業、インターネットドラフト、ドラフト-IETF-Quic-Transport-33,23月13日、<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>.

[RFC4949] Shirey、R.、 "Internet Security Glossary、バージョン2"、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<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>.

[RFC7970] DanyLIW、R。、「インシデントオブジェクトの説明交換フォーマットバージョン2」、RFC 7970、DOI 10.17487 / RFC7970、2016年11月、<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>.

[RFC8073] MoriAlty、K.およびM.フォード、「インターネットスケールでの攻撃対応(CARIS)ワークショップレポートの調整、RFC 8073、DOI 10.17487 / RFC8073、2017年3月、<https://www.rfc-editor.org/情報/ 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>.

[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ(TLS)プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<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>.

[RFC8520] Lear、E.、Droms、R。、RFC 8520、DOI 10.17487 / RFC8520、2019年3月、<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>.

[RFC8548] Bittau、A.、Giffin、D.、Handley、M.、Mazieres、D.、Slack、Q.、およびE.Smith、「TCPストリームの暗号保護(TCPCRYPT)」、RFC 8548、DOI 10.17487 /RFC8548、2019年5月、<https://www.rfc-editor.org/info/rfc8548>。

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

[スマート] IRTF、「マルウェアを停止し、脅威の調査(SMART)」、<https://datatracker.ietf.org/group/smart/about/>。

Acknowledgements

謝辞

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

インターネットスケールでの攻撃対応を進めるために、彼らの考え、エネルギー、そして意欲を持ってきたCARIS2ワークショップ参加者のそれぞれに感謝します。

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 Society, UK); Jamie Gillespie (APNIC, AU); Chris Inacio (CERT/CC, US); Mirja Kühlewind (ETH Zurich, CH); Mirjam Kühne (RIPE NCC, NL); Carlos Martinez (LACNIC, UY); Kathleen M. Moriarty, Chair (Dell EMC); Kirsty Paine (NCSC, UK); and Takeshi Takahashi (NICT, JP).

プログラム資料、論文、およびワークショップフォーマットに関するガイダンスについての見直しのためのプログラム委員会の各メンバーに大きな感謝します。マットフォード(インターネット協会、イギリス)。Jamie Gillespie(APNIC、AU);クリス・インジオ(CERT / CC、US);MirjaKühühlewind(Eth Zurich、CH);MirjamKühne(熟したNCC、NL);Carlos Martinez(Lacnic、UY);Kathleen M. Moriarty、チェア(Dell EMC);Kirsty Paine(NCSC、イギリス)。高橋武(NICT、JP)。

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

コラボレーションを成功させるためのブレイクアウトセッションやツールのフォーマットに関する彼女のレビューとガイダンスのために、私のレビューとガイダンスのためのMegan Hyland(Dell EMC)をありがとう。

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

微調典士、赤土カレン、シン・ニンジェン(Dell EMC Octo Cambridge Dojoチーム)をありがとうございました。

Author's Address

著者の住所

Kathleen M. Moriarty Center for Internet Security 31 Tech Valley Drive East Greenbush, NY 12061 United States of America

Kathleen M. MoriArtyインターネットセキュリティ31テックバレードライブEast Greenbush、NY 12061アメリカ合衆国

   Email: kathleen.moriarty.ietf@gmail.com