Fine-tuning Workload Protection Security Signals
概要
Workload Protection monitors suspicious activity occurring at the workload level. However, in some cases, benign activities are flagged as malicious because of particular settings in the user’s environment. When a benign expected activity is triggering a signal, you can suppress the trigger on the activity to limit noise.
このガイドでは、ベストプラクティスのための考察と、シグナル抑制を微調整するためのステップを説明します。
抑制戦略
良性パターンを抑制する前に、検出アクティビティの種類に基づいて、シグナルに共通する特性を特定します。属性の組み合わせが具体的であればあるほど、より正確な抑制が可能になります。
リスクマネジメントの観点からは、より少ない属性に基づく抑制は、実際の悪意あるアクティビティを除外してしまう可能性が高くなります。悪意のある行動を見逃すことなく、効果的な微調整を行うには、一般的な主要属性をアクティビティの種類別に分類した以下のリストを参考にするとよいでしょう。
プロセスアクティビティ
共通キー:
@process.args@process.executable.name@process.group@process.args@process.envs@process.parent.comm@process.parent.args@process.parent.executable.path@process.executable.user@process.ancestors.executable.user@process.ancestors.executable.path@process.ancestors.executable.envs
To determine if a process is legitimate, review its parent process in the process tree. The process ancestry tree traces a process back to its origin, providing context for its execution flow. This helps in understanding the sequence of events leading up to the current process.
通常、親プロセスと不要なプロセスの属性の両方に基づいて抑制すれば十分です。
組み合わせ例:
@process.args@process.executable.group@process.parent.executable.comm@process.parent.executable.args@process.user
広い時間軸で抑制することにした場合、値が変わると抑制が効かなくなるので、一時的な値を引数に持つ処理の使用は避けてください。
例えば、再起動や実行時に特定のプログラムは一時ファイル (/tmp) を使用します。このような値に基づいて抑制を構築しても、同様のアクティビティが検出された場合には有効ではありません。
例えば、コンテナ上の特定のアクティビティからのすべてのシグナルのノイズを完全に抑制したいとします。コンテナをスピンアップするプロセスを開始するプロセスツリー内のフルコマンドを選択します。実行中、プロセスは、コンテナが存在する限り、存在するファイルにアクセスします。対象とする動作がワークロードロジックと結びついている場合、エフェメラルプロセスインスタンスに基づく抑制定義は、他のコンテナ上の同様のアクティビティを調整するのに有効でなくなります。
ファイルアクティビティ
ワークロード、該当ファイル、ファイルにアクセスするプロセスに関する識別情報を反映した属性に基づいて、ファイルアクティビティ関連の抑制を絞り込むことができます。
共通キー:
- ワークロードタグ:
kube_container_namekube_servicehostenv
- プロセス:
@process.args@process.executable.path@process.executable.user@process.group@process.args@process.parent.comm@process.parent.args@process.parent.executable.path@process.user
- ファイル:
@file.path@file.inode@file.mode
シグナルの検査中に実際の悪意のあるアクティビティを判断するには、プロセスがファイルにアクセスし、変更する際のコンテキストが予想通りであるかどうかを検証します。インフラストラクチャー全体でファイルに対する意図的な動作を抑制することを避けるために、上記の共通キーから関連するすべてのコンテキスト情報を収集する組み合わせを常に持つ必要があります。
組み合わせ例:
@process.args@process.executable.path@process.user@file.pathkube_servicehostkube_container_name
ネットワーク DNS ベースのアクティビティ
ネットワークアクティビティモニタリングは、DNS トラフィックをチェックし、サーバーのネットワークを危険にさらす可能性のある不審な行動を検出することを目的としています。特定の IP から DNS サーバーへのクエリをチェックしながら、プライベートネットワーク IP やクラウドネットワーク IP など、既知の IP アドレスからの良性アクセスに対してトリガーをかけることが可能です。
共通キー:
- プロセス:
@process.args@process.executable.group@process.executable.path@process.parent.executable.comm@process.parent.executable.args@process.user
- ネットワーク/DNS 関連:
@dns.question.name@network.destination.ip/port@network.ip/port
ローカルアプリケーションが DNS 名を解決するために接続を行う場合、最初にチェックしたい特性は、DNS クエリと同様にルックアップを開始した IP のリストです。
組み合わせ例:
@network.ip/port@network.destination.ip/port@dns.question.*
カーネルアクティビティ
カーネル関連のシグナルでは、ノイズは通常、ワークロードのロジックや特定のカーネルバージョンに関連する脆弱性から発生します。何を抑制するかを決定する前に、以下の属性を考慮してください。
共通キー:
- プロセス
@process.args@process.executable.group@process.executable.path@process.parent.executable.comm@process.parent.executable.args@process.user
- ファイル
@file.path@file.inode@file.mode
このタイプのアクティビティに対する組み合わせの定義は、ファイルまたはプロセスのアクティビティに似ていますが、攻撃に使用されるシステムコールに関連するいくつかの特異性が追加されています。
例えば、Dirty Pipe の悪用は、特権昇格の脆弱性です。この攻撃を利用してローカルユーザーがシステム上で特権を拡大した場合、重大な事態になるため、ルートユーザーが期待するプロセスを実行することで発生するノイズを抑制することは理にかなっています。
@process.executable.user@process.executable.uid
さらに、一部のマシンでパッチが適用されたカーネルバージョン (例えば、Dirty Pipe 脆弱性のパッチが適用された Linux バージョン 5.16.11、5.15.25、5.10 など) を実行していても、シグナルが作成されることに気づくかもしれません。この場合、組み合わせに host、kube_container_name、kube_service などのワークロードレベルのタグを追加します。ただし、ワークロードレベルの属性やタグを使用する場合、広範囲の候補に適用されるため、検出対象範囲やカバレッジが減少することに注意してください。このような事態を防ぐには、ワークロードレベルのタグとプロセスまたはファイルベースの属性を常に組み合わせて、よりきめ細かい抑制基準を定義する必要があります。
シグナルから抑制を加える
When you are in the process of investigating a potential threat reported by Workload Protection detection rules, you can encounter some signals that alert on known benign behaviors that are specific to your environment.
Java プロセスユーティリティの悪用について考えてみましょう。攻撃者は、Java プロセスを実行するアプリケーションコードの脆弱性を意図的に狙います。この種の攻撃は、独自の Java シェルユーティリティを生成することにより、アプリケーションへの永続的なアクセスを伴います。
In some cases, Workload Protection rules might also detect expected activity, for example from your security team running a pentest session to evaluate the robustness of your applications. In this case, you can evaluate the accuracy of alerts reported and suppress noise.
シグナルの詳細サイドパネルを開き、タブからタブに移動して、コマンドライン引数や環境変数キーなどの主要なプロセスメタデータを含むコンテキストを取得します。コンテナ化されたワークロードの場合、関連するイメージ、ポッド、Kubernetes クラスターなどの情報が含まれます。
抑制条件を定義するには、任意の属性値をクリックし、Never trigger signals for を選択します。
この例では、これらの環境変数の使用に先立って、プロセスの祖先ツリー内で特権をエスカレートさせるアクションが実際に行われたかどうかを評価します。タグは、インフラストラクチャー内のどこでアクションが発生したかを示し、その重大度を低減するのに役立ちます。これらの情報があれば、これらの環境変数を継承しているプロセスに対して、ルールを調整することを決定できます。
ルールの調整を行う場合、シグナルの特定の属性を組み合わせることで、抑制の精度を向上させることができます。通常、抑制効果を高める以下の共通キーを使用するのが最適です。
@process.parent.comm: シグナルを担当したプロセスが呼び出されたときのコンテキスト。このキーは、その実行が予期されたものであるかどうかを評価するのに役立ちます。通常、親プロセスはその実行をコンテキスト化するので、類似の良性動作を調整する良い候補となります。@process.parent.path: 同様に、親プロセスの対応するバイナリパスを追加すると、その場所を指定することで抑制が補完されます。host: 当該ホストが脆弱な環境、例えばステージング環境で動作していない場合、そこからイベントが発生するたびにシグナルがトリガーされるのを抑制することができます。container.id: ワークロードに関連する属性が混在している場合、抑制はより効率的になります。あるコンテナが良質のアクティビティ専用であることが分かっている場合、そのコンテナ名や ID を追加することでノイズを大幅に減らすことができます。@user.id: あるユーザーを既知のメンバーとして識別した場合、そのユーザーに関連するアクティビティを抑制することができます。
さらなる粒度のために、以下の属性は実行チェーンを再構築する際に過去のプロセスに関する情報を提供します。これらはプレフィックス @process.ancestors.* の下で見つけることができます。
ルールエディターから抑制を加える
シグナルは、セキュリティアラート内の関連するコンテキストを表面化させます。イベントデータは抑制フィルターに活用できますが、検出ルールが構築される観測可能性データはより良い調整候補を提供する可能性があります。
In Workload Protection, the runtime Agent logs are generated from collected kernel events. You can preview the logs from the signal side-panel without context switching.
- 選択したシグナルの詳細サイドパネルで、[Events] タブをクリックします。
- View in Log Explorer をクリックして、ログ管理に移動し、このシグナルを発生させるログの完全なリストを表示します。
ログは多数存在するため、シグナルサイドパネルでは、これらのログとその共有属性を JSON 構造にまとめます。
- Go back to the Events tab and scroll to the end of the panel. Expand the JSON dropdown to access all log attributes contained in runtime Agent events.
- シグナルを抑制するキーと値のペアを、
@process.args、@process.group、@process.ancestors.comm、または @process.ancestors.args などの共通のキーで特定することができるようになります。 - ルールエディターでルールを開き、Exclude benign activity with suppression queries (抑制クエリを使用した良性アクティビティを除外する) で 役に立つと特定したキーと値のペアのリストを追加します。
例えば、Java process spawned shell/utility (Java プロセスが生成したシェル/ユーティリティ) というルールがあり、次のような属性の組み合わせで抑制したいとします。
@process.args:+x@process.executable.group:exec@process.ancestors.executable.comm:root@process.ancestors.executable.args:init
This rule will not generate signal if there is match (このルールは、一致がある場合、シグナルを発生させません) にこれらのキー値を入力し、不要なシグナルを抑制します。
一方、正しい属性セットを識別して特定の条件でシグナルを発生させたい場合は、Only generate a signal if there is a match (一致がある場合、シグナルのみを発生させる) の組み合わせを指定します。
