脅威検知のポリシーとルール

本文の内容は、docs.sysdig.com上のThreat Detection Policies and Rules を元に日本語に翻訳・再構成した内容となっております。(2022年6月24日現在)

このページでは、Sysdigの脅威検知ポリシーとそれを構成するルールについて紹介し、お客様の環境でセキュリティポリシーを作成、編集、適用するために必要な概念的背景を提供します。

脅威検知ポリシーの理解する

Sysdig Secureのポリシーは、企業が環境内で検出したい活動に関するルール、ポリシールールに違反した場合に実行すべきアクション、そして潜在的には送信すべき通知に関するルールの組み合わせで構成されています。多くのポリシーがすぐに使える状態で提供され、そのまま使用したり、複製したり、必要に応じて編集したりすることができます。また、定義済みのルールやカスタムルールを使用して、ゼロからポリシーを作成することもできます。

ランタイムポリシーリストを確認する

Policies > Runtime Policies を選択すると、Sysdig Secureにロードしたデフォルトポリシーと、作成したカスタムポリシーが表示されます。

この概要から、以下のことが可能です。

Severity Level: デフォルトのポリシーには、High, Medium, Low、または情報レベルの深刻度が割り当てられており、編集することが可能です。
Enabled/Not Enabled: トグルの位置で表示されます。
Policy Summary: 更新状況、ルールの数、影響を受けるコンテナに対して割り当てられたアクション（停止｜一時停止｜通知）、およびキャプチャーの詳細（ある場合）が含まれます。
ポリシータイプアイコン

アクションを取る

このパネルでは、次のことも可能です：

ポリシーの詳細をドリルダウンする (編集することも可能)
名前、ポリシー名、深刻度レベル、ポリシータイプ、またはキャプチャーが有効かどうかによってポリシーを検索およびフィルタリングする。
トグルによるポリシーの有効化/無効化
+Add Policy ボタンを使用して新しいポリシーを作成する。

ポリシーの種類をレビュー

定期的に種類が追加されます。

ランタイムポリシー

ワークロードポリシー

Falcoエンジンを搭載し、柔軟な条件式を使用してシステムコールをフィルタリングする方法を提供します。詳細については、Sysdig Secure内でFalcoを使用するを参照してください。

リストマッチングポリシー

コンテナ、システムコール、プロセスなどに対して、単純なマッチングまたは非マッチングを使用するポリシーです。詳細については、Understanding List Matching Rulesをご参照ください。

ドリフトポリシー

デフォルトのドリフト検出と防止を提供する単一のルールを持つポリシー。

こちらも参照してください。DriftControlとDrift Policy Typeの追加パラメータを理解する。

機械学習

機械学習を活用して、高度な検出機能を提供するポリシー。

こちらもご覧ください。機械学習について、および機械学習ポリシータイプの追加パラメーターを参照してください。

ログ検知ポリシー

Kubernetes監査ポリシー

Falcoエンジンを搭載し、柔軟な条件式を使用してKuernetes監査ログをフィルタリングする方法を提供します。Kubernetes Audit Loggingも参照。

AWS CloudTrail ポリシー

Falco互換の条件式を使用してAWS CloudTrailイベントをフィルタリングする方法を提供します。AWS CloudTrailイベントを送信するためには、Sysdig Secure for cloudがインストールされている必要があります。

GCP監査ログポリシー

Falco と互換性のある条件式を使用して GCP 監査ログをフィルタリングする方法を提供します。

Azureプラットフォームログポリシー

Falco と互換性のある条件式を使用して Azure プラットフォームログをフィルタリングする方法を提供する。

ポリシーの種類に応じたスコープとアクション

利用可能なスコープとアクションは、タイプによって異なります：

	スコープオプション	アクションオプション
ランタイム
ワークロード	`Custom` `Hosts only` `Container only`	`Stop/ pause/ kill` キャプチャー通知チャンネル
リストマッチング	`Customer` `Hosts only` `Container only`	`Stop/ pause/ kill` キャプチャー通知チャンネル
ドリフト	Custom only	検知通知チャンネル
ログ検知
Kubernetes	`kubernetes.cluster.name` `kubernetes.namespace.name`	通知チャンネル
AWS Cloud	`aws.accountId` `aws.region`	通知チャンネル
GCP	`gcp.projectid` `gcp.location`	通知チャンネル
Azure	`azure.subscriptionId` `azure.tenantId` `azure.location` `azure.resourceGroup`	通知チャンネル

