【ITニュース解説】Building a Local AI SOC Lab with Wazuh and Qwen: Lessons from a Real Implementation

セキュリティ監視では日々膨大なデータが生成され、多くのアラートが発生する。しかし、ただアラートを集めるだけでは不十分であり、本当に必要なイベントを特定し、何が起こったのかを理解し、証拠に基づいて適切な判断を下すことが、セキュリティ運用における大きな課題となっている。この課題に対し、ローカル環境で動作するAIモデルが、セキュリティアナリストによるアラート調査を支援できるのか、そしてその際にAIにシステムインフラの制御権を与えずに行えるのかという実践的な問いを検証する研究が行われた。

この検証のため、Wazuh、OpenSearch、Python、SQLite、そしてローカルで動作するQwenというAIモデルを用いて、隔離された環境でAI支援型のセキュリティ運用センター（SOC）ラボが構築された。これは手動で操作される概念実証であり、実際の運用環境や自律的なセキュリティプラットフォームではないことに留意が必要だ。

ラボのアーキテクチャは、セキュリティに関するデータを収集するUbuntu 24.04仮想マシン、Wazuhサービスを動かす別のUbuntu 24.04仮想マシン、そしてPythonアシスタントとAIモデルを動かすLM Studioが稼働するWindowsワークステーションで構成された。主要なコンポーネントは次の通りだ。WazuhエージェントはUbuntuのエンドポイントからセキュリティイベントを収集する役割を担う。WazuhマネージャーとOpenSearchインデクサーは、これらのセキュリティアラートを処理し、格納する。Python SOCアシスタントは、格納されたアラートを取得し、分析に適した形に準備する。SQLiteは、処理済みのイベントを追跡し、生成されたレポートを保存する。LM StudioとQwen 3.5 4B Instructは、分析されたデータに基づいて、構造化されたインシデント分析の提案を生成するAIモデルだ。そして、最終的に人間のアナリストがAIの提案をレビューし、次のステップを決定する役割を持つ。

このシステムにおいて、AIアシスタントは制限された閲覧者アカウントを使用しており、インデクサーへのアクセスはSSHポートフォワーディングとTLS検証によって保護されている。最も重要なセキュリティ上の境界は、AIがファイアウォールコマンドの実行、サーバー設定の変更、IPアドレスの自動ブロックといったインフラストラクチャを制御する権限を一切持たないことである。その目的は、自律的な修正ではなく、あくまで調査の支援にとどめられている。

プロジェクトの初期段階で遭遇した問題の一つに「アラートの欠落」があった。最初の実装では最新の20件のアラートしか取得できず、イベントが多数発生する状況では信頼性に欠けた。この問題を解決するため、Pythonクライアントを改良し、OpenSearchのスクロールページネーション機能を用いることで、一致するアラートの制限されたスナップショットを確実に取得できるようにした。あるテストでは、OpenSearchによって報告された152件のアラートがすべて正常に取得され、152件のユニークなイベントIDが確認され、ページネーションロジックの正確性が証明された。しかし、これは継続的な監視や完全な履歴の網羅を証明するものではなかった。また、インデクサーの権限の問題でスクロール処理のクリーンアップが妨げられることもあったが、読み取り専用の権限を適切に修正することで、不要なアクセス権を与えずにワークフローの信頼性を向上させた。

次に、処理済みイベントの追跡方法について改善が行われた。当初、処理済みのイベントIDはJSONファイルで管理されていたが、より信頼性の高いイベントの状態管理、障害からの回復、そしてリトライ動作を実現するためにSQLiteが導入された。既存の20件のイベントIDをSQLiteに移行する検証や、破損したMarkdown形式のレポートをデータベースから復元するテストも成功した。この経験から、AIによる分析はシステムの一部に過ぎず、信頼性の高いイベントの状態管理と回復機能がそれと同じくらい重要であるという教訓が得られた。

ローカルで動作するQwenモデルとの接続は、PythonアシスタントがLM StudioのローカルAPI互換エンドポイントを介して行われた。ワークフローは、選定されたセキュリティイベントをAIモデルに送信し、構造化されたJSON形式の出力を要求する。アプリケーションは、レポートを保存する前に必須フィールドが適切に埋められているか検証する。例えば、SSH認証失敗の模擬イベントをテストした際、Qwenは「Disposition: SUSPICIOUS（疑わしい）」「Severity: LOW（低）」「Recommended action: Investigate and review related logs（調査し、関連ログを確認する）」という提案を返した。これは有用な結果であったが、言語モデルが技術的な文脈を容易に誤解する可能性も浮き彫りになった。例えば、クライアントのソースポートと宛先サービスポートを混同したり、単一のログイン失敗を直ちにブルートフォース攻撃と解釈したりするケースが見られた。このことから、観察された証拠とAIが生成した仮説を明確に区別することが重要であると改めて認識された。

興味深い実験の一つに「セキュリティログにおけるプロンプトインジェクション」のテストがある。これは、信頼できないSSHログメッセージに、モデルを操作して認証失敗を認証成功として扱わせるようなテキストを含ませる試みだった。再テストの結果、モデルは認証失敗という本来の判定を維持した。以前のテストでは、IPアドレスをブロックするという不適切な推奨がAIから提示されたこともあった。このため、ラボの読み取り専用の調査範囲内に応答を留めるよう、保守的な推奨フィルタリングと回帰テストが導入された。これらの実験は限定的なものであり、プロンプトインジェクションに対する完全な耐性や、すべてのAI生成の推奨が安全であることを保証するものではない。セキュリティログはあくまで「証拠」であり、「指示」ではないため、人間のレビューが不可欠であることが示唆された。

このプロジェクトでは、単に動作する画面ショットを示す以上の検証に力が入れられた。リポジトリには31のモックテストとオフラインPythonテストが含まれており、これらはPython 3.10および3.12環境でGitHub Actionsを通じて実行される。実装には、イベントIDの検証、永続的な処理状態の確認、構造化されたモデル応答の検証、そして読み取り専用の運用境界の確認も含まれている。しかし、自動テストだけでは、本番環境におけるセキュリティや検出精度を証明するものではない。このラボには、手動実行であること、継続的なアラート監視がないこと、ローカルモデルサービスに関するネットワーク制限があることなど、まだ重要な制約があり、より広範な展開の前にさらなる検証が必要である。

このプロジェクトを通じて、三つの重要な教訓が得られた。第一に、信頼性の高いデータ取得はAI分析よりも優先されるということだ。アラートが欠落していては、どんなに優れたインシデントレポートもその価値を損なう。第二に、ローカルAIはセキュリティ調査を支援できるが、その出力は必ず検証されなければならないということだ。構造化された応答だからといって、必ずしもそれが正しい応答であるとは限らない。第三に、自動化には明確なセキュリティ境界が必要だということだ。潜在的に有害な行動を承認なしで実行するシステムよりも、アナリストがイベントを理解するのを助けるシステムの方が望ましいという姿勢が示されている。

今後の課題としては、より現実的なアラートのリプレイテスト、パフォーマンス測定の改善、そしてローカルモデルに対するネットワーク制限のさらなる強化が挙げられている。