カスタム検出ポリシーの作成

Sophos Linux Sensor (SLS) ポリシーはイチから作成できるため、エキスパートユーザーは、ニーズに合わせて自由にポリシーを作成することが可能です。

はじめに

SLS コンテンツパッケージは、デフォルト設定のすべての検出を含む単一のコンテンツファイル /var/lib/sophos/content/runtimedetections-content.yaml にインストールされます。コンテンツパッケージを更新すると上書きされるため、このファイルの内容を変更することはお勧めしません。

/etc/sophos/runtimedetections-rules.yaml 設定ファイルを作成および編集することで、カスタム検出とリストを作成できます。コンテンツパッケージが更新されると、/var/lib/Sophos/content/runtimedetections-content.yaml は上書きされますが、/etc/Sophos/runtimedetections-rules.yaml は上書きされません。これにより、お客様の環境用に作成したカスタム検出コンテンツが保持されます。

センサーが起動し、パッケージされたコンテンツを読み取り、該当する場合、上書きを行います。センサーは、runtimedetections-content.yaml と runtimedetections.yaml のマージの「参照」コピーを次の場所に書き込みます: /var/run/sophos/cache_analytics.yaml. このキャッシュ yaml ファイルはマージの結果を示し、デバッグや監査用に検査または保存できます。

ポリシールールの設定

まず、設定するポリシーの種類を選択します。ポリシーを警告のカテゴリや MITRE ATT&CK カテゴリ別に検討して、攻撃ライフサイクルのどの時点でどのような動作を監視するかを決定することを推奨します。

ルールのアクション

ポリシーの種類を選択したら、次に default match と default ignore のどちらを使用するかを決定します。カスタムルールを追加する前に、デフォルトのアクションを指定する必要があります。

カスタムルールは、match または ignore キーワードではじまり、その後にイベントフィールドと組み合わせた述部が続きます。ポリシーには、任意の数の match ルールや ignore ルールを設定できます。ポリシーに複数のルールがある場合、SLS はリストの先頭から順にルールを評価します。

イベントフィールド

各ポリシーには、コンテナ、イメージ、プログラム、ポート、ファイル、ユーザー、グループなどに関するメタデータを含む、独自の有効なイベントフィールドのセットがあります。ポリシーにあるさまざまな有効なイベントフィールドのなかから、どのイベントフィールドを含めるかを決定する際、まず基本的な「既知の正常」リソースや「既知の悪意のある」リソースからはじめて、徐々に設定に関する理解を深めていくことを推奨します。

たとえば、開発者が作業の一部として、対話型シェル ssh を頻繁に生成することがわかっている場合は、parentProgramName == "ssh" イベントフィールドに対して ignore アクションを指定して、開発者の正規の操作によって警告が生成されないようにしてください。

例

ここでは、Program Execution Policy の設定を順を追って説明して、ルールの作成方法を実際に確認します。まず、次のポリシーの設定から開始します。この設定によって、プログラムが実行されると警告が発生します。

Program Execution Policy Example:
  policy: program
  enabled: true
  alertMessage: Unauthorized Program Executed
  comments: Example using the program policy
  priority: High
  rules:
    -   default match

ファイルパスに関係なく、test.sh という名前のプログラムに関する警告のみを受信する場合を想定します。その場合は、ルールを変更して、programName を test.sh で絞り込み、そのフィルタに一致しないプログラムはすべて無視されるようにします。

rules:
    -   match programName == "test.sh"
    -   default ignore

次に、警告を制限して、test.sh が /tmp/ ディレクトリから実行されたときのみに警告が生成されるようにする場合を想定します。その場合は、ルールを変更して、このパスも含まれるようにします。

rules:
    -   match programName == "/tmp/test.sh"
    -   default ignore

次に、引数「malicious」を含む実行についても警告を表示することにします (巧妙でない攻撃の場合)。programArguments イベントフィールドを使用して、malicious を含む引数があるかどうかを確認するよう指定できます。

rules:
    -   match programArguments == "* *malicious*"
    -   match programName == "/tmp/test.sh"
    -   default ignore

最後に、bash シェルからの実行も無視することにします。これは、作業環境に正当な bash シェルの使用があることがわかっている場合などが想定されます。parentProgramName イベントフィールドで bash を指定して、ignore ルールを作成できます。

rules:
    -   ignore parentProgramName == "bash"
    -   match programArguments == "* *malicious*"
    -   match programName == "/tmp/test.sh" and programArguments == "/tmp/test.sh arg1 arg2"
    -   default ignore

ルールは、リストの先頭から、厳密に表示されている順に評価されます。ls malicious を bash シェル内で実行しても、警告は生成されません。ただし、最初の 2つのルールの順序を入れ替えた場合、bash シェル内から ls malicious を実行すると、ignore bash ルールが適用される前に programArguments ルールに一致するため、警告が生成されます。

リスト

リストの詳細は、詳細トピック: リストを参照してください。

警告

警告テンプレートを使用して、各ポリシーで生成された警告を設定し、特定の情報またはカスタム情報を含めることができます。プロセスが確立されているチームの場合、警告をカスタマイズすることで、トリアージと調査に必要な的確なデータを取得できます。詳細は、警告設定テンプレートを参照してください。

自動対応

警告発生時に、自動応答が行われるように各ポリシーを設定できます。有効な自動応答アクションには、プロセスの停止、プロセスの強制終了、コンテナの強制終了、ファイルの隔離、ファイルの削除などがあります。詳細は、自動対応の作業の開始を参照してください。

警告のバッチ処理

警告が過剰に表示されることを防ぐには、ポリシーレベルで警告のバッチ処理をオンにして、特定の期間内にポリシーが生成する警告の数を制限できます。ポリシーでは、警告のバッチ処理の許容範囲と期間を指定できます。また、その期間内に同ポリシーによって送信される警告の数は、指定された許容範囲を超えません。期間が終了すると、ポリシーは、抑制されたすべての警告を要約するバッチ警告を 1つ生成します。

ここで、先ほどのプログラムポリシーの例に戻ります。導入後、/tmp/test.sh arg1 arg2 を連続して何回も実行するツールがあることがわかったとします。結果として、警告が過剰に表示されます。このような警告をバッチ処理してグループ化すれば、生成される警告の数を減らすことができます。以下の警告のバッチ処理の設定を参照してください。

alertBatching:
  enabled: true
  tolerance: 1
  duration: 10s

これによって、 警告が 1つ生成されるとすぐに警告のバッチ処理がオンになり、10秒間の枠で一致する警告すべてがバッチ処理されます。上記の例を Program Execution Policy の例に追加し、10秒間内に /tmp/test.sh スクリプトを 20回実行すると、次の 2つの警告が表示されます。

• 最初に一致するとすぐに警告が 1つ表示されます。
• 10秒間の枠の終了後、2つ目の警告が表示されます。これは、同じ警告がその期間内にさらに 19回発生したことを示します。