Fortinet の SSL-VPN 脆弱性が示した、パッチ後も続くエッジアプライアンスの説明責任

概要

• Fortinet の PSIRT アドバイザリ FG-IR-24-015 は、CVE-2024-21762 を FortiOS および FortiProxy の領域外書き込みの脆弱性として説明し、細工された HTTP リクエストによる認証前のリモートコード実行が可能であり、野生下で悪用されている可能性に言及した。
• CISA は CVE-2024-21762 を「既知の悪用脆弱性カタログ」（Known Exploited Vulnerabilities Catalog）に追加し、影響を受ける Fortinet 製品を使用する組織にとっての優先課題とした。
• 本事案は単なる「FortiOS のパッチ適用」問題ではない。リモートアクセスアプライアンスは、攻撃者がパッチ前に悪用し、認証情報を収集し、設定変更や永続化を確立していた場合、信頼できないままとなる可能性がある。
• Fortinet は製品セキュリティ、PSIRT の情報開示、修正バージョン、回避策、堅牢化ガイダンスを管理下に置いていた。顧客はデバイスインベントリ、SSL-VPN の露出状況、緊急パッチ適用、ログ保存期間、侵害評価、認証情報のローテーション、再構築の判断を管理した。
• 公開情報は、エッジデバイスのパッチ適用には侵害後の調査が不可欠であるという高い信頼性の結論を支持している。しかし、すべての脆弱な FortiGate が悪用されたことや、CVE-2024-21762 が後日のすべての Fortinet 関連侵害を説明するものではない。

アドバイザリ自体が悪用の可能性を明示していた

Fortinet のアドバイザリFG-IR-24-015が主要な情報源である。これは CVE-2024-21762 を FortiOS および FortiProxy における領域外書き込みの脆弱性と説明し、細工された HTTP リクエストによる認証前のリモートコード実行が可能であるとした。アドバイザリはこの脆弱性が野生下で悪用されている可能性にも言及し、影響を受けるバージョンと修正バージョンを列挙した。また、回避策として SSL-VPN の無効化を提示した。

CVE-2024-21762の NVD エントリはこの深刻な脆弱性を記録しており、CISA のKnown Exploited Vulnerabilities カタログは、悪用された脆弱性として追加し、指令対象の連邦機関に修復を要求した。CISA のアラートFortinet Releases Security Updates for FortiOSは、管理者にアドバイザリの確認と更新の適用を促した。

この公開情報が重要なのは、「野生下で悪用されている可能性がある」という文言がオペレーターの義務を変えるからだ。理論上の脆弱性であれば緊急パッチプロセスで対処できる。悪用リスクのある脆弱性にはインシデント対応の発想が求められる。そのアプライアンスはインターネットに公開されていたか、攻撃を受けたか、どのようなログが残っているか、どの認証情報が収集された可能性があるか、その背後にはどのシステムがあるか、といった問いが必要だ。

Fortinet 製品はニッチなインフラではない。FortiGate ファイアウォールや FortiOS アプライアンスは、境界防御、VPN アクセス、セグメンテーション、リモート管理に広く使用されている。そのため、影響範囲は組織全体に及ぶ。脆弱な SSL-VPN は、本来ファイアウォールが守るべき環境への侵入口となり得る。

SSL-VPN の無効化は現実的な回避策だが、運用コストを伴う

Fortinet の回避策は明確だった。SSL-VPN を無効にせよ、と。しかし、多くの組織にとってそれは簡単なボタンクリックではない。SSL-VPN は、従業員、ベンダー、管理者、リモートサイトが内部アプリケーションにアクセスする手段かもしれない。無効化すれば、業務、リモートサポート、緊急メンテナンス、事業継続に支障をきたす可能性がある。パッチ未適用のまま有効にしておけば、組織は悪用のリスクに晒される。

これが管理上の問題である。技術的に正しいセキュリティアドバイスが、運用上は困難を伴うことがある。成熟した組織は、アドバイザリが出る前にその困難に備える。代替のリモートアクセス手段、緊急アクセスルール、特権アクセス経路、コミュニケーション計画を用意している。未成熟な組織は、緊急時に脆弱なサービスしかリモートアクセス手段がないことに気づく。

したがって、回避策は組織のレジリエンスを試す。短期間でも SSL-VPN を無効にできないなら、それは単一のコントロールプレーンに依存していることになる。無効にできても重要なスタッフをサポートできないなら、事業継続に問題がある。ビジネス上の圧力で SSL-VPN を公開し続けるなら、セキュリティリスクを受け入れていることになる。どの選択にも代償が伴う。

Fortinet の製品責任は、明確な修正バージョンと現実的な緩和策を提供することだ。顧客の責任は、緊急時の隔離が可能なアクセスアーキテクチャを構築することだ。攻撃者の責任は悪用だ。それらの役割は明確に区別される。

エッジアプライアンスには侵害の裾野が長く残る

