インシデントレスポンス　～情報共有・公表の最適化～

フェロー　関原　弘樹  

2023年がスタートしました。

関東大震災から100年目、東日本大震災から十二支で一周となる今年ですが、パンデミックの収束や紛争の出口が見通せない中、大きな天災に見舞われないような平穏な一年となるのを願うばかりです。

さて、今回のコラムでは今年もこれまで以上に攻勢が強まりそうなサイバー攻撃について、そのインシデントレスポンスの効果/効率を大きく左右する「情報の共有・公表」についての話題を取り上げます。

組織がサイバー攻撃を受けた際、そのインシデントによる被害を金銭的尺度に換算した被害額は攻撃開始から発覚、及び発覚から復旧までの時間に比例することは過去に何度も指摘されてきました。
 
となるとどの組織も被害最小化のためにインシデント発生後は素早い復旧を目指す必要がありますが、ここで「情報の非対称性」が素早い復旧の大きな障害となっていると指摘されています。
 
ここでいう「情報の非対称性」とは大きく分けて2種類です。
①サイバー攻撃が組織化、高度化する中で単一組織が持つ情報だけではその対応が難しくなっているが、現状は同様の攻撃を受けた他組織との情報共有ができていない（タコ壺化ともいえます）
②インシデントの事実、対応状況について被害組織は公表における影響を迅速かつ正確に判断することが難しく、外部のステークホルダへの適切な被害公表ができていない（遅くなって隠ぺいと叩かれるというやつですね）
 
逆に言うと
①ができていて情報共有が可能であれば迅速な攻撃の発見や復旧によりトータルの被害額の低減が可能となりますし、②ができていれば取引先、メディア、ユーザについて必要なアクションを促し、2次被害を最小化するとともに、自社のレピュテーションやブランドイメージの毀損を最小限に抑えるといったことが可能となります。
 
また、この被害額の低減や毀損の最小化は単一の組織レベルにとどまらず同一のターゲット群となりやすい同じエリアや同じ業界といった包括したレベルでも言えることでしょう。

これらの問題を踏まえ昨年末に
内閣サイバーセキュリティセンター（NISC） 
警察庁 
総務省 
経済産業省
が連名で「サイバー攻撃被害に係る情報の共有・公表ガイダンス」の案を発表しました。
※現在そのパブリックコメントを募集中(～1/30)です
 
 
内閣官房内閣サイバーセキュリティセンター（NISC） 
「サイバー攻撃被害に係る情報の共有・公表ガイダンス（案）」に関する意見募集について

https://www.nisc.go.jp/policy/group/kihon-2/pubcom-guidance2022.html(外部リンク)

パブリックコメントの対象となるドラフト版のガイダンス（PDF）は上記ページからリンクまたは、以下よりダウンロード可能です。
サイバー攻撃被害に係る情報の共有・公表ガイダンス（案）（本文）
https://www.nisc.go.jp/pdf/policy/kihon-2/guidance(draft)_honbun.pdf(外部リンク)
 
また、同時にサマリとして概要のプレゼンテーションファイル（PDF）も公開されています。
お時間のない方はこちらを確認していただくのもいいでしょう。
サイバー攻撃被害に係る情報の共有・公表ガイダンス（案）（概要）
https://www.nisc.go.jp/pdf/policy/kihon-2/guidance(draft)_gaiyou.pdf(外部リンク)
 
本コラムでは適宜これらファイルより図表を引用しています。

ガイダンスの目的や概要はプレゼンテーションファイルのP2を見ていただくと一目瞭然です。
現場の実務に沿った内容/構成というところを強調しています。
 
また、ちょっとわかりにくいかもしれませんが主として情報の発信元となる、すでに被害を受けた組織のためだけではなく、主に情報を受信する側の今まさに被害を受けようとしている組織へ効果をもたらすことも重要な要素になっています。単一組織だけというよりも全体を救いたいというのが第一義です。

