概要

  • 確認された公開記録:Cisco は IOS XE Software Web UI 機能に対する活発な悪用を開示し、後に攻撃者が 2 つの未知の脆弱性を悪用したと特定した：初期アクセスと特権レベル 15 のアカウント作成のための CVE-2023-20198、続いて root 権限への昇格とファイルシステムへのインプラント書き込みのための CVE-2023-20273。(Cisco セキュリティアドバイザリ)
  • 政府ガイダンス:CISA は、これら 2 つの脆弱性が IOS XE Web UI に影響し、認証されていないリモートの攻撃者が影響を受けるシステムを制御する可能性があると述べ、組織に対し、インターネットに面したシステムで HTTP Server 機能を無効にし、悪意のある活動を捜索し、利用可能になり次第修正済みソフトウェアリリースにアップグレードするよう促した。(CISA ガイダンス)
  • 管理プレーンの問題:公開記録は、露出した Web 管理、アカウント作成、コマンドインジェクション、インプラント設置を含むコントロールサーフェスの障害を裏付けている。しかし、すべての IOS XE デバイスが影響を受けた、すべての露出したデバイスが侵害された、Cisco だけが各顧客のインターネット露出を管理していたといった包括的な主張を裏付けるものではない。
  • 評価:悪用は攻撃者により制御されていた。Cisco は製品コード、アドバイザリ内容、修正プログラムの提供、ハードニングガイダンス、検知サポートを管理していた。顧客、MSP、公的機関は露出、インベントリ、構成、セグメンテーション、監視、復旧の規律を管理していた。この事象は、「インターネット上で Web UI が有効になっているか？」という問いを、取締役会レベルの事業継続性の問題へと変えた。

ネットワークデバイスは単なるサーバーではなく、制御点であった

Cisco IOS XE Web UI インシデントが重要なのは、ルーター、スイッチ、無線コントローラーが単なるワークロードではないからだ。それらは他のワークロードにとっての制御点である。侵害されたネットワークデバイスは、認証、トラフィックルーティング、セグメンテーション、ブランチ接続、無線アクセス、音声、監視、さらにはインシデントレスポンス自体の経路上に存在する可能性がある。管理プレーンの侵害がそのようなデバイスに及んだ場合、復旧の課題は単に CVE がパッチされたかどうかではない。そのデバイスが依然として周囲のネットワークを記述し、施行し、保護するものとして信頼できるかどうかである。

Cisco のアドバイザリは、この事象を IOS XE Software の Web UI 機能に位置づけ、攻撃チェーンに活発な悪用が含まれていたことを明確にした。攻撃者はまず CVE-2023-20198 を使用して初期アクセスを獲得し、特権レベル 15 のコマンドを発行してローカルユーザーとパスワードの組み合わせを作成した。その後、攻撃者は Web UI 機能の別のコンポーネントである CVE-2023-20273 を悪用し、新たに作成したローカルユーザーを使って root に特権を昇格させ、ファイルシステムにインプラントを書き込んだ。Cisco は CVE-2023-20198 に CVSS 10.0 を、CVE-2023-20273 に 7.2 を割り当てた。(Cisco セキュリティアドバイザリ)

CISA の公開ガイダンスは、同じ事実をオペレーターの緊急性に変換した。CISA は、Cisco IOS XE Software Web UI に影響する CVE-2023-20198 と CVE-2023-20273 の活発かつ広範な悪用について説明し、認証されていないリモートの攻撃者がこれらの脆弱性を悪用して影響を受けるシステムを制御できると述べ、IOS XE Web UI を実行する組織に対し、インターネットに面したシステムで HTTP Server 機能を無効にすることを含む Cisco の緩和策を実施し、悪意のある活動を捜索するよう伝えた。(CISA ガイダンス)

管理プレーンの側面は、脆弱性の話と説明責任の話の違いである。通常の Web サーバーのアプリケーション欠陥は深刻になり得るが、パケットを転送しポリシーを適用するデバイスの管理インターフェースの欠陥は、コントロールプレーンリスクである。攻撃者は単一のアプリケーションからデータを盗むだけではない。攻撃者は、ネットワークの信頼できる機器に対して観察、変更、永続化、またはさらなるアクセス準備を行うことができる立場を得る可能性がある。

だからといって、影響を受けたすべてのデバイスがトラフィックの傍受や破壊的なアクションに使用されたわけではない。公開された一次記録は、そのような普遍的な主張を裏付けていない。Cisco と CISA は、悪用パターンとしてアカウント作成、root への昇格、インプラントの書き込みを文書化した。説明責任を問われるべき問いは、そのアクセスが何を意味し得るか、そしてオペレーターが再びデバイスを信頼できるものとして扱う前にどのような証拠が必要か、ということだ。

