メインコンテンツまでスキップ

10月中旬のFortinetアドバイザリー集中公開：SIEMキューが膨らむ理由

· 約8分
James Yip
James Yip
Managing Director

2026年10月中旬、Fortinet PSIRTはFortiOS、FortiSIEM、FortiSandbox、FortiManager、FortiAnalyzer、FortiMailなど複数製品に関するセキュリティアドバイザリーを相次いで公開しました。この一連の公開で広く注目された項目の一つが、FG-IR-26-181 / CVE-2026-106174です。FortiOSの不適切なロック処理により、影響を受ける8.0.0および7.6.4～7.6.6のビルドで、未認証のネットワーク攻撃者がHTTPS管理GUIをサービス拒否状態にできる可能性があります。

すでにSIEMを運用しているセキュリティチームにとって、注目すべきなのは個々のCVEだけではありません。大手ベンダーが短期間に大量のアドバイザリーを公開したとき、運用キューに何が起きるかです。

Fortinetのアドバイザリーに伴うアラートが、優先順位の付いた少数のSIEMキューへ整理されていく様子

10月中旬の一斉公開で何が起きたか（ベンダー公式情報のみ）​

2026年10月13日前後、Fortinet PSIRTは同じ日に複数の新規または更新アドバイザリーを掲載しました。FG-IR-26-181のほか、公開インデックスには次のような項目が含まれていました。

  • FG-IR-26-180 / CVE-2026-106173 — FortiSIEMの重大なパストラバーサルの問題（影響を受ける7.5.0で未認証のコード／コマンド実行が可能。アドバイザリーによるとFortiSIEM Cloudは影響を受けません）。
  • FG-IR-26-182 / CVE-2026-106175 — FortiOS、FortiProxy、FortiSwitchのCLI経路におけるダブルフリー（ローカル認証済みユーザーによるサービス拒否）。
  • FG-IR-26-183 / CVE-2026-106176 — FortiSIEM GUIの認可不備。
  • FG-IR-26-179 / CVE-2026-106172 — FortiSandboxおよびFortiSandbox CloudのFabric API認証バイパスに関する問題。
  • そのほか、FortiSandbox GUIのセッション問題、FortiAnalyzer／FortiManagerのSQLインジェクション経路、FortiMailの問題、FortiManagerのコマンドインジェクション修正など、同日に掲載された項目もありました。すべてPSIRTアドバイザリーのインデックスに掲載されています。

その後、重大なサードパーティ製PHPコアのRCEに関するパッケージングアドバイザリー（FG-IR-26-186、10月21日頃に公開）も加わり、翌週まで同じ状況が続きました。確認すべきCVE、照合すべきバージョン一覧、「自社は影響を受けるか」という問い合わせが増えていきます。

これは、読者の環境でFortiGateやFortiSIEMが稼働していると仮定するものではありません。公開されたベンダーアドバイザリーから見える業界全体の状況です。大手インフラベンダーが複数製品にまたがるアドバイザリーを一斉に公開すると、監視や変更作業の予定にも二次的な影響が及びます。

ベンダーの一斉公開後にSIEMキューが膨らむ理由​

ベンダーPSIRTがアドバイザリーを公開すると、エンドユーザー側のセキュリティチームとITチームには、同時に三つの負荷がかかります。

  1. 資産の棚卸しと影響範囲の特定。 どのアプライアンス、または関連製品が、どのビルドで本番稼働しているか。管理プレーンは外部から到達可能か。影響バージョンと修正済みバージョンの表を、時間に追われながらスプレッドシートにまとめることになります。
  2. パッチ適用と検証の繰り返し。 アップグレード、仮想パッチ（FG-IR-26-181ではFMWPデータベース更新26.073のFortiGuard仮想パッチに言及）、設定の強化、変更後の検証がそれぞれチケットを生みます。変更のたびに新しいSIEMイベントが発生することもあります。
  3. 検知とスキャナーのノイズ。 新しいチェックが導入されたり、公開後に探索や便乗スキャンが起きたりすると、脆弱性スキャナー、設定監視、IDS／IPSシグネチャ、ファイアウォールログが急増することがあります。SIEMは役割どおりに活動を記録します。その結果、人の対応キューには重複に近いアラート、深刻度の不一致、「これは自社の資産か」という確認作業が積み上がります。

