JPCERT/CC Eyes

はじめに

本稿の前編では、「情報セキュリティ早期警戒パートナーシップ」[1]制度に基づく、いわゆる「協調された脆弱性開示（CVD）」について解説し、平時における取り組みをご紹介しました。後編では、脆弱性がすでに悪用されている、あるいは悪用の蓋然性が高まっている状況における対処オペレーションについてご紹介したいと思います。脆弱性悪用の情報、特に公表前のゼロデイ攻撃に関する情報は、多くの組織がその取り扱い経験のあるものではありません。JPCERT/CCでは年間を通じて多くの脆弱性調整・公表を行うほか、悪用情報に関するハンドリング（脆弱性調整と並行した脅威情報の流通、注意喚起、情報共有活動への展開、海外組織との連携等）を行っています。このあまり知られていないオペレーションの解説を踏まえた上で、今後の制度改善のための論点についても簡単に考察してみたいと思います。

＜本稿をお読みいただく際の注意点＞
・本稿で解説する際の「脆弱性が見つかった製品」は特段の指定がない限り、基本的に法人向け製品を想定し、解説しています。コンシューマー向け製品における同様の解説については紙幅の都合から省略していますので、ご了承ください。
・脆弱性悪用情報の取り扱い全般の留意点等については、「サイバー攻撃被害に係る情報の共有・公表ガイダンス」「攻撃技術情報の取扱い・活用手引き」をそれぞれご覧ください。
・本稿では国内制度外のケースも扱うため、脆弱性告示上の「製品開発者」ではなく一般的に用いられるメーカー／ベンダーという呼称を使います。

脆弱性悪用情報ハンドリング時の判断要素

未知の脆弱性を悪用する攻撃キャンペーンが発覚した場合、悪用情報のハンドリング（調整、情報共有、公表等）における各判断要素は以下の図のとおりです。

情報量／正確さ：
被害現場においてただちに「未知の脆弱性が悪用された」と確定できるケースはほとんどなく、被害現場側の調査とメーカー側での検証（期間）を経て確定されます。
脆弱性調整・公表前にメーカーが得ることができた被害現場からの情報が限られていた場合、脆弱性公表や注意喚起後に発覚した被害現場の調査結果から、脆弱性に関する新たな情報が見つかり、場合によっては別の脆弱性の追加公表や追加修正が発生することがあります。

被害現場側調査／メーカー側検証：
悪用された脆弱性の正確な特定のためには、被害現場側での調査だけではなく、メーカー側での検証が必要になります。この点については後述します。

対策の準備／顧客への連絡：
メーカー側では脆弱性の特定、検証、対策方法の準備、顧客への連絡、公表等の準備を進めることになります。
攻撃が現在進行形で進んでおり、また甚大な被害が拡大している場合、状況次第では修正プログラムの提供を待たずに情報を開示（公表や顧客への連絡）し、暫定的な回避策や侵害された際の被害低減策、Hotfixの提供を行う場合があります。

公表／注意喚起／情報共有：
一般的な注意喚起発行の判断要素等の解説については、以前公開した以下の記事をご参照ください。

JPCERT/CC Eyes：注意喚起や情報共有活動における受信者側の「コスト」の問題について ー情報発信がアリバイや成果目的の自己目的化した行為にならないためにー
https://blogs.jpcert.or.jp/ja/2023/05/cost-and-effectiveness-of-alerts.html

脆弱性を悪用した攻撃で使われたマルウェアや通信先等、侵害を見つけるためのインディケータ情報は、注意喚起時に公表されるケースもあれば、非公開の情報共有活動で展開されるケースもあり、伝達手段や組み合わせ、タイミングはさまざまです。後述の海外製品のケースのように利用者数が多すぎるために注意喚起とともにインディケータ情報も公開されるケースもあれば、メーカーや専門機関からユーザーに対して個別に非公開で連絡を取って伝達されるケースなどもあります。

脆弱性悪用のさまざまなパターンの解説

脆弱性の悪用事案について、ごく簡単に整理すると以下のようにパターン分けができます。例えば、国内製品のゼロデイでグローバルに影響するようなケースはほとんど発生していませんので、本稿では解説は省略し、JPCERT/CCがよく対応している、以下、ケースA（国内製品のゼロデイ事案）、B（海外製品のゼロデイ事案）、C（海外製品のNデイ事案）について解説します。

