エージェントベースとエージェントレスの両方を活用： End-to-end の検知で疑わしい振る舞いを防止する

本文の内容は、2023年6月7日にNIGEL DOUGLASが投稿したブログ（https://sysdig.com/blog/real-time-security/）を元に日本語に翻訳・再構成した内容となっております。

急速に進化するデジタル環境では、悪意ある行為者が絶えず戦略を変更し、私たちのシステムに侵入してきます。高度な脅威からアプリケーションやワークロードを保護するためには、従来のエンドポイント検出メカニズムではもはや十分ではありません。この懸念に効果的に対処するためには、脅威の検知に幅広いアプローチを取り入れることが不可欠になっています。そのためには、エージェントベースとエージェントレスの両方の検出方法を取り入れるというパラダイムシフトが必要です。

このブログでは、”シフトレフト”と ”シールドライト” の原則を通じて、脅威検知の範囲を拡大する概念を探ります。”シフトレフト” のアプローチでは、脆弱性スキャナー、ポスチャーハードニング、権限管理などのツールを用いて、できるだけ早い段階で脆弱性に対して積極的に防御します。一方、”シールド・ライト “は、リアルタイムの検知と対応能力に重点を置いています。従来のエンドポイントセキュリティエージェントは、実行時に詳細な可視性を提供しますが、CI/CDパイプラインやクラウド環境内でリアルタイムに脅威を検出するには不十分です。

Sysdigは、コードベース内だけでなく、アクティブなワークロード全体でリアルタイムの脅威検出を可能にする、堅牢でエンドツーエンドの戦略を提供します。Sysdigは、汎用性の高いプラグインアーキテクチャーを活用することで、開発者やセキュリティチームが、システムの複雑化に伴い不審な挙動を迅速に特定し、対応することを可能にします。

Preventing suspicious behavior with end-to-end detections

それでは、この戦略が、ソフトウェア開発ライフサイクル全体に及ぶ全体的なアプローチにどのように適合し、組織が現代の脅威と効果的に戦うための力を与えるかを見てみましょう。

シフトレフト

まず、”シフトレフト” という概念について説明します。この言葉は、開発ライフサイクルにセキュリティ対策と検出メカニズムを早期に統合することを意味しています。

ソフトウェア開発プロセスの初期段階にセキュリティ管理とポリシーを組み込むことで、潜在的な脆弱性や悪意のある活動を積極的に特定し、重大な脅威となる前に緩和することができます。多くの業界関係者は、この段階で議論する価値のある概念は、イメージ署名とイメージスキャン（大部分）だけだと考えるでしょう。

そして、これは絶対に必要なことなのです！

このアプローチは、既存のセキュリティの限界に対処することを目的としています。一方、組織はコードリポジトリにおけるコードの誤設定に過度に注目する傾向があり、偶発的なデータ露出のようなより明白な脅威をしばしば見落としています。

データ露出の一般的な形態の1つは、開発者がパスワードやトークンなどの機密情報を、一般にアクセス可能なリポジトリに不注意でプッシュしてしまうことです。その結果、意図しているかどうかにかかわらず、開発者であれば誰でもこれらのシークレットにアクセスすることができます。社内のコントリビューターや従業員に限定されたプライベートなリポジトリであれば問題ないかもしれませんが、誤ってリポジトリを「プライベート」から「パブリック」に変更してしまった場合、状況は不安定になります。

このようなシナリオでは、SysdigのエージェントレスGitHub検出機能が、疑わしい行動を迅速に検出し、セキュリティチームが偶発的なデータ漏洩に関連するリスクを軽減するために重要な役割を果たします。コード・スキャン、イメージ・セキュリティ・スキャン、その他のシフトレフト手法などの実践を強く推奨しますが、従来のエージェントベースのセキュリティ・ソリューションを含むこれらのツールでは、サードパーティのプラットフォームにおける効果的なインシデント対応に必要な検出能力を提供できないことを認識することが重要です。

Sysdigは、GitHubプラグインの機能を拡張することで、オープンソースのFalcoプロジェクトにとどまらない機能を提供します。この拡張により、Sysdigは使い慣れたYAMLフォーマットでエージェントレスの検知ルールを提供できるようになり、SysdigとFalcoの検知ルールに対する期待に沿うようになりました。Falcoルールにビルドすることで、Sysdigは検知ルールの基本的なロジックを理解できるので、特定の要件に合わせて簡単にカスタマイズできます。