多くの組織、特にネットワークチームが限られている SME や公的機関にとって、管理インターフェースは歴史的に実用的な便宜であった。Web UI 管理はリモート設定を容易にするかもしれない。MSP は顧客サポートに使用するかもしれない。ブランチチームは展開後に到達可能なままにするかもしれない。便宜として始まった制御は、露出が継続的にインベントリ管理され制約されなければ、インターネットに面した攻撃対象領域になり得る。

Cisco は、修正のシナリオがまだ進行中にチェーンを開示した

公開された時系列は重要である。なぜなら、悪用、緩和策、修正リリースは一つの整ったパッケージとして到着しなかったからだ。Cisco は当初、活発な悪用について警告し、インターネットに面したシステムでの HTTP Server 機能の無効化を含む防御措置を推奨した。その後のアドバイザリ更新で 2 つ目の CVE、修正リリース情報、ソフトウェアチェッカーが追加された。CISA のページは、複数の IOS XE トレインの修正リリースの利用可能性に関する情報で更新され、オペレーターを Cisco のアドバイザリと修正ドキュメントに誘導した。(Cisco アドバイザリ、CISA ガイダンス)

この一連の流れは、実質的な説明責任の期間を生み出した。悪用が活発で、完全な修正マトリックスがまだ組み立てられている最中には、緩和の負担は露出の削減と検知へと急激に移行する。管理インターフェースが到達可能な場合、オペレーターは完璧なパッチ計画を待つことはできない。インターネットに面したシステムで HTTP/HTTPS サーバー機能を無効化または制限し、新しく作成されたユーザーや説明のつかないユーザーを捜索し、指標を確認し、証拠を保存し、デバイスが侵害された可能性があるかどうかを判断しなければならない。

Cisco の Software Fix Availability ドキュメントは後に、バグ ID CSCwh87343 を IOS XE 修正リリースにマッピングするより具体的な方法をオペレーターに提供した。CISA の 11 月 1 日の更新では、特定の Catalyst 3650 および 3850 デバイス向けに、リリーストレイン 17.9、17.6、17.3、16.12 の修正リリースがリストされた。この区別は重要である：初期の悪用期間中は、最も重要な制御は「管理プレーンの露出を今すぐ遮断せよ」である可能性がある。修正リリースが存在した後は、「アップグレードし、検証し、捜索し、復旧せよ」となる。(Cisco 修正プログラムの可用性、Cisco Software Checker)

National Vulnerability Database のエントリと CVE レコードは、これらの脆弱性に関する追加の公開アンカーを提供する。NVD の CVE-2023-20198 ページは Cisco アドバイザリを指し示し、活発な悪用の状況を説明している。CVE.org レコードは、公開脆弱性記録の一部として脆弱性識別子を保存している。(NVD CVE-2023-20198、NVD CVE-2023-20273、CVE レコード CVE-2023-20198、CVE レコード CVE-2023-20273)

このチェーンはまた、ガバナンスにおいて CVSS 単独では不十分である理由を示している。CVE-2023-20198 の 10.0 のスコアは技術的な重大性を示すが、ビジネスリスクは露出、役割、復旧能力によって異なる。弱いログ機能と既知のクリーンなイメージがないインターネットに露出したブランチルーターは、管理 VPN 制御の背後にある内部ラボデバイスとは異なる運用上の問題を引き起こす。重大性はリーダーシップに注意を促す。一方、インベントリと露出の証拠は、リーダーシップに最初に何をすべきかを伝える。

インターネットへの露出が結果を増幅させた

オペレーターが制御できる最も重要な変数は、Web UI 管理画面がインターネットから到達可能かどうかだった。Cisco と CISA の緩和策の文言は、インターネットに面したシステムで HTTP Server 機能を無効にすることに重点を置いていた。Cisco のハードニングガイダンスはその制御と一致している：Cisco の IOS および IOS XE ハードニング資料には、no ip http serverで HTTP サーバーを無効化でき、no ip http secure-serverでセキュア HTTP サーバーを無効化できると記載されている。(Cisco IOS XE Software ハードニングガイド、Cisco Guide to Harden Cisco IOS Devices)

これは新しいセキュリティ原則ではない。管理インターフェースは、強力で監視され、制限され、文書化された理由がない限り、広くインターネットに露出すべきではない。インターネットに露出した管理インターフェースに関する CISA の Binding Operational Directive 23-02 は、連邦政府の民間機関に対し、露出した管理インターフェースからのリスクを低減するよう指示しており、その推奨事項は連邦政府の枠を超えてより広く関連性がある。(CISA BOD 23-02)