結果はよく知られたものです。アラートが増え、緊急に見えるケースが増え、本当に人の対応を必要とするインシデントに割けるアナリストの時間が減ります。

システム総入れ替えという落とし穴​

キューが膨らむと、「原因はSIEMだ」と考えてプラットフォームの入れ替えを始めたくなるかもしれません。しかし、PSIRTの一斉公開直後の週にそれを始めても、ほとんど役に立ちません。

監査や調査に必要なログの保持、検知ルール、証跡は、すでに稼働中のSIEMにあります。インシデント対応サイクルの最中にSIEMを入れ替えても、パッチ適用後の検証作業は短くなりません。ノイズが続く間に、複数年に及ぶ移行作業が加わります。

短期的に必要なのはトリアージ能力です。関連するアラートをまとめ、アドバイザリーに起因する急増の意味を平易な言葉で説明し、検証済みの次の手順をアナリストに示すこと。すでに使っているSIEMを手放さずに実現できます。

AIトリアージレイヤーの役割​

SIEM+は、すでに運用しているSIEMの上に重ねるAIレイヤーです（Microsoft SentinelやDevoは連携先の例です）。検知ルールもSIEM自体も置き換えません。必要に応じて、Enterpriseではオンプレミス環境への導入にも対応できます。

アドバイザリーが相次ぐ週、エンドユーザー側のSOCやITセキュリティチームにとって、このレイヤーは次のように役立ちます。

  • 関連アラートをまとめる。 スキャナーの検知やファイアウォールイベントをすべて個別のチケットとして残さず、優先順位を付けた少数のインシデントにまとめます。
  • 平易な言葉で要約する。 アドバイザリーに伴うノイズなのか、外部から到達可能な管理インターフェースへの実際の攻撃なのかを、幅広い知識を持つ担当者でも見分けやすくします。
  • 人が確認するための修復ガイダンスを提示する。 SIEMにすでにある資産やケースに沿って次の対応を示します。パッチ適用枠と検証作業が同じ担当者の時間を取り合うときに役立ちます。
  • 監査を意識した記録を保つ。 「10月中旬の一斉公開の後、何をしたか」を後から確認できます。

Fortinet（または他のベンダー）のアドバイザリーを無視することが目的ではありません。アドバイザリーに必要な棚卸し、パッチ適用、検証を進める間も、SIEMキューを使いやすい状態に保つことが目的です。

運用担当者が押さえておきたい実務上のポイント​

  • アドバイザリーが集中するPSIRT公開日は、CVEの一覧を読むだけの日ではなく、運用負荷の急増として捉えましょう。公開後数日間は、ファイアウォールとSIEMのキューが増えることを見込んでください。
  • FortiGuard PSIRTのベンダーのバージョン一覧（影響を受けるバージョン、回避策、仮想パッチ）を確認します。FG-IR-26-181の場合、FortiOS 8.0.0および7.6.4～7.6.6を、修正済みの8.0.1以降／7.6.7以降と照合します。
  • 影響の有無（管理プレーンに到達可能か、対象製品が環境内にあるか）と、ノイズ（スキャナーやシグネチャの頻繁な検知）を切り分けます。どちらもSIEMには記録されますが、同じ緊急度で対応する必要があるのは一方だけです。
  • アドバイザリー対応が続く間は、SIEMの全面入れ替えではなく、現在のSIEM上でトリアージを行う方法を優先しましょう。

ベンダーのアドバイザリーが集中する状況は今後も続きます。業界全体のダッシュボードが赤く染まるときも落ち着いていられるのは、SIEMが説明しやすい短いケース一覧を出せるチームです。

出典（Fortinet PSIRTのみ）： PSIRTアドバイザリーのインデックス、FG-IR-26-181 / CVE-2026-106174、FG-IR-26-180 / CVE-2026-106173、FG-IR-26-182 / CVE-2026-106175。業界の運用状況について述べたものであり、読者の環境が影響を受けているという主張ではありません。

製品について： SIEM+ — 既存SIEM上でAIがアラートをトリアージします。SIEMやその検知ルールを置き換えるものではありません。