Coordinated vulnerability disclosure

協調的脆弱性開示（CVD）

セキュリティ脆弱性を報告・受領・調整する方法。ポリシーの例付き。

協調的脆弱性開示（Coordinated vulnerability disclosure、CVD）はコンピュータセキュリティの用語です。セキュリティ上の問題について、人々がどのように報告を共有できるかを説明します。例として、バグ報告、侵入のリスク、ハッキングの警告、データ漏えい、ウェブサイトへの侵害などがあります。

翻訳: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

目次:

ポリシー:

はじめに

この文書は、人々が協力して取り組むうえで役立つよう、協調的脆弱性開示について説明します。

この文書の目標:

  1. セキュリティ上の問題を発見し、報告したいと考える人を支援します。

  2. 企業の担当者が、責任ある開示のニーズ、目標、実践、そして特殊なケースを理解できるよう支援します。

  3. リポジトリのフォルダーに、協調的脆弱性開示ポリシーの例を収録します。

プルリクエスト、GitHub の Issue、または security@joelparkerhenderson.com へのメールを歓迎します。

協調的脆弱性開示とは？

協調的脆弱性開示は、誰かがセキュリティ上の問題（ソフトウェアのバグなど）を発見し、それを製作者（そのソフトウェアを作った会社など）に報告したい場合の、3つのステップを表します。

ステップ:

  1. 発見者は、誠意をもって、問題を製作者に非公開で報告します。

  2. 製作者は、誠意をもってユーザーを守ろうとし、問題に対処しようとします。

  3. 一定の期間が経過した後、そのセキュリティ上の問題が公開されます。

ステップ1：問題を報告する

ステップ1は発見者のためのものです。誠意をもって、問題を非公開で報告します。

  • 良い例: 発見者が関連情報を製作者に送る。たとえば、製作者のセキュリティ用メールアドレス（通常は「security@example.com」）宛てにメールを送る、または製作者のウェブサイトのウェブフォーム（通常は「https://www.example.com/security」）から送る。

  • 悪い例: 報告を公開ブログに投稿する、メディアに知らせる、脅迫する、セキュリティ上の問題をハッカーに売ろうとする、など。

  • ヒント: 発見者は匿名を選んでもかまいません。製作者も匿名を選んでかまいません。

希望する場合は、その問題に引き続き注意を払ってください。

  • 良い例: 連絡経路を開いておく、続報を提供する、状況を監視する。

  • 悪い例: 問題のことを忘れてしまう。

  • ヒント: 発見者は、協力するかどうか、連絡を取り続けるかどうかを選ぶことができ、状況が変われば取り決めを変更することもできます。

希望する場合は、問題を他の人々に開示してください。

  • 良い例: 定められた期間を待ってから公開する。たとえば、セキュリティ関連のニュースサイトに関連情報を投稿する、関係する第三者のセキュリティ研究者に連絡する、公開のソーシャルサイトで問題を告知する、など。

  • 悪い例: 問題を他の人々に開示しない。ただし、開示することで自分自身や他の人々が同程度を超えるリスクにさらされると感じる場合は除きます。

  • ヒント: 状況が変わった場合、たとえばより高いリスクや、実際の攻撃（active exploit in the wild）が見つかった場合には、発見者はより早く他の人々に問題を開示してもかまいません。

ステップ2：連絡先を確保する

ステップ2は製作者のためのものです。連絡先が実際に機能するようにします。

担当スタッフの対応力を確保します。

  • 良い例: 製作者が、セキュリティに関する問い合わせを受けたときの対応方法をサポート担当者に教育する。たとえば、連絡先情報を伝えて返信する方法や、問い合わせを適切な社内チームに転送する方法です。

  • 良い例: 製作者が、スタッフの対応力が機能していることを定期的に確認する。

  • 悪い例: 製作者が教育も確認も行わない。

期限内に発見者へ返信します。

  • 発見者が期限を指定していない場合は、1営業日を使用してください。これが業界標準であり、現在の業界のベストプラクティスだからです。

  • 発見者が質問をしたら、答えてください。発見者がテストの許可を求めている場合は特に重要です。すべての回答が明確で率直であることを徹底してください。

権限のあるセキュリティ連絡窓口や、権限のあるセキュリティ対応プロセスを通じて、発見者に返信します。

  • 良い例: 「security@example.com」のようなセキュリティ専用のメールアドレスからの返信。

  • 悪い例の一例: 「help@example.com」のような汎用のメールアドレスからの返信、または権限のあるセキュリティ専門家ではない人からの返信。

