ランタイムセキュリティツールの選び方：GitLabのセキュリティチームに学ぶ

適切なランタイムセキュリティツールを選ぶことは、クラウドネイティブ環境を守るうえで欠かせません。従来のクラウド監査ログだけでは十分な詳細情報が得られず、脅威検知やインシデントレスポンス、フォレンジック分析に大きなギャップが生じてしまいます。そこでGitLabセキュリティチームでは、KubernetesクラスターとLinuxサーバーを対象に、実際の攻撃シナリオを再現したシミュレーションによる厳密な評価を実施しました。初期アクセスから横展開、データの外部流出に至るまで、重要なフェーズを一つひとつ丹念に検証しています。

本記事では特定のベンダー名は伏せつつ、詳細な評価方法と主な学びをご紹介します。皆様ご自身のセキュリティツール評価に応用いただける、実践的なガイドとしてお役立てください。

ランタイムセキュリティツールが必要な理由

ランタイムセキュリティツールがなければ、攻撃発生時に「何かおかしい」と気づき、「実際に何が起きたのか」を突き止めることは非常に困難です。

クラウド監査ログの限界

• ランタイムの詳細情報の欠如
  クラウド監査ログが記録するのは、主にクラウド内での操作やデータアクセスです。Kubernetesサーバーなどにおけるランタイムレベルのアクティビティまでは捉えきれず、細かなコマンド実行やプロセスの挙動、一時的なネットワークアクティビティが見落とされてしまいます。
• 調査・フォレンジックにおけるギャップ
  Kubernetes環境では、継続的なリアルタイムロギングが行われていないと、コンテナが終了した時点で重要なアクティビティ記録が失われかねません。

よく知られたオープンソースのランタイムセキュリティツールもありますが、今回は攻撃シミュレーションテストを通じて追加機能とエンタープライズレベルのサポートを見極めるため、商用製品を評価対象としました。

ランタイムセキュリティツールの役割と目的

ランタイムセキュリティツールは、システムをリアルタイムで継続的に監視することで、こうしたクラウド監査ログの限界を補います。主な機能は次のとおりです。

• 脅威検知
  コマンド実行やシステムコール、ネットワークイベントをリアルタイムで監視し、異常な挙動を即座に検知することで、セキュリティチームの迅速な対応を可能にします。一部のパブリッククラウドプロバイダーも限定的なランタイム監視機能を提供し始めていますが、専用のセキュリティツールに比べると、監視の深さも対象範囲の広さも限られるのが実情です。
• インシデントレスポンス
  システムアクティビティの詳細な時系列記録を保持しておけば、攻撃のタイムラインを再構築し、侵害の全容を把握し、インシデント発生後に徹底したフォレンジック調査を行うための証拠が手に入ります。
• 調査のスケーラビリティ
  エンドポイントごとにフォレンジック分析することなく、ランタイムセキュリティツールなら環境全体のデータを一元的に収集・保存・分析できます。異なるデータソースを手作業で突き合わせる必要がなく、効率的にインシデントを調査できるのが強みです。

（注: ランタイムセキュリティツールにはコンテナやサーバーの脆弱性管理機能が付属することがありますが、本記事では扱いません。）

参考：脅威検知は、アラートが適切な担当者に届き、効率的に対応されて初めて価値を持ちます。GitLabのセキュリティチームがどのようにアラート対応ワークフローを築いたのか、「セルフサービス型のアラート対応ワークフローの構築（英語版）」で紹介しています。

評価における重要なポイント

ランタイムセキュリティツールを評価する主な目的は、実際のセキュリティ調査での有効性を見極めることでした。評価では検知数やカバレッジの広さに目が行きがちですが、実際の運用では話が違います。誤検知が大量に発生したり、1つの攻撃チェーンに対して数十件ものアラートが上がったりすれば、インシデントレスポンスチームの対応はたちまち麻痺してしまうのです。そこで今回の詳細な調査では、実際の攻撃を理解し対応するうえで、このツールがセキュリティ運用をどこまで支援できるかを中心に検証しました。

• 検知能力
  • 組み込みルール
    さまざまな攻撃手法を効果的に検知できるか、また正確な検知に必要な詳細情報を提供できるか、という観点で組み込みのルールセットを評価しました。
  • カスタム検知機能
    追加ルールをどれだけ容易に組み込めるかを評価するとともに、製品が提供するテレメトリデータの品質も確認しました。自社環境への理解を活かした独自の監視ソリューションを構築できるかどうかがポイントです。
  • アラートの品質
    誤検知の発生率も検証しました。対応が必要な本物のセキュリティ脅威にきちんと焦点を当てつつ、アラート疲れの原因となるノイズを最小限に抑えられているかを確認しています。
• インシデントレスポンス
  • ログの豊富さ
    実行されたコマンド、ネットワーク接続、DNSクエリ、プロセス情報など、インシデントを完全に再構築できるだけの詳細をログが記録しているかを評価しました。攻撃シナリオ全体を組み立て、影響範囲を正確に把握できるかどうかは、インシデントレスポンスの成否を左右します。
  • ログの検索性
    複数のシステムにまたがるイベントを、どれだけ効果的に検索・フィルタリング・関連付けできるかを評価しました。膨大なデータを迅速に検索できる能力は、セキュリティインシデント発生時の迅速な調査に欠かせません。

