サイバー攻撃被害の公表、果たして「正解」なんてあるのか？
（ver.1.2）

一般社団法人JPCERTコーディネーションセンター
政策担当部長 兼 早期警戒グループマネージャー
脅威アナリスト
佐々木 勇人「InternetWeek2023」でのセッション
専門機関、弁護士、メディア／記者の3つの立場・視点から、サイバー攻撃被害公表の論点、あり方について議論「被害情報」を巡って、極めて複雑で利害関係が衝突し合う状況が存在する点について要素分解しながら解説「答えがない」課題に対して、いかに漸次的に問題を解消していくか1© 2024 JPCERT/CC前回のおさらい2© 2024 JPCERT/CC

被害公表をめぐってよくある議論
本当にそうなのか？

・情報共有のために被害公表すべき・情報共有のために攻撃手口についても公表します

・原因／手口についても公表することで注意喚起効果がある

・他の組織の被害予防に役立てば幸いです

被害公表

3

© 2024 JPCERT/CC

それぞれの「ジレンマ」
報道により、適切な二次被害防止の対応等を行っているか明らかになることを期待？

ステークホルダーメディア© 2024 JPCERT/CC

法実務（技術的な）事実関係が適切に報じられないことへの懸念

報道等により、脅威への認知が社会全体に広がること
4

情報が開示されないことへの懸念

適切な事案対応方法が広まること

セキュリティ

他の被害組織／標的組織「サイバー攻撃被害に係る情報の共有・公表ガイダンス」
2022年5月よりサイバーセキュリティ協議会に設置された「サイバー攻撃被害に係る情報の共有・公表ガイダンス検討会」（事務局：警察庁、総務省、経済産業省、NISC、JPCERT/CC）
にて検討を行ったもの
パブリックコメント実施の後、2023年3月に同ガイダンスを公表

出典：内閣サイバーセキュリティセンター
「サイバー攻撃被害に係る情報の共有・公表ガイダンス検討会」
https://www.nisc.go.jp/council/cs/kyogikai/guidancekentoukai.html

5© 2024 JPCERT/CC

ガイダンスのコンセプト：「情報共有」と「被害公表」の分離タイミングの違い：被害公表時では情報共有として有効なタイミングを失している
目的の違い：情報共有の目的と被害公表の目的は違う
手段／対象の違い：情報共有→非公表で他の標的／被害組織に対して行う
影響を受ける関係者に広く伝える

6© 2024 JPCERT/CC

被害公表→ステークホルダーなど

ガイダンスのコンセプト：攻撃技術情報と被害内容・対応情報の分離
情報を整理し切り分けることで、被害組織の匿名化や速やかな情報共有を行うことができる
ただ、厳密な切り分けが難しい情報／ケースもある（特定製品の脆弱性や特定サービスが“踏み台”となった事案など）
攻撃技術情報であっても、被害組織が推測し得る情報もあるため注意が必要（※ガイダンスで解説）
サイバー攻撃被害情報の分解
被害内容・対応情報

被害組織名
業種／規模
被害内容
タイムライン（対応状況）
タイムライン（技術情報）
攻撃対象システム共有
基本的に個別の被害組織には紐づかず（※）、対応初期で見つかりやすく、早期に情報共有しなければ効果を得られない情報

7© 2024 JPCERT/CC（被害対象の）対策状況
攻撃主体に関する情報

攻撃技術情報（自組織や他組織において）攻撃の全容解明による原因・被害範囲の特定や再発防止に必要な情報

脆弱性関連情報等
その他TTP
マルウェア
通信先

主に影響を受けるステークホルダー等へ説明を行うもの

公表
ある程度調査期間を経なければ判明しない情報や、ステークホルダー等との調整が必要な機微な情報などが含まれるため、公表までに時間がかかる情報

被害公表の目的

8© 2024 JPCERT/CC

平時・有事における公表・開示（法制度を中心に）
 個人情報保護法

保有個人データの安全管理措置の公表等（問い合わせへの回答でもよい）（2022年

組織のセキュリティ