問題は、実際のネットワークでは例外が積み重なることだ。合併中に展開されたデバイスは古いアクセスルールを保持する。MSP が緊急トラブルシューティングのために管理パスを開設し、そのまま閉じない。ブランチオフィスが HTTP が有効化されたテンプレートを引き継ぐ。パブリック IP の所有者が変わる。一時的な移行のために設定されたファイアウォールルールが恒久的になる。Web UI は必ずしも一人のエンジニアが無謀な決定を下したために露出するわけではない。資産インベントリ、変更管理、管理サービスの引き継ぎがネットワークの履歴に追いつかなかったために露出する可能性がある。

その履歴は責任の所在にとって重要である。Cisco は製品の脆弱性が存在するかどうか、およびそれがどれだけ迅速に診断および修正されるかを管理していた。顧客は脆弱な管理画面に到達可能かどうかを管理していた。MSP は多くの顧客の構成を管理していた。公的機関は自らのインベントリと緊急時の無効化プロセスを管理していた。攻撃者は到達可能なシステムを悪用した。説明責任は、一つの文に集約されるのではなく、それらの管理点に従う。

SME にとって、露出の問題は特に難しい。小規模な組織はネットワークデバイス構成を管理サービスプロバイダーに依存しており、IOS XE Web UI が有効か、露出しているか、内部で制限されているか、未使用かを知らない可能性がある。どのリリーストレインを実行しているか、修正ソフトウェアが利用可能か、説明のつかないローカルユーザーが現れていないかを知らないかもしれない。CISA がインターネットに面したシステムで HTTP Server 機能を無効にし、悪意のある活動を捜索するよう指示する場合、SME はプロバイダーがそれを具体的なデバイスチェックと証拠に変換する必要があるかもしれない。

これが、このインシデントが Cisco と大企業だけの話ではない理由である。それは管理ネットワークサポートのエコシステムへの試練である。もし MSP が顧客ネットワークの管理を一元化できるなら、正確な露出インベントリ、迅速な緩和、復旧の証明も一元化しなければならない。パッチ適用前にデバイスに root レベルのインプラントがあった可能性がある場合、顧客は「パッチを当てた」と言われるだけでは十分と受け入れることはできない。

インプラントはパッチ適用を復旧作業に変えた

公開された事実にはインプラントの書き込みが含まれており、それが作業を変える原因となった。脆弱性が認証されていないアカウント作成のみを許可する場合、アカウントを削除してパッチを適用すれば十分なケースもある。しかし、チェーンに root 権限への昇格とファイルシステムに書き込まれたインプラントが含まれる場合、オペレーターは影響を受けるデバイスを、フォレンジックトリアージと復旧検証を必要とする侵害された可能性のあるシステムとして扱わなければならない。

CISA のガイダンスは組織を悪意のある活動の捜索に導き、Cisco Talos の検出手法を参照している。Cisco Talos ブログは、ページへの自動アクセスが制限されている場合でも重要な公開検出ソースである。CISA は、組織が潜在的な悪意のある活動の証拠として、デバイス上の説明のつかないユーザーや新しく作成されたユーザーを探すべきという実践的なアドバイスを引用した。(Cisco Talos ブログ、CISA ガイダンス)

「新しく作成されたユーザー」というフレーズは平凡に聞こえるかもしれない。ネットワークデバイス上では、そうではない。悪用を通じて作成された特権付きのローカルユーザーは、表面的なレビューをすり抜け、後のアクセスのために再利用されたり、改ざんの証拠を提供する可能性がある。root レベルのコマンド実行は、構成の整合性、ファイルシステムの状態、起動イメージ、永続性、ログ、さらにはデバイス自身のテレメトリーが信頼できるかどうかについて、より深い疑問を提起する。

パッチ適用は既知の脆弱性経路を閉じる。しかし、侵害されたデバイスにインプラント、不正アカウント、変更された構成、隠れた永続性が残っていないことを自動的に証明するわけではない。したがって、復旧の証拠にはいくつかの層が必要である：Web UI が有効だったかどうかを特定する；それがインターネットから到達可能だったかどうかを判断する；不審なユーザーや指標をチェックする；利用可能な場合はログを収集・保存する；不正アカウントを削除する；修正ソフトウェアにアップグレードする；running 構成と startup 構成を比較する；イメージの整合性を検証する；侵害が疑われる場合は再構築または再イメージングする；サービス復帰後に監視する。

NIST のインシデント対応ガイダンスは、復旧をチェックボックスではなくフェーズとして扱っているため、ここで有用である。検知、封じ込め、根絶、復旧は関連しているが同一ではない。証拠がまだ収集されている間にデバイスにパッチを適用できる。監視が依然として強化されている間にデバイスをサービスに戻すことができる。脆弱性管理の観点からは「修正済み」でも、インシデント対応の観点からは未解決のままである可能性がある。(NIST SP 800-61 Rev. 2)

