侵入検知システムは、既知のシグネチャにほぼ全面的に依存する方式から、従来のマッチング、機械学習、エージェント型調査を組み合わせるハイブリッドアーキテクチャへと移行している。Stack Overflowのブログに掲載された分析では、SnortMLはSnort 3内部の低レベルのセンシング層を構成し、エージェント型AIはイベントを時間やソースをまたいで関連付け、調査における次の手順を決定するとされている。
従来のシグネチャの問題は、それが不正確であることではなく、検知するよう設計された対象に対して正確であることにある。CVE-2024-12345のような特定の脆弱性向けのカスタムルールは、誤検知率を極めて低く抑えながら既知のエクスプロイトを捕捉できる可能性があるが、同じ脆弱なコードパスを通過するよう変更されたペイロードには反応しない可能性がある。新たなエクスプロイトが実環境で出現してから、それを分析し、ルールを作成し、テストして配布するまでには数日から数週間かかる場合があり、脆弱性が実際に悪用されている状況では危険な空白となる。
Snort 3内でSnortMLはどのように動作するのか？
Cisco Talosは2024年3月、SnortMLエンジンをSnort 3内でネイティブに動作する機械学習検知エンジンとして発表した。このエンジンは外部のクラウドサービスに依存せず、ルール評価に使用されるものと同じ処理パス内でローカルに推論を実行し、1ミリ秒未満で結果を返す。
実装は、起動時に事前学習済みのTensorFlowモデルを読み込むsnort_ml_engineモジュールと、パブリッシュ・サブスクライブインターフェースを介してSnort 3の既存サービスインスペクターからデータを受け取るsnort_mlインスペクターで構成される。HTTPインスペクターがリクエストの解析を終えると、クエリ文字列とPOSTコンテンツをイベントバスへ送り、SnortMLがそれらを分類して、エクスプロイトの試行を含む可能性を示す確率値を返す。
モデルは、まずバイト値をベクトル表現に変換する埋め込み層を備えたLSTMネットワークに基づいている。これによりバイト間の関係とコンテキストを捉えた上で、LSTMがその順序と系列を処理する。最終的な全結合層は結果を単一の確率値に縮約する。SnortMLに付属するLibMLは、行列演算を高速化するためにXNNPACKライブラリを使用する。記事によれば、AMD 4.7GHzプロセッサー上での1回の分類処理にかかる時間は約350マイクロ秒である。
Secure Firewall 10.0.0以降では、SnortMLは256、512、1024バイトの長さに適したモデルを自動的に選択する。1024バイトを超えるリクエストは、分類前にこの長さで切り詰められる。初期リリースではSQLインジェクションの検知から始まり、2025年末までにXSSとコマンドインジェクションを含むよう対象範囲が拡大した。モデルの更新は、ルールコンテンツの配布に使用されるものと同じLightweight Security Packageシステムを通じて提供される。
ハイブリッド方式の強みと限界
SnortMLはシグネチャマッチングと並行して動作し、シグネチャに取って代わるものではない。モデルは既知のカテゴリに属する攻撃の新たな亜種を捕捉できる一方、従来のシグネチャは確定したパターンに対する低ノイズの防御線を提供する。両方の経路が同じペイロードに対してアラートを発した場合、機械学習だけから発せられたアラートよりも強いシグナルと見なすことができる。ただし、それぞれの仕組みは異なるエラー特性を持つ。
しかしSnortMLは、URIのクエリ文字列やPOSTコンテンツなど、単一のHTTPパラメーターを分析するだけであり、そのリクエストの前後に何が起きたか、また送信元アドレスが過去数分間に何を行ったかを把握していない。そのため、偵察、列挙、カスタムエクスプロイトという一連の流れが、個々の手順では検知しきい値を超えずに通過する可能性がある。また、現在のモデルはDNSトンネリング、TLS層の攻撃、SMBエクスプロイト、HTTP以外のプロトコルにおける異常な挙動を認識できない。利用可能なモデルがHTTPインスペクターのデータパスに結び付けられているためである。
約350マイクロ秒の処理時間も、XNNPACKによって限定的かつ予測可能になっているとはいえ、実際のコストを伴う。したがって、モデルの性能は、ルールセットの規模、プロトコルの複雑さ、セキュリティアプライアンスの処理予算から切り離して捉えるべきではない。
エージェント型AIは何を追加するのか？
分析では、目の前にあるものだけを評価する機械学習モデル、固定された手順に従うSOARプレイブック、過去の結果に基づいて次に何を調査すべきかを決定する、多段階の調査状態を保持するエージェントを区別している。提示された構想によれば、エージェントはSIEMに関連イベントを問い合わせ、脅威インテリジェンスプラットフォームでファイルフィンガープリントを調査し、アイデンティティープロバイダーからユーザーの活動を取得してから、対応を推奨する、または人間のアナリストへ引き継ぐ前にコンテキストを統合できる。
記事は、IBMが2025年4月にATOM（Autonomous Threat Operations Machine）を、Trend Microが2025年8月にAgentic SIEMを発表したことを指摘している。これらのシステムは、セキュリティ情報を付加した単なるチャットインターフェースではなく、複数のエージェントによるオーケストレーションおよび調査プラットフォームとして提示されている。分析は、これらの普及を人材不足の圧力と結び付けている。世界全体で約400万件のサイバーセキュリティ職が空席となっていることに加え、2025年の調査では、セキュリティオペレーションセンターのアナリストの82%が、アラート量の多さによって実際の脅威を見逃すことを懸念していると報告された。
このアーキテクチャでは、Snort 3とSnortMLはネットワークに近いセンサーとなり、実際に観測された内容を上位の推論層へ提供する。しかし自動化のレベルが高まるほど、センサーの精度は重要になる。誤検知はアナリストの時間を消費するだけでなく、エージェントのリソースを消費し、設定の不十分な環境では封じ込め措置を開始する可能性がある。また、SnortMLの確率的な結果を利用して複合信頼度を構築することもできる。従来のシグネチャとMLスコア0.97を組み合わせたアラートは、ML単独でスコア0.61を示したアラートとは異なる方法で扱うべきである。
統合アーキテクチャとフィードバックループの問題
記事は、DAQを介したパケットキャプチャ層から始まるアーキテクチャを提案している。スループット要件に応じてAFPacket RSSまたはDPDKを使用し、その次の検知層ではMPSE HyperscanエンジンとSnortMLを並行して実行する。両方の層は、アラート、確率スコア、フローデータを含むJSON形式のイベントを統合メトリクスバスへ送信する。
その後、タスクは専門エージェントに分散される。すなわち、トリアージ、重複排除、リスク評価を行うエージェント、脅威インテリジェンスのエンリッチメントを行うエージェント群、SIEM、アイデンティティープロバイダー、エンドポイントデータのログを関連付ける調査エージェント、活動を過去のパターンや既知のキャンペーンと比較するコンテキストエージェントである。この構想は、調査結果が確定した場合、その結果を対応段階で止めるのではなく、モデルエンジンとルールエンジンへ戻す必要性を強調している。
攻撃であることが確認されたにもかかわらず、低いスコアを得た、またはシグネチャに一致しなかったペイロードは、訓練データや新たなルール作成の入力へと変換できる。ただし、この経路には人間による検証と、訓練データの汚染を検知する仕組みが必要である。攻撃者が自動調査の結果を操作し、再訓練プロセスに汚染されたサンプルを混入させようとする可能性があるためだ。
展開上の制約と実践的な推奨事項
分析は、SnortMLの現在の対象範囲がHTTPパラメーターに限られていること、エージェント間のオーケストレーションプロトコルが未成熟であること、モデルのアラートの説明可能性が低いことなど、その他のギャップも指摘している。現在の出力には、確率スコアとアラートの原因となったペイロードが表示されるが、入力のどのバイトや領域が結果に影響したのかは説明されない。また記事によれば、難読化、エンコード、空白の操作、SQLコメントインジェクションに対するモデルの堅牢性は、公開された評価で公には説明されていない。
実際のところ、この記事ではSnortMLを監視ポート上で、ブロッキングを伴うインラインではなく、アラートのみのモードで稼働させ始めることを推奨しています。通常の業務サイクルをカバーする少なくとも2週間、既知のアプリケーションのトラフィックに対する誤検知を測定し、その後、選択的なインライン展開を有効にする前にしきい値を調整する必要があります。また、MLスコアは、従来のシグネチャの代替や、単独でブロッキングを発動するトリガーではなく、複合的な信頼度計算における要素として扱うべきです。
IPアドレスのブロッキング、デバイスの隔離、認証情報のリセットなど、影響の大きい封じ込め措置については、人によるレビューのループ内にとどめるべきです。この分析の主な結論は、自動化によってトリアージ、情報付加、関連付け、コンテキストの大規模な集約を担わせることは可能である一方、最終的な対応の判断は、エージェントが収集したコンテキストに基づいて人間が確認する方が、より安全であるということです。