2024 年以降の Fortinet 関連の公的警告は、エッジデバイスの侵害が持続しうることを繰り返し強調している。CISA、NSA、FBI、および国際パートナーは、Fortinet 製品を含むエッジデバイスの脆弱性を悪用してアクセスを獲得し足場を維持する脅威アクターに関するアドバイザリを公開した。CISA の中国に関連する国家支援アクターによるルーターおよびネットワークデバイス侵害に関する共同アドバイザリや関連するエッジデバイスガイダンスは、境界機器全般にわたる持続的アクセスの問題を浮き彫りにしている。

Mandiant のFortinet の悪用と永続化に関する分析は、以前の FortiOS ゼロデイ活動を調査し、攻撃者がカスタムマルウェアと永続化手法を用いて Fortinet デバイスに残留した経緯を示している。このレポートは CVE-2024-21762 に特化したものではない。しかし、悪用された Fortinet エッジデバイスが単なる侵入イベントではなく、持続的な足場になり得るという広範なリスクカテゴリを示す点で関連性がある。

Fortinet 自身のハードニングガイドでは、管理アクセス、信頼できるホスト、強力な認証、ログ記録、攻撃面の削減を重視している。このアドバイスは新しいものではない。問題は、重大な CVE が競争を引き起こす前に、顧客が実際にそれを適用するかどうかだ。

これが、パッチデーが終わりではない理由である。パッチ適用前にアプライアンスが悪用されていた場合、組織は永続化、認証情報の窃取、設定変更、新しいアカウント、変更されたファイアウォールポリシー、不審な VPN ログイン、異常な管理者セッション、外向きの接続を調査する必要がある。証拠が欠けていれば、信頼は不確かなままとなる。

在庫管理が警告を行動に変えるかどうかを決める

Fortinet が修正バージョンを公開した時、すべての顧客は、どのデバイスが存在し、どのバージョンが稼働しているか、SSL-VPN が有効か、アプライアンスがインターネットに面しているか、誰が所有しているか、どのサービスが依存しているかを把握する必要がある。これが資産在庫管理だ。これがなければ、アドバイザリは単なる公開文書に過ぎない。

インターネット露出データは役立つ場合がある。Shadowserver のデバイスおよび脆弱性レポートサービスや Censys に類する外部スキャンプログラムは、露出したサービスを特定できる。しかし、外部スキャンはデバイスのパッチ適用、変更の承認、ビジネスプロセスがダウンタイムに耐えられるか否かの判断はできない。スキャンは所有者に結びつかなければならない。

在庫管理の問題は、分散した組織ではより困難になる。支社、買収企業、地域 IT チーム、アウトソーシングプロバイダー、一時的なリモートアクセスセットアップなど、すべてが中央の可視性の外で Fortinet アプライアンスを作り出しうる。そのデバイスは小規模サイトにとって重要だが、本社からは見えないかもしれない。攻撃者は、そのデバイスが公式の在庫にあるかどうかを気にしない。

したがって、Fortinet アドバイザリ後の最初の説明責任のテストは、「在庫把握までの時間」だ。影響を受けるすべてのデバイスを特定するのにどれだけかかったか。内部記録ではなく外部スキャンで発見されたものはいくつあったか。所有者が不明なものはいくつあったか。アップグレード責任があいまいで古いバージョンのままだったものはいくつあったか。その答えが将来の失敗を予測する。

ログがパッチ適用だけで十分かどうかを決める

FortiGate および FortiOS アプライアンスはログを生成できるが、その有用性は設定、保存期間、エクスポート、監視に依存する。ログがアプライアンス上にのみ存在し、アプライアンスが侵害された場合、証拠は不完全になりうる。ログが十分な期間保存されていなければ、パッチ前の悪用は不可視になる。VPN、管理、システムイベントのログがレビューされなければ、パッチ適用はドアを閉めつつ、攻撃者を内部に残すことになる。

Fortinet のログ記録とレポートに関するドキュメントは、一般的な製品コンテキストを提供するが、インシデントの証拠にはならない。これは、顧客にログ記録の選択肢と、それゆえに行うべき決定があることを示している。高リスクのエッジアプライアンスは、アプライアンスの侵害によって記録が消去されないよう、中央システムにログを送信すべきだ。

運用者は、SSL-VPN ログインの成功・失敗、管理者ログイン、設定変更、ポリシー変更、新しいローカルユーザー、不審な送信元国、不可能な移動、繰り返しのセッション確立、高価値の内部サービスへのアクセスをレビューすべきである。また、パッチ適用前後の振る舞いを比較する必要がある。悪用ウィンドウ中にデバイスがインターネットに公開され、ログがなければ、組織はその信頼性に慎重になるべきだ。

これは特に公的機関や重要インフラ事業者にとって重要だ。Fortinet アプライアンスが政府サービス、公益事業、学校、病院へのリモートアクセスを提供している場合、ログがないことは単なるテレメトリの軽微な問題ではない。それは、誰も侵入しなかったという公的証拠を弱める。

認証情報とセッションは被害範囲の一部だ

