本文の内容は、2023年3月28にSTEFANO CHIERICI が投稿したブログ（https://sysdig.com/blog/csi-container-securitycon-dfir）を元に日本語に翻訳・再構成した内容となっております。
ミステリーシリーズは好きでしょうか？実際にサイバーセキュリティを舞台にした作品について考えたことはありますか？コンテナでのCSI（Crime Scene Investigation – 科学捜査班）についてどう思いますか？デジタル・フォレンジックとインシデント・レスポンス（DFIR）をコンテナやクラスターに適用する方法に興味がありますか？もしあなたの答えがすべてYESであれば、この記事を気に入ることでしょう。
2023年2月上旬に開催されたCloudNative SecurityConでは、セキュリティの第一人者が集まり、最新のリサーチやプロジェクトを発表しました。この記事では、コンテナ版CSI ： あなたはDFIRできますか？（発表資料）を詳しく見ていきたいとお思います。
警察の捜査と同じように、容疑者を見つけるためには、以下のような一連の手順を踏む必要があります：
- 準備
- 検出・解析
- 封じ込め・根絶・リカバリー
- 報告
その前に、デジタルフォレンジックとインシデントレスポンスとは何でしょうか？
DFIR＝DF＋IR
ツールについて深く掘り下げる前に、まずDFIRについて簡単に紹介しましょう。ご存知のように、DFIRは2つの分野をまとめています：
- デジタル・フォレンジック
- インシデントレスポンス
デジタル・フォレンジック（DF）は、システムデータ、ユーザーアクティビティ、その他のデジタル的な証拠を収集・分析し、マシン上で何が起こったのか、記録されたアクティビティの背後にいるのは誰なのかを特定することを目的としています。すべての活動は、ベストプラクティスと方法論に従って行われ、保管の連鎖を維持する必要があるため、証拠が正当なものであり、法的手続きのために裁判所に提出することができるようになります。
インシデントレスポンス（IR）は、データ侵害の準備、検出、抑制、リカバリーに焦点を当てたものです。IRの技術は、セキュリティの適用範囲のギャップを埋めるだけでなく、将来的に同じタイプのインシデントを繰り返さないようにする方法についてもカバーしています。調査から得られた教訓は、データ漏洩につながったセキュリティの適用範囲のギャップを啓発することができます。
初期の頃は、この2つのプロセスは目的が異なるため、分かれていました。しかし、プロセスや方法論はかなり似ていました。EDRやXDRのような新しいツールが進化し、今ではインシデント対応担当が何が起こったのか調査を開始し、さらなる活動を行うための力を与えています。ですから、この2つの領域をDFIRという帽子の下に置くことは理にかなっています。
DFIR – NIST IRライフサイクル
DFIRとそのステップについて語るとき、私たちはNISTのインシデントレスポンスライフサイクルのステップを参照します。以下のスキーマでは、4つの主要なステップを見ることができます。
よく知られているNISTのライフサイクルの各カテゴリーの詳細についてはあまり触れませんが、インシデント対応計画は事前に準備する必要があることは覚えておくとよいでしょう。
対応策を持つ
私たちが強調したい主な収穫は何ですか？攻撃者は、あなたがインシデント対応計画を作成し更新するのを待っているわけではありません！特にコンテナの世界では、使用する必要のあるツールを知っておくことが基本です。準備を怠らないようにしましょう！
ご存知のように、気にしなければならないのは技術的な側面だけではありません。設定すべきプロセスもありますし、さまざまなチームの人々が関わり、その瞬間に何をすべきかを正確に知っておく必要があります。
インシデント対応計画が決まっていても、これが最新であることを確認してください！組織内で人が変わることもありますし、採用された新しい技術によってツールもかなり頻繁に変わります。今後、DFIR活動を行うには、特定のツールが必要となります。常に最新の情報を入手することは本当に重要です。
それでは、技術的な側面、ツール、手順に焦点を当て、コンテナの世界でこれらのステップを実行する方法について説明します。
ステップ1 – 準備
準備は、インシデントレスポンスの方法論の主要な側面の1つです。
優れた準備プロセスにより、環境を強固にすることでインシデントを防止するだけでなく、組織がインシデントに対応できるようにインシデント対応能力を強化することができます。その対象と想定されるのは： 通信と設備、ハードウェアとソフトウェア、またはより一般的な分析リソースです。
この準備プロセスでは、インフラストラクチャー全体を完全に把握するために、調査に役立つすべてのデータログを収集し、すべての情報を1つのポイントに集約して、データの検索や集計ができるようにすることが主なポイントの1つです。
ここでは、検討すべきオープンソースツールをいくつか紹介します：
- コンテナランタイムセキュリティ
- Falco + Falcosidekick (CNCF Incubated)
- 監視システム
- Prometheus (CNCF graduated)
- ロギングソリューション
- Fluent-bit/Fluentd (CNCF graduated)
- ログ管理プラットフォーム
- ELK Stack、Opensearchなど…
ステップ2 – 検出・解析
この段階の主な目的は、実際にインシデントが起こったかどうかを把握し、その性質を分析することです。これらは簡単な作業ではありません。まだ、インシデントを根絶する時期ではありません。
このフェーズでは、通常、前述のツールが生成するアラートやイベントを確認し、悪意のある行動や、侵害の可能性がある疑わしい活動のIoC（Indicators of Compromises）があるかどうかを確認します。そのためには、アプリケーションのログからコンテナ・オーケストレーターやクラウドのログまで、長期にわたって収集されたログを調査して、疑わしいものがないかどうかを調べる必要があります。また、配置されているリソースを監視し、計画または予想されるリソースと比較することで、異常やスパイクを平均的な負荷と区別できるようにすることも必要です。
検出、ロギング、アラーム通知ツールで収集したすべての情報を分析し、実際のインシデントによって引き起こされた可能性があるかどうかを評価する必要があります。
ステップ3 – 封じ込め、根絶、リカバリー
この時点で、前のステップで実施した分析により、実際にセキュリティ侵害が判明し、何かが発生したことがすでに分かっています。必要な措置をすべて講じる必要があります。
根本的な原因がわからない場合は、利用可能なすべての緩和策を適用する必要があります。しかし、その前に、攻撃者が不正アクセスを拡大したり、他のシステムを侵害したりする可能性があるため、封じ込め戦略の遅れは危険であることを考慮してください。
ここでは、このフェーズで使用できるコンテナ用のツールをいくつか紹介します：
- docker/ctr/crictl/nerdctl/podman： 関係するコンテナエンジンとやり取りをする
- kubectl: kube-apiserverとコミュニケーションします
- docker-explorer/container-explorer (by Google)： スナップショットされたボリュームをオフラインでフォレンジック分析することができるオープンソースプロジェクト
- container-diff (by Google)： コンテナイメージを分析・比較するためのツールです。イメージ内のあらゆる変更を検出することができます
- cloud-forensics-utils： フォレンジックチームがクラウドプラットフォームから証拠を収集するために使用するツールを提供するオープンソースプロジェクトです。現在、Google Cloud Platform、Microsoft Azure、Amazon Web Servicesがサポートされています。
封じ込め
主な目標は、どのリソースが影響を受けたかを評価し、影響を受けたPod/Containerを隔離するアクションを取ることによって、攻撃を分離することです。
このフェーズでは、次のような攻撃の証拠をすべて保存して収集することが重要です：
- 影響を受けたPod/Containerがスケジュールされているワーカーノードボリュームをスナップショットする（クラウドプロバイダーのコンソールから手動で、またはcloud-forensics-utilsなど、このステップを自動化できるツールを使って）
- さらなる分析のために、感染したコンテナをコミットしてプッシュします
- 可能であれば、コンテナをチェックポイントする（最良の選択）
- 可能であれば、ディストロレスコンテナのライブ調査用にエフェメラルコンテナを使用する。
根絶
脅威を十分に封じ込めたら、今度は攻撃を根絶する必要があります。つまり、この段階では、インシデント中に侵入したマルウェアや脅威を除去する必要があり、また、攻撃者に被害環境での永続性や特権の昇格を認めた可能性のあるものを除去する必要もあります。さらに、必要なリカバリーテクニックを採用するためには、侵害時にどのエントリーポイントが悪用されたか、あるいは攻撃者がどのような追加のパスや権限を悪用したかを特定することが極めて重要です。
このため、根絶のステップに進む前に、攻撃がどの程度広がっているかを把握することが重要です。
リソースを共有するコンテナ環境では、この作業は非常に厄介で、何を見るべきかという特別な知識が必要です。ここでは、特に注目すべきポイントをいくつか紹介します：
- 影響を受けたPodが、機密性の高いマウント、または過剰な権限や機能で設計されデプロイされていないかどうかを確認します。もしそうなら、Podのエスケープやホストの特権情報へのアクセスがあったかもしれません。
- Kubernetesの監査ログをFalcoなどのランタイムツールで監視し、クラスター内の不要なアクションを検出する。例として、クラスター内の新しいクラスタロール/Podの作成、シークレットの読み取りなど
- クラスターがクラウド上でホストされている場合、Inspect Cloudログは横移動の試みを監視します。影響を受けたPodがクラウドメタデータ（IMDS）を活用して機密データにアクセスし、クラウドアカウント内の特権をエスカレートさせようとすることがあれば、これは、すべてのクラウドインフラストラクチャーにダメージを与えることになる可能性があります。
最後のアクションは、設定の誤りを修正するか、攻撃者がお客様の環境に侵入するために使用した脆弱性にパッチを適用することです。修正が不可能な場合は、適切な緩和策を見つけることが重要です。
リカバリー
リカバリー段階では、脅威の影響を受けた本番環境はすべてオンラインに戻します。これには、システムやサービスを通常のオペレーションに戻すために必要なデータ復旧や復元作業も含まれます。
このステージでは、以前に特定されたエントリポイントの恒久的な修正を実施することも要求されます。これには、システムおよびアプリケーション・アーキテクチャーのパッチ適用や再設定、本番環境でのシステムの再構築などが含まれます。主な目的は、脅威者が環境へのアクセスを得るために使用したエントリポイントを排除し、将来的に同様のインシデントを防止することです。
しかし、リカバリーが不可能な場合は、攻撃される対象領域を縮小させ、将来のインシデントに対応するために、適切な緩和策を見つけることが重要です。例えば、ランタイムに悪意のある実行/エクスプロイトが検出された場合、影響を受けるワークロードを削除したり、アクションのプレイブックを実行することが考えられます。
ステップ4 – インシデント後の活動
私たちは今、インシデント対応計画の最後のステップである「インシデント後の活動」に来ました。私たちの環境から脅威を封じ込め、根絶するために必要なすべての行動をとり、環境はリカバリーされ、通常通り動作しています。
インシデントは発生しましたが、これを機会に、今後より良い対応をする必要があります。
何が起こったのか、何がうまくいったのか、何がうまくいかなかったのか、そしてなぜうまくいかなかったのかを分析するときです。これらの事後活動のアウトプットは、将来同じようなインシデントが発生しないように、インシデント対応計画を適宜更新するために使用されるべきです。
まとめ
現在、KubernetesやコンテナでDFIRを遂行することは、本番環境において従来よりもはるかに複雑になっています。コンテナは刹那的であり、たとえ特定のワークロードを実行するためにビルドされたとしても、その上でDFIRを実行することは、それよりもはるかに複雑な場合があります。
必要な情報をすべて記録し、検出メカニズムを導入し、適切なツールを採用することで、インシデントレスポンスとフォレンジックチームが実際の侵害を特定し、そのようなインシデントが本番環境に与えた影響を評価するのに必要なすべての証拠を収集することができるかもしれません。
DFIRについてもっと知りたいですか？