JPCERT/CC Eyes

※脆弱性関連情報取扱制度は経済産業省およびIPAとともに運用していますが、本稿はJPCERT/CCとして執筆したものです。

日本では、「情報セキュリティ早期警戒パートナーシップ」[1][2]に基づく運用を20年以上行ってきた実績があり、各国に先んじて、いわゆる「協調された脆弱性開示（CVD）」への取り組みが官民連携で行われてきました。しかし、残念ながら、制度運用への理解が十分に広まっていないことを示すような出来事が度々発生しています。単に法律やガイドラインに書いてあることを解釈するだけでなく、「なぜこの仕組みは存在するのか／必要とされているのか」を考察しなければ、制度（や制度の維持）という「手段」が自己目的化し、形骸化、あるいは硬直化し実態にそぐわなくなる恐れがあります。 

多くの発見者、製品開発者が脆弱性調整に関わるようになったとはいえ、社会／業界全体からすると、多くの組織／人にその対応経験が十分にあるわけではありません。インシデント対応と同様に、公表される内容、経緯は一部であり、その調整過程や詳細は限られた関係者にしか知られない世界です。本稿では、制度上の「調整機関」として、また、悪用時のインシデント対応支援を行うJPCERT/CCの観点から、対応現場側の課題と今後について考察してみたいと考えています。「前編」では、まだ悪用の蓋然性がない、“平時”の脆弱性調整について解説し、後編では脆弱性が悪用される蓋然性が高まっている、あるいはすでに悪用された場合の各種オペレーションについてご紹介したいと思います。

なお、脆弱性関連情報の取扱いを巡る法的な観点でのさまざまな論点の整理については、高橋郁夫弁護士らによる「情報システム等の脆弱性情報の取扱いにおける法律面の調査 報告書改訂版」[3]がIPAのWebサイトで公開されていますので、まずはこちらをご参照ください。

平時の対応について

前述のとおり、日本では「情報セキュリティ早期警戒パートナーシップ」制度に基づき、各国に先んじて、いわゆる「協調された脆弱性開示（CVD）」への取り組みが官民連携で行われてきました。

海外においては、基本的に発見者―メーカー間で直接／個別の調整が行われてきた結果、意図しない情報開示などのトラブルが度々起きてきました。「メーカーが脆弱性であると認めないから情報開示する」「公益性が高いと判断し公表する」といった主張にて、両者の協調に依らない情報開示が度々行われてきました。あるいは、発見者が脆弱性について指摘していたにも関わらずメーカー側から誠実な対応が得られなかったというトラブルも度々起きてきました。他方で、最近では国としてCVDを推進したり、メーカーとして対応方針を宣言する組織も増え、また、脆弱性情報に触れるプレーヤーがこれまでのさまざまな脆弱性情報ハンドリングの失敗を経験しながらも徐々に相場観を形成し、自発的に足並みを揃えつつある状況です。

脆弱性情報というものは、メーカーにとってはネガティブな情報であり、一方で発見者にとってはその活動成果や能力を示すポジティブな情報です。ユーザーにとっては、問題が解消されるポジティブな情報ですが、コントロールされない情報開示が悪用につながればネガティブな情報となります。そうした中で、日本の脆弱性情報の取り扱い制度においては、調整後のメーカーからの公表を基本とし、また、公表時（JVN掲載）には発見者を明記することができるようになっています。JVNという場を使い、メーカーとしての情報開示、発見者としての情報開示がスムーズに連動できるようになっているのです。
以前のブログ記事[4]でも解説したとおり、こうした仕組みは、情報を効率よく活用し、どこか一個人／一組織だけのために“消費”され、他者の不利益が発生するような、負の外部性を可能な限り避けるための仕組みと言えます。

調整制度はなぜ存在するのか

脆弱性を悪用する攻撃者と悪用された製品のメーカーとの関係は「加害者」と「被害者」の関係になりますが、他方で、脆弱性の発見者とメーカーとの関係はそうではありません。こうした、「加害者」「被害者」だけの図式で捉えられない利害の衝突へのアプローチとして、経済学や法学の分野では「コースの定理」という考え方が用いられることがあります。当事者間の私的な取り引きを通じて「最も効率的な結果が達成される」という定理を、コースの定理といいます。

※ちなみに、本来、コースの定理は公害などの外部不経済に対して、当事者間で調整・解説するための考え方として使われるものであり、脆弱性の発見者とメーカーとの関係では厳密には外部不経済とは言えませんが、その解決アプローチは援用できると考え、引用しています。

取引費用というのは「取引を行う際に生じる費用の総称であり、取引の相手方を探す費用、交渉の実施や合意書作成の費用、履行の監視や違反に対する制裁の費用、戦略的行動に伴う費用」[5]というもので、これを脆弱性調整の作業に当てはめると、

