【要点抽出】サイバー攻撃被害に係る情報の共有・公表ガイダンス その2
後半です。残りのFAQ20問を読んでいきます。前半はこちら
ここからは公表や法令に基づく報告など、民間企業としてはより気になる点についてです。
3章 FAQ
今回も特に知っておきたいQには✅をつけます。
＜被害の公表や法令等に基づく報告・届出について＞
Q14.公表の目的は何ですか？
1章の「何のために」の通りです。
Q15.公表のタイミングはどのようなものがありますか？✅
以下が代表例として挙げられます。
攻撃が起きた後、時間が経過してから検知した場合（標的型攻撃など）は、
攻撃発覚時点や深刻な被害が判明した時
調査を終えた時
攻撃と同時に検知・対処を行う場合（DDoS攻撃など)は、
公表せずとも攻撃されていることが世間に気づかれることが多いですが、
攻撃の可能性に気づいた時
システムが復旧した時
詳細調査しているうちに他に深刻な被害がみつかった時
調査を終えた時
Q16.公表の内容としてはどのようなものがありますか？✅
大事なのでそのまま引用します。
・サイバー攻撃の種類／概要
・侵害されたシステム、範囲（現時点で判明しているもの）
・侵害原因（判明している場合）
・サイバー攻撃の発生日時や侵害期間（判明している場合）
・影響内容（業務影響、情報漏えい、サービス停止、その他）、影響範囲（現時点で判明しているもの）
・（即応的な第一報の場合）初動対応内容
・専門組織への相談有無（※公的機関の場合は当該組織名）、（該当する場合）所管省庁等への報告状況
・影響を受ける者・組織や二次被害に関する相談先
----------------------<以下は調査終了後の公表段階＞------------------------
・侵害原因、攻撃の経緯
・影響範囲
・対応の経緯
・再発防止策
・公表内容に関する問い合わせ先
公表は主に「被害内容・対応状況」を発表するものとこれまで書きました。
一方で、攻撃技術情報も他社の参考にもなるのでできるだけ書いた方がよい。とあります。
また、公表を早くしないと世間から文句を言われる反面、早すぎると情報が揃わないジレンマについても触れています。
こうした場合は、Q15のように初報、第二報、、と分けて出すことでバランスがとれそうです。
ただし、なんでも早けりゃいいというわけではなく、早く雑に出しすぎると、本当は被害が大したことがないのに騒ぎすぎたり、逆に後からどんどん深刻な情報が出て印象が悪くなったりする恐れがあります。
影響範囲が広そうだと分かった時や、長期間のシステム停止が必要そうな時に初報を出すなどタイミングは要注意です。
初報や最終報に含める情報の例が本書のQ17に掲載されています。
#便宜上、Q17の内容も混ぜてここに書いています
Q17.公表する際の留意点はありますか？
以下3点があげられています。
①公表／非公表の判断を自組織だけで行えないケースがある
（非公表のつもりでも関係者が多いと自然に漏れ出てしまうことがあったり、公表タイミングを関係各社で調整する必要があったり）
②途中段階での不完全な情報の伝え方によっては誤解を与えるケースがある
③詳しく公表しすぎてセキュリティ上のリスクを高めてしまう
Q18.警察への通報・相談は、行った方が良いでしょうか？
したほうがいいです。
Q19.警察に通報・相談することによる業務への影響はあるのでしょうか？
警察もそのへんは配慮しながら捜査するそうです。
Q20.所管省庁への任意の報告は、行った方が良いでしょうか？✅
したほうがいいです。
なお、以下は任意ではなく法的義務がありますので要注意。
個人データの漏洩、滅失、棄損：個人情報保護委員会へ
特定個人情報の漏洩等：個人情報保護委員会へ
各業法に基づく事故報告：所管省庁へ
当局から報告を求められた場合：求められた機関へ
上場企業でインシデントが起き、投資に影響を及ぼす場合：開示が必要
認定個人情報保護団体の対象事業者の場合：同団体へ
プライバシーマーク付与事業者：関係審査機関へ
その他、法的義務はないが報告を推奨するケースも載っています。
＜被害組織の保護の観点について＞
Q21. 公表していないのに自組織の被害が知られて公開されてしまうのはなぜですか？
以下が代表的なパターンです。
外から見たら分かる場合（Webサイトの改ざん等）
漏洩した情報や犯行声明を公開された場合
内部者による情報発信（SNS等）
検体解析結果からの推測
OSINTによる推測（こういう構成だから攻撃を受ける、受けた可能性があるのでは？的なもの）
特に脅迫型ランサムの場合は、攻撃者が窃取した情報を一部リークすることがあります。
この場合、自社で攻撃が発覚するタイミングと世間に知れ渡るタイミングがほぼ同時なので、被害組織的にはすごくバタつく辛さがあります。
Q22. 他組織の被害に関する情報を発見した場合、どうしたらよいですか？
直接相手組織に伝えるよりも、専門組織を介したほうがトラブル防止のために良いです。
Q23. 製品の脆弱性が悪用されていた場合、当該情報はどのように扱えばいいですか？✅
既知の脆弱性をついた攻撃の場合、公表することは問題ありません。
未知の脆弱性をついた攻撃の場合、安易に公表すると他の被害につながる恐れがありますので、「情報セキュリティ早期警戒パートナーシップガイドライン」に基づいてIPAやJPCERTに相談してください。
どうしても公表しなければならない場合は、製品名を出さずに「未知の脆弱性つかれちゃって、今しかるべき対応してるんです」くらいの表現が良いようです。
Q24. 他の被害組織を踏み台として攻撃された場合や利用するクラウドサービス、運用保守ベンダが管理／提供するシステムが攻撃された場合、当該情報はどのように扱えばいいですか？
Q22と同じです。
特にクラウドサービス事業者やMSPが被害を受けた場合、多数のサービス提供先の組織に通知する必要があり、そのタイミングや手法については様々な観点で判断する必要があります。
Q25. 共有・公表したことで二次被害が出てしまうような情報はありますか？
脆弱性ではなく、ソフトウェア等の設定不備に関する情報の場合は、模倣犯が表れる恐れがあります。
サービスやソフトウェア提供側が脆弱性を修正するわけにもいかず、各ユーザによる対応の早さによるため、二次被害につながる可能性があるのです。
＜攻撃技術情報の取扱いについて＞
Q26. マルウェアに関する情報とはどういうものですか？
ハッシュ値、マルウェアの種類、通信先、ファイル名やパス、主な機能、発見経緯
Q27.不正通信先に関する情報とはどういうものですか？
IPアドレス、ドメイン名、通信の発生時期や期間、プロトコル
ただし、攻撃者が攻撃元IPアドレスをコロコロ変える場合などは、上記の情報を共有してもうまく役立てられないこともあります。
Q28. 攻撃の手口に関する情報（TTP情報）とはどういうものですか？
初期侵入／感染経路
悪用される脆弱性
侵入／感染後の動き
攻撃目的／想定される被害
Q29.専門組織から「見つかった情報を共有活動に展開してよいか？」と尋ねられたらどう判断すればいいですか？
匿名なのか、誰に、何の目的なのか、によるものの、基本的には協力しましょう。
Q30. 情報共有先をどのように指定／制限すればいいですか？✅
TLPの紹介です。
RED:共有相手(個人)限り。転送や再共有は禁止。
AMBER：共有相手はNeed To Knowの考え方により組織内や関係組織には再共有可能。
再共有できる組織を絞る場合はAMBER+STRICTとする。
GREEN：共有相手はコミュニティ内になら再共有可能。一般公開は禁止。
CLEAR：一般公開可能
Q31. 専門組織から「分析結果をレポートとして発信してもよいか」と尋ねられたらどう判断すればいいですか？
社会を守るためにも、できるだけ協力するのが良いです。
Q32. どのような攻撃技術情報であれば速やかに共有することができますか？（公開情報と非公開情報の違いについて）
Q33. どのような攻撃技術情報であれば守秘義務契約上の「秘密情報」にあたりませんか？
調査ベンダ向け解説のため割愛
残りの章は割愛しますが、
4章 ケーススタディとして「標的型攻撃」「脆弱性をついたWebサーバへの不正アクセス」「侵入型ランサムウェア攻撃」の3つがまとまっています。
5章 チェックリスト/フローシートとして、情報共有と被害公表における出すべき情報一覧や、判断フローが載っています。
感想
長かったー！情報発信を掘り下げるとこんなに論点があるのですね。
それだけコミュニケーションは難しいものであり、これまでに上手く共有・公表できずに残念な感じに終わってる事例が多いのだろう…という過去の反省の積み重ねのようなものを背景に感じました。
その意味で、本書は情報発信における「そういうことじゃねえんだよ」を避けるためのノウハウ集なのだと思います。
しかもこうした絶妙な力加減が求められるコミュニケーションをインシデント対応のクソ忙しい中やらねばならないわけで、訓練なくしては急にできるものではないと思います。
また、民間企業としては公表や監督省庁への報告に意識がいきがちですが、情報共有について学べたことは貴重でした。
正直なところ、現場の人間としては
「忙しい中で共有にまで気を回せる余裕があるだろうか」
「攻撃情報だけであっても出したら色々質問される、変に噂たてられる、身構えるのではないだろうか」
という懸念はやはりまだあります。
しかし、経営ガイドラインの指示１０でも共有の大切さが触れられている通り、社会全体で共助が当たり前になっていかないと結局は自組織が困ることなりますね。
こうした部分もインシデント対応と並行してしっかりこなせるくらい、成熟度の高い組織にしたいものです。
＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら
この記事が気に入ったらサポートをしてみませんか？