＜ケースA：国内製品のゼロデイ事案＞

国内製品の場合、発見者や被害組織、または製品開発者からの連絡・相談を受けて、脆弱性の特定と製品開発者での修正プログラム準備、公表に向けた調整が行われます。本稿前編で解説のとおり、国内においては「情報セキュリティ早期警戒パートナーシップ」に基づき、調整機関として指定されたJPCERT/CCが製品開発者との調整を行います。国内で悪用被害がすでに発生している場合はインシデント対応支援や情報共有活動とセットで調整が行われ、被害現場からの情報をもとに原因（悪用された脆弱性）の特定が行われます。被害組織、調査を行う組織、JPCERT/CC、製品開発者と複数の関係者が連携して脆弱性公表や悪用に関する注意喚起に向けた調整が行われます。

〇被害現場側調査とメーカー側調査との間の仲介・調整・検証
本稿前編にて、脆弱性発見者と製品開発者との間の知見の非対称性によるミスコミュニケーションの問題について触れましたが、悪用事案対応においても同様の問題はあります。例えば、悪用被害現場側が調査結果から指摘する脆弱性の存在の可能性とその修正方法について、製品開発者側が攻撃に関する知見や情報が不足しているため正確に理解できず、修正プログラムが不十分なものとなってしまうケースがあります。また、被害現場側は調査に係るNDAや行政機関側への報告等、情報の取り扱いに制限がかけられていることが多いため、製品開発者側に十分な情報が提供されず、脆弱性の特定・検証や修正が不十分に終わる恐れがあります。
逆に、悪用被害現場側の調査者が当該製品について知見や情報が不足しており、脆弱性やその発生箇所について誤認（あるいは不足）してしまっているケースもあります。そうした際には調整機関であり、かつ、インシデント対応組織であるJPCERT/CCが仲介を行い、適切な脆弱性修正への調整を行っています。

また、当該時点までに認知・調査できている被害現場が限定的であったり、攻撃者が痕跡を消去、または痕跡が極めて残りにくい脆弱性／攻撃であったりする場合、当該脆弱性情報以外のインディケータ情報を情報共有活動に展開・照会を行い、同一アクターによる他の被害現場を見つけ出し、不足するアーティファクト／情報を補う必要がある場合もあります。
さらには、同一アクターが複数の脆弱性（※同一製品の複数の脆弱性を組み合わせている場合や、複数の製品の脆弱性を同一攻撃キャンペーン内で悪用している可能性も否定できない）を悪用していないか確認する必要もあり、攻撃キャンペーンへの対処という観点では、被害現場―メーカー間の調査結果を相互に連携させる必要があるのです。
調整機関としてのJPCERT/CCの役割は、単に「連絡役」ではなく、こうした情報の出し入れや検証がスムーズに行えるよう「調整役」「検証役」でもあるのです。

〇他のゼロデイ攻撃被害組織の発見と支援
脆弱性調整と別にインシデント対応支援／情報共有活動としてインディケータ情報の展開などを行い、まだ被害を認知できていない被害組織の特定を行います。攻撃キャンペーンがなおも継続中で緊急を要する場合、修正プログラム等の準備ができ次第、速やかに脆弱性公表や注意喚起を行い、その際にIoC情報や侵害調査方法を開示し、このフェーズの代わりとすることもあります。
また、法人向け製品の場合、製品開発者側から利用顧客にコンタクト／サポートできるケースがあるため、脆弱性公表前に影響のある顧客等への事前連絡を行う場合が多くあります。主に海外製品の先行例が多いですが、製品のテレメトリー通信やリモートサポート等によって製品開発者側から侵害疑義のある顧客を特定・通知できる場合もあり、脆弱性公表や注意喚起前に事前に実施するケースもあります。

