ブログ

HOME Developer Square ブログ【SCSK技術者によるブログ】生成AIで過検知対策を効率化！Sysdig Sageの実力検証

2025

06月

20日

Falco SCSK技術者ブログ Sysdig Sage Sysdig Secure コンテナ・セキュリティ

【SCSK技術者によるブログ】生成AIで過検知対策を効率化！Sysdig Sageの実力検証

皆さん、こんにちは！SCSK技術者によるSysdigブログ、第26回は鳥飼が担当します。

今回は、Sysdigに搭載されている生成AI機能「Sysdig Sage」を使って、セキュリティ運用における悩みの種である「過検知」への対応をどれだけ効率化できるのか、実際に検証してみました。

Sysdig Sageに関する過去の記事もぜひご覧ください。

【SCSK技術者によるブログ】～Falco初学者に送る～

Sysdig SageでFalcoを勉強してみよう①②
https://www.scsk.jp/sp/sysdig/blog/scsk/scskfalco_sysdig_sagefalco.html
https://www.scsk.jp/sp/sysdig/blog/scsk/scskfalco_sysdig_sagefalco_1.html

※本記事における注意事項

検証結果は環境によって異なる場合があります。
AIによる分析結果はあくまで参考情報として活用し、最終的な判断は必ず人が行うようにしてください。

ふるまい検知と過検知

近年、マルウェアの高度化・巧妙化が進み、従来のパターンマッチング方式では対応しきれない脅威が増加しています。そこで注目されているのが、「ふるまい検知」です。

ふるまい検知とは、アプリケーションの不審な挙動を検知してマルウェアによる被害を防ぐセキュリティ対策です。Sysdig Secureでは、Falcoというツールを用いてシステムコールのふるまいを監視しています。
従来のパターンマッチング方式では、既知のマルウェアしか検知できませんでしたが、ふるまい検知は挙動に着目するため、未知のマルウェアも検知できるというメリットがあります。

しかし、挙動に着目する性質上、正常な動作を誤って検知してしまう「過検知」が発生しやすいという課題もあります。過検知が多発すると、アラート疲れを引き起こし、本当に対応すべきアラートが見過ごされるリスクも高まります。

そのため、過検知が発生した場合は、そのふるまいを検知対象から除外する設定(例外設定)を行う必要があります。しかし、Sysdig（Falco）のルールに精通していない場合、例外設定はハードルが高く感じられるかもしれません。

Sysdig Sageで過検知対応を効率化

そこで今回は、Sysdig Sageに過検知の対応を依頼し、その実力を検証します。

通常、過検知が発生した場合は、イベントの詳細を確認し、発生理由や過検知であるかの判断を行う必要があります。今回は、検証のために意図的にイベントを発生させ、Sysdig Sageにその理由や過検知であるかの判断を依頼します。

いざ検証！

httpdコンテナを起動し、シェルに侵入します。
/var/log/dpkg.logを削除し、「Clear Log Activities」ルールを検知させます。
Sysdig Sageに「この検知イベントは誤検知である可能性は高いですか？低いですか？」と質問します。

Sysdig Sageからは、初期評価の結果に加えて、以下のような回答が返ってきました。

これは、状況を的確にとらえた妥当な回答と言えるでしょう。

次に、担当者に確認した結果、今回は意図的な操作による過検知であったと仮定し、Sysdig Sageに例外設定(検知除外設定)を依頼します。

Sysdig Sageに「このイベントは意図する操作の結果、発生したものでした。Rules Editorにて検知除外とするException記述を教えてください。」と質問します。

すると、Sysdig SageからException記述が提示されました。

exceptions: 
-	Syscalls:
  #'rm'コマンドが特定のログファイルを削除する場合を例外とする
condition: >
  proc.name = rm and fd.name= /var/log/dpkg.log
# 特定のコンテナに対して例外を指定する場合
   -condition: container.name = httpd
   # 特定のユーザに対して例外を指定する場合
-condition: user.name = root

しかし、Falcoルールに詳しい方ならお気づきかもしれませんが、この記述はexceptionの形式に則っておらず、そのままでは機能しません。

そこで、既存のexception記述を例として示し、修正を依頼してみます。

すると、下記のように修正された記述が返ってきました。

exceptions: 
-	name: maintenance_rm_commands
fields: [ user.name, proc.pname, proc.name, proc.cmdline ]
comps: [ =, =, =, contains]
values:
  - - root
   - bash
   - rm
   - dpkg.log

かなりよさそうです！
この記述に、ルール名と、上書きの設定を追加し、Rules Editorに保存してみましょう。