JPCERT/CC Eyes

はじめに

複数の省庁からメール関連システムへの不正アクセスによる情報漏えいについて被害公表がなされていますが、報道やSNS上では、どの製品の脆弱性が原因なのか明かされないことへの疑問などが指摘されています。悪用された脆弱性に関する情報の被害公表時の取り扱いは、サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]検討会（事務局：NISC、警察庁、総務省、経済産業省、JPCERT/CC）で議論され、同ガイダンスにて示されています。あらためて、個別の被害公表時の扱い方と、複数組織がいる場合の全体のコーディネーションについて解説します。

※なお、公表のあった事案の詳細は不明ですが、現時点において関連する被害公表がなされた事案について弊センターは関与していないため、本稿については個別のインシデント対応に係る守秘義務契約等になんら影響するものではない点を記しておきます。

原因となった製品の脆弱性に関する情報の取り扱い

サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]では、「Q23. 製品の脆弱性が悪用されていた場合、当該情報はどのように扱えばいいですか？」（94ページ）の冒頭で

と示されています。

侵害原因となった製品の既知の脆弱性に関する情報（製品名や脆弱性の種類（CVE番号や脆弱性悪用方法の通称など））を被害公表時に示すことの目的・効果としては、

• A：他の利用組織など広く社会全体に注意喚起効果を持つ
• B：侵害原因を可能な範囲で示すことで自組織の運用・管理上の問題だったのかゼロデイ攻撃など事前の予防が困難なものだったのか示す

などが挙げられます。

Aの場合、既知の脆弱性であれば、すでにメーカーから脆弱性やその悪用に関する公表がなされていたり、専門機関から注意喚起がなされていたりするケースが大半ですが、こうした情報発信が影響を受けるユーザーすべてに伝わっているとは限らず、被害の公表や報道等を通じて悪用に関する情報が伝わることで、脅威の度合や対応の温度感が広く伝わっていきます。この点は、サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]の74、75ページ等で示されています。
そのほか、脆弱性の悪用に関して注意を呼びかける情報が伝わる方法／ルートとしては、以下が想定されます。

• （１）メーカーからの脆弱性公表や注意の呼びかけ
• （２）JVN公表、専門機関からの注意喚起、セキュリティ専門企業による攻撃に関する分析レポートの公表
• （３）被害組織からの被害公表での悪用に関する言及やこれを受けた報道等
• （４）メーカーからの個別通知（サポート登録、商流上の伝達、製品の機能等を通じた機械的な通知）

特に法人向け製品の場合、メーカーが個別のユーザー組織に連絡できる場合があるため、悪用について注意を呼びかける公表は行わず、非公表のまま、個別連絡をもって影響のあるユーザーに通知・サポートを行う場合があります。サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]の97ページでは、主にMSP（Managed Service Provider）と呼ばれるような、遠隔での運用保守を行うベンダー経由での攻撃を例示して、ベンダーからの個別通知だけでよいのか、公表による注意喚起や情報共有活動への情報展開を通じた積極的な情報展開が求められるのか論点を解説しています。このMSPの事例と比べると、法人向け製品の場合、2022年7月のブログ「なぜ、SSL-VPN製品の脆弱性は放置されるのか ～“サプライチェーン”攻撃という言葉の陰で見過ごされている攻撃原因について～」でも取り上げたように、いわゆる商流構造上の問題から、メーカーからの脆弱性情報や悪用に関する情報などがユーザー組織に伝達されないトラブルが度々発生しています。また、一部のアプライアンスなどでは、インタフェース上への通知メッセージ表示にてメーカーからの通知を行うものもあります

原因となった個別製品名等を明かさない理由とは何か

次にBについてですが、被害公表の目的については、サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]で整理が示されていますので、本稿での解説は省略しますが、（法令上の義務があるかどうかに関わらず）情報の漏えいやサービス停止の影響を受ける顧客・取引先等への注意喚起的な目的で行われる速やかな第一報ではなく、被害認知・インシデント対応からしばらくの時間が経過した後の公表においては、説明責任／アカウンタビリティの観点から、攻撃原因についてある程度技術的な説明が求められることになります。被害公表時に被害組織に多くの批判がなされる点はサイバー攻撃被害に係る情報の共有・公表ガイダンス[1]のほか、同ガイダンスの予備的調査を行った総務省報告書、昨年4月のブログ記事「サイバー攻撃被害情報の共有と公表のあり方について」などで度々示してきたところですが、侵害原因についてある程度の詳細を公表することは必ずしも被害組織にとってネガティブなものではありません。例えばゼロデイ攻撃や運用保守ベンダー経由の攻撃のように、被害組織自身の対策では予防・回避が極めて困難だったことを知らしめることができます。

よく見かけるものとして、被害組織への取材に対する回答として「原因となった製品名／システム名についてはセキュリティの問題上答えられない」という回答があります。未修正の脆弱性が悪用され、かつこれがまだ修正されていない場合の情報の取り扱いや、公表することで二次被害を惹起してしまうような情報の取り扱いについては、サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]で解説されているとおりですが、ガイダンス77ページ目にあるとおり、サイバー攻撃に係るさまざまな情報の特性から、非公表とした情報が完全に秘匿され続ける可能性は低く、侵害原因について「セキュリティの問題上答えられない」という回答は現実的ではありません。