こうした、情報共有、注意喚起、被害組織への個別通知、製品開発者からの連絡、とさまざまな伝達経路を組み合わせ、被害の早期発見や被害拡大防止に取り組みます。これらの手段の組み合わせは、攻撃活動の状況（攻撃キャンペーン中なのか事後なのか）、修正プログラム準備の進捗状況、影響範囲（被害範囲）などに応じて、その組み合わせ方、順番、タイミング等はケースバイケースで判断されます。特定のガイドラインやマニュアルがあるのではなく、攻撃キャンペーンへの対処という観点から柔軟に調整を行っています。

＜ケースB：海外製品のゼロデイ事案、ケースC：海外製品のNデイ事案＞

海外製品の脆弱性悪用被害が日本以外で先行して発覚した場合、特に影響がグローバルに波及するような脆弱性の場合、すべてのケースではありませんが、当該国内で対応した専門機関やセキュリティベンダー、メーカーから事前に各国への情報共有が行われ、脆弱性公表と同時に各国において注意喚起が行われるよう、事前調整が行われます。

ケースとしてほとんどありませんが、海外製品の脆弱性悪用被害が日本国内で先行して発覚した場合、発見者から海外メーカーに直接連絡がなされるか、JPCERT/CCを経由した連絡、またはJPCERT/CCを同報した上で海外メーカーに連絡がなされます。

〇脅威動向の変化への対応
従前は、「過去に悪用（ゼロデイ攻撃）されており、脆弱性公表時点では攻撃キャンペーンはすでに終了しているが、他のアクターによる悪用の蓋然性が高いため注意喚起を行う」という対応が行われていました。
他方で、ここ数年で増えてきているケースとして、「（X）注意喚起を行っても攻撃キャンペーンが継続しているもの」「（Y）脆弱性公表からすぐにNデイ攻撃が行われるもの」があります。（図4下段）
（X）のパターンについては、正確には、

（X-1）早期に悪用が発覚し、攻撃キャンペーン中に脆弱性公表・注意喚起を行えたケース
（X-2）ゼロデイ攻撃が発覚・脆弱性が公表されても攻撃活動が継続されるケース

の2種類があります。
前者については、いわゆるIAB的アクター[2]によって広範囲な攻撃が行われることから、その早期発覚の可能性も高まっている背景があると推測されます。後者についてもIAB的アクターによる悪用ケースがほとんどですが、例えば2024年1月の「Ivanti Connect SecureおよびIvanti Policy Secureの脆弱性（CVE-2023-46805およびCVE-2024-21887）」[3]のケースでは、UNC5221が先行するゼロデイ攻撃（2023年12月）に加えて、脆弱性公表＋注意喚起直後も攻撃活動を継続していたことが確認[4]されています。

こうしたIAB的アクターがゼロデイ攻撃／Nデイ攻撃を行うケースでは、ネットワークアプライアンス／エッジデバイスへのWebshell設置等が戦術として好まれることから、侵害されたホストを外形上特定することが可能なケースが多くあります。そのため、攻撃発覚後に多くのセキュリティベンダー／研究者等によりスキャン調査が行われ、「侵害済みホストに関する情報」が国際機関間等で共有されることになります。
JPCERT/CCが調査するケースもありますが、こうした海外提供情報を活用し、すでに侵害されたホストの管理・利用組織への通知オペレーションを注意喚起や情報共有と並行して実施します。
やや余談になりますが、こうしたスキャン情報はレポートやSNSを通じて公開情報として流通することがありますが、実際には脆弱性影響バージョンかどうかの調査が不正確な情報発信もあり、こうした情報の精査も行っています。

〇通知オペレーションの実施（特にケースCの場合）
前述のような、すでに侵害されたことが外形上判明しているホスト管理組織への個別通知のほかに、脆弱性公表／注意喚起後も脆弱なままの状態になっているホスト管理組織への通知オペレーションも実施する場合があります。
特に、ExploitやPoCが公表され、広く不特定多数のアクターが悪用可能な状態であったり、前述のような、IAB的アクターが継続して攻撃キャンペーンを展開する可能性があったりするケースにおいて、未被害・脆弱なホスト管理組織への通知オペレーションを実施しています。

