マイクロソフト脆弱性報告窓口 ガイド (日本語)が、2021年6月16日に公表されています。
この「マイクロソフト脆弱性報告窓口 」(ダウンロード先リンク)のスライドは、以下のような表紙ですが、必見かと思います。
ここで、興味深いのは、
マイクロソフトの脆弱性報告窓口には、時折、この脆弱性関連情報の届出との関係についてご質問をいただくことがあります。例えば「脆弱性関連情報の届出をした場合でもマイクロソフトの脆弱性報告窓口に報告したほうがよいのか？」「脆弱性関連情報の届出と、マイクロソフトの脆弱性報告窓口はどちらに報告するべきか？」といった質問です。
といって、「情報セキュリティ早期警戒パートナーシップガイドライン」との関係についてのコメントがなされているところです。この「情報セキュリティ早期警戒パートナーシップガイドライン」の全体像については、ワクチン予約システムの報道とも関係して、「脆弱性の開示の枠組を深く勉強したい人に-ワクチンの予約システムの報道に関して」でふれたところでもあります。
ちなみに(お約束ですが)以下の私のコメントは、IPA もしくは、そこで開催されている脆弱性研究委員会の見解とは異なる筆者個人の意見です。
まず、そもそも、「情報セキュリティ早期警戒パートナーシップガイドライン」は、2003年当初から、検討が開始されていたものです。
最初の調査としては、『セキュリティホールに関する法律の諸外国調査』報告書 平成 15 年 8 月 29 日 経済産業省 セキュリティホールに関する法令等の国内外調査委員会 があります。この公表は、2003年8月です。
(ちなみリンクは、国立国会図書館 インターネット資料収集保存事業からです)
でもって、この年の12月くらいから、早期警戒パートナーシップの枠組の議論か始まります。この年の11月に起きたのが、Office氏事件ということになります。Office氏事件は、たとえば、「「不正アクセスとは何か」–office氏の判決を読み解く」をどうぞ。
でもって、2004年7月7日に「済産業省告示第235号 ソフトウエア等脆弱性関連情報取扱基準」が告示されました。ガイドラインと「情報システム等の脆弱性情報の取扱いにおける法律面の調査 報告書 」が公表されました(これらは、6月)。
本来は、ソフトウエアの開発者、流通者、ウェブサイトの作成者およびその責任者、開発関係者などによってその脆弱性情報が適切に共有されて、早急にその脆弱性に対して対策がなされるべきであるにもかかわらず、そのルートが明らかではないことによって、脆弱性情報の共有が図られず、脆弱性に対する対応が遅れがちになったり、その脆弱性情報が悪意ある者の間でのみ共有されることになったりしてしまっていると考えられる。
（２）手法
脆弱性情報を適切に収集し、それを分析・評価し、それに対する対応を促し、これらの関係者を調整する機能が、現状において欠けているものと認識されている。これらの機能を実現するために、本基準は、そのような機能を担わせるものとして関係の機関を指定し、それに関連して、関係機関への届出の際の基準、それらの関係機関の機能および行動基準、内部関係者の行動基準を定め、関係者には、それに応じる一定の行動を推奨するものである。
（３）目的
このような事実認識のもと、WGとしては、適切な脆弱性情報の流通ルールを提唱することにより、我が国における情報処理機能の機密性、完全性、可用性の確保・促進を図ろうとするのが妥当であるとの認識に到達した。脆弱性情報が、いわば、「闇に埋もれている」状態は、望ましいものではない。それを放置するよりも、適切なルートで「日のあたるところ」に拾い上げ、上記（２）の手法により適切な流通および共有を図ることにより、我が国のセキュリティが確保・強化・促進されるという認識に至ったということになる
ということです。(この報告書の3ページ)
ここで記載れているように
本来は、ソフトウエアの開発者、流通者、ウェブサイトの作成者およびその責任者、開発関係者などによってその脆弱性情報が適切に共有されて、早急にその脆弱性に対して対策がなされるべきであるにもかかわらず、そのルートが明らかではないことによって、脆弱性情報の共有が図られず、脆弱性に対する対応が遅れがちになったり、その脆弱性情報が悪意ある者の間でのみ共有されることになったりしてしまっていると考えられる。
ということだったのです。
ちなみに、2004年は、新年が上のOffice氏事件の報道で幕が明け、Yahoo! BB事件が起きて、個人情報保護法が制定されたり、日弁連コンピュータ委員会のシンポにNHKが入ったりと、情報セキュリティと法にとっては、ある意味、エポックメイキングな年でもありました。
—
その後、この早期警戒パートナーシップは、関係者に広く認知され、また、世界的にも、脆弱性情報についての調整の仕組みとして、非常に注目されるべきものになりました。脆弱性取扱手順については、「情報セキュリティ－セキュリティ技術 脆弱性取扱過程（ISO/IEC 30111:2013 Information technology — Security techniques — Vulnerability handling processes）」、脆弱性開示については、「情報セキュリティ－セキュリティ技術 脆弱性開示（ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure）」が制定、公表されたというのは、この早期警戒パートナーシップが世界に先駆けるプロジェクトであったということがわかるかと思います。
でもって、上記の「情報システム等の脆弱性情報の取扱いにおける法律面の調査 報告書」は、改定されることになります(2019年3月)。
この報告書では、
開発者が脆弱性情報に対応する役割を見直しつつあるという動きというのは、当初の制定された2003年時点においては、脆弱性という用語それ自体になじみがなかったし、それとソフトウエアの欠陥との違いというのも意識して議論されていることがなかった。また、開発者において、脆弱性をできるかぎり解消した製品を社会に提供するのが望ましいものであるという認識も非常に乏しかった。発見者から、脆弱性の報告を受けたからといって、むしろ、製品に対して何かクレームをつけられているかのような対応をとる開発者もいたといわれたところである。しかしながら、現在においては、脆弱性のもたらすセキュリティ上の脅威が社会においても許容しうるものではないという認識が一般化しつつある。開発者が、積極的に、脆弱性の届出受け付けの窓口をもうけるようになってきている 。制度が構築された時期と比較して、セキュリティの重要性の認識／脆弱性解消の努力の正当な評価という観点からするとき、非常に良い方向に進展していると評価することができる。そもそも、開発者の提供するソフトウエアが脆弱性なく安心して使えることは、現代社会においては、本来であれば、他の性能などと総合的に正当に評価されるべきひとつの要素である。ソフトウエアの利用者が、その開発者のセキュリティに対する積極的な対応姿勢などをも踏まえた総合的な判断をベースにソフトウエアを選択し、すぐれたものが社会に受け入れられるようになり、その一方で、脆弱性対応などに劣ったソフトウエアは、利用者の評価で劣ったものとして支持をうしなうものとなって、社会で利用されなくなり淘汰されるというのが望ましい姿である。このようなあるべき姿にむけて、社会においてプログラムにおいて脆弱性を減らしていこうという意識が高まっているというのは、きわめて重要な動きであるということができる。
と評価されているように変わってきているのです(改訂版4ページ)。
この文章でもわかるように
マイクロソフトが迅速に脆弱性の対応を開始するために、マイクロソフトの脆弱性報告窓口に直接報告することを了承いただける場合は、直接マイクロソフトの脆弱性報告窓口に報告をお願いいたします。
ということは、まさに、上の最初の記載の「本来は」という本来ありうべき姿に戻ったということにほかなりません。
でもって、上のマイクロソフトの「脆弱性報告窓口」というスライドをみていくこと(スライドへのリンク)にしましょう。スライドの表紙は、こんな感じです。
脆弱性報奨プログラム(Bug Bounty)、研究者表彰プログラム 、謝辞の掲載のプログラムがあります。対象プログラムの一覧があって、「Microsoft Hyper-V Hyper-V での重大なリモート コード実行、情報漏えい、およびサービス拒否の脆弱性」については、最大25万米ドルだそうです。
やっぱり、インセンティブは、現金だよね、ということで、うらやましい限りですね。
本当に興味深いのは、「セーフハーバーポリシ」ですね。
————————-
概要
- 私たちは、バグバウンティプログラムを通じて責任を持って情報を開示していただきたいと考えています。また、研究者が私たちのバグバウンティポリシーに誠実に従おうとしたために、法的な結果を招く恐れがあることを望んでいません。当社は第三者に効力を及ぼす(bind )ことはできませんので、この保護がいかなる第三者にも及ぶとは考えないでください。疑問がある場合は、当社のポリシーの範囲外になる可能性があると思われる特定の行動をとる前に、当社にお尋ねください。
- (高橋注・個人の)識別情報と非識別情報の両方が研究者を危険にさらす可能性があるため、当社では第三者と共有する情報を制限しています。ただし、あなたに通知し、その第三者があなたに対して法的措置をとらないという確約を得た後にのみ、あなたの報告書から得られた個人を特定できない実質的な情報を、影響を受ける第三者に提供することがあります。識別情報（氏名、電子メールアドレス、電話番号など）を第三者と共有するのは、お客様が書面で許可した場合のみです。
- バグバウンティプログラムの一環としてのお客様のセキュリティ調査が、当社サイトポリシーの特定の制限に違反する場合、セーフハーバー条項により、以下の限定的な免除が認められています。
1. セーフハーバー条項
セキュリティ脆弱性の研究と責任ある開示を奨励するため、マイクロソフトは、Microsoft Bug Bounty Terms and Conditions（以下、本ポリシー）の偶発的または善意の違反に対して、民事訴訟または刑事訴訟を起こしたり、法執行機関に通知を送ったりしません。マイクロソフトは、本ポリシーに基づいて行われるセキュリティリサーチおよび脆弱性の開示活動を、Computer Fraud and Abuse Act（コンピュータ不正使用防止法）、DMCA、およびWA Criminal Code 9A.90などのその他の適用可能なコンピュータ使用法に基づく「許可された」行為とみなします。当社は、バグバウンティプログラムの対象となるアプリケーションを保護するために当社が使用した技術的手段を回避した場合、お客様に対するいかなるDMCAの請求権も放棄します。
お客様のセキュリティ調査が（当社のではない）第三者のネットワーク、システム、情報、アプリケーション、製品、またはサービスに関わる場合、当社は、その第三者に対して、法的拘束力を及ぼすことはできないので、その第三者は法的措置または法執行機関の通知を求めることができることをご理解ください。当社は、他の事業体の名前でセキュリティ調査を行うことはできませんし、認めていません。また、お客様の行動を理由とした第三者の行動からお客様を守り、補償し、その他の方法で保護することは一切できません。
常に、お客様は、適用されるべての法を遵守することを求められており、私たちのバグバウンティプログラムが許諾することを越えて、データを破壊(disrupt ) し、または、漏洩させる(compromise)ことは求められていません。
本ポリシーと矛盾する、または本ポリシーで対処されていない可能性のある行為を行う前に、当社にご連絡ください。本ポリシーへの違反が偶発的なものであるか、善意によるものであるかを判断する権利は当社のみが有しており、何らかの行為を行う前に当社に積極的に連絡することは、その判断において重要な要素となります。疑問がある場合は、まず当社にお問い合わせください。
2. サードパーティのセーフハーバー
第三者のサービスに影響を与えるバグバウンティプログラムを通じて報告書を提出した場合、当社は影響を受ける第三者と共有する内容を制限します。当社は、お客様の報告から得られた非識別情報を影響を受ける第三者と共有することがありますが、それは、当社が共有する意図があることをお客様に通知し、お客様の報告に基づいて第三者がお客様に対して法的措置を講じたり、法執行機関との連絡を開始したりしないことを書面で確約してもらった後に限ります。当社は、お客様の書面による許可を得ることなく、お客様の識別情報を影響を受ける第三者と共有することはありません。
なお、当社は、第三者の名義での範囲外のテストを許可することはできず、そのようなテストは当社のポリシーの範囲外であることをご了承ください。そのようなテストは、当社のポリシーの範囲外となります。サードパーティのバグバウンティポリシーがある場合はそれを参照するか、サードパーティやそのサービスのテストを開始する前に、そのサードパーティに直接または法的代理人を通じて連絡してください。これは、あなたの行動に基づく第三者の行動からあなたを守り、補償し、その他の方法で保護するという当社側の合意ではなく、またそのように理解されるべきではありません。
とはいえ、お客様が本バグ報奨プログラムに参加したことが原因で、法執行機関を含む第三者からお客様に対して法的措置が開始され、お客様が当社のバグ報奨方針を十分に遵守していた場合（すなわち、意図的または悪意のある違反をしていなかった場合）、当社はお客様の行動が本方針を遵守して行われたことを周知させるための措置を講じます。当社は、提出された報告書を機密文書および潜在的な(秘匿)特権文書と考えており、ほとんどの状況で強制的な開示から保護されていますが、当社の反対にもかかわらず、裁判所が当社に第三者との情報共有を命じる可能性があることをご承知おきください。
3. 他のサイトポリシーの限定的な権利放棄
お客様のセキュリティ研究活動が、当社の関連サイトポリシーの特定の制限と矛盾していても、当社のバグバウンティプログラムの条件と一致している限り、当社は、このバグバウンティプログラムの下でお客様のセキュリティ研究を許可するという唯一かつ限定的な目的のために、これらの制限を放棄します。上記のように、疑問があれば、まず私たちに尋ねてください。
脆弱性の調査については、どこまで許されるのか、とか、その調査のために併発的に(コラテラルに)第三者の権利を侵害することは許されるべきではないのか、という問題が発生します。
これについては、
当社はお客様の行動が本方針を遵守して行われたことを周知させるための措置を講じます。
とあります。この点については、報告書 改定版では、
秘密保持契約が締結されていなかったり、ライセンス契約上に守秘義務条項が設けられていなかったりするケースでは、発見するために種々の利用をすることが、ライセンス契約違反ということは困難なように思われる。また、それによって得られた脆弱性情報の公開を禁止する趣旨というのを一般のライセンス契約に読み込むことは困難なように思われる。もっとも、公開の態様によっては刑事上民事上の問題が発生する可能性もあることに留意すべきであろう。
としているところですが、この点については、むしろ、法的な責任を問うことはないということが明らかになっているというのは、きわめて大きな意味があるかと思います。
また、
当社は、提出された報告書を機密文書および潜在的な(秘匿)特権文書と考えており、ほとんどの状況で強制的な開示から保護されていますが
というのもあります。報告書改定版では、情報公開法との関係で触れています。
バグ報告ガイドライン
興味深いのは、スライドの16ページの「バグ報告ガイドライン」になります。このような脆弱性の報告の取扱については、どのような内容の報告をあげてもらうかということなりますが、
マイクロソフトのBug Bountyプログラムの品質定義を報告する
マイクロソフトは、報告された脆弱性に可能な限り迅速に対処するよう努めています。脆弱性に対処する時間に影響を与える要因の1つは、脆弱性の根本原因、深刻度、および影響を評価するのにかかる時間です。実際には、マイクロソフトが脆弱性を評価するのにかかる時間は、脆弱性レポートで提供される情報の質に大きく影響されます。セキュリティリサーチャーが、脆弱性の評価を迅速に行うために必要な情報をよりよく理解できるように、脆弱性レポートの品質レベルを低、中、高の3つに定義しています。これらの品質レベルは以下の表にまとめられています。当社は、可能な限り高品質のレポートを提供することを推奨しており、当社の報奨金プログラムでは通常、高品質のレポートに対してより高い報奨金を提供することで、これを奨励しています。
高品質のレポートを提供していただきたいと思いますが、マイクロソフトに影響を与える脆弱性については常に知りたいと思っていますので、最高レベルの品質を提供できない場合でも、研究者の方には脆弱性をレポートしていただきたいと思います。
ということで、高品質のレポートというのは、どのようなものかというのを具体的な例を挙げて、わかるようにしている点かと思います。
IPAに報告した場合との違い
スライドの20ページは、IPAに報告した場合との違いが記載されています。
これについては、私としては、本来あるべき姿に20年かけて戻ったものと理解しているのは、最初に書いた通りになります。ということで、このスライドを、もし、余裕があれば、リンクもたどってきちんと分析することが必要なのではないか、と考えたりしていました。