この区別は取締役会への報告を形作るべきである。「すべてのデバイスにパッチが適用された」という報告は技術的には真実かもしれないが、依然として不完全である。リーダーシップは、脆弱な機能が有効だったデバイスの数、インターネットに露出していた数、侵害の指標を示した数、再構築された数、不正ユーザーがいた数、利用不可能なログがあったかどうか、管理サービス顧客が証拠を受け取ったかどうかを知る必要がある。それらは復旧の指標であり、単なるパッチの指標ではない。

検知証拠は設計上、不均一だった

ネットワークデバイスはしばしば真実の源泉として扱われる。それらはログを生成し、ACL を施行し、トラフィックをルーティングし、ステータスを報告する。管理プレーンが侵害された場合、その前提は弱まる。攻撃者がユーザーを作成し、昇格された特権でコマンドを実行できる場合、デバイス自身の記録は不完全、改変、または不在である可能性がある。オペレーターは外部の証拠を必要とする場合がある：NetFlow、ファイアウォールログ、SIEM レコード、構成バックアップ、アウトオブバンド管理ログ、TACACS または RADIUS ログ、EDR のようなネットワークテレメトリー、および既知の正常な構成との比較。

これはマニフェストにおける「ネットワークリソース証拠」の問題である。侵害されたリソースは証拠を担っているだけでなく、証拠を形成している。ルーターやスイッチが本来ログを生成すべき場所であり、そのデバイスが侵害されている場合、証拠の質はログがインシデントの前にエクスポートされ保護されていたかどうかに依存する。デバイス上のローカルログバッファーは有用かもしれないが脆い。集中ログと AAA レコードははるかに重要になる。

CISA の Known Exploited Vulnerabilities カタログも証拠インフラストラクチャである。CVE-2023-20198 および関連する悪用された脆弱性をリストすることで、機関やオペレーターに、問題が理論的なものではないという優先順位付けのシグナルを提供する。KEV カタログと Binding Operational Directive 22-01 は、既知の悪用された脆弱性を修復するための連邦プロセスを作成し、多くの民間組織がトリアージのシグナルとしてこのカタログを使用している。(CISA Known Exploited Vulnerabilities Catalog、CISA BOD 22-01)

それでも、KEV への掲載は、オペレーターにそのデバイスが侵害されたかどうかを伝えるものではない。悪用が既知であり、修復を優先すべきであることを伝える。オペレーターは依然としてローカルな証拠の質問に答えなければならない：機能はオンだったか？ 到達可能だったか？ 調査されたか？ ユーザーは作成されたか？ インプラントは存在したか？ 修正ソフトウェアはインストールされたか？ デバイスは再構築されたか？ 下流のルート、ACL、または認証情報は変更されたか？

認証情報の証拠は特に重要である。攻撃者がローカルアカウントを作成した場合、そのデバイスは AAA サーバー、SNMP コミュニティ、ネットワーク管理システム、自動化資格情報、バックアップリポジトリ、または構成アーカイブにもアクセスしていた可能性がある。公開された Cisco と CISA のアドバイザリは、そのような下流システムすべてがアクセスされたとは述べていない。しかし、デバイスローカルの侵害が、より広範な管理資格情報や信頼関係を露出させた可能性がないかを検証する合理的な理由を生み出している。

集中認証を使用している組織にとって、ローカルアカウントは異常であるべきだ。ローカルの緊急アカウントと外部 AAA が混在している組織では、調査はより困難になる。不審なアカウントは、命名、文書化、定期レビューが弱い場合、正当な緊急アカウントの中に隠れる可能性がある。したがって、このインシデントは退屈なガバナンスを評価する：一意のアカウント、AAA ログ、構成ベースライン、頻繁なバックアップ、最小権限、クリーンなインベントリ。

Cisco の役割はパッチを書くだけではなかった

Cisco の説明責任には製品の脆弱性が含まれるが、それで終わりではない。ネットワークオペレーティングソフトウェアのベンダーは、セキュア設計、コードレビュー、デフォルトの姿勢、アドバイザリの明確さ、修正プログラムの提供、ソフトウェア互換性、検出ガイダンス、TAC キャパシティ、ハードニングドキュメンテーション、顧客が影響を受けるリリースを特定する能力を管理している。このインシデントにおいて、Cisco はチェーンを開示し、2 つの CVE を特定し、推奨事項を提供し、修正リリース情報を公開し、ハードニングガイダンスを維持した。

修正マトリックスが重要である理由は、IOS XE が単一のアプライアンス上の単一のバージョンではないからである。大規模ネットワークには、異なるリリーストレイン、ハードウェアファミリー、サポート契約、運用上の制約、メンテナンスウィンドウが含まれる場合がある。「今すぐパッチを当てろ」という指示は方向性としては正しいが、運用上は不完全である。顧客は、どのイメージが修正されているか、どの SMU が存在するか、どのトレインがまだサポートされているか、どのデバイスがアップグレードを必要とするか、アップグレードがダウンタイムのリスクを伴うかどうかを知る必要がある。Cisco の修正可用性ドキュメントとソフトウェアチェッカーはその変換に役立つ。(Cisco 修正可用性、Cisco Software Checker)