「取引の相手方を探す費用→メーカーの適切な交渉窓口を探すコスト」
「交渉の実施や合意書作成の費用→発見者の主張とメーカー側の主張の着地点を探す（検証）作業」
「履行の監視や違反に対する制裁の費用→公表までの進捗管理」
「戦略的行動に伴う費用→発見者の目的（カンファレンス発表、自社能力のアピール、公益目的等）とメーカーの戦略（レピュテーションダメージの最小化）との間の調整」

といったところになるかと思います。コースの定理は脆弱性調整のように多くの取引費用が発生する場合では「何らかのルールや制度が必要」であることを示唆する理論ともいえます。調整制度がなく、発見者―メーカー間で交渉を行う場合、あらゆる取引費用をお互いが負担することになるわけですが、両者間にはもともと信頼関係がなく（むしろ、最初から主張や利害が衝突していることがある）、さらに脆弱性やセキュリティ技術への知見や情報にも非対称性（メーカーが必ずしもセキュリティに詳しくない場合もあれば、発見者が当該製品について技術的に詳しくないこともある）があります。あまりにも取引コストが高すぎるため、調整が難航し、取引コストを負担せずに個別の目的（例：脆弱性を知らしめること）を達成（例：合意に至らない一方的情報開示）しようとする動きが出てしまうわけです。

脆弱性情報の取り扱い制度は、あらかじめ取扱いルールを示し、調整役を設けることで、こうした双方の取引コスト負担を減らし、交渉を効率よく進めるための制度だと考えることができます。初めて脆弱性を発見する発見者／修正対応するメーカーにとってだけでなく、何度もこうした制度を使うプレーヤーにとっても、制度を使うほど取引費用を減らし、効率化を進めることができるというメリットもあります。

「脆弱性の存在を示せば」それで対策は進むのか

「脆弱性の存在を明らかにして注意喚起をする」ということであれば、制度以前、あるいはかつての海外側がそうだったように、各自がそれぞれの判断の基で情報開示をすることが「最短ルート」に思えます。問題は、「では、どうやって修正するのか」という観点です。
コンシューマー製品の脆弱性対応の多くでは、公表と同時に修正プログラムの配布を行い、メーカーからの公表等を通じてユーザーに適応を呼びかけるケースが大半です。
他方で、法人向け製品では、修正プログラムや暫定的な回避策／被害軽減策の提供を先んじてユーザー組織に個別通知し、ある程度リスクを低減したところで公表を行うというケースがよく行われています。
これは、「コンシューマーよりも法人向け製品の方が確実にコミュニケーションできる手段があるから」[6]という実務的な背景もありますが、そうしたユーザーの対象製品が侵害されることで、さらにそのユーザー法人の顧客／ステークホルダーなどに影響が出ることが想定されるため、万が一公表後に悪用する攻撃が発生した場合に備えて、暫定的な対応を先んじて行っておきたいという考え方があるからです。
また、法人向けの製品の場合、修正プログラムを瞬時に適用できるケースは少なく、顧客やステークホルダーに影響がある場合、システム停止や修正前のパッチテスト等、多くの工程／リソース投入／コストが発生することから、本格的／根本的な修正を行うまでの暫定的措置が極めて重要です。

一方で、ここまではあくまで「平時」の想定です。悪用がすでに発生している場合、あるいは悪用される蓋然性が高まっている場合はまた異なったタイムラインでの動きが必要になりますが、これは後編で解説したいと思います。

脆弱性公表による「価値の総量」

脆弱性調整について、基本的に発見者もメーカーも「開示」するという目的ではベクトルが一致しています。ただ、問題になるのはその（期待する）「タイミング」が異なるという点です。
本来、お互いが望んだ公表タイミングがあり、これがズレた分だけ、片方側の不利益になります（図3のとおり）。前述のとおり、修正作業にはメーカー内でもまたユーザーサイドでも相当の期間を必要とすることが多いため、基本的にメーカーが希望する公表タイミングというものは発見者が望む公表タイミングよりは時間軸的に後ろになりがちです。他方で、発見者側にも事情[7]はあり、例えば、国際カンファレンスでの発表を予定している場合などがあります（※しつこいですが、悪用の蓋然性が高まっている、あるいはすでに悪用が発生している場合は事情が異なります。後編で解説します）。この調整もまた、前述のとおり、取引コストがかかるため、調整制度を用いて、この取引コストを減らし、お互いの妥協点となる公表タイミングを調整するわけです。

こうした調整は、発見者、メーカーの「二者それぞれの利益」だけを調整するというものではないことに注意が必要です。脆弱性が適切に開示されなければ、悪用等を惹起したり、メーカーもさることながら、製品のユーザー側で本来の修正タイミング・リソースが大きく変化することでのコスト負担、経済的損失など、ユーザーや社会インフラ全体が不利益を被ったりする可能性があるわけです。前述のコースの定理が示すのは「価値の総量」をどう分配できるかという観点であり、脆弱性情報の取り扱い制度もまた、社会全体としての脆弱性開示による利益を得るための制度であると考えることができます。
脆弱性情報開示の議論において、よく「公益性」という用語が使われているのを散見しますが、二者間の直接交渉がどうしても「二者間の利益の調整」に陥りがちです。ここまでに述べたとおり、社会全体での「価値の総量」を調整するためには、効率的な調整ができる、脆弱性告示制度に基づいた調整が望ましいと筆者は考えます。