あとは、対象となる情報としてマルウェア、ネットワーク、システム構成といったテクニカルな部分もありますが、組織の連携状況といったノンテクニカルな部分も重要なのでそこを意識していただくといいかと思います。

本ガイダンスの使い方としてはプレゼンテーションファイルのP6のように以下の3つが挙げられています。
 
流れから言うとまず
中心となるCSIRT、インシデントレスポンスメンバーが「共有／公表のやり方がわからない場合の目安」として本ガイダンスを正しく理解 
↓ 
その後、各ステークホルダに「社内理解のための参照として」「調整の相手方への説明資料として」と展開
していく形が自然ですね。

資料と順序が前後しますが目次で全体像が確認できます。

まず、枕に置かれた用語や用語集ですがドラフト版ガイダンスのP6で「共有」「報告／届出」「連絡」「公表」の違いについての整理がされていますのでここは確認しておきたいですね。
 
スペースの関係で一言になりますが
「共有」                ⇒（業界特有のものを含む）セキュリティ組織に対して 
「報告／届出」       ⇒お上に対して 
「連絡」                ⇒顧客を含むサプライチェーンに対して 
「公表」                ⇒世間一般に対して
 
という解釈ができます。

時間の都合上「さわりの部分だけを」なんていうときの「さわり」という言葉は今では物事の導入部分という意味で理解されることが多いですが、本来の意味は歌舞伎でおなじみの三味線と語りからなる義太夫節の「聞かせどころ」のことで、転じて物事の最も重要な部分を指しています。
 
なぜ「さわり」というのか？
それは義太夫節では変化をつけるためにしばしば他の音曲の様式をつかった（他の曲に触る）ことからきています。現代の楽曲で言うとサビの繰り返しからさらに転調してみるようなものでしょうか？
 
話がそれました。
まず、プレゼンテーションファイルのP7～16のスライドタイトルを確認すると以下の様になっています。
 
1.(1) 情報共有の目的：速やかな情報共有の必要性 
1.(2) 情報共有のタイミング：「共有」と「公表」の分離 
1.(3) 共有情報の整理：攻撃技術情報と被害内容・対応情報の分離 
  
2.(1) 被害公表の目的 
2.(2) 被害公表のタイミング 
2.(3) 被害公表内容の整理 
  
3. 外部組織（専門組織、警察、行政機関等）との連携 
4. 機微な情報への配慮

行数も考慮してみてみると本ガイダンスの「さわり」は「１. 」と「2. 」の項目と受け取れます。
##なぜならば「３. 」「４. 」はインシデントレスポンスではすでに一般的な話なので、本ガイダンスでは「関連して当然これも忘れないでおいてください」という位置付けになるからです。
 
①インシデントに関する情報共有とインシデントによる被害の公表は分けて考える
被害最小化のために迅速さが優先の攻撃手法等の情報はセキュリティ組織に早いタイミングで共有する。
一方、様々なステークホルダへの調整が必要な被害の公表については共有とは分けて考えて（遅くなりすぎない）適切なタイミングを計って実施することが望ましい。
 
②共有と公表のタイミングは現在のフェーズを理解し、フェーズごとに必要なアクションを行う
共有については攻撃キャンペーン※の検知のため早期に必要となる攻撃技術情報は第1報として、調査が必要な被害内容・対応情報は第2報とすることで結果的に必要十分なタイムリーな情報共有ができる。
公表については目的（法令/ガイドライン、注意喚起、対外説明、広報/リーガルリスク）と対象（全体、不特定多数）を明確にすることで公表を行うべきタイミングと公表に必要な情報が決まってくるので結果、対応工数も少なく無理がなくなり組織への信頼のさらなる低下を防止できる。
 
 
※一定期間内において特定の組織／分野に対して特定の攻撃手法／攻撃インフラを用いて行われる攻撃活動

ここには以下の4項目についてのFAQが計33問記載されています。
＜情報共有の方法等について＞　⇒Q1~13 
＜被害の公表や法令等に基づく報告・届出について＞　⇒Q14~20 
＜被害組織の保護の観点について＞　⇒Q21~25 
＜攻撃技術情報の取扱いについて＞　⇒Q26~33
 