あらゆるケースで脆弱なままのホスト管理組織への通知を行っているわけではありません。基本的に脆弱性対応については、一義的には製品開発者等からユーザーへの伝達と脆弱性修正対応がなされるべきであって、ユーザー（あるいはその委託等を受けた組織）自身での機器管理・脆弱性情報把握が行われるべきと考えているからです。
他方でこれまでもブログ記事で触れてきた通り、市場／商流上の脆弱性情報流通には課題[5]があるところ、上記のような攻撃の蓋然性が高まっている、あるいはすでに攻撃キャンペ―ン中であるという状況においては、通知オペレーションを行わざるを得ない、というのが実情です。

今後の課題

ここまで、脆弱性悪用に対する現行のJPCERT/CCでのオペレーションを紹介しましたが、さまざまな課題もあるところ、今後、脆弱性対応制度や能力の改善に向けた動きが出てくる可能性があります。
昨年11月に公表された、サイバー安全保障分野での対応能力の向上に向けた有識者会議による「サイバー安全保障分野で対応能力の向上に向けた提言」（以下、「提言」という。）[6]では、脆弱性対応や注意喚起等の情報発信についていくつか言及がなされています。有識者会議で取り上げられた提言を中心に、現状のオペレーション上の課題と今後の論点について簡単に考察してみます。

＜緊急性の高い情報発信に関するワンボイス化について＞

現行では（JPCERT/CCからの情報も活用いただきつつも）各機関が独自の情報発信を行っており、同じ脆弱性について注意喚起を出す／出さない判断が分かれる場合も散見されます。発信内容の「温度感」や技術的内容に差異があるような、個別バラバラな情報発信は改善しなくてはなりませんが、他方で、「ワンボイス化」の論点としては以下の点を挙げることができます。

〇スピード感の問題
前述のとおり、影響範囲の大きい、特に海外製品の脆弱性の悪用ケースについては、公表後1日以内での注意喚起発行を行っています[7]。例えば注意喚起の検討段階で複数機関間の検討プロセスを設けた場合、スピードが落ちる可能性や、立場上の意見が異なった場合にある程度妥協した内容が発信情報として採用されてしまう恐れがあります。

〇複数機関が発信・対応することのメリット
何かしらすり合わせをした情報発信が行われる必要がある一方、発信組織を必ずしも一つにする必要はありません。「ワンボイス」は必ずしも対応組織を一本化することと同義ではありません。例えば行政学の分野では、複数機関による冗長性があることで過誤の発生を抑制し、また、環境変化への適応性が高まる点が指摘[8]されています。また、現行の体制においても、各機関からの発信情報や支援が届くリーチ範囲はそれぞれ異なっており、重複による受信者負担等を解消しなければならない課題があるものの、冗長性の観点で捉えると重層的な対処体制と解釈することもできます。

＜悪用に関する情報の取り扱いについて＞

〇温度感が不明瞭な点
現行のKEVでは、ランサムアクターによる悪用有無が示されるものの、当該悪用がいつの時点の事象なのか、現時点で攻撃キャンペーンが継続中なのか、また、今後の悪用の蓋然性があるのかどうかなどが示されていません。また、悪用のエビデンスとして、セキュリティベンダーの分析レポートも紐付いていません。

〇国内制度における取り組みの周知不足
情報セキュリティ早期警戒パートナーシップにおいて、2023年度の「情報システム等の脆弱性情報の取扱いに関する研究会」による検討結果を踏まえて、悪用を示す情報の取り扱いに関する規定が新たに定められ、関連する告示改訂も行われています[9]。すでに2024年度から運用が始まっており、JVNに掲載された国内製品については、その悪用有無に関する情報が掲載されるケースが徐々に増えてきています。有識者検討会では本制度運用について言及がありませんでしたが、まずは本制度運用の周知強化の課題に取り組む必要があると考えます。

＜スキャン、通知オペレーションについて＞

注意喚起を巡る受信組織側のコスト負担については、先に紹介した以前のブログ記事[10]にて解説のとおりですが、通知オペレーションについても同様の課題があります。通知はJPCERT/CCだけが行っているものではなく、また、組織だけでなく個人も含めて国内外で多くの「通知」が行われています。よく見られる問題として、侵害されていると判断した根拠（技術的証拠）が不明瞭なケースや、侵害の調査方法や調査に必要な情報（タイムスタンプなど）が示されない／サポートされない“一方通行”的な通知ケースがあります。
特に、悪用されている攻撃キャンペーンを観測・対応した組織ではない組織／個人が侵害調査方法を知り得てスキャン調査と通知をするケースでは、通知対象組織への提供情報が限定的であったりサポートが不十分であったりするケースが見受けられます。また、こうした発見者／調査者の情報を単に仲介するだけの組織による通知活動においても同様の問題が散見されます。

