コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)の概要

コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)を読んでみました。ガイドラインの概要をまとめます。

コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)
https://www.ipa.go.jp/files/000025341.pdf

概要

このガイドラインは、組織がセキュリティインシデント対応機能を確立し、インシデントへの対応をを効率的に進められることを目的としたものです。
セキュリティインシデント対応として、大きく以下の項目について解説されています。

• コンピュータセキュリティインシデント対応能力の組織化
• 事件処理(初期の準備フェーズから、事件後に教訓を生かすフェーズまで)

インシデント対応ライフサイクル

インシデント対応フローのステップごとの内容

項目	概要
準備
事件処理に備える	インシデントに対応する際に必要なツールやリソースが解説されています。 インシデント発生時に連絡するための連絡先のリストであったり、インシデント発生時に現地で対応するためのツール（ノートPC等）がまとめられています。
事件の予防	セキュリティコントロールとして、パッチ管理、ホストのセキュリティ（堅牢性）、ネットワークセキュリティ、悪意のコードの予防、ユーザの意識向上とトレーニングについて解説しています。
検知と分析
事件の分類	インシデントの分類として主だったものを挙げています。 （インシデントを網羅したものではない） サービス不能 悪意のコード 不正アクセス 不適切な使用 複合要素
事件の兆候	インシデントの兆候の例が示されています。 FTPサーバに対しバッファーオーバーフロー攻撃が仕掛けられたことを検知したネットワーク侵入検知センサーが、警報を発する。 ホストがワームに感染したことを検知したウイルス対策ソフトウェアが、警報を発する。 ウェブサーバがクラッシュする。 インターネット上のホストへのアクセスが遅いという、ユーザからの苦情を受ける。 システム管理者が、異常な文字が使われたファイル名を発見する。 ユーザがヘルプデスクを呼び出し、脅迫的な電子メールメッセージがあったことを報告する。 ホストのログに、監査設定の変更が記録される。 アプリケーションが、見慣れないリモートシステムからの、複数回のログインの試みの失敗をログに記録する。 電子メール管理者が、怪しい内容の大量のバウンスメールを見つける。 ネットワーク管理者が、典型的なトラフィックフローからの異常な逸脱に気づく。 ウェブサーバが、ウェブ脆弱性スキャナの使用を示すエントリーをログに記録する。 組織のメールサーバの脆弱性をターゲットにした、新しいエクスプロイトの告知。 政治的ハッカーグループが、組織を攻撃するという声明を出して脅迫する。
前兆と兆候のソース	インシデントの兆候を表す情報のソースとして、以下のものがあげられます。 コンピュータセキュリティソフトウェアの警報 ログ 公に入手できる情報 人
事件の分析	インシデントの兆候から、実際に問題があるか分析します。 ここでは分析の推奨事項がまとめられています。 ネットワークとシステムのプロファイル 正常動作の理解 一元化されたログ取得とログ保管ポリシーの作成 イベント相関処理の実施 すべてのホストの時刻を同期させておく 情報の知識ベースの維持と利用 インターネットのサーチエンジンを使った調査 パケットスニッファを使った補足データの収集 データのフィルタリングの検討 経験を最優先する 経験が少ないスタッフのための診断マトリックスの作成 他からの支援を求める
事件の文書化	インシデントの記録に関しての指針が示されています。 記録には、以下のものを記載する。 事件の現在の状態 事件の概要 この事件に対して、事件処理担当者がとった行動の内容 ほかの関連者(システム所有者、システム管理者など)の連絡先情報 事件調査の際収集した証拠の一覧 事件処理担当者からのコメント 次にとるべきステップ(たとえば、システム管理者によるアプリケーションへのパッチの適用を待つなど)
事件の優先順位付け	インシデント対応の優先順位付けは、「事件による、現在および将来起こりうる技術的な影響」及び「影響を受けたリソースの重要度」により判断することを示している。
事件の通知	インシデントを分析して優先順位した後、インシデント対応チームは組織内の適切な人間や、場合によっては他の組織に通知する必要がある。 一般に以下の関係者への通知が必要である。 CIO 情報セキュリティ部門長 各地区の情報セキュリティ担当 組織内のほかのインシデント対応チーム システムオーナー 人事部門(電子メールによる嫌がらせなど、職員が関係する場合) 広報部(公共性がある事件の場合) 法務部(法的問題が想定される事件の場合) US-CERT (連邦政府機関または連邦政府機関の業務を代行するシステムは、報告が義務付けられている)
封じ込め、根絶、復旧
封じ込め戦略の選択	封じ込めの戦略の基準を明確に文書化しておくことが示されています。 適切な戦略を決定するための基準として、以下のものが挙げられています。 リソースに対する潜在的な損害およびリソースの盗難の可能性 証拠保全の必要性 サービスの可用性(ネットワーク接続、外部関係者へのサービス提供) 戦略を実施するのに必要な時間とリソース 戦略の有効性(事件の部分的な封じ込めや、完全な封じ込めなど) 対策の期間(たとえば、4時間以内に中止する緊急回避策、2週間以内に中止する一時回避策、恒久策など)
証拠の収集と処理	証拠保全に関する指針がまとめられている。 識別情報(たとえば場所、シリアル番号、型番号、ホスト名、MAC (Media Access Control)アドレス、コンピュータのIPアドレスなど) 調査中に証拠を収集・処理した者の名前、役職、電話番号 証拠処理の日付と時刻(タイムゾーンを含む) 証拠の保管場所
アタッカーの特定	インシデント対応チームは、あくまで封じ込め、根絶、復旧に重点を置くべきである、アタッカーの特定は時間がかかる割には効果がないプロセスであるとしながらも、 アタッカーを特定するために最も一般的に行われる活動について説明されています。 アタッカーのIPアドレスの確認 アタッカーのシステムをスキャン←個人的には疑問視 サーチエンジンを使ったアタッカーの調査 事件データベースの利用 可能性のあるアタッカーの通信チャネルの監視
根絶と復旧	インシデントの事後対応が行われることを示している。 詳細な内容は対象外としている。
事件後の対応
教訓	インシデントの振り返りについて記載されている。
収集された事件データの利用	インシデント対応の履歴を蓄積し分析することで改善を促すことを示している
証拠の保管	証拠保管のポリシー確立について記載されている。