全てを紹介することはできませんが、若番の方から包括的で重要度が高くなっています。疑問に思ったQuestion、興味のあるQuestionからご覧になっていただければいいと思います。
 
ここではガイダンスの目的に紐付けて特に重要な部分として以下を要約しておきます（2つのFAQ間で丸付数字の内容は対応していません）
Q4.サイバー攻撃被害に係る情報にはどのようなものがありますか？ 
⇒①被害内容や被害組織の対処内容を示す情報
②攻撃者の活動や攻撃方法を示す情報
前者を「被害内容・対応情報」、後者を「攻撃技術情報」と呼ぶ

このセクションでは以下3つのケースが解説されています。
ケース 1：標的型サイバー攻撃  
ケース 2：脆弱性を突いた Web サーバ等への不正アクセス  
ケース 3：侵入型ランサムウェア攻撃
 
スペースの都合上詳細な解説はできませんが、現在のサイバー攻撃で典型的ともいえる上記3つの攻撃ケースそれぞれについて
①発覚～初動対応～詳細な調査の各フェーズの状況を提示
②行動の判断に関連するポイントを解説
③適切な対応を記載
となっているので
ここをじっくり読んでいただくといざというときでも落ち着いて正しい対処が可能になるなという印象です。
CSIRTやインシデント対応メンバー内で読み合わせをしてみるのも有効でしょう。
 

例）ケース 3：侵入型ランサムウェア攻撃の冒頭

巻末に付録的に1つのチェックリストと2つのフローチャートが記載されています。
・情報共有と被害公表における情報の種類のチェックリスト 
・情報共有判断のためのフロー 
・被害公表判断のためのフロー
 
チェックリストの使い勝手は何とも言えませんが2つのフローチャートは実用性が高そうなので情シスの部屋の壁あたりに貼っておき定期的に眺めてみるのも有益かもしれません。

情報共有判断のためのフロー（前半抜粋）

このフローチャートではFAQでも示されたように被害を与えた攻撃が「よく知られた過去のものか？」それとも「新しいキャンペーンの可能性があるか？」により最初の情報共有方針が決まるとしています。

被害公表判断のためのフロー（前半抜粋）

ここでは関連する法令や個々の顧客との契約に基づいての判断が第一であることから、事前にそれらを確認し基準を正確に認識しておくことが最も重要だということが一目でわかります。

今年の大河ドラマは「どうする家康」です。
 
家康の祖父である松平清康は幼少の時分に家督を継ぎ、日の出の勢いで東海地方に勢力を広げた名将でしたが25歳の時、織田家との合戦直前に流言から疑心暗鬼になった家臣に斬られ絶命しています。
 
これは陣中で清康が乗っていた馬が突然暴れ出したという些細なインシデントが発生した後、現場が混乱し情報が錯綜した結果と伝えられています。
 
歴史の「If」は時間と場所を飛び越えていつもわれわれの想像力をかき立てますが、もしもその時、現場の侍たちが事実関係をしっかり掴んで正しい対応をしていれば……
その後の合戦がどうなっていたのか興味がわきます。
 
もしかすると信長、秀吉の覇権を含め戦国時代後期のその勢力図は全く違ったものになっていたかもしれません。
 
 
まあ、それはさておいて今回ご覧いただいたように本ガイダンスは現場レベルの対応にかなり有用なものになりそうです。CSIRT、インシデントレスポンスメンバーの方々はガイダンスの正式版がリリースされた際にはぜひご確認いただければと思います。
 
 
ではまた、次回のエントリーでお会いしましょう。
 
 
Hiroki Sekihara,
CGEIT, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,
AWS Certified Security – Specialty,
Azure Solutions Architect Expert,
Google Cloud Certified Professional Cloud Security Engineer,
Oracle Cloud Infrastructure 2021 Certified Architect Professional,
Oracle Cloud Platform Identity and Security Management 2021 Certified Specialist,

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。