SplunkでKubernetes環境の異常な振るまいを検知し、クラウドネイティブ基盤のセキュリティを強化しよう

はじめに

• クラウドインフラの普及に伴い、マイクロサービスやコンテナを活用したクラウドネイティブアーキテクチャを採用する企業が増加しています
  一方で、従来型のエンドポイントセキュリティ（EDRなど）だけでは、クラウドネイティブ環境特有の動的で分散した構成を十分にカバーすることが難しくなってきています

• 特にKubernetesは、クラウドネイティブアーキテクチャにおいて、コンテナのデプロイやスケーリング、運用管理を自動化する「オーケストレーション機能」を担っており、その中心的かつ基盤的な役割を果たしています

• Kubernetesの普及に伴い、これを狙ったサイバー攻撃や不正アクセスの脅威も年々増加しています。そのため、Kubernetes環境に特化した監視や異常検知の仕組みがこれまで以上に求められています。本記事では、こうした脅威に対応するためのアプローチとして、Splunkを活用したセキュリティ強化の手法をご紹介します

Splunkセキュリティコンテンツ「Enterprise Security Content Update(ESCU)」について

• Kubernetes環境における異常な振るまいの検知には、Splunkセキュリティコンテンツの「Enterprise Security Content Update（以下、ESCU）」の検知ルールを利用します。ESCUの概要や活用方法については、こちらの記事で解説していますので、あわせてご参照ください

• ESCUでは、セキュリティユースケースごとに「分析ストーリー（Analytics Story）」として複数の検知ルールがまとめられています
  本記事では、ESCUの分析ストーリー「Analytics Story: Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring」の検知ルールについて説明します。
  

• Splunk Enterprise Securityでは、ESCUのすべての検知ルールを利用することができ、前述の分析ストーリーも利用可能です。Splunk Enterprise SecurityにおけるESCUの活用については、こちらの記事で解説していますのでご参照ください。
  また、Splunk Enterprise Securityのリスクベースアラート機能を利用することで、異常な振るまいに基づく誤検知を抑えつつ、より確度の高いアラートを生成することができます。
  さらに、Splunk Enterprise Security上のESCUの検知ルールにはあらかじめリスクスコアが設定されており、これを基にした柔軟なアラート設計が可能です

• 今回ご紹介する検知ルールでは、OpenTelemetry(OTEL)コレクターを使用して収集され、Splunk Infrastructure Monitoring Add-onを使用してSplunk Observability Cloudから取得されたメトリックを活用します

分析ストーリー「Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring」

• ​Kubernetes公式ドキュメントでは、Kubernetes環境のセキュリティを強化するためのベストプラクティスや設定方法が記載されていますが、これらは主に事前のセキュリティ対策に焦点を当てています
  例えば、​RBAC（ロールベースのアクセス制御）を用いたユーザーやサービスアカウントの権限管理や、Podの特権やアクセスコントロールを制限するためのポリシー指針などです。

• 一方で、ESCUの分析ストーリー「Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring」の検知ルール（以下の画像を参照）は、リアルタイムの監視と異常検知に重点を置いています
  具体的には、ネットワークトラフィックの異常、リソース使用率の異常、そして不審なプロセスの実行などが主な監視対象となっています

• 以下は、各検知ルールを想定される脅威の種類ごとに分類したものです。それぞれの検知ルールがどのような異常を対象とし、どのような攻撃や侵害に対応しているかを記載しました

1. 異常なネットワーク通信

• 該当ルール：
  • Kubernetes Anomalous Inbound Network Activity from Process
  • Kubernetes Anomalous Inbound Outbound Network IO
  • Kubernetes Anomalous Inbound to Outbound Network IO Ratio
  • Kubernetes Anomalous Outbound Network Activity from Process
  • Kubernetes Anomalous Traffic on Network Edge
  • Kubernetes newly seen TCP edge
  • Kubernetes newly seen UDP edge
• 想定される脅威：
  • 攻撃者によるコマンド＆コントロール（C2）通信
  • データの持ち出し（Exfiltration）

2. 異常なコンテナイメージやリソース使用

• 該当ルール：
  • Kubernetes Previously Unseen Container Image Name
  • Kubernetes Process with Anomalous Resource Utilisation
  • Kubernetes Process with Resource Ratio Anomalies
• 想定される脅威：
  • 未知または改ざんされたコンテナイメージの使用によるマルウェアの実行や脆弱性の悪用
  • クリプトジャッキング（リソースの不正使用による仮想通貨マイニング）
  • DoS（サービス拒否攻撃）につながる過剰なリソース使用
  • 侵害されたコンテナによる不正処理の実行

3. 不正なプロセス実行・ユーザー実行

• 該当ルール：
  • Kubernetes Previously Unseen Process
  • Kubernetes Process Running From New Path
• 想定される脅威：
  • マルウェアや不正スクリプトの実行
  • 権限昇格（Privilege Escalation）
  • 持ち出し用ツールの実行によるデータ漏えい

4. 異常なプロセスの振るまいとCPU使用