※数多く行っているJPCERT/CCからの通知オペレーションにおいても、諸事情により調査に必要な技術的情報を完全に提供しきれていないと反省するケースが残念ながらあります。ご意見・クレーム等あればいつでもお寄せいただければと思います。

＜情報発信だけ行われる問題点について＞

有識者提言では触れられませんでしたが、情報発信「後」の取り組みについても課題があります。本稿前半で解説のとおり、JPCERT/CCから注意喚起や情報共有、通知オペレーションを行った場合、侵害有無調査に必要な情報提供のほか、侵害疑義が見つかった組織からのインシデント相談にも対応しています。本稿でも取り上げたようにここ数年で増加しているネットワークアプライアンス／エッジデバイス関連の脆弱性悪用事案では、当該侵害機器のフォレンジック調査に課題があります。IAB的アクターは国際的に広範囲の機器に対して攻撃を行う一方、製品の多くでは運用保守ベンダーでは詳細な調査ができないためメーカーへの調査依頼が殺到し、速やかに回答を得られないケースが散見されています。また、こうした攻撃では機器の侵害後に横展開されるかどうか調査が不足しているケースも多く見受けられるため、注意喚起を出して終わりではなく、その後の調査までサポートが必要になります。
現状では、情報発信をするすべての機関があらゆる製品に対してこうした調査まで行う能力・リソースを有しているわけではないため、国全体としての対応にバラつきが出てしまっている次第です。

＜公表前の脆弱性情報／悪用情報の取り扱いについて＞

こちらも有識者提言では触れられなかったポイントです。現行の国内制度上は、公表前の脆弱性の詳細に関する情報はごく限られた関係者（IPA、JPCERT/CC、メーカー、発見者）間で取り扱いがなされます。例外はあり、2017年からは政府と一部の重要インフラ事業者に対して公表前の優先的な情報提供（「優先情報提供」）[11]が整備されています。
こうした「優先的な（公表前の）情報提供」については日本のような制度的なものではないものの、例えば海外においてはMicrosoft社がベンダー等に公表前の脆弱性情報提供行うMAPP（Microsoft Active Protections Program）[12]があります。
他方で、こうした公表前の事前情報提供については公表前の情報漏えい疑義のトラブルも発生[13]しています。現行の国内制度では、優先的な情報提供先は現時点で限られていることや、詳細な情報については調整フェーズ（基本的に発見者―JPCERT/CC―メーカー間のやり取り）内で扱われていることから、罰則規定のない取り扱い制度とはいえ、万が一不適切な扱いがあった場合に原因となった組織等を比較的特定しやすい体制にはなっています。他方で、2023年度の「情報システム等の脆弱性情報の取扱いに関する研究会」でJPCERT/CCから意見[14]を表明していますが、優先情報提供を拡充することへのメーカー側からの懸念が出ており、今後、公表前の脆弱性情報の扱いについてプレーヤー等が増えるのであれば、情報漏えい対策の議論がさらに必要になります。

さいごに

日本は世界的にも珍しく、公的な制度の元で官民連携による脆弱性情報のハンドリングが行われてきました。海外においては、基本的に発見者―メーカー間の直接／個別の調整が行われてきた結果、意図しない情報開示などのトラブルが度々起きてきました。他方で、JPCERT/CCが日々国際連携している中で見えている範囲では、海外において、脆弱性の悪用に関する情報の流通度は日に日に高まってきているように見えます。悪用情報に触れるプレーヤーがこれまでのさまざまな脆弱性情報ハンドリングの失敗を経験しながらも、徐々に相場観を形成し、自発的に足並みを揃え始めているのではないかと考えています。