4月1日～）

平 対策やリスク管理体制、  金融商品取引法
ガバナンス等の公表・

時 開示

①
②

有価証券報告書等におけるサステナビリティ情報の開示（2023年3月期～）※「サステナビリティ情報」には、サイバーセキュリティやデータセキュリティ等が含まれうる内部統制報告制度（J-SOX法）の改訂：サイバーリスクの高まりを踏まえたセキュリティ確保の重要性を記載（2024年4月1日～）

 個人情報保護法
有 サイバー攻撃を含むインシデントに関する事 公表・開示

公表自体は「望ましい措置」だが、本人通知義務の履行が困難な場合の代替措置として公表が必要となる場合がある（2022年4月1日～）

 有価証券上場規程

上場会社等においてサイバーセキュリティインシデントが発生し、それが投資判断に著しい影響を及ぼす場合の適時開示
参考：財政に著しい影響：臨時報告書（金融商品取引法）※サイバーインシデントが特出しされているわけではない

出典：InternetWeek 2023 「サイバー攻撃被害の公表、果たして「正解」なんてあるのか？」パネル登壇の森・濱田松本法律事務所 蔦大輔先生投影資料より

9© 2024 JPCERT/CC

米国証券取引委員会：セキュリティ関連の開示ルール
 米国証券取引委員会（SEC）による開示ルールの採択
SECは、2023年7月26日付で、上場登録会社に対し、主に以下の2つを義務付ける規則を採択（1）サイバーセキュリティ体制に関する定期開示（年次） サイバーセキュリティに関するリスク管理、戦略、ガバナンスの開示（2）重大なサイバーセキュリティインシデントの臨時開示
 サイバーセキュリティインシデントが重大であると判断してから４営業日以内に提出 インシデント発見から不当な遅延なく重大性を判断 制度の観点からの日本への影響
日本においても同種の制度導入に向けての議論の可能性

出典：InternetWeek 2023 「サイバー攻撃被害の公表、果たして「正解」なんてあるのか？」パネル登壇

10© 2024 JPCERT/CC

森・濱田松本法律事務所 蔦大輔先生

投影資料より「セキュリティ上の理由で答えられない」という回答で耐えられるのか・・・
脆弱性公表

レポート公表メーカー

セキュリティ専門企業／専門機関

報道／SNS

侵害原因は製品Xの脆弱性悪用ではないかと推測する情報

製品Xの脆弱性／悪用事案に関する情報

問い合わせ保護すべき何らかの利害関係者、法益

セキュリティ上の問題ではなく、当該利害関係者等との関係性や法令上の問題
11© 2024 JPCERT/CC

原因について知りたい／知るべき者（ステークホルダーなど）

外形上のインフラ調査
検索エンジン
リサーチャーなど

ガイダンスにおける「原因情報」の取り扱いの解説①

12© 2024 JPCERT/CC

ガイダンスにおける「原因情報」の取り扱いの解説②

13© 2024 JPCERT/CC

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

悪用する攻撃活動は続いていないため、注意喚起効果はない（A）注意喚起効果
個別のインシデント対応

攻撃キャンペーン© 2024 JPCERT/CC

被害公表
まだ悪用する攻撃活動が続いている
ようであれば、注意喚起効果がある

悪用が拡大しているようであれば、直ちに脆弱性公表＋注意喚起が行われる

14

被害公表

情報共有

注意喚起（公開）

他の組織への攻撃