SSL-VPN アプライアンスは、認証情報、セッション、証明書、デバイスポスチャ、グループメンバーシップ、アクセスポリシーを扱う。攻撃者がこれを侵害した場合、被害範囲にはローカル管理者アカウント、VPN ユーザー資格情報、セッション Cookie、設定バックアップ、LDAP バインドアカウント、RADIUS シークレット、証明書、ファイアウィールポリシーが含まれる可能性がある。すべてのエクスプロイトがすべての資産を奪取するわけではないが、対応では何が露出した可能性があるかを判断しなければならない。

エッジデバイス侵害後の認証情報のローテーションは困難だ。管理者、ユーザー、サービスアカウント、ディレクトリ統合、多要素認証システム、サイト間 VPN、監視に影響が及ぶ。その苦痛ゆえに、組織はローテーションを避けることがある。しかし、アプライアンス侵害の可能性があった後に古い資格情報を有効なままにしておくと、クローズされた CVE が継続的なアクセスに転化しうる。

説明責任を果たす対応では、閾値を設定する。ログが悪用を示さず、露出が限定的だった場合、ローテーションはより狭くできる。悪用が確認されたかログが欠落している場合は、ローテーションを広げるべきだ。アプライアンスが高価値のシークレットを保持していたり、特権ユーザーにサービスを提供していたりした場合は、再構築とローテーションがより強く求められる。

Fortinet のPSIRT アドバイザリは製品アップデートに不可欠だが、個々の顧客の認証情報の範囲を決定することはできない。顧客は、自社のアプライアンスに紐づく内部的なシークレットインベントリを必要とする。どの証明書がそこに存在するか。どの管理者アカウントか。どのサービス資格情報か。その在庫がないと、侵害後のローテーションは推測に頼ることになる。

回避策がシャドーアクセス経路を生み出すことがある

SSL-VPN が無効化されても、ユーザーはなおアクセスを必要とする。組織に適切な代替手段がなければ、チームは臨時の例外を設けるかもしれず、一時的なファイアウォールの開放、共有ジャンプボックス、個人用 VPN、管理外リモートデスクトップ、緊急ベンダーアカウント、幅広いクラウドアクセスなどの回避策をアドホックに作成する。これらの回避策は、適切に管理されなければ当初のリスクよりも悪い結果を招きかねない。

これが、回避策の計画が重要である理由だ。組織は危機の前に、緊急用のリモートアクセス代替手段を把握しておくべきである。IPsec VPN、ZTNA、特権アクセスワークステーション、緊急特権アカウント、踏み台ホスト、アウトオブバンド管理、またはローカルの事業継続手順などだ。各代替手段には、アイデンティティ管理、ログ記録、有効期限を設けるべきである。緊急アクセスが恒久的なシャドーインフラになってはならない。

Fortinet アドバイザリの SSL-VPN 回避策は技術的には明確だった。運用上の課題は顧客に帰属する。SSL-VPN の無効化が管理されていない回避策を生むなら、それは事業継続設計の問題だ。SSL-VPN を有効のままにして露出を残すなら、それはセキュリティリスクの意思決定だ。優れた計画は、プレッシャーの下でそのトレードオフを迫られることを避ける。

公共部門の事業継続がリスクの重みを増す

Fortinet アプライアンスは公共部門や重要サービス環境で一般的だ。リモートアクセスのエッジ障害は、政府職員、緊急サービス、学校、裁判所、公衆衛生、規制対象の公益事業に影響を与えうる。市民は、公共ポータルや行政ネットワークを保護する VPN アプライアンスを選べない。

CISA の KEV 期限は対象の連邦システムにとっての最低要件であり、完全な説明責任モデルではない。公的機関は、露出状況、パッチ適用時間、悪用レビュー、残余リスクを文書化すべきだ。また、市民サービスが影響を受けたかどうか、機密データに到達可能だったか、認証情報がローテーションされたか、マネージドプロバイダーが義務を果たしたかどうかを監督機関に説明できるようにすべきだ。

公的機関がこれらの質問に答えられない理由が、マネージドプロバイダーがアプライアンスを管理しているからだという場合、それは契約が不完全だ。マネージドエッジセキュリティには、アドバイザリ対応時間、ログ保存期間、顧客通知閾値、認証情報ローテーションサポート、再構築手順、事後報告を含む証拠条項が必要だ。

したがって、Fortinet の CVE は公共部門の事業継続に組み込まれるべきである。これは単に民間企業のパッチ適用課題ではない。リモートアクセスインフラは、気象事象、パンデミック、地域的な混乱、通常の分散業務の後に公的機関が運営するための手段である。そのエッジが信頼できなければ、事業継続も信頼できない。

ベンダー責任にはパターン認識が含まれる

Fortinet は過去数年間にわたり、FortiOS、FortiGate、SSL-VPN、関連製品にまたがる複数の注目すべき脆弱性を経験してきた。だからといって、すべての問題に共通の根本原因があるわけではない。しかし、ベンダーと顧客は、エッジ露出リスクを再発する製品・デプロイメントのパターンとして扱うべきである。