前項に同じく、ここまでの整理はあくまで悪用がまだ確認されておらず、また、悪用の蓋然性も高まっていない状態での「平時」での整理です。悪用がすでに発生している、または差し迫った脅威があるという場合はまた異なった判断軸が必要になるわけですが、こちらも後編で解説したいと思います。

前編のまとめ：予測可能性を担保する制度

世界的にも珍しい制度が、強い義務や罰則等のない仕組みとしてこの20年以上運用できたのは、ひとえに官民各プレーヤーの理解と協力があったからです。特に重要なのは、脆弱性というものに対する技術的な理解と製品が提供・利用されているという現場側の事情の双方をエンジニアや研究者が理解し、また、さまざまな公的機関やメディアが仕組みの利点を理解しているからこそ成立している仕組みなのです。

前述のとおり、海外ではメーカーとの合意に至らないまま脆弱性情報を開示してしまうトラブルが多く発生していますが、仮に多少強引な方法であったとしても「公益性の観点から開示が望ましい」として、「目的が手段を正当化する」的な擁護の声も見受けられます。しかし、こうしたアプローチは（発見者も含めて）長期的に不利益を生むことになると考えます。

こうした調整されない開示が行われると、当該案件だけではなく、後続の将来の脆弱性調整に影響を及ぼします。メーカーは脆弱性発見者側に不信感を抱くようになり、そうした背景から後ろ向きな対応に見えてしまうことで、発見者側はメーカー側に不信感を抱く・・・という不信の連鎖が蓄積します。これは逆のパターンもあり、発見者からの指摘にメーカー側が反応しないケースが増えるようになると、発見者は「メーカーに伝えるとうやむやにされてしまう」と不信感を抱くようになり、フルディスクロージャーに傾くようになります。

法律、ルールというものは、その運用結果が一定度予測できるからこそ成り立つものであり、脆弱性関連情報取扱制度でいえば、「発見者は受付窓口に届け出る」「第三者に勝手に漏えいしない」「公表については調整機関が調整に入る」「製品開発者は脆弱性の修正と公表を行う」というルールが事前に示されることで関係者の動きが見える（予測できる）のです。また、その実績が公開（メーカーからの公表、JVN公表や発見者名の明示）されることで「ルールのとおり関係者が動いたんだな」と検証できるわけです。この予測可能性が担保されているからこそ、各プレーヤーは疑心暗鬼に陥ることなく、脆弱性情報という極めてリスキーな情報を安定して扱うことができるのです。「目的が手段を正当化する」的な動きというのは、そのルールは動いた当人／組織内の事情であり、予測可能性を持ちません。

現行の制度がベストなのか、という論点はまた別の議論になりますが、後編では、あまり知られていない脆弱性が悪用される場合の対処オペレーションの実際を紹介しつつ、制度運用現場／インシデント対応現場から見える今後の課題・論点について考察したいと思います。

参考文献等

[1]経済産業省「脆弱性関連情報取扱体制」https://www.meti.go.jp/policy/netsecurity/vulinfo.html
ソフトウエア製品等の脆弱性関連情報に関する取扱規定 https://www.meti.go.jp/policy/netsecurity/vul_notification.pdf
情報セキュリティ早期警戒パートナーシップガイドライン https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html
ソフトウエア製品開発者による脆弱性対策情報の公表マニュアル https://www.ipa.go.jp/security/reports/vuln/kenkyukai-report2023.html#section6

[2]制度全体の改善に係る検討や活動の年次報告等については、情報システム等の脆弱性情報の取扱いに関する研究会の各年度報告書をご参考ください https://www.ipa.go.jp/security/reports/vuln/kenkyukai-report2023.html

[3]https://www.ipa.go.jp/archive/files/000072543.pdf

[4]サイバー攻撃被害に係る情報の意図しない開示がもたらす情報共有活動への影響について　https://blogs.jpcert.or.jp/ja/2023/12/leaks-and-breaking-trust.html

[5]飯田高「法と社会科学をつなぐ」（有斐閣）136ページ

[6]派生する論点として、法人向け製品の脆弱性悪用事案の場合に、ただちに公表・注意喚起を行わず、基本的に非公開・個別通知で対応を行うことへの賛否があります。この点については、「サイバー攻撃被害に係る情報の共有・公表ガイダンス」97ページをご参照ください https://www.nisc.go.jp/pdf/council/cs/kyogikai/guidance2022_honbun.pdf

[7]メーカーやユーザーの不利益を防止するということも重要ですが、発見者のモチベーションも、脆弱性発見・修正のサイクルを健全に保つためには重要と考えています。