初期侵害経路となる脆弱性公表／注意喚起の増加
2019年
・Pulse Connect Secure（CVE-2019-11510）
・Fortigate（CVE-2018-13379）
2020年
・Citrix（CVE-2019-19781）
・BIG-IP（CVE-2020-5902）
・Trend Micro製品の複数の脆弱性
2021年
・Filezen（CVE-2021-20655）
・SonicWall（CVE-2021-20016）
・Proxyshell（Exchange Serverの複数の脆弱性）
・Trend Micro 製品の脆弱性（CVE-2020-24557等）
・Pulse Connect Secure（CVE-2021-22893）（・Confluence脆弱性（CVE-2021-26084））（・ManageEngine ADSelfService Plusの脆弱性（CVE-2021-40539)）（・Vmware Horizon Log4j脆弱性）
2022年
・Sonicwall SMA100シリーズの複数の脆弱性
・BIG-IP（CVE-2022-1388）
・Trend Micro Apex Central製品の脆弱性（CVE-2022-26871）
・FortiOS等の脆弱性（CVE-2022-40684）
・FortiOS（CVE-2022-42475）
2023年（・MOVEit File Transferの複数の脆弱性）
・Citrix ADCおよびCitrix Gatewayの脆弱性（CVE-2023-3519）
・Proself の複数の脆弱性（CVE-2023-39415等）
・FortiOS等の脆弱性（CVE-2023-27997）（・Ivanti Endpoint Manager Mobileの複数の脆弱性）
・BarracudaESG（CVE-2023-2868）
・Citrix ADCおよびCitrix Gatewayの脆弱性（CVE-2023-3519）
・Array Networks Array AGシリーズの脆弱性
・ProselfのXML外部実体参照（XXE）に関する脆弱性
・Cisco IOS XEのWeb UIにおける権限昇格の脆弱性（CVE-2023-20198）
括弧付は国内で注意喚起が発行されなかったもの

15© 2024 JPCERT/CC

標的型サイバー攻撃や侵入型ランサムウェア攻撃の初期侵入経路（Attack Vector／Initial access）として悪用される脆弱性が多く見つかった3年間
引き続きメール経由で侵入を試みる標的型サイバー攻撃も存在するところ、特に侵入型ランサムウェア攻撃を中心に、インターネットに面したソフトウェア製品の脆弱性を突く攻撃が相次ぐ
他方で、Emotetのテイクダウン（※その後断続的に活動再開）、Trickbotの活動停止など、マルウェアディストリビューターが拡散させるマルウェア経由での侵害事案は想定的に減ったのではないかと推測＜傾向＞
ランサムアクターによるゼロデイ攻撃での悪用
特定製品分野でクリティカルな脆弱性が度々見つかる＆悪用される（例：SSL-VPN製品、オンラインストレージ）
特定製品で度々クリティカルな脆弱性が見つかる＆悪用される（例：Fortigate、Sonicwall、Proself）

外形上「見える」侵害経路からの被害事例

出典：大阪急性期・総合医療センター「情報セキュリティインシデント調査委員会報告書について」
https://www.gh.opho.jp/important/785.html

16© 2024 JPCERT/CC

出典：内閣官房内閣サイバーセキュリティセンター
「内閣サイバーセキュリティセンターの電子メール関連システムからのメールデータの漏えいの可能性について」
https://www.nisc.go.jp/pdf/news/houdousiryou_20230804.pdf

「特定の製品／サービスが悪用された」という情報
同じ情報であっても、「その情報をどう扱いたいか」という点においてそれぞれ利害の異なるプレーヤーが複雑に関係する状態にある ⇒ 情報を扱うにあたって利害の衝突が発生してしまう
消極的な背景／動機を持つ

積極的な背景／動機を持つ

メーカー

被害組織
原因：製品／サービス⇒ 自組織の“責任”を減らす情報

原因：製品／サービス⇒ 自組織の“責任”を増やす情報
Sier／運用保守ベンダー

積極的な背景／動機を持つ
他のユーザー17© 2024 JPCERT/CC

専門組織

メディア

顧客、取引先なぜメーカーからの情報だけでは不十分か
脆弱性の悪用事案が発生している場合、「脆弱性情報」を伝えるだけでは足りない
当該脆弱性悪用はあくまでInitinal Accessでしかないため、その後のラテラルムーブメントの調査をどうフォローできるかが重要
当該製品／サービスについて最も情報を有している

メーカー

専門組織

（セキュリティベンダー／専門機関）

運用保守ベンダー

18© 2024 JPCERT/CC