ベンダーの改善には、安全なデフォルト、より明確なハードニングガイダンス、アップグレードの簡易化、テレメトリの推奨、リスクの高い機能がインターネットに公開される際の強い警告が含まれるべきだ。顧客が、管理インターフェースや VPN の露出を最小化すべきことを毎回アドバイザリから読み取らねばならないのは望ましくない。製品体験は安全な運用を容易にすべきである。

顧客の改善には、特定の CVE だけでなく、すべての Fortinet デバイスクラスをレビューすることが含まれる。まだ古いバージョンが稼働していないか？ SSL-VPN はまだ必要か？ 管理インターフェースは制限されているか？ ローカルアカウントはレビューされているか？ ログは集中管理されているか？ 高リスク地域はブロックされているか？ 緊急特権アカウントは監視されているか？ 設定は安全にバックアップされているか？

パターン認識の教訓は Fortinet に限ったものではない。あらゆるエッジベンダーに当てはまる。リモートアクセスや境界防御を提供する製品は、今後も高価値の標的であり続ける。ベンダーと顧客はそれを設計上の事実として扱わねばならない。

評価を変える証拠

この評価は、SSL-VPN が無効または露出前にパッチ適用され、管理アクセスが制限され、ログが不審なアクセスを示さず、認証情報の範囲が限定され、アプライアンスが中央監視下にあったことを示せる組織にとっては厳しさが和らぐだろう。反対に、アプライアンスが露出し、パッチ適用が遅れ、ログが欠落し、侵害レビューが行われなかった場合にはより厳しくなる。

Fortinet をベンダーとしての評価は、透明性のある根本原因分析、より強固なセキュア・バイ・デフォルトの変更、明確な侵害後ガイダンス、顧客が迅速にアップグレードまたは緩和できる証拠によって改善されるだろう。同様の深刻なエッジ脆弱性が、デモンストレーション可能な製品強化の変更を伴わずに続くなら、評価は下がる。

現在の公的証拠は中心的な結論を支持している。CVE-2024-21762 は SSL-VPN の露出を説明責任の実地テストにした。パッチは製品の欠陥をふさいだが、それだけでは公開されたすべてのアプライアンスが信頼に値すると自動的に証明されたわけではない。

攻撃フレームワークはエッジが最初の標的になりやすい理由を示す

MITRE ATT&CK の「パブリック向けアプリケーションの悪用」（T1190）および「外部リモートサービス」（T1133）のテクニックが、攻撃者のロジックを説明している。攻撃者はパブリックに面したシステムを好む。なぜなら到達可能だからだ。リモートアクセスサービスは、まさに外界と内部リソースの橋渡しをするものだからだ。脆弱な SSL-VPN はその両方の特性を兼ね備える。

これは理論上の分類学の問題ではない。リモートアクセス用途で公開された FortiGate は、アイデンティティシステム、ファイル共有、管理ネットワーク、開発環境、あるいは機密性の高い業務アプリケーションの前面に位置していることがある。攻撃者がそのエッジを通じてコード実行や有効なリモートアクセスを取得すると、次の段階はエッジでは見えなくなるかもしれない。それは通常の内部アクセス、資格情報の使用、または横方向の移動として現れる可能性がある。

フレームワークの視点は、パッチ適用だけでは不十分な理由も明確にする。パブリック向けアプリケーションの悪用は最初のテクニックに過ぎない。アクターはその後、正規のアカウントを使用したり、自動起動項目を変更したり、設定情報を窃取したり、トンネルを作成したり、資格情報を収集したりする可能性がある。攻撃が脆弱なサービスを越えて進行すると、元の CVE をクローズしても後続のステップは消えない。

したがって防御側は、CVE 対応と行動ハンティングを組み合わせるべきだ。VPN ユーザーが通常とは異なるインフラから認証したか？ 新しい管理者アカウントが登場したか？ ファイアウォールポリシーが変更されたか？ 露出ウィンドウ後に通常と異なる内部システムが接続を受け付けたか？ 成功したアクセスの前にログイン失敗が急増したか？ アプライアンスが外向きの接続を開始したか？ これらの問いが、対応をパッチ管理から侵入評価へと引き上げる。

セキュアな管理は設計上の義務である

英国 NCSC のセキュアなシステム管理に関するガイダンスは、管理アクセスは制御され、監視され、通常の露出から分離されるべきだという基本原則を強調している。Fortinet アプライアンスはセキュリティデバイスであるが、同時に管理対象のシステムでもある。同じセキュア管理の原則が当てはまる。

管理アクセスは信頼できるネットワークと指名された管理者に限定すべきだ。緊急特権アカウントは稀であり、監視されるべきだ。設定変更は中央でログに記録すべきだ。管理インターフェースは通常のウェブアプリケーションのように扱ってはならない。リモート管理が必要なら、強力なアイデンティティ証明とログ記録を伴う堅牢化された経路を使用すべきだ。