- rule: Private Repository Becoming Public
  desc: Detect changing the visibility of a repository to public
  condition: github.type=repository and github.action=publicized
  output: A repository went from private to public (repository=%github.repo 
  repo_owner=%github.owner org=%github.org user=%github.user) 
  priority: CRITICAL
  source: githubCode language: PHP (php)

シールドライト

さて、Kubernetes環境内の不要なユーザー活動を検知する手段として、Kubernetes Auditログの活用に焦点を移しましょう。シールドライトの領域では、Sysdigは脅威の検出を開発段階から本番環境へと拡張する革新的なアプローチを提供します。

シールドライトを利用することで、企業はSysdigによる実行中のワークロードにおける継続的な監視と分析の恩恵を受けることができます。これにより、企業は現実のエンドツーエンドの脅威を効果的に特定し、対応することができるようになります。私たちは以前、Falcoプラグインアーキテクチャー内の動的でカスタマイズ可能な脅威検出ルールによって、組織が進化する脅威に適応し、新たな攻撃ベクトルからシステムを保護することができることを説明しました。

SysdigとオープンソースのFalcoは、システムコールに基づくコンテナとホストのアクティビティを検出することができます。例えば、コンテナの削除をリアルタイムで観察することができます。しかし、この情報だけでは、重要なコンテキストが欠けています。コンテナが手動で削除されたのか、それともKubernetesのようなオーケストレーションソリューションの一部だったのかを確認することが極めて重要になります。さらに、コンテナの削除がホスティングポッドの削除と関連しているのか、デプロイやネームスペースの変更など、他の抽象化レイヤーの変更に起因しているのかを判断することも重要です。

Sysdigのプラグインアーキテクチャーは、エージェントレス検出機能に限定されるものではありません。具体的には、KubernetesプラグインはKubernetes Auditログからのリアルタイムイベントを処理するように設計されており、シールドライト検出のための貴重なコンテキストを提供します。これを例で説明しましょう：

- rule: Disallowed K8s User
  desc: Detect any k8s operation by users outside of an allowed set of users.
  condition: kevt and non_system_user and not ka.user.name in (allowed_k8s_users) and not ka.user.name in (eks_allowed_k8s_users)
  output: K8s Operation performed by user not in allowed list of users (user=%ka.user.name target=%ka.target.name/%ka.target.resource verb=%ka.verb uri=%ka.uri resp=%ka.response.code)
  priority: WARNING
  source: k8s_auditCode language: JavaScript (javascript)

私たちのアプローチは、コンテナ化の一時的な性質のために追跡が困難な個々のコンテナIDのみに固執するのではなく、Kubernetes Auditログを監視して不要なユーザーとコンテナの活動を検出することにシフトしています。これらのログを分析することで、デプロイの変更を追跡し、各変更の背後にある責任者についての洞察を得ることができます。この情報をリアルタイムのコンテナコンテキストと関連付けることで、悪意のある動作と良性の動作を区別することが可能になります。監査ログにKubernetesのコンテキストを含めることで、ワークロードの削除や再作成の背後にある正確な理由の理解が大幅に深まり、不要なユーザーの行動を効果的に特定して対処することができます。

アイデンティティプロバイダー

セキュリティは、シフトレフトとシールドライトの思想だけに留まるべきではありません。Oktaのようなアイデンティティ・サービスは、多要素認証（MFA）を通じてセキュリティのレベルをさらに高めるのに適しています。シフトレフトのセクションで述べたように、Secretsのような機密情報を収容するプライベートリポジトリが偶然または悪意を持って公開された場合、セキュリティチームがこのデータ漏洩に気付くまでどれくらいの時間がかかるでしょうか？

同様に、この敵がそのリポジトリから盗んだ認証情報を使ってあなたのIdPプロバイダーにログインしたとしたら、この疑わしい行動を検出するための現在のビジネス戦略は何でしょうか？

これらのサービスはすべて、その活動に関連するリアルタイムのイベントストリームを生成する傾向があります。難しいのは、これらのイベントをどのように処理し、関連するコンテンツでアラートをリアルタイムにトリガーするかということです。

Sysdigはこのためのプラグインを用意しています！

Kubernetesの不要なユーザーアクティビティルールと同様に、Oktaのログインに認識されないIPアドレスや地域から発信された不明なログインを特定するための検出メカニズムを実装しています。アイルランド、マルタ、スペインなどの国を含むホワイトリストを作成することで、異なる国からのログイン試行は疑わしいものとしてフラグを立てることができます。