攻撃手法／調査方法について最も情報を有しているインシデント対応をどこまでフォローできるのか「外からの情報」によって、被害組織が対応の温度感を認識・判断できる場合がある
他方で外部が“無風”であれば、対応の温度感を認識することができなくなる
当該製品／サービスについて最も情報を有している・専門機関からの情報
・（上記などの踏まえた）報道
・ステークホルダー等からの問い合わせ
・他の被害組織からの被害公表

メーカー

専門組織

（セキュリティベンダー／専門機関）

運用保守ベンダー

被害組織
19© 2024 JPCERT/CC

攻撃手法／調査方法について最も情報を有している

その後の論点・議論20© 2024 JPCERT/CC

「被害公表／報道が増えた気がする」の背景
令和2年改正の全面施行（2022年4月～）以降の変化「棄損」や「可能性」での報告義務化
3～5日以内の速報対応が必要に
これまで「個人情報漏えい」として明確に扱われてこなかった事案も事故報告対象になり、被害公表対象としても増加している（特に、ランサムウェア攻撃被害）

これまで被害組織が想定していたもの

改正保護法の施行以降データの棄損

データが外部に送信された痕跡が確認できなかった（※ログの不足等による）

8© 2024 JPCERT/CC

リークサイトを用いるなど、データの外部漏えいを基本的に行うアクター漏えいの可能性

ランサムウェア攻撃被害の特性
他の不正アクセス事案に比べ、外部に被害事実が早期に認知されやすい
業務影響

・顧客／取引先への連絡により被害を推測させる情報が拡散
・生産ライン停止時などに従業員等がSNS上でつぶやいてしまう、等

個情法対応

・漏えい等の恐れが高い時点で顧客等への通知と被害公表が行われる（原因が「ランサム」と明かさなくても、上記／下記等の事情から容易に推測されてしまう）

リーク

OSINT

・（特に海外事案で）検体がVirustotalなどにアップロードされ、脅迫文から被害組織が推測されてしまうケース
・Webサーバー等外部からアクセス可能なシステムが暗号化されたり、ランサムノートが設置されてしまうことで、被害が検索可能なケース

22© 2024 JPCERT/CC

ランサムウェア犯罪者の経済合理性
身代金支払いという選択肢は決して非合理的に選択されているわけではなく、極めて合理的に選択されている。
攻撃者側も経済的に合理的な要求をしている
他方で、被害組織を取り巻く環境は被害組織に非合理的なコストを負担させてしまっている
本来必要のない調査や初動対応不備による機会損失の発生、インシデント対応における当局対応コストやレピュテーションリスクなど、「避けられるはずの損失・コスト」が“加算”されてしまっている身代金の方がはるかに安いだろ？
“勉強代”と考えたら、セキュリティ専門企業の調査より安いだろ？

身代金要求額＜バックアップがなかったことで復元できなかったデータの棄損による損失

必要な復旧・調査費用
初動対応で行ったネットワーク遮断の影響による機会損失
本来必要のない調査費用等／不適切な調査

知見不足なファーストレスポンダーによる初動対応不備

23© 2024 JPCERT/CC

行政指導／罰金行政／警察への対応コスト
報道／SNS等での情報拡散（レピュテーションダメージ）最近いただいた質問「最近のランサムウェア攻撃の被害リリースにおいて、『ランサムウェア（攻撃）』と明記しないものが散見される。被害公表に『ランサムウェア／ランサム攻撃による～』と書かない理由はあるのか？」
結論から言えば、「書かない合理的理由はない」
ただし、直近の報道事案等を踏まえて、「注目されたくない」と考える被害組織も多いと推察

24© 2024 JPCERT/CC

ランサム攻撃であると公表することで攻撃はどう変化するか（※暫定的な考察）
二重の脅迫タイプの場合公表することで攻撃者はどう反応するか

暗号化実行＆脅迫時点ですでに標的組織 NW
内から撤収している場合

身代金を支払わない
身代金を支払う方向で交渉を始めている場合支払う気がないのではないかと考える。
場合によっては激高して報復（リークサイトに掲載する）

二重の脅迫タイプでない場合
身代金を支払わない