評価プロセス

評価プロセスは、以下の4つの主要なフェーズに分けて実施しました。

1. 攻撃シナリオの策定
   実際の攻撃フローを模したシナリオを設計しました。Red Teamと連携して作成したこれらのシナリオには、以下の要素が含まれています。
   • GitLab固有の脆弱性（例: CVE-2021-22205）を悪用する攻撃
   • 開発者のノートパソコンの侵害を利用した攻撃
   • 詳細なステップバイステップの攻撃手順
2. インフラのセットアップ
   以下の2つの並行環境を構築しました。
   • Kubernetes環境
   • 仮想マシン（VM）環境
   
   既知の脆弱性を検証するため、GitLabの旧バージョンをインストールし、Kubernetes環境とVM環境の両方で同様の評価フローを実施しました。
3. 攻撃の実行
   各シナリオの攻撃フローを実行し、初期アクセスから横展開、データの外部流出に至るまでのタイムラインを綿密に記録しました。
4. 結果の分析
   検知能力、ログの充実度、改善が必要な点を総合的に評価し、ツールの強みと弱みを明確に整理しました。

攻撃シナリオ

シナリオ1: 既知のGitLab脆弱性の悪用

• 攻撃フロー
  1. 初期アクセス
     リモートコード実行を許してしまう既知のGitLab脆弱性、CVE-2021-22205を悪用した攻撃をシミュレートしました。これにより、対象システムへの不正アクセスに成功しています。
  2. コマンド実行
     アクセス権を取得した後、リバースシェルを実行し、侵害したマシンとリモートでやり取りしながら制御を奪いました。
  3. C2エージェントの展開
     永続化（パーシステンス）の手法を評価するため、C2（コマンド＆コントロール）エージェントをインストールしました。これにより、さらなるコマンドの実行やシステムのリモート管理が可能になります。
  4. 横展開
     続いて環境内で横展開を行い、Kubernetes APIのシークレットやPostgreSQLデータベースにアクセスしました。
  5. データの外部流出
     専用のC2チャネルを経由して、機密データを外部へ流出させました。

各フェーズで使用された攻撃手法をまとめると、以下の表のとおりです。

シナリオ2: 開発者のノートパソコンの侵害

• 攻撃フロー
  1. 初期侵害
     攻撃者が開発者のノートパソコンを侵害し、正規の認証情報を悪用して社内リソースへ不正アクセスするシナリオをシミュレートしました。
  2. 権限昇格
     侵害した認証情報を使い、Kubernetes環境内で権限を昇格させました。
  3. コンテナの操作
     特権コンテナをデプロイし、機密情報を抽出しました。
  4. データの外部流出と永続化
     永続的なアクセスを維持しながら、機密データを外部に流出させました。
     各フェーズで使用された攻撃手法をまとめると、以下の表のとおりです。

攻撃の実行

攻撃シナリオの実行中は、詳細な記録を残すため次のプロセスに従いました。

• 検知の確認: 各攻撃コマンドが検知されたか、また各シナリオの重要なポイントが適切にフラグ付けされたかを確認しました。
• タイムラインの記録: コマンド実行やネットワーク通信がどれだけ的確に記録されるかを見極めるため、すべてのイベントを時系列で記録しました。
• スコアリングと分析: ツールの性能を定量的に評価するため、検知の有効性に基づいて各イベントにスコアを付けています。

学んだこと

商用製品を過信せず自ら検証する

• 検知のギャップの特定と対応（ベンダーとの連携）
  評価の結果、いくつかの重要なシナリオやイベントが検知されなかったり、ログに記録されなかったりすることが判明しました。そこでベンダーとのミーティングを重ね、複数の改善要望を提出しています。その結果、ベンダーは新機能の追加や検知能力の改善によって製品を強化し、評価で見つかった多くの課題を解消してくれました。
• 限界の理解
  多くの最新のランタイムセキュリティツールは、eBPFを使ってLinuxのシステムコールを監視し、検知を行います。しかし、C2フレームワーク内で実行されるコマンドは新しいプロセスを生成しないため、こうした攻撃イベントの追跡には限界がありました。
• ツールの限界を認識する
  今回の調査から見えてきたのは、インシデントレスポンスにおいてランタイムセキュリティツールだけに頼るのでは不十分だということです。全体像を把握するには、Kubernetes監査ログやクラウドログなど、他のログと組み合わせることが欠かせません。

Kubernetesにおける継続的なランタイムイベントロギングの重要性

Kubernetes環境では、コンテナが終了するとフォレンジックデータが失われるリスクがあるため、継続的なロギングが欠かせません。今回の評価を通じて、スケーラブルで永続的なロギング基盤を構築することの重要性をあらためて確認しました。適切なランタイムセキュリティツールがなければ、攻撃発生後に重要な情報の大部分が失われてしまいかねません。

まとめ

今回ご紹介したような徹底的な製品評価は、ベンダーが見落としがちな独自のユースケースや改善点を明らかにしただけでなく、ツールを最適に活用する方法を整理するうえで、ベンダーと社内チームの双方に価値ある知見をもたらしてくれました。GitLabセキュリティチームでは、このように単にセキュリティツールを導入するだけでなく、その有用性を評価することで、お客様が安心してGitLab.comをご利用いただける環境づくりを目指しています。