Fortinet 自身のハードニングガイダンスもこのアプローチに沿っている。問題は実行だ。多くの組織では、エッジデバイスの管理が歴史的に成長してきた。ある時はここのファイアウォール、別の時は支店のアプライアンス、リモートサポート用のベンダーアカウント、停電後の一時的な開放など。数年後、誰も管理がまだ制御されていることを証明できない。重大な CVE が、その累積したドリフトを露呈させる。

したがってセキュアな管理は、一度限りのハードニング作業ではない。それは継続的なガバナンスプロセスである。すべてのアカウント、信頼できるホスト、管理経路、緊急例外は、現在の所有者を持つべきである。すべての例外には理由と有効期限が必要だ。目標は、次の重大な CVE がデフォルトで到達しにくくなるようにすることだ。

CIS コントロールはパッチだけでなく完全な対応をマッピングする

CIS コントロールは、対応の広さを示すのに役立つ。エンタープライズ資産のインベントリと管理は、FortiGate デバイスを特定する。セキュアな構成は SSL-VPN と管理の露出を制限する。アカウント管理はローカルおよびリモートユーザーを統治する。アクセス制御管理は VPN の到達範囲を制限する。継続的脆弱性管理がパッチ適用を推進する。監査ログ管理が証拠を保全する。インシデント対応管理が侵害レビューを導く。

この全体像が重要なのは、多くの組織が脆弱性管理コントロールに過度に集中するからだ。彼らはパッチが適用されたかどうかを問う。完全なコントロールレビューでは、そのデバイスが把握され、安全に構成され、中央にログが送られ、管理的に制御され、異常な使用について監視され、インシデント対応プレイブックに含まれていたかを問う。

これが、脆弱性がガバナンス監査になる方法である。パッチの適用遅延の原因が、所有者がいなかったことならば、失敗はインベントリと所有権にある。パッチは適用されたがログが欠如していたなら、失敗は証拠にある。パッチは適用されたが侵害が疑われるにもかかわらず古い VPN 資格情報が有効なままなら、失敗は認証情報対応にある。パッチは適用されたが同じ危険な露出が後に復活したなら、失敗は構成ガバナンスにある。

Fortinet のインシデントは、これらのすべてのコントロールを一度にテストする点で有用だ。リモートアクセスアプライアンスは単一の資産ではない。それはアイデンティティ、ネットワークポリシー、ログ、証明書、ユーザー行動、事業継続の結節点なのだ。

セキュア・バイ・デザインの期待はベンダーとデプロイメントの双方に及ぶ

CISA のSecure by Designプログラムはしばしばソフトウェア開発の文脈で語られるが、エッジアプライアンスにも同じ考え方が必要だ。ベンダーは、危険な露出を困難にし、警告を明確にし、アップデートを現実的にし、ログを有用にするよう製品を設計するべきだ。顧客は、それらの安全性前提を維持する形で製品をデプロイするべきだ。

Fortinet にとってセキュア・バイ・デザインとは、管理アクセス周りの強力なデフォルト、SSL-VPN 露出の明確なリスクシグナル、安全なアップグレード経路、使用可能なログ、悪用が疑われる際の対応手順を含むだろう。顧客にとってそれは、ファイアウォールをラックに設置したら終わりの一度きりの箱として扱わないことを意味する。それは、インターネットに面したセキュリティ製品としてのデバイスのライフサイクルを管理することを意味する。

この共有された設計視点は、よくある非難のループを防ぐ。ベンダーは顧客が誤設定したと言い、顧客はベンダーが欠陥を出荷したと言う。両方とも正しい可能性がある。セキュア・バイ・デザインの説明責任は、ベンダーが安全な設定を容易にしたか、顧客がリスクに見合った形で製品を使用したかを問う。

公的な CVE レコードは、すべてのデプロイメントについてこの問いに答えることはできない。しかし、それは再発する問題を特定できる。リモートアクセスエッジデバイスが魅力的な標的であり続けるのは、製品の欠陥、難しいアップグレード、露出のドリフト、ビジネス依存が組み合わさるからだ。

過去の脆弱性が新たな信頼判断に影響する

CVE-2024-21762 以前にも、Fortinet デバイスは悪用された脆弱性の対象になっていた。その履歴は重要である。なぜなら、新しい CVE へのパッチが適用されても、以前の侵害が調査されていなければ、古い経路を通じて依然として侵害されている可能性があるからだ。Fortinet エッジの永続化に関する CISA や Mandiant のアドバイザリはその点を強調している。アプライアンスの信頼状態は累積的なのである。

CVE-2024-21762 のパッチを適用した組織は、同じデバイスが以前の FortiOS SSL-VPN 脆弱性の際に露出していなかったかどうかも問うべきだ。過去のアドバイザリは修正されたか？ 当時ログはレビューされたか？ 認証情報はローテーションされたか？ 侵害が確認された際にデバイスは再構築されたか？ もしそうでなければ、現在のパッチは古い不確実性の上に載っているに過ぎない。