ドリフトコントロールを理解する

ドリフトとは、バージョン管理システムにチェックされた期待される状態とは異なる環境での変化、例えば、本番環境に導入、更新、アップグレードされたソフトウェアのことを指します。

Sysdigのドリフトコントロール機能は、コンテナ起動前にはコンテナイメージに含まれていなかった新しい実行可能ファイルがコンテナ内でダウンロード、更新、変更されたときにシステムを監視するなど、さまざまな検知技術を使用します。

デフォルトのエージェント構成では、ドリフトポリシー/ルールは、このような検知されたプロセスを開始後に停止します。

特定のタスクの開始を確実にブロックする必要がある場合は、エージェント設定ファイルで以下の設定を有効にします。

drift_killer:
        enabled: true

このオプションは ptraceを使用するため、デフォルトのモードよりもリソースを消費することに注意してください。

機械学習ポリシーを理解する

機械学習は、インフラストラクチャーから低レベルのアクティビティを収集し、時間的に集約してアルゴリズムを適用します。

機械学習ポリシーでは、使用する検知とその閾値を設定できます。

検知アルゴリズムは、これらのアクティビティが検知対象（マイナーなど）に関連する確率を推定することで機能します。

Sysdigの機械学習による検出は、単なるプログラム名や実行ファイルのチェックサムの一致に依存するものではありません。その代わり、実際の実行時の動作に基づいています。

脅威検知ルールを理解する

ルールは、セキュリティポリシーを構成するために使用する基本的な構成要素です。ルールは、企業がその環境において検出したいと考えるあらゆるタイプの活動です。

ルールは、2つの形式で表現することができます。

Falcoルール構文：複雑で階層化することができます。Sysdigが提供するデフォルトのルールはすべてFalcoルールであり、ユーザが独自のFalcoルールを作成することもできます。
リストマッチングルール構文：これは、マッチ/ノットマッチ条件が適用される単純なリストです。これらのルールはすべてユーザー定義である。これらは5つのタイプに分類されます。コンテナイメージ、ファイルシステム、ネットワーク、プロセス、およびシスコールです。

ルールライブラリを理解する

ルールライブラリには、ポリシーで参照できるすべての作成されたルールが含まれています。Sysdigの脅威リサーチチーム、Falcoのオープンソースコミュニティのルール、CISやMITRE ATT&CKなどの国際的なセキュリティベンチマークによって開発されたコンテナ固有のルール（および定義済みのポリシー）を含む包括的なランタイムセキュリティライブラリをすぐに利用することが可能です。

監査に適した機能

ルールライブラリのインターフェースでは、

Published By:
Last Updated

を一目で確認でき、トレーサビリティと監査を強化します。

デフォルトのルールは、UI上ではPublished By: Sysdigとして表示されます。

ユーザー定義のルールは、Published By: Secure UIとして表示されます。

ルールはタグによって分類されるため、機能、セキュリティ基準、ターゲットなど、組織にとって意味のあるスキーマでルールをグループ化できます。

さまざまなタグがあらかじめ定義されており、ポリシーを作成または編集する際に、ルールを論理的なグループに整理するのに役立ちます。

検索

上部にある検索ボックスを使用して、ルールの名前またはタグで検索します。

Sysdig Secure内でFalcoを使用する

Falcoとは？

Falcoは、オープンソースの侵入検知およびアクティビティモニタリングのプロジェクトです。Sysdigによって設計されたこのプロジェクトは、Cloud Native Computing Foundationに寄贈され、コミュニティによって継続的に開発・強化されています。Sysdig Secureは、Policy and Complianceモジュールの一部としてFalco Rules Engineを組み込んでいます。

Sysdig Secureのコンテキスト内で、ほとんどのユーザーは、主に自分の環境のためのポリシーに展開されたルールを書いたりカスタマイズしたりすることでFalcoと接することになります。