アドバイザリの明確さは修正の可用性と同じくらい重要である。活発な悪用の最中には、アドバイザリはオペレーターに、何を無効にすべきか、何を探すべきか、何が影響を受けるか、何が影響を受けないか、回避策が存在するか、いつ修正ソフトウェアが利用可能になるか、指標をどう解釈すべきかを伝えなければならない。Cisco のアドバイザリは CVE を割り当てる以上のことをした。初期アクセスからローカルユーザー作成、root への昇格、インプラント書き込みに至る観測されたチェーンを説明した。これは、対応を定型的なパッチ適用から侵害評価へと変える種類の情報である。

ベンダーデフォルトは公正だが慎重な問いである。Web UI が存在するかどうかを尋ねるだけでは十分ではない。管理機能は正当な理由で存在していることが多い。より良い問いは、製品とドキュメントが安全でない露出を困難にし、可視化し、または喧伝するものとなっているかどうかである。HTTP/HTTPS 管理サーバーが有効な場合、オペレーターはそれが信頼できないネットワークから到達可能かどうかを容易に確認できるか？ テンプレートやウィザードは最小限の露出に偏っているか？ 警告はインターネットに面した管理が危険であることを明確にしているか？ テレメトリーはインターネット露出を示すか？ ソフトウェアはオペレーターが未使用の管理サービスを無効にするのを支援するか？

Cisco のハードニングドキュメントは管理プレーンの露出を減らすことを助言している。それは有用だ。しかし、ハードニングドキュメントは展開のプレッシャー、継承された構成、そして「前回はうまくいった」という運用の習慣と競合する。セキュア・バイ・デザインへの期待は、ベンダーが露出した道よりも安全な道を容易にすることをますます求めている。CISA のセキュア・バイ・デザインガイダンスは、テクノロジーメーカーは単にハードニングチェックリストを公開するのではなく、顧客のセキュリティ成果に対してより多くのオーナーシップを持つべきだと主張している。(CISA Secure by Design)

その原則をここに適用しても、Cisco がすべての露出したデバイスに対する単独の責任を負うことにはならない。しかし、ネットワーク製品が、管理の露出を表面化し、インターネット到達性を抑止し、展開後のハードニングへの依存を減らし、オペレーターが現在の状態を証明するのを支援するために、より多くのことができるかどうかを問うている。ガイドに記載された警告は、製品に組み込まれた制御と同じではない。

顧客と MSP の説明責任は Cisco にアウトソースできない

顧客は、爆発半径を決定した変数の多くを管理していた。彼らは、Web UI が有効かどうか、HTTP/HTTPS 管理がインターネットから到達可能かどうか、管理アクセスが VPN または専用ネットワークに制限されていたかどうか、構成がバックアップされていたかどうか、ログが集中化されていたかどうか、ローカルユーザーアカウントがレビューされていたかどうか、脆弱なデバイスが迅速に発見可能だったかどうかを決定または引き継いだ。

マネージドサービスプロバイダーは、多くの顧客にとってこれらの変数を管理していた。それゆえ、MSP の役割は中心的である。MSP が顧客のネットワークデバイスを管理している場合、正確なデバイスインベントリ、リリースインベントリ、管理露出インベントリ、AAA モデル、バックアップ状態、ログ状態、緊急緩和策のプレイブックを維持すべきである。Cisco のアドバイザリが届いたとき、プロバイダーはどの顧客が機能を露出している可能性があるかを尋ねることから始めるべきではない。すでに知っておくべきだ。

SME の事業継続性への影響は、その依存関係から生じる。小規模な製造業者、クリニック、学校、地域の小売業者、または専門サービス事業者は、ネットワークデバイスの侵害を、ダウンタイム、不確実性、または緊急のコントラクター費用として経験する可能性がある。IOS XE リリーストレインや侵害指標を評価する社内の専門知識を持たないかもしれない。もし MSP が証拠を提供できなければ、顧客は信頼と高額なセカンドオピニオンの間で選択を迫られることになる。

その不確実性は、悪意のあるトラフィック操作が発生する前であっても、事業の中断になり得る。顧客は、緊急メンテナンスのスケジュール、デバイスの交換、認証情報のローテーション、ログのレビュー、リーダーシップへの通知、リモート管理の一時停止、監査人への説明を必要とする場合がある。SME にとって、これらのコストはスタッフのキャパシティに比べて大きくなり得る。脆弱な製品がエンタープライズグレードであるという事実は、影響を受けるすべてのオペレーターがエンタープライズグレードの対応能力を持っていることを意味しない。