これが、エッジデバイスのリスク台帳がパッチレベルだけでなく侵害履歴を追跡すべき理由である。デバイスは最新でも、以前に露出し完全なレビューが行われていなければ、疑わしいままである。逆に、露出が制限され、ログがクリーンで、タイムリーに再構築された強固な履歴を持つデバイスは、より信頼に値するかもしれない。

公共部門や規制環境では、この累積的な信頼履歴が監査人に利用可能であるべきだ。個々のエンジニアが過去の緊急時に何が起きたかを思い出すことに依存すべきではない。

事業継続計画にはリモートアクセスの喪失を含めるべきだ

リモートアクセスは、利用できなくなるまでは単なる便利さとして扱われがちである。SSL-VPN を無効にしなければならないとき、組織は管理者がシステムに到達できず、リモートスタッフが作業できず、ベンダーがアプリケーションをサポートできず、インシデント対応者がツールにアクセスできないことに気づくかもしれない。セキュリティ回避策が事業継続インシデントとなる。

事業継続計画は、重要なリモートアクセスグループと代替手段を定義すべきだ。VPN 停止中にアクセスを維持すべきユーザーは誰か？ どのシステムに緊急管理が必要か？ どのベンダーがアクセスを必要とするか？ どの機能を停止できるか？ どのアクセス経路が十分に安全か？ ヘルプデスクはどうやって連絡するか？ 一時的なアクセスをどのように失効させるか？

CISA のStopRansomware ガイドは、レジリエンス、バックアップ、アイデンティティ管理、復旧計画を強調している。Fortinet に特化したものではないが、同じ運用原則を捉えている。セキュリティ管理は事業継続計画と組み合わせなければならない。事業を壊す回避策は迂回される。計画された代替手段を伴う回避策であれば強制できる。

ここで、一部の組織は不快なトレードオフに直面する。強力な境界管理を望むが、バックアップアクセス経路に資金を投じていない。迅速なパッチ適用を望むが、脆弱な変更プロセスしか持っていない。SSL-VPN を無効にしたいが、テスト済みの代替手段がない。Fortinet のインシデントは、これらの矛盾を白日の下にさらす。

顧客証拠パッケージは標準化されるべきだ

Fortinet エッジの緊急事態の後、組織は F5 と同様の内部証拠パッケージを作成すべきである。それは、在庫、影響を受けたバージョン、露出ステータス、パッチまたは回避策の適用時間、ログレビュー、不審なアクティビティ、認証情報への対応、事業継続への影響、残余リスクを含む。マネージドプロバイダーの場合、顧客向けに安全なバージョンを依存する顧客と共有すべきだ。

パッケージには、不明だった事項も記載すべきだ。ある期間のログが利用できなかったなら、その旨を明記する。悪用が除外できなかったなら、それを述べ、補償アクションを説明する。ローテーションが証拠から不要と判断されたなら、その証拠を文書化する。ビジネスオーナーが残余リスクを受け入れたなら、その受諾を記録する。

この規律が重要なのは、悪用されたエッジの脆弱性が再発するからだ。証拠パッケージなしでは、新しいインシデントは毎回推測から始まる。パッケージがあれば、組織は対応を比較し、プレイブックを改善し、繰り返される弱点を特定できる。

公的な説明はパッチ適用に道徳的役割を負わせるべきでない

企業はしばしば「パッチを適用した」と言いたがる。なぜならそれが決断力ある響きを持つからだ。パッチ適用は良いことだが、道徳的な赦しではない。パッチはソフトウェアの状態を変える。それだけでは、そのデバイスが以前に悪用されていたか、認証情報が盗まれていたか、永続化が仕込まれていたか、ログが存在するか、ユーザーが露出したか、あるいは顧客の業務に影響があったかという問いに答えるものではない。

同じ注意がベンダーの声明にも当てはまる。ベンダーアドバイザリは必要だが、顧客の安全を保証するものではない。安全の成果は、顧客のデプロイメント、スピード、監視、対応に依存する。成熟した説明はこうだ。ここに欠陥があり、修正方法はこれ。悪用が可能だった期間はこれ。調査方法はこれ。再構築すべき時はこれ。再発を防ぐ方法はこれ。

したがって Fortinet の事例は公的に有益な教育ケースである。これにより組織は、より正確な言葉を練習できる。パッチを当てた、緩和した、露出した、悪用された、調査した、信頼できる、再構築した、ローテーションした、復元した――これらは異なる状態であり、混同するとリスクが不可視になる。

最も強力な修復とはどのようなものか

CVE-2024-21762 後の最も強力な修復は、ベンダーと顧客のアクションを含む。Fortinet は、セキュアデフォルト、アップグレードガイダンス、テレメトリ、侵害後ドキュメンテーションの改善を続けるだろう。顧客は、すべての Fortinet アプライアンスのインベントリを取得し、不必要な SSL-VPN を無効にし、管理アクセスを制限し、ログを中央集中し、強力な認証を強制し、必要に応じて機密の認証情報をローテーションし、代替アクセス経路をテストする。

