＜インシデントマネジメント⑦～インシデントハンドリング～＞

さて、ようやくインシデントマネジメントシリーズの最後となります！ここまで読んで頂いた方、いらっしゃれば本当にありがとうございます('ω')

最後にご紹介するのは、インシデントハンドリングとなります。

はじめに基本的な知識として「インシデントとは？」について以下を覚えておいたください。

「インシデントとは？」

→情報セキュリティーポリシーに違反するor違反する可能性のある脅威

上記は少々教科書的ですが、重要な部分としては「情報セキュリティーポリシーに」という点で、つまりは情報セキュリティーポリシーが異なれば、インシデントも異なるということです。これは最終的には組織ごとに「それはインシデントだ！！！」となる基準が異なることを意味していますので、ある事象（イベント）をインシデントとしてハンドリングするかどうかは組織毎の基準で決めていく必要があるということになります。そういう意味でも、情報セキュリティーポリシー策定はもちろんですが、過去のシリーズでご紹介をしてきたような平時における準備がいかに大切かということに行きつきます。

次にインシデントハンドリングの流れを見ていきましょう。用語自体は拠り所とする規定や基準などにより異なりますが、ここではNISTSP800-61に沿って、インシデントハンドリングの流れを見ていきましょう！！（現実の世界では②と③を行ったり来たりしながら、何とか④にたどり着くようなイメージでしょうか・・・涙）

①準備（予防）

→下記の「インシデントマネジメント①～インシデントマネジメントの概要を理解する～」でご紹介した中の、主に【平時のお話】と関連がある部分であり、繰り返しとなりますが「備えあれば患いなし」という事です。

②検知・分析　＝　検知・受付連絡+トリアージ

→ここでは数あるイベント（分かりにくい方はログと読み替えてOKです）から、「これはインシデントだ！！」を判断するフェーズとなります。利用される代表的なものにIOC（indicator of compromise＝代表例はIPアドレス、ハッシュ値、ドメイン情報など）があります。

③封じ込め・根絶・復旧　＝　インシデントレスポンス

→文字通りインシデントを封じ込め、根絶し、被害を受けたシステムなどを元の正常な状態にするフェーズです。その他のポイントとして、インシデントに関する情報を正しく収集し、保管する必要がある点を覚えてください。言い換えると、第三者が見たときに「うん。これだけの信頼性のある証拠があるなら、確かにインシデントだね」と思ってもらえるように、例えば感染した端末のイメージファイルやメモリダンプを正しい手順で取得し、保管するなどの作業があります。

そうです、詳しい方は「フォレンジック」ということにお気づきになるかと思います(^^)/

④事件後の対応　＝　報告・情報公開

→一言で行きます！「インシデントハンドリングの振り返りをちゃんとやろう！」というフェーズです。これをやることで、今後の対策やまたインシデントハンドリングをするはめになる時のレベルを向上することを目指します。

さて、シリーズ最終回のインシデントハンドリングでしたが、如何でしたでしょうか。

個人的には色々と思うことはありますが、あえて意見を言わせて頂くとするとシリーズの中でもっとも重要なのは②脆弱性分析、③事象分析かな～と思っています。

＜インシデントマネジメント②～脆弱性対応～＞ - CyberSEALs’s diary

＜インシデントマネジメント③～事象分析～＞ - CyberSEALs’s diary

やはりセキュリティ業界では攻撃者の方が数歩以上1も上手であり、守る側は後手後手の状態であることは事実です。そう意味でも、インシデントハンドリングをするレベルを上げるよりも、平時からしっかりとした準備をすることでインシデントハンドリングをせずに済むようにセキュリティ対策を頑張って行きましょう！という意味も込めて上記をあげさせて頂ければと思います(^^♪

改めて最後までありがとうございました！今後もよろしくお願い致します✌