--- title: "#6　セキュリティ・インシデント発生！その時に直面する課題 その②" description: セキュリティ・インシデント発生時にお客様が直面する問題と、対処の考え方などを解説します。今回は調査を進めていくうちに気づく３つの問題、そして最終的な終息を宣言する際に考慮が必要な３つのポイントを説明します。 --- [Security Report ](https://www.iim.co.jp/security-report) # [#6　セキュリティ・インシデント発生！その時に直面する課題 その②](https://www.iim.co.jp/security-report/no006) 作成者: [山本 太郎](https://www.iim.co.jp/security-report/author/yamadatarou)｜Sep 7, 2023 1:00:00 AM   さて、今回は前回に引き続き、セキュリティ・インシデント発生時にお客様が直面する問題と、対処の考え方などを解説します。 その①では、インシデント発生直後から調査開始までにお客様が直面する課題について事例をあげて説明しました。 今回は調査を進めていくうちに気づく３つの問題、そして、最終的な終息を宣言する際に考慮が必要な３つのポイントを説明します。   ＃6 調査の進め方。そこで起こる問題。 　調査における３つの問題 インシデントの終了宣言。困難な終了の定義。 　「終了」を定義する３つのポイント     ## 調査の進め方。そこで起こる問題。 ### 調査における３つの問題 調査が始まってもいくつかの問題が生じる可能性があります。 本稿では、そのうち次の3つを取り上げて説明します。   - フォレンジックベンダーによる過剰な調査 - 失敗するサイロ化した調査 - シナリオベース調査の問題   #### フォレンジックベンダーによる過剰な調査  調査対象を論理的に設定しておかないと、フォレンジックベンダーの意向で次から次へと調査対象を拡大され続けてしまいます。 「このセグメントのPCを全数調査します」と他社フォレンジックベンダーに言われ、莫大な調査費用が生じたケースがありました。    多くのフォレンジックベンダーでは、影響範囲の特定の目的によりフォレンジックを実施していますが、技術的な視点からそれは合理的ではありません。侵入経路から認知された事象までがどのように引き起こされたのか、という根本原因や攻撃の全容解明と、その影響範囲の特定は別の技術的手法が採られるべきです。   「とにかく全数をフォレンジック対象にして実施する」というフォレンジックベンダーに対して、本来であればNOというべきですが、被害組織の中に技術的にフォレンジックベンダーと議論できる技術者はいないことがほとんどであるため、多くのケースではフォレンジックベンダーの言いなりになってしまうようです。    影響範囲の特定では、調査対象が非常に広くなります。 筆者が実施したケースでは、日本、ドイツ、英国、米国各地のPCの影響を調査するため、IoC : Indicator of Compromise（影響の痕跡）に係わる情報を抽出する専用プログラムを開発し、被害企業のIT担当者に全PC上で実行してもらうことにより影響範囲を正確に特定しました。   #### 失敗するサイロ化した調査 サイロ化した調査とは、サーバー担当、ネットワーク担当、クライアント担当など各技術担当がそれぞれの責任範囲の中で調査を進め、それぞれの発見した内容を報告する形で進める調査のことです。 事故対策委員会の中で、ファシリテーターとなったCSIRTが「サーバーでは何か新しいことが分かりましたか？」と進められている場合、それは「サイロ化した調査」です。 また、サーバー別のフォレンジック結果がExcelにまとめられている場合、粒度は細かいですがそれも「サイロ化した調査」です。 サイロ化した調査でインシデント全体が明らかになることはほとんどなく、調査が失敗すると言っても過言ではありません。 筆者は「その調査方法では失敗します」と何回もお客様に発言してきました。 セキュリティは横串で考える、とはよく言われることです。これは、インシデント対応においても全く同じです。 インシデント対応における横串とは、複数のサーバー、ネットワーク機器、複数のPC等の情報を一カ所にまとめ相関して総合的に調査をすることが必要です。 #### シナリオベース調査の問題 シナリオベースの調査とは、事象を認知するまでの過程をシナリオとして構築（多くの場合は複数のシナリオを作成されます）し、そのシナリオに適合する証拠を探す調査方法です。   この方法には、いくつかの致命的な問題があります。 そのうち特に問題なのは、「証拠物の無視」が無意識に生じてしまうことです。 シナリオベースでの調査実施者は「シナリオに適合する情報を収集」しようとします。 これにより、「シナリオに適合しない情報の無視」が結果的に生じる理由になります。 もちろん、調査実施者が意図的に無視するのではありません。 これは、経験を積んだ調査担当者ですら生じる可能性があります。 一般的には、シナリオベース調査は分かりやすいものですが、シナリオを作成することで調査方針が確定したという「錯覚」を関係者にもたらします。 サイロ化した調査同様、筆者は何回も「その調査方法では失敗します」と発言した経験があります。     ## インシデントの終了宣言。困難な終了の定義。 ### 「終了」を定義する３つのポイント セキュリティインシデント対応において、最も大きな問題の1つがインシデント終了の定義です。 よく聞かれるのが、「安全宣言を出したい」というリクエストです。 何を持って安全と定義するのか、誰に向かって宣言するのか、漠然としていることがほとんどです。 これに対して弊社では、3つの終了という考え方を提示します。   - 技術的な終了 - 組織内部管理上の終了 - 対外的な終了   技術的な終了とは、フォレンジックをはじめとする技術調査の終了です。 根本原因、影響範囲などが明らかになった時点で技術的な終了とします。 これによりCSIRTの技術人員を解放し、具体的な対応策策定に集中させることができるようになります。 組織内部管理上の終了とは、被害組織内部向けの終了です。終了条件はその組織によって異なります。 具体的な対策方針および対策計画の立案を持って終了とする組織、対策計画の実施を持って終了とする組織、対策計画実施後の効果測定を持って終了とする組織など様々です。 対策計画の実施までを管理上の終了とした場合、経営状況による投資計画の変更、事業優先順位の変更などの影響を受け、計画実施自体の延期や停止等が生じる可能性があります。 このようなインシデント対応からは制御できない影響を排除し終了を定義するためにも、具体的な対策方針とその対策計画策定を持って終了とすることを推奨しています。 最後は、対外的な終了です。インシデントの影響範囲により内容が変わります。 一般への公表だけではなく、ビジネスパートナーに限定した情報開示や報告などの場合もあります。 大阪急性期・総合医療センターで発生したランサムウェア感染被害のように状況を公開するケースもあれば、筆者が対応したビジネスパートナーに対する報告書の提供までで終了するケースもあります。 このケースでは、ランサムウェア被害に遭った企業に対し、ビジネスパートナーは電子メールを含む一切のネットワークを介したやり取りを遮断しました。これにより、ビジネスが遂行できなくなった被害企業の支援のため、筆者チームは、根本原因と影響範囲の特定、再発防止策確定とビジネスパートナーへの簡潔な報告書の作成を行いました。 この場合、対外的な終了は「ビジネスパートナーとのリレーションの復旧」となります。 最後に、本稿では筆者が実際にインシデント対応を行った際に直面した数々の問題のうち、インシデント対応に対する影響が大きいものだけをいくつか取り上げました。 セキュリティインシデントは発生しないことが一番よいのですが、残念ながらどんな規模の組織においても被害が発生する可能性があります。本稿がいざインシデント対応に陥った際の参考になれば幸いです。             [完全な記事を表示](https://www.iim.co.jp/security-report/no006) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "山本 太郎" }, "dateModified" : "2024-03-14T01:58:50.085Z", "datePublished" : "2023-09-07T01:00:00Z", "headline" : "#6　セキュリティ・インシデント発生！その時に直面する課題 その②", "image" : { "@type" : "ImageObject", "height" : 1080, "url" : "https://19823358.fs1.hubspotusercontent-na1.net/hubfs/19823358/IIM/%E3%83%96%E3%83%AD%E3%82%B0/Security%20Report/%E3%82%B5%E3%83%A0%E3%83%8D%E3%82%A4%E3%83%AB/6.jpg", "width" : 1920 }, "mainEntityOfPage" : "https://www.iim.co.jp/security-report/no006", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60, "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png", "width" : 60 }, "name" : "Security Report" } } ```