マネージドプロバイダーは、修復ウィンドウ、顧客通知閾値、ログ保持の保証、事後報告を含む契約上の証拠を追加する。公的機関は監査証拠、KEV 準拠、事業継続テストの監視を追加する。保険会社や規制当局は、エッジアプライアンスが資産インベントリとインシデント対応計画の対象かどうかを尋ねる。

修復はこの CVE で終わってはならない。あらゆるリモートアクセスエッジ製品に一般化されるべきだ。組織が「Fortinet のパッチをより早く」とだけ学ぶなら、より広範な教訓を見逃す。教訓は「リモートアクセスエッジの信頼を生きたシステムとして扱え」である。

再構築の判断には公的閾値が必要だ

悪用されたエッジの欠陥の後に最も居心地の悪い問いの一つは、そのデバイスが再構築なしで信頼できるか否かだ。ファイアウォールや VPN アプライアンスは通常のエンドポイントではない。管理資格情報、証明書、ルーティングポリシー、VPN 設定、ログ、アイデンティティ統合のシークレット、インスペクションルールを保持している可能性がある。攻撃者が特権コード実行を獲得した場合、オペレーターはソフトウェア更新で十分か、あるいはアプライアンスの再イメージ化、交換、または既知の良好な設定からの再構築が必要かを判断しなければならない。

この判断は緊急時に即興で行うべきではない。組織はインシデント前に閾値を決めておく必要がある。悪用の確認、ログの欠落、説明不能な設定変更、不審な管理者セッション、不明なローカルアカウント、マルウェアの証拠は、対応を再構築へと導くべきだ。クリーンなログと侵害指標のない低リスクの露出は、パッチと監視で正当化できるかもしれない。重要なのは、すべてのアドバイザリ後にすべてのデバイスを再構築することではなく、「パッチ済み」と「信頼できる」が同義語であるふりをやめることだ。

Fortinet は侵害後のガイダンスを具体的にすることで顧客を支援できる。顧客は、どの成果物を収集するか、どのログが最も重要か、どの設定場所が改ざんを示唆し得るか、どのシークレットが露出し得るか、そしてベンダーがパッチよりも再構築を推奨するのはいつかを知る必要がある。ガイダンスが具体的であればあるほど、顧客が自前のフォレンジックチェックリストを発明する必要が減る。

顧客はまた、クリーンな設定ベースラインを保存する必要がある。バージョン管理されずに何年も変更されてきたブランチファイアウォールは、確信を持って再構築するのが難しい。文書化された例外付きの中央管理された設定は、より迅速に復元できる。これも、運用の規律がセキュリティの成果を変える場面だ。同じ製品の脆弱性でも、既知の良好な状態から再構築できる環境とできない環境とでは結果が異なる。

再構築の問いは、マネージドサービスプロバイダーにとって特に重要だ。一つのプロバイダーが多数の Fortinet アプライアンスを複数の顧客向けに管理している場合、再構築判断の誤りがポートフォリオ全体に繰り返されうる。プロバイダーは閾値を文書化し、一貫して適用し、いつアプライアンスが単にパッチ適用されたにすぎないのか、再構築されたのかを顧客に伝えるべきだ。顧客はそれを稼働時間から推測すべきではない。

アプライアンスの証拠はアプライアンスの侵害を生き延びるべきだ

エッジデバイスはしばしば、自身の侵害に対する最初で最後の証人となる。それは脆弱な証拠モデルである。ログがアプライアンス上にのみ存在する場合、アプライアンスを制御する攻撃者が記録を改変または消去する可能性がある。設定バックアップが整合性チェックなしで保存されていれば、オペレーターは「既知の良好」とされるバックアップが既に攻撃者の変更を含んでいるかどうかを知ることができない。管理活動が外部ログシステムに送信されていなければ、最も重要なタイムラインが消失しうる。

説明責任を果たせるアーキテクチャでは、アプライアンスのログ、設定変更、管理者アクティビティ、VPN イベント、システムアラートを、アプライアンスの侵害が証拠を破壊しないほど迅速に分離システムへ送信する。その外部証拠は完璧である必要はない。しかし、最初の問いに答えるのに十分な独立性を持つべきだ。すなわち、アプライアンスはいつ、どこから、誰のアカウントでタッチされ、何が変わり、変更後に何が起きたかという問いだ。

ここで多くのエッジ対応プログラムが成熟度を露呈する。彼らはラップトップやサーバーにエンドポイント検知を導入していても、アプライアンスの可視性は弱いことがある。インターネット露出は監視していても、設定ドリフトは監視していない。ファイアウォールのトラフィックログは中央集中していても、管理イベントは収集していない。重要な FortiOS の CVE が、その監視ギャップを浮き彫りにする。