Falcoのルールは、アラートが生成されるべき条件と、アラートとともに送信されるべき出力文字列から構成されます。

条件

Falcoのルールは、Sysdigのフィルタリング構文を使用しています。
- Falcoのドキュメントの残りの大部分は、独立したツールとしてのインストールと使用について説明しており、ほとんどのSysdig Secureユーザには当てはまらないことに注意してください。
ルール条件は、通常、マクロとリストで構成されています。
- マクロは、ルールや他のマクロの中で再利用できるルール条件のスニペットで、よくあるパターンを因子分解して名前を付ける方法を提供するものです。
- リストは、ルールやマクロ、その他のリストに含めることができる項目のリストです。ルールやマクロとは異なり、これらは Sysdig フィルタリング式として解析することはできません。

舞台裏では、 falco_rules.yaml ファイルは、Falco マクロとリストを含む、環境内のすべての Falco ルールのための生コードを含んでいます。

Falcoルールの仕組み

すべてのFalcoルールは、以下の基本パラメータを含んでいます。

ルール名: デフォルトまたはユーザーが割り当てたもの
条件: ルールを作成するために使用されるフィールドと引数のコマンドラインの集合体
出力
ソース
説明
タグ: 検索と並べ替え用
優先順位

ルールライブラリからルールを選択すると、その基本的な構造を見たり編集したりすることができます。新しいFalcoルールを作成し、それをライブラリに追加する際にも、同じ構造が適用されます。

既存のルール

ルールの作成

注記
k8s_auditをソースとするFalcoルールは、条件を満たすためにKubernetes Auditのロギングを有効にする必要があります。

Falcoマクロについて

ルールライブラリ内の多くのFalcoルールは、その条件コードにFalcoマクロを含んでいます。

あなたは、Falcoマクロのリストを参照したり、マクロの基礎となるコードを調べたり、あなた自身のマクロを作成したりすることができます。デフォルトのFalcoルールセットは、ルールを書き始めるのを容易にするいくつかのマクロを定義しています。これらのマクロは、多くの一般的なシナリオのためのショートカットを提供し、任意のユーザ定義のルールセットで使用することができます。

Falco リストについて

デフォルトの Falco リストは、環境のためのカスタムルールを書く際のユーザーエクスペリエンスを向上させるために追加されます。

例えば、 allow.inbound.source.domains というリストはカスタマイズ可能で、任意のルール内で簡単に参照することができます。