その問題がセキュリティ報告として認識されたことを、発見者に伝えます。

  • 良い例: セキュリティに特化した文言。たとえば「弊社のセキュリティチームは、あなたの責任ある開示の報告を受領しました」、「弊社のセキュリティプロセスでは次のステップがあります」、「あなたの情報は現在、ID番号 XYZ で弊社のセキュリティトラッカーに登録されています」など。

  • 悪い例: 汎用的な文言。たとえば「ご利用ありがとうございます」、「セキュリティを真剣に受け止めています」、あるいはたらい回しの文言、たとえば「あなたのメールを別の部署に送りました」など。

ステップ3：誠実に協力する

ステップ3は、発見者と製作者がともに行うものです。誠意をもって協力します。

協調的脆弱性開示は、誠意に基づくプロセスであることを理解してください。

  • 第一の目標は、ユーザーがセキュリティ上のリスクから自分自身を守れるよう、誠意をもって助けることです。

  • 第二の目標は、セキュリティ上の問題に誠意をもって対処することです。

  • 発見者や製作者は、誠意をもって他のセキュリティ関係者を関与させることを選んでもかまいません。たとえば、問題の解決を助けてもらうために、関係する他のセキュリティ研究者に連絡することです。

協調的脆弱性開示は、いかなる義務も生じさせないことを理解してください。

  • 発見者や製作者は、いつでも、どんな理由でも、予告の有無にかかわらず、手を引くことができます。関係者全員に最新情報を伝え続けるのは礼儀正しいことですが、それが常に可能、現実的、または望ましいとは限りません。

  • 協調的脆弱性開示は、いかなる法的合意も生じさせません。発見者と製作者の間にすでに法的合意がある場合は、関係者全員が適切な弁護士に相談することをお勧めします。この文書を法的助言として使用しないでください。

協調的脆弱性開示は、良好なコミュニケーションを用い、脅しを退けることを目指していることを理解してください。

  • 協調的脆弱性開示は、関係者全員が、第一の目標がユーザーのセキュリティ上のリスクからの自己防衛を助けること、第二の目標がセキュリティ上の問題に対処することだと理解しているとき、最もうまくいきます。

  • 協調的脆弱性開示は、報復、威嚇、停止、取り消し、恐喝、フォローアップの負担、被害者非難といった、あらゆる種類の脅しを拒否します。

協調的脆弱性開示は、人によって意味が異なる場合があることを理解してください。

  • 発見者と製作者は、協調的脆弱性開示について異なる理解をしているかもしれません。それらの理解は互いに一致しないかもしれません。誠意とは、関係者全員がこのことを理解していることを含みます。

  • 協調的脆弱性開示ポリシーを公開している製作者もいます。これらは役立つガイダンスになりえます。発見者が別の種類の協調的脆弱性開示を用いることを選んだり、責任ある開示について異なる理解を持っていたりしても、まったくかまいません。

通常、発見者は公開者のために善意の行為をしているのだと理解してください。

  • 通常、発見者は脆弱性を公開するために誰かの許可を得る必要はありません。

  • 通常、発見者の情報は公開者の助けになります。

成功の確認

問題が解決した後、製作者は成功を確認しなければなりません。

  • すべての関係者とプロセスは、開示にうまく対処できたか。できていれば良好です。そうでなければ、事後調査を検討してください。たとえば、根本原因分析（RCA）、ポストモーテム報告、石川ダイアグラム（特性要因図）、システム理論に基づく因果分析（CAST）などです。

  • 未解決の問題は、トリアージされ追跡されているか。

  • 製作者と発見者は、今後のステップについて、ともに何をすべきか理解しているか。今後に協調的脆弱性開示が続く可能性がある場合、これを正しく把握しておくことは特に重要です。

ガイダンス

協調的脆弱性開示のガイダンスは、倫理の専門家、法律の擁護者、一般市民の合理的な期待など、さまざまな分野から得られます。

ガイダンスを探している場合は、以下に説明する3つの分野に関心があるかもしれません。

  • 善きサマリア人

  • 救助義務

  • 注意義務

善きサマリア人

Wikipedia: 善きサマリア人の法