修正はより多くのデータだけではない。より良い証拠設計である。ログは、ストレージの都合ではなく、現実的な悪用タイムラインに合わせた保存期間を持つべきだ。設定バックアップは保護され、比較されるべきだ。管理アクセスは個人または承認された自動化に帰属できるべきだ。デバイスの時刻は同期され、タイムラインが使用可能であるべきだ。変更チケットは設定変更にリンクすべきだ。インシデント対応者は、証拠を破壊せずに誰がアプライアンスから収集できるかを知っているべきだ。

この規律の公的価値は信頼である。公共機関、病院、通信事業者、学区が「悪用の証拠は見つからなかった」と述べる時、公衆はその声明がアプライアンス外部で生存したログに基づいているかどうかを知るべきだ。さもなくば、その声明は単に、侵害されたシステムが自白しなかったに過ぎないかもしれない。

契約は厄介な作業を割り当てるべきだ

Fortinet のデプロイメントの多くは、リセラー、マネージドセキュリティプロバイダー、アウトソーシング IT チーム、あるいは中央とローカル管理者の間の共有責任を伴っている。この構造は、重要なアドバイザリが到着するまではうまく機能し得る。しかしその後、誰がパッチを適用するのか、誰が SSL-VPN を無効にできるのか、誰がビジネスオーナーに通知するのか、誰がログをレビューするのか、誰が認証情報をローテーションするのか、誰が再構築を決定するのか、誰が下流の顧客に伝えるのか、全員が把握する必要がある。

これらの割り当ては、インフォーマルではなく、契約上かつ運用上のものであるべきだ。「ファイアウォール管理」を約束するマネージドプロバイダー契約は、悪用された脆弱性への対応を定義すべきだ。緊急時の修復ウィンドウ、顧客承認ルール、メンテナンスウィンドウの上書き、証拠共有、ログ保持義務、再構築手順、認証情報ローテーションサポート、事後報告を含めるべきだ。これらの条件がなければ、顧客はインシデント中にプロバイダーがパッチ適用はできるが調査はできない、あるいは調査はできるがシークレットをローテーションできない、あるいはローテーションはできるがダウンタイムを正当化できないことを発見するかもしれない。

同じ原則が大企業内でも当てはまる。ネットワークチームがアプライアンスを所有しているかもしれない。セキュリティチームが検知を所有しているかもしれない。アイデンティティチームがディレクトリ資格情報を所有しているかもしれない。アプリケーションチームが VPN 背後のサービスを所有しているかもしれない。法務とコミュニケーションが通知を所有しているかもしれない。対応がそれらすべてを必要とし、誰も招集しなければ、CVE は組織的なボトルネックになる。

Fortinet のアドバイザリは時計をスタートできるが、ローカルな権限を割り当てることはできない。組織は事前にそれをしなければならない。成熟度の最良の証拠は、英雄的な一夜のパッチ適用ではない。それは、事前に合意されたプロセスであり、悪用されたエッジ警告を、所有を混乱させることなく、インベントリ、封じ込め、検知、認証情報、事業継続、顧客コミュニケーションの作業へと変換するものだ。

これが、説明責任の問題が単一のベンダーを超える理由である。リモートアクセスアプライアンスを持つすべての組織は、公的なエクスプロイトが現れた時に誰が厄介な作業を所有するのか答えられるべきだ。答えが「オンラインの奴なら誰でも」なら、そのコントロールは統治されていない。それは幸運だ。

説明責任テスト

Fortinet インシデントは 6 つのコントロールで評価されるべきだ。

第一に、露出：影響を受けるバージョンで SSL-VPN が有効でインターネットから到達可能だったか？

第二に、修復速度：Fortinet アドバイザリおよび CISA の悪用脆弱性リスト登録後、どれだけ迅速にオペレーターが修正バージョンを適用したか、または SSL-VPN を無効にしたか？

第三に、ログ記録：SSL-VPN、管理、システム、設定ログが中央で保持され、パッチ前の悪用についてレビューされたか？

第四に、認証情報対応：侵害が除外できなかった場合、管理者資格情報、VPN 資格情報、証明書、統合シークレットがローテーションされたか？

第五に、信頼判断：オペレーターは、FortiGate または FortiOS アプライアンスがパッチのみの処理ではなく再構築または交換を必要とする時を定義していたか？

第六に、事業継続：組織は SSL-VPN に代わる安全な代替手段を持ち、安全でない緊急回避策を回避できたか？

最終的な結論は限定されている。Fortinet は CVE-2024-21762 に関する重大なアドバイザリを公開し、野生下での悪用の可能性に言及した。CISA はそれを悪用済みと扱った。SSL-VPN サービスが露出していた顧客は迅速に行動する必要があった。しかし、より深い説明責任の教訓はパッチデーの後にある。悪用された可能性のあるエッジアプライアンスは自動的に信頼できるとは限らない。責任ある対応は、パッチ適用と合わせて、在庫確認、ログ検証、認証情報ローテーション、永続性レビュー、事業継続計画を組み合わせることだ。