> For the complete documentation index, see [llms.txt](https://snowyowls-organization.gitbook.io/snowyowl644-hacklog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://snowyowls-organization.gitbook.io/snowyowl644-hacklog/hack-the-box-academy/soc-analysit/incident-handling-process.md). # Incident Handling Process コースURL : ## インシデントハンドリング 用語 * イベント * システムまたはネットワーク内で発生するアクション * イベントの例 * メールを送信するユーザー * マウスクリック * 接続要求を許可するファイアウォール * インシデント * 悪影響を伴う出来事のこと * インシデントの例 * システムのクラッシュ * 機密データへの不正アクセス * マルウェアおよびリモートアクセスツールのインストールと使用 * インシデント処理は侵入インシデントだけに限定されないことに注意することが重要 * 悪意のある内部関係者によるインシデント、可用性の問題、知的財産の損失など、その他の種類のインシデントもインシデント対応の範囲に含まれる * 包括的なインシデント対応計画 * 様々な種類のインシデントに対応 * インシデントを特定、封じ込め、根絶、そして復旧するための適切な対策を講じること * 可能な限り迅速かつ効率的に通常の業務運営を再開できるようにする必要がある インシデント対応 * インシデントマネージャー * 必要に応じて情報を入手し、組織内の従業員に適切なタイミングで活動を実施するよう指示する権限を有していなければいけない * インシデントマネージャーは、調査中に実施された活動とその完了状況を追跡する唯一の連絡窓口になる * インシデント対応チームは、インシデントマネージャーが率いる * この役割は、SOCマネージャー、CISO/CIO、またはサードパーティ（信頼できる）ベンダーに割り当てられることが多い * 通常、他の事業部門を指揮することも可能 * インシデント対応に関する資料 * NISTの「コンピュータセキュリティインシデント対応ガイド」 * ) * 中小企業のためのセキュリティインシデント対応の手引き * ## Cyber Kill Chain * Cyber Kill Chain : 攻撃ライフサイクルともいう * 攻撃がどのように顕在化するかを説明している * 以下の7つの段階で進む ![サイバー キル チェーンのステップのフローチャート: 偵察、武器化、配信、悪用、インストール、C\&C、アクション。](https://academy.hackthebox.com/storage/modules/148/Cyber_kill_chain.png) recon * 攻撃者が標的を選定する段階 * 攻撃者は標的をより深く理解するために情報収集を行う * LinkedInやInstagramなどのWebソースからのOSINTだけでなく、標的組織のWebページ上のドキュメントからも受動的な情報収集を行うことを好む人もいる * 求人広告や企業パートナーは、標的組織で使用されている技術に関する情報を開示することが多いため、それらの情報からもわかることがある * ウイルス対策ツール、オペレーティングシステム、ネットワーク技術など weaponize * 初期アクセスに使用されるマルウェアが開発され、何らかのエクスプロイトや配信可能なペイロードに埋め込まれる * マルウェアは極めて軽量で、アンチウイルスや検出ツールでは検出されないよう巧妙に細工されている * 大規模な攻撃では、この初期段階の唯一の目的は、標的環境内の侵害されたマシンへのリモートアクセスを提供すること * マシンの再起動後も継続し、必要に応じて追加のツールや機能を展開する機能も備えている delivery * エクスプロイトまたはペイロードが被害者に配信される * 従来の手法 * 悪意のある添付ファイルのメール * Webページへのリンクを含むフィッシングメール * エクスプロイトを含んでいるweb * メールスキャンツールを経由しないように悪意のあるペイロードをホスト * フィッシングで認証情報を取得しようとするか * ソーシャルエンジニアリングで、ペイロードを実行させようとするか exploitation * エクスプロイトまたは配信されたペイロードがトリガーされる瞬間 * サイバーキルチェーンのエクスプロイト段階では、攻撃者は通常、アクセスまたは制御を取得するために、標的のシステム上でコードを実行しようとする install * 初期ステージャーが実行され、侵入先のマシン上で実行される * インストール段階でよく使用される手法 * ドロッパー・ダウンローダー * マルウェアをインストールして実行するように設計された小さなコード * メールの添付ファイル、悪意のあるウェブサイト、ソーシャルエンジニアリングの手法など、様々な手段で配信される可能性がある * バックドア * 攻撃者が侵入先のシステムへの継続的なアクセスを可能にするために設計されたマルウェア * 攻撃者がエクスプロイトの段階でインストールするか、ドロッパーを介して配信される可能性がある * バックドアはさらなる攻撃を実行したり、侵入先のシステムからデータを盗み出したりするために利用される * ルートキット * 侵入したシステム上で存在を隠すように設計されたマルウェアの一種 * 他のマルウェアの動きを隠すためのマルウェア C\&C * **侵害したマシンへのリモートアクセス機能を確立する** * 追加のスクリプトを「on the fly(その場で即座に動的に)」で読み込むモジュール式の初期ステージャーを使用することは珍しくない * しかし、高度な攻撃グループは、複数のマルウェア亜種が侵害されたネットワーク内に潜伏するように、別々のツールを活用する * そして、たとえマルウェアの1つが発見され封じ込められたとしても、元の環境に戻る手段を確保する Action * 攻撃の目的の実行 * 機密データの取得 * ネットワーク内で可能な限り最高レベルのアクセス権を取得してランサムウェアを展開 防御側としては、攻撃者のサイバーキルチェーンを切るのが大事 ## Incident Handling Process ### Overview * NISTによると、インシデント処理プロセスは以下の4つの段階で行われる ![インシデント対応プロセスのフローチャート: 準備、検出と分析、封じ込め、根絶と回復、インシデント後の活動。](https://academy.hackthebox.com/storage/modules/148/handling_process.png) * インシデント ハンドラーは、最初の 2 つの段階にほとんどの時間を費やしている * 画像でわかるように、プロセスは線形ではなく循環的 * ここで、新しい証拠が発見されると、次のステップも変わる可能性があるということを覚えておく必要がある * プロセスのステップを省略せず、次のステップに進む前に 1 つのステップを完了することが重要 * 例 : 感染したマシンが 10 台見つかった場合、残りの 5 台を感染状態のままにして、そのうちの 5 台だけを封じ込めて駆除を開始するようなことは絶対に避けるべき * インシデント対応には大きく分けて **調査**と**復旧**の2 つの活動がある * 調査の目的の例 * 最初の被害者を発見し、（まだ活動中の場合は継続中の）インシデントタイムラインを作成する * 攻撃者が使用したツールやマルウェアを特定する * 侵害されたシステムと攻撃者が行った行為を文書化する * インシデントが完全に処理されると、インシデントの原因とコストの詳細を記載した報告書が発行される * 同様のインシデントの再発を防ぐために組織が何をすべきかを理解するために、「教訓」の収集活動などが実施される ### Preparation 準備 * 普段ハンドラーは、技術を向上させ、次の悪意のあるイベントを探すことに多くの時間を費やしている * 悪意のあるイベントが検出されると、次の段階に進み、イベントに対応する * しかし、いつでも準備と検知ができるようにリソースを動かし続ける必要はある #### 前提条件 必要なもの * 熟練したインシデント処理チームのメンバー * インシデント処理チームのメンバーは外部委託できますが、社内にインシデント処理に関する基本的な能力と理解が必要 * 訓練を受けた労働力 * セキュリティ意識向上活動やその他のトレーニング手段を通じて可能な限り * 明確なポリシーと文書 * ツール * ソフトウェアとハ​​ードウェア #### インシデント対応能力の確立 **明確なポリシーとドキュメント** * 以下の情報の最新バージョンが含まれている必要がある * インシデント対応チームメンバーの連絡先情報と役割 * 連絡先情報 * 社内 : 法務・コンプライアンス部門、管理チーム、IT サポート、コミュニケーションおよびメディア関係部門 * 社外 : 法執行機関、インターネット サービス プロバイダー、施設管理、外部インシデント対応チーム * インシデント対応ポリシー、計画、手順 * インシデント情報共有ポリシーと手順 * ゴールデンイメージとクリーンな状態環境から得られるシステムとネットワークのベースライン * ゴールデンイメージ : 理想的な標準構成を持つシステムのひな型 * セキュリティ的にクリーンで、必要な設定やパッチがすべて適用された状態の OS / 仮想マシン / コンテナのこと * * これをベースに複製・展開することで、常に同じ「正しい状態」からシステムを構築できる * ネットワーク図 * 組織全体の資産管理データベース * 過剰な権限を持つユーザーアカウントは、必要に応じてチームがオンデマンドで使用できるようにしておくこと * ビジネスクリティカルなシステムにもアクセスできる * そのシステムを管理するのに必要なスキルが求められる * これらのユーザーアカウントは通常、初期調査でインシデントが確認された時点で有効化され、インシデント終了後に無効化される * ユーザーを無効化する際には、パスワードのリセットも必須 * 完全な調達プロセスを経ずに、ハードウェア、ソフトウェア、または外部リソースを入手できる能力（一定量までの緊急購入） * インシデント発生時に、500ドルのツールの承認を何週間も待つことは、最悪の事態 * 法医学/捜査チートシート インシデント対応時の連絡 * 社内 : 比較的迅速に、組織内外で大きな摩擦なく対応できるものもある * 社外 : 法執行機関への通知や、顧客やサードパーティベンダーへの外部コミュニケーションが必要となるケースもあり、特にインシデントに起因する法的懸念が生じた場合は連絡しないといけない * 例えば、顧客データに関するデータ漏洩は、GDPRに基づき、一定の期限内に法執行機関に報告する必要がある インシデントの文書化は不可欠だが、調査を進める中でインシデントを文書化することも重要 → 効果的な報告体制を確立する必要がある * インシデントが進行するにつれてこの部分を忘れてしまいがち * 冷静さを保ち、メモを取り、タイムスタンプ、実行した作業、その結果、そして誰がそれをしたかを明確に記録することが大事 * 全体として、**誰が、何を、いつ、どこで、なぜ、どのように行ったのかという問いへの答え**を書く必要がある **ツール** * 業務を遂行するために以下のような適切なツール（ソフトウェアとハ​​ードウェア）を確保することも重要 * これらに限定されるものではない * インシデント対応チームメンバーそれぞれに、ディスクイメージとログファイルの保存、データ分析、そして制限のない調査を行うための追加のノートパソコンまたはフォレンジックワークステーションを用意する * マルウェアのテストが行​​われるため、ウイルス対策ツールなどのツールは無効化する必要がある * これらのデバイスは適切に管理し、組織にリスクをもたらすような方法では使用しないでください。 * デジタルフォレンジック画像取得および分析ツール * メモリキャプチャおよび分析ツール * ライブレスポンスのキャプチャと分析 * ログ分析ツール * ネットワークキャプチャおよび分析ツール * ネットワークケーブルとスイッチ * 書き込みブロッカー * 法医学画像用ハードドライブ * 電源ケーブル * 必要に応じてハードウェアデバイスを修理または分解するためのドライバー、ピンセット、その他の関連ツール * 侵害指標（IOC）の作成者と組織全体でIOCを検索する機能 * 保管記録フォーム * 暗号化ソフトウェア * チケット追跡システム * 保管と調査のための安全な施設 * 組織のインフラストラクチャに依存しないインシデント処理システム 上記のツールの多くは、いわゆる`jump bag` : **必要なツールを常に準備しておき、すぐに取り出して出発できるようにしておく**ためのもの * この準備されたバッグがなければ、必要なツールを即座に集めるのに数日から数週間かかる可能性があり、対応準備が整うまでに数日から数週間かかる可能性がある 文書化システムを組織のインフラストラクチャから完全に独立させ、適切に保護することの重要性 * 最初から、ドメイン全体が侵害され、すべてのシステムが利用できなくなる可能性があることを想定する必要がある * **同様にインシデントに関するコミュニケーションは、組織のシステムとは別のチャネルを通じて行う必要がある** * つまり、攻撃者がすべてを制御しており、電子メールなどの通信チャネルを読める可能性があることを想定する必要がある #### 適切な保護対策の実施 * ITセキュリティインシデントを防止・防御する能力を高めること * エンドポイントとサーバーの強化、Active Directoryの階層化、多要素認証、特権アクセス管理などが含まれる ほとんどの脅威に対して大きな軽減効果を持つ、強く推奨される保護対策 **DMARC** * [DMARCは](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#what-is-dmarc)、既存の[SPF](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#what-is-spf)と[DKIM](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#what-is-dkim)をベースに構築された、フィッシング対策のメール保護技術 * 組織から送信されたように見せかけたメールを拒否することが根底の考え * 攻撃者が従業員を装って請求書の支払いを求めるメールを送信した場合、システムはメールが宛先に届く前に拒否することができる * **DMARCは導入が簡単で費用もかかりませんが、徹底的なテストが必須**であることは強調しておきたいところ * そうしないと、正当なメールがブロックされ、復元できなくなるリスクがある * メータフィルタリングルール * 所有していないドメインからのDMARCに不合格となったメールに対して追加の保護を適用できる可能性がある * 一部のメールシステムがDMARCチェックを実行し、DMARCの合格/不合格を示すヘッダーをメッセージヘッダーに含めるため可能 * あらゆるドメインからのフィッシングメールを検出する上で非常に強力だが、実稼働環境に導入する前には広範なテストが必要 * 誤検知率が高くなるのは、何らかのメール送信サービスを介して「代理送信」されたメール * ドメインの不一致によりDMARCに不合格になる傾向があるため **エンドポイントの強化** * エンドポイントデバイス（ワークステーション、ノートパソコンなど）は、私たちが日常的に直面する攻撃のほとんどが侵入する入り口 * 現在、エンドポイント強化の標準として広く認知されているものがいくつかある * 中でも**CISとMicrosoftのベースラインが最も一般的**で、組織の強化ベースラインの基盤となるべきもの * LLMNR/NetBIOSを無効にする * LAPSを実装し、一般ユーザーから管理者権限を削除する * PowerShell を「ConstrainedLanguage」モードで無効化または構成する * Microsoft Defender を使用している場合は、Attack Surface Reduction (ASR) ルールを有効にする * ホワイトリストの実装 * これはほぼ不可能なことですが、少なくともユーザーが書き込み可能なフォルダ（ダウンロード、デスクトップ、AppDataなど）からの実行をブロックすることを検討する * これらは、エクスプロイトや悪意のあるペイロードが最初に出現する場所 * .hta、.vbs、.cmd、.bat、.jsなどのスクリプトタイプもブロックする * ホワイトリストを実装する際は、 [LOLBin](https://lolbas-project.github.io/)ファイルに注意する必要がある。 * LOLBinファイルは、ホワイトリストをバイパスするための初期アクセスとして実際に使用されている * ホストベースのファイアウォールの活用 - 最低限、ワークステーション間の通信とLOLBinへの送信トラフィックをブロックする * EDR製品の導入 - 現時点では、[AMSIは](https://learn.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps)難読化されたスクリプトに対する優れた可視性を提供し、マルウェア対策製品が実行前にコンテンツを検査できるようにする - AMSIと統合された製品のみを選択することを強くお勧めする AMSIとは * Windowsに搭載された柔軟なインターフェースで、アプリケーションやサービスから**アンチマルウェア製品**を呼び出してスキャンできる仕組み * ベンダー非依存（vendor-agnostic）で任意のセキュリティ製品と連携可能 * ファイルだけでなく、メモリやストリームの内容、URL/IPのレピュテーションチェックなども対象 * Windows 10 以降では、以下のような機能にAMSIが統合されている * ユーザーアカウント制御（UAC） * PowerShell（スクリプト、インタラクティブ実行、動的評価） * Windows Script Host（wscript.exe、cscript.exe） * JavaScript / VBScript * Office VBAマクロ  **ネットワーク保護** * ネットワークセグメンテーション : 組織全体への侵害の拡大を防ぐための強力な手法 * ビジネスクリティカルなシステムは分離し、ビジネス上必要な場合にのみ接続を許可する必要がある * 内部リソースは、DMZに配置されていない限り、インターネットに直接接続されるべきではない ネットワーク保護について言えば、IDS/IPSシステムも検討すべき * これらのシステムの真価は、SSL/TLSインターセプションの実行時に発揮される * IPアドレスが攻撃者のものかだけではなく、ネットワーク上のコンテンツに基づいて悪意のあるトラフィックを識別できるため * IPアドレスのレピュテーションは、悪意のあるトラフィックを検出する従来の非効率的な方法 * 組織が承認したデバイスのみがネットワークに接続できるようにする必要がある * 802.1xなどのソリューションを活用することで、BYOD（個人所有デバイス持ち込み）や悪意のあるデバイスが企業ネットワークに接続するリスクを軽減できる * Azure/Azure ADなどを使用しているクラウドのみを利用する企業であれば、条件付きアクセスポリシーを適用することで同様の保護を実現できる * 条件付きアクセスポリシーでは、企業が管理するデバイスから接続した場合にのみ組織のリソースへのアクセスを許可する **特権ID管理 / MFA / パスワード** * 現時点では、Active Directory環境において特権ユーザーの資格情報の盗難が最も一般的なエスカレーションパスとなっている * よくあるミスとして、管理者ユーザーが弱い（しかし複雑な）パスワードを設定したり、通常のユーザーアカウントとパスワードを共有したりすることが挙げられる * これは、これはキーロギングなどの複数の攻撃ベクトルによって取得可能 * 文字が複雑だからといって、弱くないわけではない : `Password1!`みたいに * パスワードではなく、「i LIK3 my coffeE warm」のようなパスフレーズを使用させる * 第二言語を知っている人は、複数の言語の単語を組み合わせることで、保護を強化することができる **脆弱性スキャン** * 環境の脆弱性スキャンを継続的に実施し、発見された脆弱性のうち少なくとも「高」および「重大」と評価されたものについては修正する * スキャン自体は自動化できるが、修正には通常、手作業が必要 * 何らかの理由でパッチを適用できない場合は、脆弱なシステムを必ずセグメントで分ける **ユーザー意識向上トレーニング** * 定期的な「サプライズ」テストもこのトレーニングの一部に含める必要がある * 例えば毎月のフィッシングメールやオフィスビル内にUSBメモリを落としたケースなどの実施 **ペネトレーションテスト** * セキュリティ設定ミスや露出した重大な脆弱性を検出する最良の方法は、攻撃者の視点から探すこと * 自社でレビューを実施（または、組織内に適切なスキルセットがない場合は第三者に依頼）することで、エンドポイントデバイスが侵害された場合でも、攻撃者がネットワーク上で高い権限にワンステップでエスカレーションするのを阻止できる **パープルチーム演習** * インシデント対応担当者をトレーニングし、継続的に関与させる必要がある * 紛れもない事実であり、組織内の環境内で実施するのが最適 * パープルチームの演習は、基本的にレッドチームによるセキュリティ評価であり、レッドチームの行動、発見事項、可視性／セキュリティ上の欠陥などについて、継続的または最終的にブルーチームに報告する * 組織内の脆弱性を特定すると同時に、ブルーチームのログ記録、監視、検知、対応能力といった防御能力をテストするのに役立つ * 検出された脅威については、ブルーチームはプレイブックとインシデント対応手順をテストし、それらが堅牢であり、期待される結果が得られているかどうかを確認できる ### Detection & Analysis 検知と分析 脅威は無数の攻撃ベクトルを通じて組織に持ち込まれ、次のようなソースから検出される * 異常な行動に気づいた従業員 * 弊社のツール (EDR、IDS、ファイアウォール、SIEM など) からのアラート * 脅威ハンティング活動 * 組織が侵害されている兆候を発見したことを知らせる第三者からの通知 その際は、ネットワークを論理的に分類して検出レベルを作成することを強くお勧めする * ネットワーク境界での検出 (ファイアウォール、インターネットに接続されたネットワーク侵入検知/防止システム、非武装地帯などを使用) * 内部ネットワーク レベルでの検出 (ローカル ファイアウォール、ホスト侵入検知/防止システムなどを使用) * エンドポイント レベルでの検出 (ウイルス対策システム、エンドポイント検出および応答システムなどを使用) * アプリケーション レベルでの検出 (アプリケーション ログ、サービス ログなどを使用) #### 初期調査 * セキュリティインシデントが検出された場合は、チームを編成し、組織全体のインシデント対応を要請する前に、初期調査を実施し、状況を把握する必要がある * 管理者アカウントがHH:MM:SSのIPアドレスに接続した場合、情報がどのように表示されるかを考えてみる * そのIPアドレスがどのシステムで、どのタイムゾーンの時刻なのかがわからなければ、このイベントが何を意味するのか、簡単に誤った結論に至ってしまう可能性がある * まとめると、この段階では、以下の点について可能な限り多くの情報を収集することを目指すべき * インシデントが報告された日時。また、インシデントを検知した人物、報告した人物は誰ですか？ * 事件はどのようにして発見されたのでしょうか? * インシデントの内容は何ですか？フィッシング？システムが利用できなくなった？など。 * 影響を受けるシステムのリストを作成する（該当する場合） * 影響を受けたシステムに誰がアクセスし、どのような措置が講じられたかを文書化します。インシデントが継続中か、不審な活動が停止されたかをメモします。 * 物理的な場所、オペレーティングシステム、IPアドレスとホスト名、システム所有者、システムの目的、システムの現在の状態 * (マルウェアが関係している場合) IP アドレス、検出日時、マルウェアの種類、影響を受けるシステム、悪意のあるファイルのエクスポートとそれに関するフォレンジック情報 (ハッシュ、ファイルのコピーなど) のリスト * これらの情報が手元にあれば、収集した知識に基づいて意思決定を行うことができる * CEOのノートPCとインターンのボートPCが侵害されたかによって、取るべき行動は変わってくる * 最初に収集した情報を基に、インシデントタイムラインの作成を開始できる * このタイムラインは、イベント全体を通して状況を整理し、発生した事象の全体像を把握するのに役立つ * 発生時刻に基づいて証拠を並べることで、発生した個々のイベントの文脈を把握することができる * タイムラインは主に攻撃者の行動に焦点を当てる * タイムラインに書くこと #### インシデントの重大性と範囲に関する質問 インシデントの重大性と範囲を把握するために、次の質問に答えることも必要 * 悪用された場合の影響は何ですか？ * 悪用に必要な条件は何ですか？ * このインシデントによって、ビジネス上重要なシステムが影響を受ける可能性はありますか？ * 推奨される修復（対応）手順はありますか？ * どれくらいのシステムが影響を受けましたか？ * このエクスプロイトは実際の環境（野生環境）で利用されていますか？ * このエクスプロイトにはワームのように自己拡散する機能がありますか？ #### インシデントの機密性とコミュニケーション * インシデントは非常に機密性の高いトピックであるため、収集された情報はすべて、適用法または経営判断で別途指示がない限り、必要最小限の関係者のみに公開する必要がある * 理由としては * 攻撃者が社内の従業員である可能性もあり、また侵害が発生した場合には、社内外へのコミュニケーションは法務部門の指示に従い、指定された担当者が行う必要がある * 調査を開始する際には、いくつかの期待値と目標を設定する * これには多くの場合、発生したインシデントの種類、利用可能な証拠の出どころ、調査に要するおおよその時間の見積もりが含まれる * インシデントの内容に基づき、攻撃者を特定できる可能性があるかどうかについても期待値を設定する * もちろん、調査の進展や新たな手がかりの発見に伴って、これらの多くは変化する可能性がある * したがって、関係者および経営層に対し、進展状況や期待値について継続的に情報共有することが重要 #### 調査 * 何がどのようにして発生したのかを理解することを目指す * インシデントがどのように発生し、何が影響を受けたかがわからなければ、どのような修復措置を講じても、攻撃者がアクセスを奪還するために同じ行動を繰り返すことを阻止することはできない * 一方、攻撃者がどのように侵入し、どのようなツールを使用し、どのシステムが影響を受けたかを正確に把握していれば、同じ攻撃経路が再現されないよう修復計画を立てることができる 当初収集された（そして限定的な）情報に基づいて開始されて、以下の3つのサイクルプロセスで回っていく * 調査の進展に合わせて繰り返し実行される3段階のサイクルプロセス * 侵害指標（IOC）の作成と使用 * 新たなリードと影響を受けるシステムの特定 * 新しいリードと影響を受けるシステムからのデータ収集と分析 ![調査プロセスを示すフローチャート: 初期調査データは、IOC、侵害されたシステム、収集と分析につながります。](https://academy.hackthebox.com/storage/modules/148/investigation_new.png) **初期調査** * インシデント対応チームは、既知の悪意のあるツールといった特定の発見だけにとらわれず、常に新たな手がかりを提示し続ける必要がある * 調査を特定の活動に絞り込むと、発見が限定的になり、結論が早まり、全体的な影響の理解が不完全になることがよくある **IOCの作成と使用** * 侵害の痕跡（IOC : indicator of compromise）とは、インシデントが発生したことを示す兆候 * IOCは構造化された形式で文書化され、侵害の痕跡を表す * IOCの例としては、IPアドレス、ファイルのハッシュ値、ファイル名などが挙げられる * IOCのもう一つの広く使用されている標準はYara * MandiantのIOC Editorなど、IOCの作成や編集に利用できる無料ツールは数多くある * これらの言語を使用することで、インシデント調査中に発見された痕跡を記述し、活用することができる * 攻撃者や攻撃が既知の場合は、第三者からIOCを入手することもある * IOCを活用するには、IOC取得/IOC検索ツール（ネイティブまたはサードパーティ製、場合によっては大規模）を導入する必要がある * Windows環境でIOC関連の操作を行う一般的な方法は、WMIまたはPowerShellを利用すること * 調査中は、（潜在的に）侵害されたシステム（あるいは実際にはあらゆるシステム）に接続する際に、高い権限を持つユーザーの資格情報がキャッシュされないように細心の注意を払う必要がある * WinRMなど * ログオンタイプ3（ネットワークログオン）を使用したWindowsログオンでは、通常、リモートシステムに資格情報がキャッシュされない 「ツールを知る」ことの最も優れた例は「PsExec」 * 「PsExec」を明示的な資格情報とともに使用すると、その資格情報はリモートマシンにキャッシュされない * 現在ログオンしているユーザーのセッションを通じて、資格情報なしで「PsExec」を使用すると、資格情報はリモートマシンにキャッシュされない **新たなリードと影響を受けるシステムの特定** * IOCを検索した後、同様の侵害の兆候を示す他のシステムを明らかにするヒットがいくつか見つかることが予想される * これらのヒットは、調査対象のインシデントと直接関連しない可能性がある * 例えば、IOCがあまりにも一般的すぎる可能性がある * 誤検知を特定し、排除する必要がある * 大量のヒットに遭遇する可能性もある * その場合は、重点的に調査するヒットを優先順位付けする必要がある * 理想的には、フォレンジック分析によって新たな手がかりが得られる可能性のあるヒット **新しいリードと影響を受けるシステムからのデータ収集と分析** * IOCを含むシステムを特定したら、新たな手がかりを発見したり、インシデントに関する調査上の疑問に答えたりするため、それらのシステムの状態を収集・保存し、さらなる分析に活用する * システムによって、収集方法や収集するデータの種類は複数ある * 稼働中のシステムに対して「ライブレスポンス」を実行したい場合もあれば、システムをシャットダウンしてから分析を実行したい場合もある * ライブレスポンスは最も一般的なアプローチ * 通常はシステムに何が起こったかを説明する可能性のあるアーティファクトを豊富に含む、事前定義されたデータセットを収集 * 貴重な情報を保存するという点では、システムをシャットダウンすることは容易ではない * なぜなら、多くの場合、アーティファクトの多くはマシンのRAMメモリ内にのみ保存され、マシンの電源を切ると失われてしまうから * ### Containment Eradication & Recovery 封じ込め・駆除・復旧 * インシデントの拡散を防ぐための行動を取る * 行動は「短期的封じ込め」と「長期的封じ込め」に分かれる #### 短期的封じ込め * システムに残る痕跡を最小限にしながら行う対応 * 例 * システムを別のVLANに隔離する * ネットワークケーブルを抜く * 攻撃者のC2（コマンド&コントロール）用DNS名を自分たちが管理するもの、または存在しないものに書き換える * これにより被害を止め、具体的な修復戦略を検討する時間を稼ぐ * さらに、システムをできるだけ改変しないため、調査時にまだ行っていなければフォレンジックイメージを取得し証拠を保全できる * （これを「バックアップ・サブステージ」と呼ぶこともある） * なお、短期的封じ込めの中でシステムのシャットダウンが必要な場合は、必ず事業部門への連絡と承認を得る必要がある #### 長期的封じ込め * より持続的な対策や変更に焦点を当てます。 * 例 * ユーザーパスワードの変更 * ファイアウォールルールの適用 * ホスト型侵入検知システムの導入 * システムパッチの適用 * システムのシャットダウン * こうした活動の際は、事業や関係するステークホルダーに適宜情報を共有する必要がある * ただし「システムにパッチを当てた＝インシデント解決」とは限らない * 駆除・復旧・事後対応はまだ残っている #### 駆除 * Eradication * インシデントを封じ込めたら、次は**根本原因や残存要素を排除し、攻撃者を完全にシステムやネットワークから締め出す**必要がある * 具体的には * 検出されたマルウェアをシステムから削除 * 一部システムを再構築 * バックアップからの復元など。 * また、封じ込め時には必須ではなかった追加パッチを適用したり、システムの堅牢化を実施することもある * これは被害を受けたシステムだけでなく、場合によってはネットワーク全体に行われる #### 復旧 * 復旧段階では、システムを通常の運用状態に戻す * システムが正しく動作しているか、必要なデータが揃っているかを事業部門が検証し、問題なければ本番環境に戻す * ただし、復元したシステムはしばらく詳細なログ収集と監視の対象になる * 攻撃者が短期間で再び環境にアクセスするケースがあるため * 特に監視すべき不審な挙動 * 通常ではログオンしないユーザー／サービスアカウントによるログオン * 不審なプロセスの実行 * マルウェアがよく変更するレジストリ箇所の変更 大規模インシデントでは、復旧に数か月かかる場合もある 通常は段階的に進める * 初期フェーズでは「早期改善」「簡単に解消できる問題の排除」に注力 * 後半フェーズでは「長期的で恒久的な対策」に重点を置き、組織のセキュリティを可能な限り強化していく ### Post-Incident Activity 事後対応活動 * インシデントを文書化し、そこから得られた教訓を基に自らの能力を改善すること * この情報は、インシデントに関わったすべての関係者とのミーティングで収集・分析するのが最も効果的 * 通常は、インシデント発生から数日以内に最終報告書が完成したタイミングで実施される #### 報告 * 最終報告書は、このプロセス全体において極めて重要な部分 * 完全な報告書には、以下のような問いへの回答が含まれる * 何が、いつ起こったのか？ * チームの対応は、計画・プレイブック・方針・手順に沿って機能したか？ * ビジネス部門は必要な情報を提供し、迅速に対応して効率的なインシデント処理を支援したか？改善点はあるか？ * インシデントを封じ込め、駆除するためにどのような行動を実施したか？ * 同様のインシデントを防止するために、どのような予防策を導入すべきか？ * 将来、類似のインシデントを検知・分析するために必要なツールやリソースは何か？ これで、たとえば • これまでに処理したインシデントの件数 • インシデント1件あたりにチームが費やした時間 • 処理の過程で実施された具体的なアクション などを知ることができる #### 学習と改善 * 新しいチームメンバーを教育する絶好の機会でもある * 経験豊富なメンバーがどのようにインシデントを処理したかを共有することで、学習の場になる * 同時に、計画・プレイブック・方針・手順の更新が必要かどうかを評価することも重要 *