さらなる脅迫のために追加攻撃をする可能性があるが、再侵入できない場合はDDoSか追加コンタクト（連絡）程度となる

身代金を支払う方向で交渉を始めている場合

さらなる脅迫か、あるいは報復のために攻撃するが、再侵入できない場合は上記に同じ

上記いずれのタイプであれ、現在も攻撃者がNW内にいる場合／管理権限等を掌握・侵害している場合

25

身代金を支払わない

さらなる脅迫のために追加攻撃をする可能性※公表がなくても行う可能性がある

身代金を支払う方向で交渉を始めている場合支払う気がないのではないかと考える。場合によっては激高して報復（妨害／追加の被害）© 2024 JPCERT/CC

リークサイトに掲載する※ただし、これは被害組織に対する威力ではなく、将来の標的組織に対する“みせしめ”であって、公表しようがしまいが実施される
リークサイトに掲載する※上記のほか、報復措置の可能性も含む

報道と被害公表
被害組織からの公表前の“スクープ”記事再び・・・

出典：読売新聞オンライン「ＪＡＸＡにサイバー攻撃か、宇宙開発の「機微」
閲覧の恐れ…警察から連絡受けるまで気づかず 」
https://www.yomiuri.co.jp/politics/20231128-OYT1T50242/

26© 2024 JPCERT/CC

出典：朝日新聞デジタル「JAXAに複数回サイバー攻撃、機密流出か NASA、トヨタ情報も」https://www.asahi.com/articles/ASS6N40X6S6NUTIL02GM.html

被害組織だけの問題ではない
被害情報に触れる各プレーヤーは極めて利己的に被害情報を扱いやすい構造にある
被害組織側がコントロールできない情報開示が発生すると、同じ攻撃を受けている他の被害組織からの相談・情報提供が委縮してしまい、全体として攻撃対処に失敗する

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

27© 2024 JPCERT/CC

「攻撃キャンペーン」という観点の欠如
攻撃活動をミクロな観点だけで見ていると、「被害情報を開示すべきか否か」という極論に陥る「攻撃キャンペーン」という観点から、他の被害組織、そして、次の標的組織の関係性というマクロな観点で見た場合、「被害情報を開示すべきか否か」という単純な議論
ではなくなる

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

28© 2024 JPCERT/CC

攻撃活動と被害組織保護という観点の欠如「現在進行形」の事案に対する関係者の意識の欠如
被害組織自身が被害開示をコントロールしにくい事案であるランサムウェア攻撃の増加
被害が外部に知られること自体が攻撃者を利することに⇒ 被害組織以外の関係者の「配慮」が必要
一般的な不正アクセス事案

過去の攻撃キャンペーン

過去の攻撃

標的型攻撃キャンペーン事案

調査

過去の攻撃キャンペーン

過去の攻撃ランサム事案

29

発覚© 2024 JPCERT/CC

新たな攻撃キャンペーン

発覚

調査

現在の攻撃発覚

初動対応

攻撃者の動向を踏まえた情報開示
・流通が必要になるタイミング

攻撃者の動向を踏まえた情報開示・流通が必要になるタイミング

被害「事実」は周知されるのか？
インシデント対応現場は被害組織と調査ベンダーの間の「閉鎖空間」
第三者の眼が入りづらいため、初動対応やその後調査等に失敗していても、修正されにくい構造
攻撃や被害の全容について調査不足・対応不足のまま被害公表やステークホルダーへの通知が行われてしまっていても、誰もそのミスに気付けない
セカンドピニオン的相談やファーストレスポンダー同士の平時から情報共有（知見の補強）が必要「外部の専門家に相談しています」「〇〇省に報告しています」

断片的な情報開示

ファーストレスポンダー

出典：JPCERT/CC Eyes
（上）https://blogs.jpcert.or.jp/ja/2024/03/ransom_incident_and_infosharing.html（下）https://blogs.jpcert.or.jp/ja/2024/07/ir_consult.html

30© 2024 JPCERT/CC

技術的な評価できない

技術的な評価できない

行政