日本においては脆弱性告示制度のもとで、特に公表前の脆弱性悪用に関する情報を流通させるプレーヤーがある意味限定されてきた経緯があるわけですが、一方で、今後は脆弱性悪用情報に触れる／発信するプレーヤーが増えていくことが想定されます。
今年5月にいわゆるサイバー対処能力強化法と同整備法が成立しましたが、強化法第42条では脆弱性のある製品のベンダー等に対して、「サイバー攻撃による被害を防止するために必要な措置を講ずるよう要請する」ことや、改正されたサイバーセキュリティ基本法第7条において、責務規定（利用者のサイバーセキュリティ確保のための設計・開発、情報の継続的な提供等に努める旨）が追加[15]されました。今後、行政機関やベンダーの役割が拡大されていく中で、脆弱性の公表だけでなく、悪用情報がどのように扱われ、ユーザーが調査のために必要な技術的情報がどのようなタイミングでどのような手段によって提供されるべきか、今後の議論にJPCERT/CCのこれまでの知見を積極的にインプットしていきたいと考えています。

参考文献等

[1]経済産業省「脆弱性関連情報取扱体制」https://www.meti.go.jp/policy/netsecurity/vulinfo.html

[2]IABというと、いわゆるクライム系アクターの一分類として扱われてきましたが、近年、APTキャンペーンにおいて分業制が採られるケースが増えており、APTキャンペーンにおける”IAB”的アクターを定義する動きもあります。Cisco Talos,"Redefining IABs: Impacts of compartmentalization on threat tracking and modeling", https://blog.talosintelligence.com/redefining-initial-access-brokers/

[3]2024/1/11 JPCERT/CC 「Ivanti Connect SecureおよびIvanti Policy Secureの脆弱性（CVE-2023-46805およびCVE-2024-21887）に関する注意喚起」https://www.jpcert.or.jp/at/2024/at240002.html

[4]2024/4/5 Google/Mandiant, “Cutting Edge, Part 4: Ivanti Connect Secure VPN Post-Exploitation Lateral Movement Case Studies”, https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement?hl=en

[5]JPCERT/CC Eyes 「なぜ、SSL-VPN製品の脆弱性は放置されるのか ～“サプライチェーン”攻撃という言葉の陰で見過ごされている攻撃原因について～」https://blogs.jpcert.or.jp/ja/2022/07/ssl-vpn.html

[6]https://www.cas.go.jp/jp/seisaku/cyber_anzen_hosyo/koujou_teigen/teigen.pdf

[7]海外機関―ベンダー間の調整前後で、公表前に情報共有がなされるケースもあります。

[8]鈴木潔「新型コロナウィルス感染防止対策における行政組織間の連携―冗長性・他機関連携・リーダーシップ―」（年報行政研究57「行政における冗長性」収録）

[9]https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html

[10]JPCERT/CC Eyes：注意喚起や情報共有活動における受信者側の「コスト」の問題について －情報発信がアリバイや成果目的の自己目的化した行為にならないために―
https://blogs.jpcert.or.jp/ja/2023/05/cost-and-effectiveness-of-alerts.html

[11]優先情報提供については、早期警戒パートナーシップガイドラインをご参照ください。
https://www.ipa.go.jp/security/guide/vuln/ug65p90000019by0-att/partnership_guideline.pdf
また、過去の検討経緯はIPAのHPで公開されている、過去の「情報システム等の脆弱性情報の取扱いに関する研究会」報告書でご覧いただけます。https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html

[12]https://www.microsoft.com/en-us/msrc/mapp

[13]2025年7月にゼロデイ攻撃が発覚・公表となった、Microsoft Sharepointの脆弱性（CVE-2025-53770等）について、MAPP経由で事前に情報が漏えいした可能性が指摘されていることについてブルームバーグ紙が報じました。現時点で本件の結論等はまだ不明ですが、同様の指摘は2021年のMicrosoft Exchange Serverの脆弱性（いわゆるProxyshell）についてもWSJ紙が報じた経緯があります。

[14]「情報システム等の脆弱性情報の取扱いに関する研究会」2023年度報告書33ページ　https://www.ipa.go.jp/security/reports/vuln/nq6ept000000ldxx-att/report2023.pdf

[15]https://www.nisc.go.jp/pdf/council/cs/dai43/43shiryou4.pdf