• 該当ルール：
  • Kubernetes Shell Running on Worker Node
  • Kubernetes Shell Running on Worker Node with CPU Activity
• 想定される脅威：
  • 攻撃者によるシェルアクセスの確立（リモート操作）
  • 横方向移動や情報収集（Reconnaissance）
  • クリプトジャッキングなどによる高負荷なCPU活動
  • 持続的な侵害活動（Persistence）

検知ルールの紹介

• ここでは分析ストーリー「Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring」に含まれる検知ルールをピックアップしてご紹介します

• 上記の分析ストーリーに含まれる検知ルールは、すべてサーチタイプが「Anomaly（異常）」に分類されています
  「Anomaly」は、通常とは異なる挙動を検知するものであり、必ずしも攻撃を直接示すものではない点に注意が必要です。
  サーチタイプの説明と利用例はこちらの記事で解説していますので、あわせてご参照ください

• Splunk Enterprise Securityのリスクベースアラート機能は、検知ルールがトリガーされた際に付与されるリスクスコアを積み上げて、閾値超過時にアラートを生成する仕組みです。そのため、「Anomaly」タイプのサーチで発生しがちな単発の誤検知を抑えつつ、より確度の高いアラート生成を実現できます

Detection: Kubernetes Anomalous Outbound Network Activity from Process（リンク）

• 本検知ルールのサーチでは、過去1時間の最新のネットワーク メトリック (tcp.bytes、tcp.new_sockets、tcp.packets、udp.bytes、udp.packets) と、過去30日間の平均メトリックを比較して検出します
• Kubernetes環境のワークロード（Pod）内のプロセスが、通常よりも大きく逸脱したアウトバウンド通信（TCP/UDP）を行っている場合、サーチのロジックに合致した結果として、クラスタ名・ワークロード名・プロセス名を返します
• 本検知ルールでは、統計的な異常検出手法として標準偏差（Standard Deviation）を利用しています。
  過去30日間のデータから各メトリクスの平均値と標準偏差をベースラインとして取得し、現在の値が「平均 + 3 × 標準偏差」を超えている場合に、統計的に異常な値（Outlier）として検出します。
  ただし、「平均 + 3 × 標準偏差」を超えるデータは全体の約0.15%未満とされており、非常に厳しい条件であるため、誤検知の発生状況や運用環境によっては、「平均 + 2 × 標準偏差」など、しきい値を調整することも検討すべきです。

Detection: Kubernetes newly seen TCP edge(リンク)

• 本検知ルールのサーチでは、過去1時間のネットワーク アクティビティを過去30日間と比較して、新しいワークロード間のTCP通信を検出します
• Kubernetes環境において、過去30日間に一度も通信履歴のなかったワークロード間で、直近1時間にTCP通信が確認された場合に、サーチのロジックに合致した結果として、送信元ワークロード名・宛先ワークロード名を返します
• 本検知ルールでは、過去に存在しなかったTCP通信エッジで、直近1時間に初めて観測されたものを抽出します

Detection: Kubernetes Previously Unseen Container Image Name(リンク)

• 本検知ルールのサーチでは、過去1時間に確認されたコンテナイメージ名を過去30日間のコンテナイメージ名と比較して検出します
• 不正なイメージの持ち込み、バックドア付きのイメージ、未知のワークロード実行などの兆候がある場合、サーチのロジックに合致した結果として、ホスト名・クラスタ名・ノード名・コンテナイメージ名を返します
• 本検知ルールでは、過去30日〜1時間前のコンテナイメージ情報を取得し、現在は使われているが、過去30日には見られなかったコンテナイメージを検出します

Detection: Kubernetes Shell Running on Worker Node with CPU Activity(リンク)

• 本検知ルールのサーチでは、プロセス メトリック (process.cpu.utilization、 process.memory.utilization) を利用し、許可されていないシェルプロセスを検出します
• Kubernetesノード上でCPUを使用して活動しているシェル（sh, bash, csh, tcsh）を検出し、サーチのロジックに合致した結果として、ホスト名・クラスタ名・ノード名・プロセスID・プロセス実行名を返します。本サーチは攻撃者によるリモート操作、マイニング、探索活動などの能動的な異常動作を早期に特定することが目的だと考えます

さいごに

• 今回紹介したKubernetesセキュリティの検知ルールは、障害対応やパフォーマンス改善を目的としたObservability（O11y）の代表的なデータであるメトリクスを、セキュリティ用途に応用した事例です
• 今後ますます重要性が高まるKubernetesセキュリティの領域における、Splunkの活用事例をご紹介しました。Splunkはデータ活用において中心的な役割を担うプラットフォームであり、本記事で取り上げたように、Observability（O11y）とセキュリティの両領域にまたがって活用することが可能です
• Splunkで取得した長期間のデータに対して、サーチ文を用いて簡単に統計処理が行えるという、Splunkの強みについても触れることができたかと思います。本記事が少しでも皆さまの参考になれば幸いです

今日もHappy Splunking!!