- rule: Detecting unknown logins using geolocation in Okta
  desc: Detect a logins event based on user geolocation
  condition: okta.evt.type = "user.session.start" and not user_known_countries
  output: "A user logged in OKTA from a suspicious country 
   (user=%okta.actor.name, ip=%okta.client.ip, country=%okta.client.geo.country)"
  priority: NOTICE
  source: okta
  tags: [mitre_defense_evasion]Code language: PHP (php)

Macros や Lists などのオブジェクトを使用すると、セキュリティチームは、ルール自体を変更することなく、Oktaのログインが予想される国を簡単にホワイトリスト化できます。このように、ステージングから本番まで一貫したルールをプッシュし、固有の環境に対してのみリスト項目を修正することができます。

- macro: user_known_countries
  condition: (okta.client.geo.country in (allowed_countries_list))
- list: allowed_countries_list
  items: [ireland, malta, spain]
Code language: Perl (perl)Code language: CSS (css)

プラグインによるデータエンリッチメント

エンドツーエンドのソフトウェア脅威を防御するためには、リアルタイムのアラートだけでは十分ではありません。問題の根本原因を本当に理解し、タイムリーに対応するためには、スタック全体でメタデータのコンテキストをつなぎ合わせる必要があります。

FalcoとSysdigは、洗練されたデータエンリッチメントエンジンを通じてこれを実現します。

先に述べたように、プラグインは、異なるソースからのストリームイベントを扱うことを可能にします。しかし、プラグインは、これらの新しいデータソースの使用方法を記述するための新しいフィールドを定義することによって、インシデントレスポンス機能を拡張することもできます。以下のスクリーンショットからわかるように、単純なドリフト検出ポリシーは、システムコールを通じてプロセス、コンテナ、ホストからの Output コンテキストを持ちます。

すでに、コンテキストが強化されたデータソースの3つの例を見ています。プラグインアーキテクチャーを通じて、Kubernetes Audit logs stream、クラウド監査ロギングサービス（この場合はAWS CloudTrail）、Oktaなどのアイデンティティプロバイダーからのメタデータコンテキストでアラートを豊かにすることも可能です。

ルール Output でどのような情報を公開するかは、完全にあなた次第です。例えば、ECSコンテナ内のExecute Interactive Commandを検出するために設計されたルールがここにあります。出力内容は、アラートに表示されるものです。もちろん、これらのルールに詰め込むことができるコンテキストが多ければ多いほど、より良いです。ただし、ルールエンジンの性能に影響を与えることはできません。そのため、このようなアラート出力でエンドユーザーにカスタマイズを提供しています。

- rule: Execute Interactive Command inside an ECS Container
  desc: Detect execution of an interactive command inside an ECS container.
  condition: >-
    aws.eventSource="ecs.amazonaws.com" and aws.eventName="ExecuteCommand" and
    not jevt.value[/requestParameters/command] in (system_shells) and
    jevt.value[/requestParameters/interactive]=true and not aws.errorCode exists
  output: >-
    An interactive command has been executed inside an ECS container (requesting
    user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region,
    cluster=%jevt.value[/requestParameters/cluster],
    container=%jevt.value[/requestParameters/container],
    command=%jevt.value[/requestParameters/command],
  priority: critical
  source: aws_cloudtrailCode language: JavaScript (javascript)

説明しましたように、FalcoとSysdigにおけるデータエンリッチメントとは、生データをデコードしたり、プラグインなどの補完的なソースから収集したりして得られたイベントメタデータをルールエンジンに提供するプロセスのことを指します。そして、このメタデータをルール条件と関連する出力フォーマットの両方のフィールドとして使用することができます。本番環境では、収集したメタデータをフィールドクラスのセットで整理するため、どのコンテキストに属するかを容易に認識でき、インシデント対応者がコンテキストをつなぎ合わせようとする時間と労力を大幅に節約することができます。

まとめ

脅威の検出範囲を広げる必要性は、今日のダイナミックなサイバーセキュリティの状況において、重要な要件となっています。Falcoのプラグインアーキテクチャーが提供するシフトレフトとシールドライトのアプローチを採用することで、組織は開発環境やライブ環境において疑わしい行動を検出し対応することができます。これらのコンセプトの実践的な実装を探求し、Sysdigが現実世界の脅威から私たちのシステムを保護する方法にどのような革命をもたらすかを発見するための取り組みに参加しませんか？

さらにご興味のある方は

この記事で、最新のクラウド検知・対応機能について詳しくご紹介しています。
ウェビナーもお見逃しなく（英語）： Shift Cloud Security Left and Right with CNAPP, Powered by Runtime Insights
日本でのウェビナー録画はこちらにアクセスください。
詳細については、デモをリクエストしてください。