契約はその現実を反映すべきである。マネージドネットワーク契約は、誰が露出インベントリを維持するか、誰がベンダーアドバイザリを受信するか、誰がインターネットに面した管理を無効にできるか、誰が緊急変更を承認するか、誰が証拠を保存するか、誰が指標を顧客に報告するか、誰が緊急時の再構築費用を支払うか、クロージャ後に顧客がどのような証拠を受け取るかを規定すべきである。これらの条件がなければ、IOS XE のようなインシデントは、ベンダー、MSP、顧客、保険会社、監査人の間での混乱となる。

公的機関にも同様の義務がある。彼らはしばしば、レガシーデバイス、調達制約、メンテナンスウィンドウを抱えた分散ネットワークを運用している。また、ルーティング、無線、緊急通信、学校ネットワーク、または自治体サービスが劣化した場合の公共サービスへの影響にも直面する可能性がある。連邦政府の BOD が自動的にすべての地方または外国の公共機関を統治するわけではないが、その原則は移転可能である：露出した管理インターフェースを知り、既知の悪用された脆弱性を優先し、修復を文書化する。(CISA BOD 23-02、CISA KEV Catalog)

国際的なアドバイザリは共通の依存を示した

IOS XE インシデントは、Cisco デバイスがグローバルであるため、グローバルなものとなった。米国以外の政府のサイバー機関が警告を発令または増幅した。オーストラリアのサイバーセキュリティセンターは、この脆弱性の悪用により、リモートの認証されていないユーザーが脆弱なシステム上に高度な特権アカウントを作成し、システムを制御できる可能性があると警告した。カナダのサイバーセンターは、Cisco のアドバイザリと修正の可用性を追跡する最新情報を公開した。(Australian Cyber Security Centre alert、Canadian Centre for Cyber Security advisory)

これらのアドバイザリが重要なのは、ネットワークデバイスの脆弱性が調達システムよりも速く国境を越えるからである。多国籍企業、地域 ISP、学校ネットワーク、市の機関はすべて、異なるリリーストレインとサポート契約のもとで、異なる方法で IOS XE を実行している可能性がある。同じアドバイザリが、環境ごとに異なる運用上の問題となる。

国際的な増幅は、インシデントが 1 つのベンダーのプライベートな顧客通知として片付けられる可能性を減らす。複数の国家機関がオペレーターに行動を促す場合、この問題は公共インフラの衛生問題の一部となる。これには説明責任の結果が伴う。取締役会や公的機関の幹部は、Cisco、CISA、その他のサイバー機関がガイダンスを公開した後に、リスクが不明瞭であったとはもっともらしく主張できない。

同時に、グローバルなアドバイザリがローカルな実行を解決するわけではない。機関のページは、顧客のルーターにログインして Web UI を無効にしたり、ローカルユーザーをレビューしたり、修正ソフトウェアをインストールしたり、侵害されたデバイスを再構築したりすることはできない。それはシグナルを上げることしかできない。最後の 1 マイルは依然として資産所有者とそのプロバイダーに委ねられている。

したがって、この事象はおなじみの非対称性を示している：警告はグローバルだが、復旧はローカルである。Cisco は修正プログラムを公開できる。CISA はガイダンスを公開できる。国家機関は増幅できる。研究者はインターネットをスキャンできる。しかし、学区、SME、または自治体は、自分たちがどのデバイスを所有しているか、誰がそれらを管理しているか、露出をどのように遮断するか、どの停止ウィンドウが許容可能か、どのクリーンアップの証明が自身のリスク判断を満たすかを知らなければならない。

オペレーターが保持すべきだったクリーンな復旧記録

IOS XE Web UI 事象の防御可能な復旧記録は、「パッチ済み」よりも具体的であるべきである。それはインベントリから始まるべきである：すべての IOS XE デバイス、モデル、リリーストレイン、役割、管理アドレス、管理アクセスパス、Web UI の状態、インターネット露出状態、責任所有者。次に、緩和策を文書化すべきである：適切な場合の HTTP および HTTPS サーバーの無効化または制限、アクセス制御の適用、修正ソフトウェアの特定、メンテナンスウィンドウのスケジュール、緊急例外の承認。

次に侵害評価である。オペレーターは、各デバイスが説明のつかないユーザーや新しく作成されたユーザーを示したか、既知の指標が存在したか、ログが不審なアクセスを示したか、AAA レコードが期待される管理と一致したか、構成変更が不正に見えたか、デバイスを再構築する必要があったかを記録すべきである。記録は、「脆弱ではない」、「脆弱だが露出していない」、「露出していたが指標は見つからなかった」、「露出しており指標があった」、「侵害が確認された」を区別すべきである。