善きサマリア人の法は、負傷している、病気である、危険にさらされている、またはその他の理由で行動できない状態にある（あるいはそうだと信じられる）人に、合理的な援助を行った人に法的保護を与えます。この保護は、訴えられたり起訴されたりすることへの恐れから、傍観者が援助をためらうことを減らすことを目的としています。

救助義務

Wikipedia: 救助義務

救助義務とは、危険にさらされている他者を救助しなかったことについて、ある者が責任を問われうる状況を表す概念です。救助義務には、道徳的な側面や法的な側面がある場合があります。

注意義務

Wikipedia: 注意義務

注意義務とは、他者に害を及ぼすことが予見できる行為を行う際に、合理的な注意の基準を守る義務のことです。注意義務には、道徳的な側面や法的な側面がある場合があります。考慮すべき点には、害や傷害の予見可能性、起こりうる害や傷害の大きさ、被告が行った活動の重要性や社会的価値、その行為が被告にとって持つ有用性、代替行為の実行可能性、代替行為に伴う費用と負担、代替行為の相対的な有用性、代替行為の相対的な安全性があります。

特殊なケース

私たちのセキュリティチームは、さまざまな特殊なケースを見てきました。

何が許容され何が許容されないかについて、幅広い意見があることを人々が理解できるよう、ここで説明します。関係者全員が、これらについて誠意をもってコミュニケーションをとることをお勧めします。

他のユーザーの情報へのアクセス

例: URL に自分のユーザー ID が含まれていて、それがバグを明らかにしており、URL を編集して自分のユーザー ID を別のユーザー ID に変更できると考えられる場合。

  • 発見者がこれを行ってもよいか。たとえば、他のユーザーにも影響しているかどうかを調べることだけを目的とする場合は？

  • すべてのユーザーに対するリスクの広がりを素早く把握することは、すでにハッカーに情報が見えているかもしれない数人のユーザーを守ることよりも重要か。

  • 発見者が好きなだけ多くのユーザーに対してこれを行ってもよいか。

  • 発見者が影響を受けていることを知らせるためにユーザーへ連絡を試みてもよいか。軽減策の提案をしてもよいか。

サービス拒否

例: パスワードロックの発動など、バグによって意図せず自分のアカウントが停止される場合。

  • これはサービス拒否攻撃とみなされるか。

迷惑メール

例: 会社のなかで関係があると思われる人々に、LinkedIn や Facebook などを調べて見つけた人や、「webmaster@example.com」や「security@example.com」のような命名規則を使って、セキュリティ上の問題を報告しようとする場合。

  • これは許容されるか。

  • これは迷惑メール（unsolicited email）とみなされるか。

  • これは無許可のメール（unauthorized email）とみなされるか。

除外されるグループ

例: 未成年である、制裁リストに載っている、制裁リストに載っている国にいるなど、除外されるグループに属している場合。

  • 報告を行ってもよいか。

  • 匿名で報告してもよいか。

  • 除外されるグループから逃れるために、そして開示が適切な人々に届くようにするために、個人を特定しうる情報をわざと変更してもよいか。

第三者

例: ある企業のソフトウェアに、他のソフトウェアや別のウェブサイトとの連携など、第三者が関わるバグがあることを発見した場合。

  • 見つけたすべての情報を双方に報告してもよいか。

  • 各社に送る情報を制限する目的で、ある会社への報告と第三者の会社への別の報告という、2つの別々の責任ある開示を行う必要があるか。

  • 発見者が両社を引き合わせてもよいか。

妨害的なソフトウェア

例: ユーザーがセキュリティ上のリスクから身を守る、自分がリスクにさらされているかどうかを特定する、またはセキュリティ上のリスクを修正するのに役立つと考えられるウイルスを書けるだけの技能がある場合。

  • それは許容されるか。

  • 発見者が、この種のソフトウェアをユーザーに案内したり、この種のソフトウェアの作り方を説明するガイドやチュートリアルを案内したりしてもよいか。

協調的脆弱性開示と責任ある開示の違い

協調的脆弱性開示が、推奨される用語です。

  • 最も重要なのは、発見者と製作者の間の協調です。

責任ある開示（responsible disclosure）は、非推奨の用語です。

  • 責任あるとはどういうことかについて、人々の見方はさまざまです。たとえば、発見者は製作者とのやりとりにかかわらず直ちに公衆に知らせることが責任ある行動であり、協調的脆弱性開示は公衆から情報を隠すので無責任だと主張する人もいます。

トラッキング