本文の内容は、2023年3月22にBIAGIO DIPALMA が投稿したブログ（https://sysdig.com/blog/guidelines-reduce-noise-falco-rules）を元に日本語に翻訳・再構成した内容となっております。
ルールのチューニングは、セキュリティ態勢を定義する際の最も重要なステップの1つです。検知ルールの場合、「1つですべて解決する」アプローチは不可能です。お客様にはそれぞれ固有の環境があり、その特性やビジネスニーズがあります。そのため、新しいルールがリリースされたら、検出の背景にあるセキュリティのユースケースを理解し、偽陽性（FP）を可能な限り減らすことが極めて重要です。
脅威調査チームは、ノイズが発生していないか常にチェックしています：
- 異なるお客様で同じ偽陽性が発生した場合、ルールセットに例外が作成されます。
- ノイズはお客様の環境と密接に関係しているため、ローカルでチューニングを行う必要があります。
マネージドSysdig OOTBルール
アウトオブボックス（OOTB）のSysdig Secureルールセットは、マネージドポリシーに依存しています。ポリシーは、異なるスコープ（システムコール、AWS、GPC、Azureに関するルール）、異なる重大度、冗長性を持つルールのグループで、新しいルール、検出の改善、またはチューニングによって定期的に更新されます。
実際に脅威に関連し、十分に調整されたルールを持つポリシーは、デフォルトで有効な状態で提供されますが、疑わしいイベントを検出するルールを持つ他のポリシーには、デフォルトで無効になっているものがあります。お客様は、デフォルトで無効になっているポリシーのうち、どのポリシーを有効にするかを選択すれば、問題なく利用できます。
注意：ルールの更新は自動的に適用されます。お客様は、アラートを確認し、最終的に不審なことが起こった場合に調査すればよいことになります。
アラートの受信件数が増える原因として、ルールの検出方法の変更や環境の変化が考えられますので、悪意のある事象がノイズに隠れないよう、定期的にルールチューニングを行うことが重要です。
例外事象の解析
Sysdig Secureでは、特定のルールから発生するノイズを、例外を利用することで低減することが可能です。このFalcoルールを考えてみましょう：
rule: Write below etc
desc: This rule detects writing operations under the /etc folder
condition: open_write and fd.name startswith “/etc/”
exceptions:
output: Write below etc detected
priority: WARNING
tags: []
このルールは、etc.フォルダの下にあるファイルへの書き込みの試みをすべて検出します。これは、攻撃者が悪用中にいくつかの設定を編集しようとしたり、新しいサービスを追加しようとしたりする可能性があるため、疑わしいものです。
このルールが有効化されると、nginxサービスが独自の設定を書き込むことで大量のアラートが発生するとします。このイベント自体は悪意があるものではなく、誤検出であることは間違いありません。
これは、例外が必要な典型的な状況です。正しい処理を行うためには、例外は以下のフィールドを持つ必要があります：
- Name: このフィールドは、例外を識別するものです。
- Fields: 関与するフィールド。
- Comps: 使用される演算子。各フィールドに対して演算子があるので、フィールドの数と演算子の数は等しくなければなりません。この2つのエンティティの関連付けは位置関係なので、例えば、最初のフィールドは最初のcomp 値と一緒になります。
- Values: ここには、ホワイトリストされた値のリストが入りますが、これも位置的な関連付けです。
ここでは、動作する例外の例を示します：
name: proc_name_folder
fields: [proc.name, fd.name]
comps: [“=”, startswith]
values:
- [“nginx”, “/etc/nginx”]
- [“nginx-runner”, “/etc/nginx”]
以下のように訳すことができます：
(proc.name=”nginx” and fd.name startswith “/etc/nginx”)
or
(proc.name=”nginx-runner” and fd.name startswith “/etc/nginx”)
このコードは、ルールの “exception” フィールドに追加され、この種のイベントでアラートが発生しなくなることを確認することができます。
より良い例外のための秘密
価値ある例外を記述するために従うべきベストプラクティスのリストがあります。例外は汎用的である必要があり（同じ例外が異なるタイプのノイズのホワイトリストに使用できる）、広すぎない必要があります（例外が汎用的すぎると、悪意のあるイベントの可視性が失われる可能性があります）。
ここでは、有用なヒントのリストを紹介します：
- 少なくとも2つのフィールドを使用する： これは、例外を正確にし、広範なホワイトリストを避けることができます。
- 一般的に使用されるフィールドは、proc.name、proc.pname、proc.cmdline、proc.pcmdline、proc.aname（このフィールドはプロセスのすべての祖先にマッチします）、fd.name、コンテナイメージのリポジトリ。
- 値が頻繁に変わる可能性のあるフィールド（container.id、container.name、hostNameなど）は使用しないでください。
- in、endswith、startswithの3つの演算子を使用します。
- contains演算子は、必要な場合のみ使用する： これは広範であり、一般的にはstartswithまたはendswithで置き換えることができます。
- “in” を “=” の代わりに使う： “in” 演算子を使うと、例外の中でリストを使うことができ、似たような例外の大きな集合を避けることができます。以下はその例です：
name: proc_name_folder
fields: [proc.name, fd.name]
comps: [“=”, startswith]
values:
- [“nginx”, “/etc/nginx”]
- [“nginx-runner”, “/etc/nginx”]
- [“nginx-server”, “/etc/nginx”
これは、以下のように簡単に置き換えることができます：
name: proc_name_folder
fields: [proc.name, fd.name]
comps: [in, startswith]
values:
- [[“nginx”, “nginx-runner”, “nginx-server”], “/etc/nginx”]
- 特にクラウドプロバイダーのレジストリでホストされているイメージの場合、container.image.repositoryフィールドにendswithオペレータを使用します。このフィールドの最初のセクションは、頻繁に変更される可能性があります。AWS Elastic Container Registryを考えてみましょう。イメージは
“aws_account_id.dkr.ecr.region.amazonaws.com/my-repository.”のように名付けられます。このaccount_idやregionは変わる可能性があるので、文字列の最後の部分を使ってイメージをホワイトリスト化するのがよいでしょう。私たちは、次のようにします：
name: container_image_repo
fields: [container.image.repository]
comps: [endswith]
values:
- [“amazonaws.com/my-image”]
- “glob” 演算子は慎重に使用してください： この演算子を使用すると、パス上で望ましくないマッチが発生する可能性があります。
例外として利用可能なフィールドの完全なリストは、公式ドキュメントに記載されています。同じように、演算子のリストも見ることができます。
チューナーを使用して Sysdig Secure のノイズを処理する
Sysdig Secureには、既存の例外にカスタム値を簡単に追加してFPを削減するためのツール、「Tuner」があります。
このツールは、自動的に動作するように設定することも、カスタム例外の作成、検証、適用に使用することも可能です。すべての例外は、”Policy “メニューから “Runtime Policy Tuning “ボタンをクリックすることで利用できるチューナーファイルに追加されることになります。このファイルはエディターで開いて、更新することができます。
手動チューニング
手動チューニングは、チューナーツールを使用することで簡単に行うことができます。このツールはイベントを調べ、ノイズが既存の例外の1つで対処できる場合、解決策を提供します。次の例は、そのツールを示しています：
Sysdig Secure Tunerツール
最適なオプションを選択し、 “Apply tuner Exceptions” をクリックするだけで、例外が適用されます。異なるオプションを選択し、一度に複数の例外を追加することも可能です。
提案された例外がうまく適合しないことがあります。範囲が広すぎたり、安全な方法でノイズに対処できなかったり、極端に具体的だったりすることがあります。このような場合、お客様は独自の例外を追加することができます。
この例外がすでにルールに定義されているとします：
rule: Write below etc
exceptions:
- name: proc_name_pname_fd_name
fields: [proc.name, proc.pname, fd.name]
comps: [“=”, contains, endswith]
チューナーファイルを編集して、以下のように追加するだけです：
rule: name of the rule that needs tuning
exceptions:
- name: proc_name_pname_fd_name
values:
- [value1, value2, value3]
append: true
appendフィールドは重要です。これは、例外が既存のルールに追加されることを確認するために使用されます。appendフィールドがfalseの場合、ルール全体が上書きされることになります。
例を示してみましょう：
rule: Write below etc
exceptions:
- name: proc_name_proc_pname_proc.cmdline
fields: [proc.name, proc.pname, container.image.repository]
comps: [“=”, contains, endswith]
values:
- [“nginx”, nginx, “/etc/nginx”]
append: true
この例外では、nginxプロセスによってトリガーされ、nginxプロセスの1つによって呼び出され、/etc/nginxフォルダの下に書かれたアラートが表示されることはありません。
自動チューニング
自動チューナーは、あるルールに対して見られるアラートの量を減らすために、利用可能な例外を使用して、ノイズを処理するために最適な例外を適用します。自動チューナーは、広範な例外を避けるために、少なくとも2つのフィールドを持つ例外のみを適用します。
このツールは、 “Runtime Policy Tuning” ページで、ハイライトされたトグルをクリックすることで有効にできます。
独自の例外を定義する
定義された例外がノイズとうまく適合していない可能性もあるし、誤検知に適切に対処するために、演算子とフィールドの新しい組み合わせが必要な場合もあります。
注意：これはSecureで簡単に行うことができますが、Policies > Rules > Rules Editorにあるカスタムルールファイルを編集する必要があります。
このファイルは、新しいルールやカスタム例外を定義するために使用することができます。新しい例外を選ぶ場合は、ここにallowを書く必要があります。これらは基本的に Falco の例外なので、name、field、value、およびcompを定義し、前に見たように append フィールドを true として設定したものを使用する必要があります。
Sysdig Secureルールテキストエディタ
まとめ
ルールのライフサイクルの中で、チューニングのステップは重要です。これは、新しいルールが定義されたときだけに行われるわけではありません。むしろ、ネットワーク内のエンティティ（ソフトウェア、サービス、オペレーティング・システム、インフラストラクチャー・コンポーネント）は変化する傾向があるため、継続的なプロセスに近いと言えます。変化が起きたり、新しい検出方法が導入されたりするたびに、ルールセットを更新する必要があります。
チューニングの段階は、可視性を向上させるために非常に重要です。無駄なイベントを削除すれば、疑わしいイベントや悪意のあるイベントだけを見ることができるようになります。しかし、例外には気をつけなければなりません。広範なホワイトリストは、本当の悪意のある活動を隠してしまう可能性があります。一方、特定の例外は、問題解決に必要な労力を増大させるノイズに対する一時的または部分的な解決策にしかならないことがあります。