次に復旧である。修正ソフトウェアバージョン、イメージソース、チェックサムまたは整合性検証、構成バックアップの比較、不正ユーザーの削除、認証情報のローテーション、AAA レビュー、SNMP および自動化資格情報のレビュー、ログ検証、変更後の監視を記録すべきである。高価値デバイスの場合、侵害が疑われる場合、その場でのクリーンアップよりも信頼できるメディアからの再構築の方が信頼性が高いかもしれない。

最後に、顧客およびリーダーシップへのコミュニケーションである。幹部は技術的状態をビジネスリスクに結びつける要約を必要とする。MSP の顧客は、単なる一般的なアドバイザリリンクではなく、デバイス固有の証拠を必要とする。公的機関は、監査人、保険会社、監視機関に適した記録を必要とする。良好な復旧と弱い復旧の違いは、多くの場合、緊急事態が過ぎ去った後に保持される証拠である。

NIST のパッチ管理ガイダンスは、脆弱性の修復が単一のアクションではなく管理されたライフサイクルであるという点を補強している。組織は、インベントリ、優先順位付け、テスト、展開、検証を必要とする。活発に悪用されているネットワークデバイスインシデントでは、そのライフサイクルは圧縮されるが、消えるわけではない。(NIST SP 800-40 Rev. 4)

このインシデントはまた、定期的な露出テストを主張するものでもある。四半期ごとまたは継続的にインターネットに露出した管理サービスをチェックしていれば、驚きは減少しただろう。インターネットに面したデバイス上のip http serverやip http secure-serverをフラグする構成管理システムがあれば、対応時間は短縮されただろう。集中型 AAA があれば、予期しないローカルユーザーを発見しやすくなっただろう。これらは特殊な制御ではない。それらは、欠けているときにだけ大声になる静かな制御である。

構成の来歴は、その記録の中で独自の行を占めるに値する。ネットワークデバイスは、脆弱性スキャンに合格しても、その起源が十分に理解されていない構成で動作している可能性がある。オペレーターは、running 構成が標準テンプレート、緊急変更、MSP の例外、継承された買収ネットワーク、またはローカル管理者の一度限りの修正に由来するかどうかを知るべきである。IOS XE のケースでは、来歴が、なぜ Web UI が有効で到達可能だったのかを説明できる可能性がある。その文脈がなければ、修復は当面の露出を閉じる一方で、次のテンプレートプッシュや交換デバイスを通じて同じパターンが再発する脆弱性を組織に残す可能性がある。

プロバイダーの証拠も同様に具体的であるべきだ。MSP は顧客に対し、影響を受けたデバイスと影響を受けなかったデバイスの日付付きリスト、緩和前の露出状態、管理画面を閉じるために使用されたコマンドや構成変更、ターゲットとする修正ソフトウェア、侵害評価の結果、残っている例外を提供できるべきである。顧客はすべてのパケットキャプチャや機密の資格情報の詳細を必要としない。事業継続性、サイバー保険の通知、監査人への通知、または顧客通知が必要かどうかを判断するのに十分な証拠が必要である。「Cisco デバイスがレビューされました」という一般的な声明は、復旧記録と同じではない。

その記録はまた、インシデント前に露出状態を承認したのは誰かを特定すべきである。多くのネットワークでは、管理インターフェースが到達可能になるのは、古い例外、一時的なトラブルシューティングの変更、前任者から継承されたテンプレート、または広範なアクセスを静かに正常化するアウトソーシングサポートモデルが原因である。ゼロデイの後に露出を閉じることは必要だが、説明責任はその露出がなぜ存在したかを学ぶことを要求する。理由が把握されなければ、交換デバイスがインストールされたとき、バックアップ構成が復元されたとき、またはサポートプロバイダーが次の展開を標準化するときに、同じパターンが再発する可能性がある。

証拠のギャップ自体が教訓である

公開記録は、完全な被害者数、完全な攻撃者の特定、インプラントの詳細すべて、影響を受けたハードウェアプラットフォームすべて、すべての顧客の露出状態、または普遍的な復旧処方箋を提供していない。その情報の一部は公的に知り得ないかもしれない。一部は影響を受けた顧客や法執行機関と非公開で共有されたかもしれない。その不在を憶測で埋めるべきではない。

最も責任ある公的な知見はより狭い。Cisco と CISA は、IOS XE Web UI の脆弱性の活発な悪用を文書化し、特権レベル 15 のアカウント作成、root への昇格、インプラントの書き込みを伴うことを示した。CISA は、インターネットに面した HTTP Server の露出を無効化し、捜索し、アップグレードすることを促した。修正リリースはリリーストレイン全体で利用可能になった。説明責任の結果は、ローカルな露出、インベントリ、復旧に依存する。

