インシデントレスポンス第3版まとめ
避けられないインシデントへの備え
インシデントとは
イベントとの違い
イベントとは、「システム または ネットワーク における 識別 可能 な 事象」
インシデントとは、「コンピューター の セキュリティ ポリシー、 適正 利用 規約、標準的 な セキュリティ 慣習 に対する 違反 もしくは 違反 の 脅威」 （NIST SP800-61）
インシデントの例
http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf
https://msdn.microsoft.com/en-us/library/ms682586.aspx
攻撃のライフサイクル
- 初期侵入
- 足掛かりの構築
- 権限昇格
- 内部偵察
- 任務の完遂
参考）サイバーキルチェーン
- 偵察（RECONNAISSANCE)
- 武器化（WEAPONIZATION）
- 配送（DELIVERY）
- 攻撃（EXPLOITATION）
- インストール（INSTALLATION）
- 遠隔操作（C&C Command&Control)
- 目的の実行（ACTION ON OBJECTIVES)
参考2）MITRE ATT&CK
- 偵察（Reconnaissance)
- リリース開発（Resource Development）
- 初期アクセス（Initial Access）
- 実行（Execution）
- 永続化（Persistence）
- 権限昇格（Privilege Escalation）
- 防衛回避（Defense Evasion）
- 認証情報アクセス（Credential Access）
- 探索（Discovery）
- 水平展開（Lateral Movement）
- 収集（Collection）
- C&C（Command and Control）
- 持ち出し（Exfitration）
- 影響（Impact）
インシデント対応ライフサイクル
- 準備
- 検査と分析
- 封じ込め、根絶、復旧
- 事件後の対応
IRチームの人材について
必要な資質
- 技術的な調査の経験
- コンピュータフォレンジック調査の経験
- ネットワークトラフィック解析の経験
- 組織に関連のある産業用アプリケーションの知識
- エンタープライズITの知識
- 悪意のあるコードの解析に関する知識
必要な特性
- 高い分析能力
- コミュニケーションスキル
- 細部への目配り
- 問題解決への体系的で計画的なアプローチ
- 問題解決を明示できる実績
インシデント対応の手順
- 初動対応
- 調査
- 修復
初動対応
チームが適切な対応を判断できるだけの初期情報を集める
- 対応チームの編成
- ネットワークベースのデータとすぐに入手できるその他のデータの検討
- インシデントの種類の見極め
- 潜在的な影響の判断
調査
何が起こったのか、どういう経緯で起こったのか、また場合によっては誰に責任があるか
価値ある手がかり
- 関連性がある
- 詳細である（5W1H）
- 利用可能である
侵害のインジケータ（IOC：Indicator of Compromise)とは
- インシデントの特性とアーティファクト(※）を体系的に文書化する手順のこと
※攻撃者がマルウェアやツールを実行することによって残された痕跡や遺物。 - サイバー攻撃の痕跡をデータベース化して技術仕様として活用することで、攻撃を受けていることを素早く察知し、その影響範囲の最小化を目指すのがIoCの基本的な考え方
IOCの配備
全社を通じてIOCを検索し、自動的それについて報告出来るようにする
疑わしいシステムの特定
指定されたルールやIOCと一致したものをIOCツールが見つけた（ヒット）ときに それが本当に疑わしいか検証し、分類する
証拠保全
ライブレスポンス
- インシデント対応で行われる最も一般的な証拠収集の手順
- 自動化されたツールを使って稼働中のシステムの標準的なデータセットを集める
メモリー収集
- 攻撃者がルートキットのように自分たちの活動を隠す仕組みを利用している疑いがあり、ディスクイメージが得られない場合に有効
- 悪意のある活動がメモリ上でのみ発生しているケースなどにも有効
フォレンジックディスクイメージ
- システムのハードディスクの完全な複製
データ解析
保全した証拠を利用し調査上の疑問に答えることに的を絞って吟味する手順
主に3つの領域がある。
修復
態勢整備
- 修復を確実に成功させるための段階を踏む手順こと
戦術（短期的）
- 今起こっているインシデントへの対処として適切と判断される行動をとること
戦略（長期的）
- 通常は長時間かかり、組織内の大きな変更が必要かもしれない改善に取り組むこと
重要な調査情報を追跡する
- 集めた証拠のリスト
- 影響を受けたシステムのリスト
- 疑わしいファイルのリスト
- アクセスまたは窃取されたデータのリスト
- 攻撃者による重大な活動のリスト
- ネットワークベースIOCのリスト
- ホストベースIOCのリスト
- 侵害を受けたアカウントのリスト
- チームで進行中のタスクと要請されているタスクのリスト
インシデント発生前の備え
インシデント対応に向けた組織の準備
リスクの特定
企業が抱えるリスクの全体像をとらえる。
極めて重要な資産は何か。その資産の弱点、脅威は何か。
- 企業の評判
- ビジネス上の機密情報
個人を特定できる情報
決済口座データ
インシデント対応の成功を促すポリシー
- 利用規定
- セキュリティポリシー
- リモートアクセスポリシー
- インターネット利用ポリシー
アウトソースされたITへの対応
重要ないたく内容への対応に関するサービス品質保証契約（SLA)や、契約範囲外の作業を行うオプションなどについて取り決めておく。
グローバルなインフラの問題
国境をまたぐインシデントの調査を適切にこなすのは困難 - プライバシーと就業規則 - チームの調整 - データへのアクセス性
ホストベースのセキュリティに関するユーザ教育
企業セキュリティとインシデント対応の両方の観点から、ユーザはシステム上で取るべき行為と、取ってはいけない行為を知っておく必要がある。
インシデント対応チームの準備
任務の明確化
- 計画的かつ組織的な調査手順を使って、あらゆるセキュリティインシデントとインシデント疑惑に対応する
- 完全に厳正な調査を行う
- 侵入やセキュリティインシデントが実際に発生していることを直ちに確定するか、その疑いを取り除く
- インシデントの範囲と被害を査定する
- インシデントを制圧し、封じ込める
- インシデントに関わるすべての証拠を収集し、文書化する
- 必要に応じて追加の支援を要請する
- 法律と企業ポリシーの両方、またはどちらかで定められているプライバシーの権利を守る
- 適切な捜査当局と監督機関に連絡を取る
- インシデントに関して適切な守秘義務を守り、組織が不要にさらされないようにする
- 専門家証言を行う。
- 経営陣に対して事実に十分裏付けられた提言を行う。
コミュニケーション手順
内部のコミュニケーション
- メールは暗号化する
- すべての文書および通信を適切に分類する
- 電話会議の参加状況をモニターする
- 調査への言及にはケース番号やプロジェクト名を使う
外部関係者とのコミュニケーション
- インシデントが報告の閾値に達するのはいつか
- 通知は第三者にどのように伝わるのか。契約に機密保持の文言はあるか
- 開示後にどのような違約金や罰金が科されるか。通知のタイミングがこの要素に影響するか
- 開示後に予想される調査上の制約は何か
- 開示は修復にどう影響するか
成果物
ケースステータスレポート
- 個々のケースの進捗状況について利害関係者に最新情報を提供
- 頻度：毎日、または要求に応じて
ライブレスポンスレポート
- 1つのシステムに対する最初のライブレスポンストリアージの結果を文書化する
- 草案：1営業日以内、最終稿：2営業日以内
フォレンジック調査レポート
- 証拠となる1項目に対して行ったフォレンジック解析の詳細結果を文書化する
- 草案：4営業日以内、最終稿：6営業日以内
マルウェア解析レポート
- 悪意の疑われるソフトウェアの解析結果を文書化する
- 草案：3営業日以内、最終稿：5営業日以内
侵入調査レポート
- 1つのインシデントについてすべてのインシデントと発見をまとめ、が要的なエグゼクティブサマリーを作成する
- 草案：調査完了から5営業日以内、最終稿：調査完了から8営業日以内
インシデント対応チームのリソース
インシデント対応チームのトレーニング
- カーネギーメロン大学（http://www.sei.cmu.edu）
- パデュー大学工学部（https://polytechnic.purdue.edu)
- ジョンズ・ホプキンス大学（http://isi.jhu.edu)
- SANS研究所（http://www.sans.org）
インシデント対応チームに装備するハードウェア
インシデント対応チームのためのソフトウェア
- OS
- ブートディスク
- ディスクイメージングツール
- メモリーキャプチャーおよび解析
- ライブレスポンスキャプチャーおよび解析
- IOCの作成および検索ユーティリティ
- フォレンジック調査スイート
- ログ解析ツール
文書
- 証拠の取り扱い
- 内部ナレッジレポジトリ
インシデント対応に向けたインフラの準備
コンピュータ機器構成
- 資産管理
- 調査の実施
- インストゥルメンテーション （ログ、通信、エンドポイントの活動を監視・記録するための手段やツールのこと）
- セキュリティ向上のための追加装置
ネットワーク構成
- ネットワークのセグメント化とアクセス制御
- 文書化
- インストゥルメンテーション
- ネットワークサービス
インシデントの検知と特性評価
最初の事実集め
5つのチェックリスト
インシデントサマリー
インシデントの基本的な要点を集める際に使用する
- インシデントが報告された日付と時刻
- インシデントが検知された日付と時刻
- この情報を文書化する人物の連絡先
- インシデント対応者の連絡先
- インシデントを検知した人物の連絡先
- インシデントの性質。検知されたものを分類する
- 影響を受けたリソースの種類
- インシデント検知の経緯
- インシデントの影響を受けたコンピュータの一意の識別情報と位置情報
- 検知以降にシステムにアクセスしたのは誰か
- インシデントに気付いているのは誰か
- 現在、インシデントが進行中かどうか
- インシデントについて知るのは原則「必要最低限の人のみ」にする必要があるか
インシデント検知の経緯
- 検知は自動プロセスによるものか、手動プロセスによるものか。
- 最初の検知にはどんな情報が含まれていたか。
- 検知に役立ったデータはどのソースから提供されたものか。
- ソースデータを入手し、正確であることを確認したものはいるか。
- 関連するソースデータは保存されているか。
- 検知ソースはどれくらい前から稼働し、誰が実行しているか。
- 検知率とエラー率はいくつか。
- データソースに関して何か変更はあったか。
個々のシステムの詳細
- 物理的な場所
- 資産タグ番号
- システムのメーカーと型式
- インストールされているOS
- システムの主要な機能
- 担当のシステム管理者またはユーザー
- 割り当てられたIPアドレス
- システムのホスト名とドメイン
- システムに保存された重要情報
- システムのバックアップが存在するかどうか
- システムがまだネットワークに接続されているかどうか
- 調査の時点からログデータの最初まで遡って検知されたマルウェアのリスト
- すでに講じた修復措置のリスト
- 保存されたデータがある場合に、どんなプロセスが使われているか、どこに格納されているか
ネットワークの詳細
- 外部の悪意あるIPアドレスや関連するドメイン名すべてのリスト
- ネットワーク監視が行われているかどうか
- すでに講じた修復措置のリスト
- 保存されたデータがある場合に、どんなプロセスが使われているか、どこに格納されているか
- ネットワーク図と設定の更新
マルウェアの詳細
- 検知の日付と時刻
- マルウェアが検知された経緯
- マルウェアが見つかったシステムのリスト
- 悪意のあるファイルの名前と、ファイルが存在していたディレクトリ
- 検知メカニズムが何を見つけたか
- IR中にマルウェアがアクティブか、アクティブなネットワーク接続があるか
- マルウェアのコピーが手動か検疫プロセスで保存されているか
- 解析されている場合の状況
- マルウェアが自動プロセスか従業員の直接処理によって第三者に提出されたかどうか
ケース記録の管理
攻撃のタイムラインを作成する（調査員が何をしたかの記録）
記入日、イベント時刻、ホスト、イベントの説明を記録
手がかりの初期展開
価値のある手がかり
- インシデントと関連性がなければならない
- 意思決定可能でなければならない
- 十分に詳細でなければならない
手がかりに基づいて動く
手がかりをインディケータにする
インディケータ作成のライフサイクル
インシデントの範囲を特定する
何をすべきか
- 初期データを調べる
- 暫定的証拠を集めてレビューする
- 活動方針を決める
データ収集
ライブデータ収集
ライブレスポンスがふさわしいか判断するときのポイント
- 揮発性データの中に、調査に欠かせず他には存在しない情報が含まれると考える根拠はあるか
- ライブレスポンスは、対象システムへの変更を最小限に抑えられる理想的な方法で実行できるか
- 影響を受けたシステムの数が多いため、すべてに対してフォレンジックコピーを実行するのは不可能か
- フォレンジックコピーの作成にかなりの時間がかかったり、失敗したりするリスクはあるか
- 出来るだけデータを保全するのが得策となる法的もしくはその他の考慮すべき事柄があるか
ライブレスポンスのリスクが大きすぎるかどうかを判断するポイント
- ライブレスポンスのプロセスを同じようなシステムで試したことがあるか
- そのシステムはパフォーマンス上の問題の影響を特に受けやすいか
- システムがクラッシュした場合、どんな影響が出るか
- 出資者全員と連絡を取り、承認を得ているか。場合によっては、書面で承認を得るのが妥当かもしれない
ライブレスポンスツールの選択時のポイント
- フォレンジックの世界で一般に受け入れられているツールか
- 自分たちの環境でよく使われているOSに対応しているか
- 自分たちの環境に基づき、持っておくべき重要データを収集してくれるか
- データ収集にどれぐらい時間がかかるか
- データ収集の設定は変更可能か
- 出力データはレビューや理解が用意か
何を収集するか
- タイムゾーンも含めたシステム時刻および日付。
- OSのバージョン情報。
- メモリー容量やハードディスク、マウントされているファイルシステムなどの一般的なシステム情報。
- Webサービスやデータベース、マルチメディアアプリケーション、電子メールプログラムなど、起動時に自動的にスタートするように設定されているサービスとプログラムの一覧。
- 所定の時刻に、または一定の間隔で自動的に実行するようにスケジュールされているタスクの一覧。
- ローカルユーザーアカウントとグループメンバーシップの一覧。
- IPアドレスやMACアドレスを含むネットワークインターフェースの詳細。
- ルーティングテーブル、ARPテーブル、DNSキャッシュ。
- 関連するプロセスも含めたネットワーク接続情報。
- 現在ロードされているドライバーまたはモジュール。
- ファイルハンドルおよびその他のオープンハンドル。
- 親プロセスID（PID）やランタイムなどの詳細を含む実行中のプロセス。
- システム設定データ。
- ユーザーログイン履歴。ユーザー名、接続元、接続時間を含む。
- 標準的なシステムログデータ。
- インストールされているソフトウェアの一覧。
- 適切なアプリケーションログデータ（Webブラウザー履歴、アンチウイルスソフトのログなど）。
- 適切なタイムスタンプを含むファイルシステムの詳細な一覧。
Windowsシステムでのライブデータ収集
- Mandiant Redline
- Mandiant Memoryze
- FTK Imager Lite
UNIXシステムでのライブデータ収集
フォレンジックコピー
ネットワーク上の証拠
ネットワーク監視の意義
- 疑惑のコンピューターセキュリティインシデントについて、証拠をつかんだり疑いを払拭したりする。
- 追加の証拠と指標を集める。
- セキュリティ侵害の範囲を確かめる。
- さらなる関係者を割り出す。
- ネットワーク上で発生しているイベントのタイムラインを作成する。
ネットワーク監視の種類
- イベントベースのアラート監視
- ヘッダキャプチャー
- 全パケットロギング
- 統計データ
エンタープライズサービス
DHCP
Windows DHCP
- %windir%\System32\Dhcp にログがある
ISC DHCP
- UNIX系サーバで使用
- rsyslogなどで出力先ファイルを指定
DNS
Bind
Microsoft DNS
ネットワークレベルのDNSロギング
- DNSCAP
Webサーバ
データベースサーバ
- 書籍「SQL Server Forensic Analysis」
データ解析
解析の方法論
- 目的を定義して理解する。
- 関連のあるデータを取得する。
- データの内容を調査する。
- 必要な変換や標準化を実施する。
- 解析手法を選択する。
- 解析を実行する。
- 結果を評価する。
目的を定義する
調査の目的は通常質問の形で定義される。それぞれの質問をレビューし 現実的な質問かどうか評価する。
データの格納場所
収集できる情報
- オペレーションシステム
- アプリケーション
- ユーザデータ
- ネットワークサービスと装置
解析手法の概略
次の2種類の証拠を探すところから調査を始める
- ネットワーク異常
- 一般的なデータの窃取に関するホスト上のアーティファクト
この種類の証拠がどのデータソースに含まれているかを考える
ネットワーク異常なら
ホスト上のアーティファクトなら
- 異常なユーザーアクティビティ
- 時間外のログインアクティビティ
- 異様な接続時間
- 予想外の接続ソース（ワークステーションからサーバーへのリモートセッションなど）
- CPU使用率またはディスク使用率が異常に高い期間（データ圧縮時に多い）
- 一般的な圧縮ツールの使用に伴うファイルアーティファクト
- 最近インストールまたは更新されたサービス、あるいはその他の永続的なメカニズムの存在
3.具体的なタスクの内容を書き出し何をすべきか決定する
解析手法の選択
- 外部リソースの選択
- 手動の調査
- 専用ツールの使用
- ソートとフィルタリングによるデータ量の最小化
- 統計的解析
- キーワード検索
- ファイルとレコードの抽出
結果を評価する
- 解析プロセスのいたるところで定期的に結果を評価する
- プロセス完了後に、得られた結果が調査上の疑問にどの程度まで答えているかを評価する
Windowsシステムの調査
MacOS Xシステムの調査
- HFS + ファイルシステム
- OSのコアデータ
- Spotlightのデータ
- システムのアプリケーションのログ
- アプリケーションとシステムの設定
アプリケーションの調査
アプリケーションデータの格納先
Windows
- インストールディレクトリ C:\Program Files / C:\Program Files（x86）
- アプリケーションデータ C:\Users{Username}\AppData
- レジストリのアンインストール情報 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall ←64ビット版の場合はこれも確認
- レジストリデータのデフォルトの場所 HKLM\SOFTWARE 以下のサブキーすべて HKLM\SOFTWARE\Wow6432Node ←64ビット版の場合はこれも確認
MacOS
- インストールディレクトリ /Applications
- アプリケーションデータ /Users{profile}/Library/Application Support
Linux
手作業でファイルシステムを調べる
- 設定ファイル /etc /usr/local/etc
- ユーザアプリケーションデータ /home/{username}
- 実行ファイル /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin
- アドオンソフトウェア /opt
パッケージマネージャに対してクエリを実行する
- RPM
- dpkg
一般的な調査方法
- 環境を設定する
- アプリケーションを入手する
- インストゥルメンテーションを設定する Windows： Process Monitor、Linux：straceなど
- インストールを実行する
- アプリケーションを実行する
- インストゥルメンテーションデータを確認する
- インストゥルメンテーションを調整し、必要に応じてテストを再実行
Webブラウザーの調査方法
- 履歴
- キャッシュ
- Cookier
マルウェアのトリアージ
マルウェアの取り扱い
- トリアージ用の仮想環境を使用する
- 設定とプロセスを変更する
文書化
悪意のあるサイトへのアクセス
マルウェアがアクセスしようとしているサイトをチェック「逆ハッキング」してはいけない理由
- コンピューターが感染し、いろいろな不具合が生じる。
- 攻撃者に気付かれてしまう。
- 自分たちを標的としてさらすことになりかねない。
- 「悪意がある」と思ったサイトも被害者かもしれない。
- 善良なユーザーの行動を邪魔する可能性がある。
- 法律に触れる恐れがある。
仮想環境の設定
- 最新バージョンと旧バージョンのOSをサポートしていること。
- 複数のアーキテクチャー（例えば、x86とARM）をサポートしていること。
- 変更を簡単に元に戻せるように、スナップショットの概念をサポートしていること。
- 仮想マシンが感染しても、仮想環境の外のシステムには被害が及ばないように、 隔離されたネットワークのような保護メカニズムが利用できること。
- 便利機能（例えばホスト端末とゲスト環境の間で容易にファイルを転送できるなど）があること。 このような機能は、マシンが正常な状態にあるときにのみ使用すること。
静的解析
- 情報の検索
- ファイルヘッダー（fileコマンド）
- 文字列（stringsコマンド）
- エンコードされたファイル
- パック（圧縮やコードの難読化）されたファイル
動的解析
レポートの作成
レポートの作成基準
- 焦点を明確にすること
- 理解できること
- 事実に徹する
- タイミング
- 再現性
レポートの文体と形式
- 能動体で書く
- 過去形で書く
- 簡潔な文を使用する
- 具体的に書く
- 実施したことを述べ、できなかったことは述べない
- つなぎのための文章を使う
- 略語は正しく使用する
- 業界用語や曖昧な言葉を使用しない
- 一貫した名称を使用する
- 話し言葉は使用しない
- 意見は明確に示す
- 一貫したフォントと行間を使用する
- 日付と時刻の表示形式を決めて遵守する
- メタデータ報告の標準化
- 図や表にキャプションと相互参照を使用する
- 図や表を適切に使用する
- 必要に応じて箇条書きや番号付きリストを使用する
レポートの内容と構成
- タイトルページと目次
- 背景情報
- 調査結果
- 推奨事項
- 中間レベルのセクション
- 個々の解析レポート
- 付録
修復
修復のフローチャート
修復のケーススタディ
修復の実行方法に絶対という方法はない。
状況はそのつど違い、克服しなければならない課題もそのつど変わるものです。
修復計画は時間とともに進化させる必要があり、変更できないものとは考えない。
インシデントの多くは、攻撃者が活動中であるため、被害の状況や既知の情報は日々変化する可能性があります。
そのため修復チームには、変化する状況や情報に対処できる能力が必要です。
修復作業の成否は修復チームの肩にかかっている。
つまり、修復チームはすべてのアクションがタイミングよく成し遂げられ、適切に実行されることに責任を負わなければならないということです。