(オンプレミスのみ）ルールインストーラーによるFalcoルールのアップグレード

Sysdig Secure SaaSは、常に最新のFalcoルールセットを使用しています。

Sysdig Secure On-Premのアカウントは、定期的にFalcoルールセットをアップグレードする必要があります。

ルールインストーラ
Rules InstallerのDocker pullコマンドと手順については、Falco Rules On-Premisesのインストールを参照してください。

リストマッチングルールについて

リストマッチングルール（以前は「高速」ルールとして知られていた）は、アイテムのリストに対するマッチング（matchItems=trueのとき）、またはアイテムのリスト以外のすべてのマッチング（matchItems=falseのとき）に使用されます。このルールは、プロセス、ネットワーク接続、およびその他の操作の簡単な検出を提供します。例えば

このプロセスが検出された場合、このルールがポリシーに含まれているときにアクションをトリガする (通知の送信など)。

または

xポート上のネットワーク接続が検出された場合、このルールがポリシーの中にあるときにアクションをトリガする (通知を送信するなど)

Falcoルールとは異なり、リストマッチングルールタイプでは、”y IPアドレスからのxポートでの接続が検出された場合… “などの複雑なルールの組み合わせは許可されません。

5つのリストマッチングルールタイプを以下に説明します。

コンテナルール

これらのルールは、特定のイメージ名が環境内で実行されているかどうかを通知するために使用されます。ルールは、コンテナが起動されたときに評価されます。リスト内の項目はイメージパターン名で、構文は <host.name>:<port>/<name>/<name2>:<tag>@<digest> となっています。

<name2> のみが必須で、それ以外はオプションであり、名前から推測されます。

こちらもご覧ください。マッチングの仕組み：コンテナの例とリストマッチングルールの作成も参照してください。コンテナタイプの例も参照してください。

ファイルシステムのルール

これらのルールは、特定のディレクトリ/ファイルへの書き込みアクティビティがあるかどうかを通知するために使用されます。このルールは、ファイルが開かれたときに評価されます。リストの項目は、パスの接頭辞です。

たとえば /one/two/three は、パス /one/two/three, /one/two/three/four にマッチしますが、/one/two/three-fourにはマッチしないでしょう。

ネットワークルール

これらのルールは、以下の目的で使用されます。

特定のリストにあるポートでインバウンド接続をリッスンしようとする試みを検出する。
一般的に、インバウンドまたはアウトバウンドの接続の試行を識別する。

現在のSysdig UIでは、ネットワーク・ルールによる接続の「許可」または「拒否」について説明していますが、これにはいくつかの混乱が生じる可能性があることに注意してください。

インバウンドとアウトバウンドの両方の接続について。

Allow は何もしないことを意味します。
Deny とは、インバウンドまたはアウトバウンドの接続の試みにマッチすることを意味します。

それでも、このルールをポリシーに追加し、接続が発生したコンテナを停止/一時停止/停止することで、接続の試行に対応するアクションを追加する必要があります。こちらもご参照ください：ポリシーアクションのトリガーを理解する。

プロセスルール

これらのルールは、SSH などの特定のプロセスが、環境の特定の領域で実行されているかどうかを検出するために使用されます。

このルールは、プロセスが起動されたときに評価されます。リストの項目はプロセス名であり、Linux カーネルによって強制される 16 文字の制限に従います。(プロセス名の長さに関する情報も参照してください)。

シスコールのルール

注記
syscall ルールタイプは、ユーザーが作成したポリシーに展開されることはほとんどなく、以下の定義は情報提供のみを目的としています。

これらのルールは、（内部的に）以下の目的で使用されます。

リスト内で特定のシステムコールが発生した場合に通知する
この信頼できるリストの外側のシステムコールが環境で発生した場合に通知する。

このルールは、インバウンド (accept, recvfrom, recvmsg, listen) および/またはアウトバウンド (connect, sendto, sendmsg) 接続を作成するシステムコールで評価されます。リスト内の項目はポート番号です。

マッチングの仕組みコンテナの例

コンテナイメージは、以下の要素で構成されます。

<registry host>:<registry port>/<image>:<tag>@<digest>.

ただし、<image>は<project>/<image>や<project>/<subproject>/<image>のように複数のパスで構成されている場合があります。

完全な例: docker.io:1234/sysdig/agent:1.0@sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709

ここで

<registry host> = docker.io

<registry port> = 1234

<image> = sysdig/agent

<tag> = 1.0

<digest> = sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709

コンテナリストの各項目は、まず、以下のルールで上記の構成要素に分解される。

文字列が / で終わっている場合、それはレジストリホストおよびオプションのレジストリポートとして解釈され、image/tag/digest は提供されません。
それ以外の場合は、イメージとして解釈されます。レジストリホストとポートはイメージの前に書くことができますが、それはオプショナルです。

項目が構成要素に分解されると、それらは画像名の候補に対して前方一致とみなされます。

例を挙げます：

docker.io:1234/sysdig/agent:1.0 @sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709: すべてのコンポーネントに正確に一致しなければなりません。

docker.io:1234/sysdig/agent:1.0: レジストリのホスト、ポート、イメージ、およびタグと、任意のダイジェストで一致する必要があります。

docker.io:1234/sysdig/agent: レジストリのホスト、ポート、およびイメージに、任意のタグまたはダイジェストを付けて一致させる必要があります。

sysdig/agent: イメージと、任意のタグまたはダイジェストで一致する必要があります。イメージはマッチ式にない追加情報を提供するため、イメージ docker.io:1234/sysdig/agent にはマッチしないでしょう。

docker.io:1234/: レジストリのホストとポートにあるすべてのイメージにマッチします。

docker.io/: そのレジストリホストに対するすべてのイメージにマッチします。