その証拠の境界は、二つの悪いナラティブから保護する。第一の悪いナラティブは、事象全体が単に Cisco の責任であると言う。それは、インターネットに露出した管理に対する顧客と MSP の制御を無視している。第二の悪いナラティブは、事象全体が単に管理を露出した顧客の責任であると言う。それは、脆弱性、アドバイザリの品質、修正プログラムの提供、製品設計のインセンティブに対する Cisco の責任を無視している。

真実はそれほど満足のいくものではなく、より有用である。製品の欠陥と展開の露出が組み合わさった。攻撃者はその両方を悪用した。良好な復旧には、ベンダーの修正とオペレーターの規律が必要だった。どちらの側の制御も完全ではなかったが、双方とも自らの部分について説明責任を負うのに十分な制御を持っていた。

この事象はまた、管理プレーンの侵害後に否定的な信頼を証明することがいかに困難かを示している。デバイスはパッチされているかもしれないが、オペレーターはアカウント作成がなかったことを証明できるか？ユーザーは削除されたかもしれないが、構成が変更されなかったことを証明できるか？再起動後にインプラントが消えるかもしれないが、後で永続化がなかったことを証明できるか？公開向けのステータスメッセージがこれらの質問に答えることはめったにない。インシデントの前に構築された証拠アーキテクチャは答える。

説明責任は管理プレーンに従う

管理プレーンは、権限が集中する場所である。管理者が認証し、構成が変更され、ユーザーが作成され、サービスが有効化され、ログが閲覧され、復旧が始まる場所である。そのプレーンを公共のインターネットから到達可能にしておくことは、認証、コード、構成、監視、パッチ適用のすべてが、現在および将来のあらゆるエクスプロイトに対して十分に強力であり続けるという恒久的な賭けをすることになる。

IOS XE Web UI インシデントは、その賭けが失敗し得ることを示した。Cisco の製品には、Web UI チェーンに 2 つの未知の問題があった。顧客とプロバイダーは管理インターフェースを露出させていた。攻撃者は、緩和策と修正プログラムの提供が緊急事態になるほどの速さで動いた。政府機関はガイダンスを増幅しなければならなかった。オペレーターはアカウント作成とインプラントを捜索しなければならなかった。SME は回答をプロバイダーに頼らなければならなかった。

教訓は、すべてのリモート管理を排除することではない。現代のネットワークはリモート管理を必要とする。教訓は、管理アクセスを、より小さな攻撃対象領域、より強力なアイデンティティ、ネットワーク制限、ログ、変更管理、継続的な露出レビューを備えた特権インフラストラクチャとして扱うことである。リモート管理は、広範な公共のインターネット露出を通じてではなく、意図的な管理パスを通じて到達可能であるべきだ。

Cisco にとっての継続的な教訓は、セキュア・バイ・デザインの管理プレーンの姿勢である：安全でない露出を困難にし、危険な構成を可視化し、修正を追跡可能にし、検出ガイダンスを実用的にし、リリースマッピングを混乱させないこと。顧客と MSP にとっての教訓は、資産と露出の真実である：何が実行されているか、何が到達可能か、誰がそれを所有しているか、どのように無効にするか、どのように再構築するか、クリーンアップを証明する証拠が何かを知ること。

公的機関と規制当局にとっての教訓は、ネットワークデバイスの管理インターフェースが、主要なアプリケーション CVE と同様の可視性に値するということだ。侵害されたルーターやスイッチは、他のインシデントに関する証拠環境を歪めることができる。それは対応アーキテクチャ内部の盲点になり得る。それが管理プレーンの露出を、単なる IT 衛生問題ではなく、事業継続性リスクにしている。

Cisco IOS XE の 2023 年の Web UI 悪用の記録は、単純な結末を拒否するため価値がある。パッチは重要だった。ハードニングは重要だった。アドバイザリは重要だった。インベントリは重要だった。MSP の説明責任は重要だった。インプラントは重要だった。最も重要だったのは露出したインターフェースである。なぜなら、防衛側が完璧な情報を得る前に、どのデバイスが到達可能だったかを決定したからだ。

したがって、説明責任を果たす結論は実践的である。ネットワークデバイスは、所有者が管理 Web UI が世界に開かれていたことを発見する前に侵害されるべきではない。ベンダーは、ゼロデイが既に着弾した後に、顧客があらゆる安全でない露出を見つけることに依存すべきではない。プロバイダーは、証拠なしに「対応しました」と顧客に伝えるべきではない。管理プレーンセキュリティにおいて、信頼はブランドやパッチレベルに対する感情ではない。それは記録である：露出が閉じられ、侵害が評価され、ソフトウェアが修正され、必要に応じてデバイスが再構築され、ネットワークの権限が証明とともに回復されたことの。