仮に未修正の脆弱性悪用であったとして、いずれはJPCERT/CCなどの調整により当該脆弱性は公表され、悪用に関する注意喚起が発出されますし、既知の脆弱性であれば、すでにメーカーからの公表や悪用に関する注意喚起、分析レポートが出ていますので公開情報ベースですぐに当該事実が認知されることになります。「みんな何が原因だったのかわかっているのに当事者はかたくなに言及しない」状況に一体どのような秘匿すべき利益があるのでしょうか。単純なセキュリティインシデントに係る技術的対応以外の何らかの利害関係において、なおも秘匿すべき事情がある、ということであれば、それは「セキュリティの問題上答えられない」という回答以外の回答が適切なはずです。

コーディネーションの意義とその評価

複数の被害組織で同一の原因による侵害が発生した場合、国内全体でのコーディネーション（攻撃対処全体の「ハンドリング」と呼称される場合もあります）が重要になります。サイバー攻撃被害に係る情報の共有・公表ガイダンス[1]の「Q17公表する際の留意点はありますか？」（76ページ）では、同一原因による被害組織が同時多発的に複数存在する場合の被害公表の難しさについて指摘しています。以下の図3のとおり、被害組織それぞれは別々にインシデント対応を行い、被害公表判断を行いますが、ある組織は公表を見送っていたが、別の被害組織が公表したことを受けてあわてて後追い的な公表をすることになったり、あるいは、ある組織は侵害原因について明らかにしようと準備していたところ、先に公表した組織が侵害原因を明示せずに公表してしまった、といった個別事案間での足並みが揃わないことでその後に続く公表準備組織に混乱が発生してしまうのです。

したがって、弊センターがこうした同一原因によって同時多発的に複数被害が発生する事案のコーディネーションを行う場合は、すべてのケースではないですが、公表タイミング判断や公表内容について個別の被害組織の要望をうかがった上で、最低限の足並みがそろうよう調整をすすめます。政府機関、特定の重要インフラ分野など、ある特定分野内だけで足並みをそろえればよいというものではなく、被害が分野を横断する場合はさらに広範囲な調整が必要になります。分野ごとに所管法令やガイドラインがそれぞれ存在し、被害公表の判断にも差が発生するため、分野横断的なコーディネーションにより、分野間の差をある程度解消させる必要が出てくるのです。

サイバーセキュリティ戦略に「ナショナルサート」なる用語が示されて久しいですが、「調整」という用語が多義的なため具体的にイメージしにくいところ、もともと、個別組織／分野単位のインシデント対応を主眼としてCERT/CSIRTが作られている中で、米CERT/CCと弊センターの呼称に「CC:Coordination Center」が付記されているのは、官民問わず、産業分野を問わず、営利／非営利を問わずあらゆる組織のセキュリティインシデントの支援を行うだけでなく、分野を超えて存在する脆弱性などの問題解消や、前述の分野毎の被害公表の差のような、広範囲な被害が発生した場合の個社間／分野間の対応ギャップを埋めるための調整を行うことを示しています。

現行のサイバーセキュリティ戦略の紹介資料等で「誰一人取り残さないサイバーセキュリティ」という用語がありますが、JPCERT/CCがメーカーからの脆弱性公表や顧客への個別通知だけでなく、悪用に関する注意喚起を広く行ったり、情報共有活動への情報展開のために被害組織をはじめ、さまざまな利害関係者を説得してまわるのは、個社間の取り決めやビジネス上／商流上の都合、所管関係などの理由によって攻撃に関する技術的情報が流通せず、そうした情報を必要とする者が取り残されることを避けるためです。

コーディネーションを行う役割はあらゆる事案で弊センターだけが担うわけではありません。攻撃の類型や悪用された脆弱性／製品の種類などに応じて国際的にも、国内においてもJPCERT/CC以外のプレーヤーがコーディネーションの役割を担うことがありますし、そもそもコーディネーション役がいなくても、メーカーや商流上のベンダーなどが自主的にハンドリングできるケースもあります。いずれにせよ、こうした調整は非公開で行わざるを得ないため、何らかの役割を担う各組織がしかるべき役割を果たしたのか、コーディネーション役の組織がしかるべき責務を果たしたのかどうかは、事後の各被害組織からの公表を通じて社会全体が知ること（※）になります。こうした評価メカニズムがなければ、各プレーヤーは極めて利己的にのみ動くため、必ず「取り残される者」が出てきます。被害組織からの公表を通じた情報に依存すること自体の論点もありますが、少なくとも被害公表を通じて、こうした評価がなされていくメカニズムも引き続き必要です。これもサイバー攻撃被害に係る情報の共有・公表ガイダンス[1]検討会で度々議論され、ガイダンス本体にも示されていますので、あらためてご覧ください。

※被害公表は同時に攻撃者／その背景主体側も“オーディエンス”に含まれます。自らの行った攻撃キャンペーンに標的組織側の国／対処組織がどのように対応できていたのか／できなかったのかを“検証”することができます。国や専門機関からの注意喚起をはじめとした情報発信も、いわゆる「アクティブ・サイバー・ディフェンス」的な対抗手段として重要である点は昨年9月のブログ記事「『積極的サイバー防御』（アクティブ・サイバー・ディフェンス）とは何か ―より具体的な議論に向けて必要な観点について―」をご覧ください。

早期警戒グループ 佐々木 勇人

参考情報

[1]サイバー攻撃被害に係る情報の共有･公表ガイダンス検討会
サイバー攻撃被害に係る情報の共有・公表ガイダンス
https://www.nisc.go.jp/council/cs/kyogikai/guidancekentoukai.html