レインボーテーブルの公開リリース:Net-NTLMv1廃止の加速

Net-NTLMv1ハッシュを対象とした事前計算済みレインボーテーブルの公開リリースは、オフラインパスワード復元の計算コストを大幅に削減する。レインボーテーブルは、ストレージ容量と計算時間をトレードオフする検索構造であり、ハッシュから平文への変換を数時間や数日ではなく数秒で可能にする(Oechslin, 2003)。このようなテーブルが公開されると、Net-NTLMv1ハッシュを保存するあらゆるシステムの脅威モデルは、理論的なものから運用上のものへと変化する。

• 前提*:この分析は、レインボーテーブルのリリースが発生し、配布に対する法的または技術的障壁なしに利用可能な状態が維持されることを前提としている。

プロトコル移行の経済的インセンティブ構造は、侵害のコストとアップグレードのコストの相対的な関係に依存する。組織は、移行の認識コストが侵害リスクの認識コストを上回る場合、レガシー認証プロトコルを維持する。公開レインボーテーブルの利用可能性は、侵害された認証情報データベースの攻略までの時間を数時間から数分に短縮することで、この計算を変える。Net-NTLMv1に依存する認証データベースを持つ中規模組織は、新たな運用上の現実に直面する:認証情報の侵害は、もはや検出と対応のための数時間を提供せず、数分しか提供しない。

• 必要なデータポイント*:クラック時間の短縮の定量化(例:8時間から2分への短縮)は、この主張を強化するが、ソース資料には提供されていない。

セキュリティ上の意味合いとして、組織はNet-NTLMv1の廃止を、他の優先事項と順序付けされる任意のアップグレードとして扱うことはできない。代わりに、レインボーテーブルの利用可能性は、許容可能な認証アーキテクチャに対するハード制約として機能する。セキュリティチームは、Net-NTLMv1認証にまだ依存しているシステムのインベントリを直ちに実施し、露出ウィンドウ(認証情報の侵害から検出までの時間)を定量化し、移行タイムラインを経営幹部スポンサーにエスカレーションすべきである。予算サイクルやベンダーロードマップに基づく延期は、レインボーテーブルが公開された時点で、許容できない運用リスクをもたらす。

システムアーキテクチャと移行のボトルネック

Net-NTLMv1が単独で存在することは稀である。これは、ドメインコントローラー、レガシーアプリケーション、VPNゲートウェイ、サードパーティ統合にまたがる複雑な認証スタック内の一層として機能する。この相互接続性は、セキュリティの緊急性や技術的能力に関係なく、廃止を遅らせるボトルネックを生み出す。

• 可視性の問題*

組織は理論的にはNet-NTLMv1を直ちに無効化できる。実際には、そうすることで文書化されていない認証チェーンが破壊される。レガシーERPシステムは、Active Directoryに対して認証するためにNet-NTLMv1を必要とする場合がある。サードパーティのセキュリティアプライアンスは、NTLMv2が失敗した場合にNet-NTLMv1にフォールバックする場合がある。これらの依存関係は、カットオーバーの試みが失敗するまで不明なままであることが多い。

500以上のアプリケーションを持つ医療機関がこのリスクを示している。セキュリティチームがドメインコントローラーでNet-NTLMv1を無効化したところ、数時間以内に3つの重要なシステムが失敗した:廃業したベンダーの医療画像システム、文書化されていない依存関係を持つカスタムスケジューリングツール、およびDHCP経由でNet-NTLMv1にデフォルト設定されたネットワークプリンター。組織は変更をロールバックし、Net-NTLMv1を有効なままにした。

• 段階的移行戦略*

ボトルネックは技術的能力ではなく、可視性と制御である。組織は、完全に理解していないプロトコルから移行することはできない。解決策には構造化されたアプローチが必要である:

1. すべての認証依存関係をマッピングする:認証に関わるすべてのシステム(アプリケーション、アプライアンス、統合、IoTデバイス)を文書化する。
2. 互換性を評価する:NTLMv2をサポートするシステム、設定変更が必要なシステム、交換が必要なシステムを特定する。
3. 段階的に移行を順序付ける:依存関係が最小限のシステムから始め、最も複雑なシステムに向けて構築する。
4. 本番カットオーバー前にテストする:カスケード障害を防ぐため、各段階をステージング環境で検証する。

この依存関係優先アプローチは、廃止を二者択一のオン/オフ決定から、Net-NTLMv1の露出を排除しながら運用の継続性を維持する管理された移行へと変換する。

• 図4：レガシーシステムの隠れた認証依存関係による可視性の問題。複雑に絡み合ったシステム構造の中で、未発見の脆弱性ポイントが隠蔽されている状況を表現。（データソース：コンセプトイメージ（AI生成））*

プロトコル移行のための参照アーキテクチャとガードレール

Net-NTLMv1の廃止を成功させるには、組織が実装し、運用コンテキストに適応できる正式に定義された参照アーキテクチャが必要である。このアーキテクチャは以下を指定する必要がある:(1)代替として許容可能な認証プロトコル、(2)各プロトコルのセキュリティ設定要件、(3)移行の完全性と有効性を確認するための検証基準と方法。

• 図5：段階的なプロトコル移行のための参照アーキテクチャとガードレール*

構造化された移行の理論的基礎

根底にある前提は、明示的な目標状態を欠く組織は、移行を反応的に実行し、既存のものを修復しながら新たなセキュリティギャップを導入する可能性があるということである。この仮定は、認証プロトコルの決定が、集中化されたポリシーではなく、システム展開の時点で行われることが多いという観察に基づいている。具体的な失敗モードには以下が含まれる:

• Net-NTLMv1を無効化しながら、NTLMv2を必須のメッセージ署名なしで残し、認証情報の傍受に対する脆弱性を保持する
• キー配布センター(KDC)インフラストラクチャを強化せずにKerberosに移行し、昇格された特権を持つ単一障害点を作成する
• 同等のセキュリティ制御を実施せずに、レガシーシステムを別のネットワークセグメントに分離し、リスクを排除するのではなく延期する

これらの部分的な移行は、セキュリティ態勢の改善という錯覚を生み出しながら、攻略可能な認証経路を残すため、監視されているNet-NTLMv1ベースラインと比較して組織のリスクを増加させる可能性がある。

規範的プロトコル階層

Net-NTLMv1廃止のための参照アーキテクチャは、暗号強度と既知の攻撃クラスに対する耐性に基づいて、以下のプロトコル優先順位を確立すべきである:

• ティア1(推奨):* Kerberos(RFC 4120)は、Windowsドメイン環境における推奨認証メカニズムである。Kerberosは時間制限付きチケットと相互認証を使用し、レインボーテーブル攻撃を可能にする認証情報送信パターンを排除する。実装には、機能的なKDCインフラストラクチャと同期されたシステムクロック(通常5分以内;RFC 4120、セクション5.3を参照)が必要である。

• ティア2(制約付きで許容可能):* NTLMv2(MS-NLMP、バージョン11.0以降で指定)は、技術的制限によりKerberosをサポートできないシステム(例:非ドメイン参加デバイスや、ハードコードされたNTLM依存関係を持つレガシーアプリケーション)に対して許容される。NTLMv2は、セッションごとのnonceを持つHMAC-MD5を使用し、各セッションのレインボーテーブル事前計算を実行不可能にする。ただし、NTLMv2は、拡張認証保護(EPA)またはチャネルバインディングで保護されていない場合、リレー攻撃に対して脆弱なままである。

• ティア3(非推奨):* EPAなしのNTLMバージョン1およびバージョン2は、新しいシステム、統合、またはグリーンフィールドインフラストラクチャに展開すべきではない。特にNet-NTLMv1は暗号学的に破られており(DES暗号化、MD4ハッシュ)、実行可能な場合は積極的に無効化すべきである。

セキュリティ設定要件

この階層を実装する組織は、以下の設定ガードレールを実施する必要がある:

• メッセージの完全性と機密性:* すべてのNTLMトラフィックは、メッセージ署名(完全性)とメッセージシーリング(機密性)の両方を実施する必要がある。Windows環境では、これはグループポリシーオブジェクト(GPO)設定を介して構成される:「ネットワークセキュリティ:NTLM SSP(セキュアRPCを含む)の最小セッションセキュリティ」は、NTLMv2セッションセキュリティと128ビット暗号化を要求するように設定すべきである。これにより、ダウングレード攻撃とパッシブな認証情報キャプチャが防止される。

• ドメインコントローラーのNTLM制限:* NTLM認証は、文書化されたレガシーシステム互換性のために明示的に必要な場合を除き、ドメインコントローラーで無効化すべきである。これは、「ネットワークセキュリティ:NTLM制限:受信NTLMトラフィック」GPO設定を介して実施される。組織は、NTLMフォールバックを必要とするシステムのインベントリを維持し、このインベントリを四半期ごとにレビューして、プロトコル移行の候補を特定すべきである。

• 拡張認証保護(EPA):* EPA(RFC 6578)は、NTLMセッションを基盤となるトランスポートチャネルにバインドし、中間者リレー攻撃を防止する。EPAは、特にHTTPベースのプロトコル(例:IIS、Exchange)のすべてのNTLM認証に対して有効化する必要がある。これには、サーバー側の設定とクライアントサポートの両方が必要である;組織は、グローバルに実施する前にEPA機能を検証すべきである。

• Kerberosの強化:* Kerberosが主要な認証メカニズムとして展開される場合、以下の制御が必要である:

• KDCインフラストラクチャは、制限された管理アクセスを持つ専用ネットワークセグメントに分離する必要がある

• Kerberosチケットの有効期間は保守的に設定すべきである(例:ユーザーチケットは10時間、更新可能チケットは7日間)、盗まれたチケットからの侵害ウィンドウを制限する

• サービスプリンシパル名(SPN)は一意に登録され、Kerberoasting攻撃を防ぐために検証される必要がある(SPN列挙に関するMicrosoftセキュリティアドバイザリを参照)

検証チェックポイントと検証方法

移行実行後、組織は目標状態が達成され、Net-NTLMv1への意図しないフォールバックが発生していないことを検証する必要がある。検証は3つのレベルで行うべきである:

• プロトコルトラフィック分析:* ドメインコントローラーおよび認証ゲートウェイインフラストラクチャにネットワーク監視を展開し、Net-NTLMv1認証試行を検出する。これは、Windowsイベントログ監査(NTLMログオン試行のイベントID 4776)またはNTLM署名パターンのパケット検査を使用したネットワークベースの検出を介して実現できる。予想されるトラフィックのベースラインを確立し、異常についてアラートを出す。

• システムインベントリ監査:* 環境内のすべてのシステムの包括的な監査を実施し、NTLMバージョン1がプロトコルレベルで無効化されていることを確認する。これには以下が含まれる:

• Windowsシステムに対してレジストリキーHKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0を照会し、NtlmMinClientSecとNtlmMinServerSecがNTLMv2を要求するように設定されていることを確認する

• レガシーアプリケーションが移行、分離、または廃止されたことを確認する

• サードパーティ統合(例:VPNクライアント、アプリケーションサーバー)がEPA付きのKerberosまたはNTLMv2をサポートすることを確認する

• 侵入テスト:* キャプチャされた認証トラフィックに対するレインボーテーブル攻撃が有効な認証情報を生成しなくなったことを確認するために、制御されたセキュリティテストを実施する。これには以下が含まれる:

• 制御されたラボ環境でNTLM認証交換をキャプチャする

• 公開されているレインボーテーブルを使用して、キャプチャされたハッシュを事前計算またはクラックしようとする

• 認証情報が復元されないことを確認する(Net-NTLMv1からの移行が成功したことを示す)

具体的な実装例

200人の開発者、50台のビルドサーバー、および内部システムへの認証に現在Net-NTLMv1に依存している30のサードパーティ統合を持つソフトウェア開発組織を考える。

• 目標状態の定義:*

• 開発者ワークステーション:会社のActive DirectoryドメインへのKerberos認証

• ビルドインフラストラクチャ:32文字以上のランダム生成パスワードを持つサービスアカウント、四半期ごとにローテーション;クラウドホスト型ビルドエージェントの証明書ベース認証

• サードパーティ統合:EPA有効化されたNTLMv2、認証サービスへのアクセスを制限するファイアウォールルールを持つ専用ネットワークセグメントに分離

• レガシーシステム:18ヶ月以内に廃止またはサポートされているプロトコルに移行

• 移行の順序付け:*

1. フェーズ1(第1～4週): すべての開発者ワークステーションのKerberos互換性を監査する。20台のワークステーションのパイロットグループでKerberos認証を設定する。認証失敗とアプリケーション互換性の問題を監視する。
2. フェーズ2(第5～8週): すべての開発者ワークステーションにKerberosを展開する。GPOを介して開発者ワークステーションでNTLMを無効化する。ユーザー受け入れテストを実施する。
3. フェーズ3(第9～16週): ビルドインフラストラクチャを移行する。クラウドエージェントの証明書ベース認証を実装する。オンプレミスビルドサーバーを強力なパスワードを持つサービスアカウントを使用するように再設定する。CI/CDパイプライン機能をテストする。
4. フェーズ4(第17～20週): サードパーティ統合を監査する。EPA付きNTLMv2をサポートするものを特定する。ファイアウォールルールを持つ分離されたネットワークセグメントを設定する。互換性のある統合を移行する;互換性のないものについては廃止または交換をスケジュールする。
5. フェーズ5(第21～26週): GPOを介してNet-NTLMv1をグローバルに無効化する。認証失敗についてイベントログを監視する。まだNet-NTLMv1を試行しているシステムを修復する。

• 検証チェックポイント:*
• フェーズ1後:パイロットワークステーションでの認証失敗ゼロ
• フェーズ2後:開発者ワークステーションの100%がKerberos経由で認証;ネットワークログでNet-NTLMv1トラフィックがゼロ検出
• フェーズ3後:ビルドパイプラインの成功率≥99%;NTLMフォールバックが観察されない
• フェーズ4後:すべてのサードパーティ統合が移行または分離;すべてのNTLMv2トラフィックでEPAが有効化
• フェーズ5後:30日間の監視期間中にNet-NTLMv1トラフィックが検出されない;侵入テストでレインボーテーブル攻撃が認証情報を生成しないことを確認

実行可能な推奨事項

組織は、Net-NTLMv1廃止の前および期間中に以下のステップを実行すべきである:

1. 目標認証アーキテクチャを明示的に文書化する、プロトコルの選択、設定基準、コンプライアンスマッピングを含む。この文書は、セキュリティ、インフラストラクチャ、およびコンプライアンスの利害関係者によってレビューおよび承認されるべきである。

2. アーキテクチャを組織のセキュリティ基準および規制要件に整合させる。 例えば、組織がPCI DSSの対象である場合、目標アーキテクチャがPCI DSS要件8.2.3(強力な認証)を満たすことを確認する。HIPAAの対象である場合、45 CFR § 164.312(a)(2)(i)への準拠を確認する。

3. 明示的なフェーズ、成功基準、およびロールバック手順を持つ移行プロジェクト計画を確立する。 各フェーズの所有権と説明責任を割り当てる。

4. 各フェーズで検証チェックポイントを実装し、目標状態が達成されていること、および意図しないセキュリティギャップが導入されていないことを確認する。

5. NTLMフォールバックを必要とするシステムのインベントリを維持し、プロトコル移行または廃止の候補を特定するためのレビューケイデンス(最低四半期ごと)を確立する。

大規模な廃止のための実装と運用パターン

組織規模でNet-NTLMv1から移行するには、変更管理の原則と測定可能なプロセス管理に基づいた運用規律が必要です。本セクションでは、大規模なプロトコル廃止で観察されたパターンを形式化し、成功に必要な前提条件を特定します。

基本的な前提:継続的プロセスとしての廃止

Net-NTLMv1の廃止を個別のプロジェクトとして扱う組織は、それを継続的な運用に組み込む組織よりも高い失敗率に遭遇するという中心的な主張は、以下の前提に基づいています:

1. 隠れた依存関係は包括的にではなく、反復的に発見される。 Net-NTLMv1を使用するレガシーシステムと文書化されていない統合は、修復が始まる前に完全に棚卸しすることはできません。無効化の各フェーズで、以前は知られていなかった依存関係が明らかになります。

2. 組織の記憶と所有権は、形式化された追跡なしに減衰する。 永続的なインベントリと割り当てられた説明責任がなければ、修復作業はチーム間で断片化し、停滞します。

3. ロールバック圧力は範囲とともに増加する。 すべてのシステムで同時に廃止を試みると、逆転を余儀なくされる可能性のある運用リスクが生じますが、段階的なアプローチでは封じ込めと解決が可能になります。

これらの前提は、大規模なインフラストラクチャ移行で観察されたパターンと一致していますが(Humble & Farley, 2010; Forsgren et al., 2018)、特定の組織コンテキスト内で検証する必要があります。

監視と検証を伴う段階的な無効化

• 定義と前提条件:* 段階的な無効化とは、認証インフラストラクチャ全体でNet-NTLMv1サポートを段階的に削除することであり、限定された範囲から始め、依存システムが修復または再構成されたことを検証した後にのみ拡大します。

• 実装の前提条件:*

• Net-NTLMv1認証が可能なすべてのシステム(ドメインコントローラー、クライアント、アプリケーション)のベースラインインベントリ

• プロトコルバージョンごとに認証試行を検出してログに記録できる監視インフラストラクチャ

• 割り当てられた所有者を持つ定義されたエスカレーションと修復ワークフロー

• 各フェーズについて文書化およびテストされたロールバック手順

• 運用パターン:*

1. パイロットフェーズ(認証インフラストラクチャの5〜10%): 定義されたユーザーまたはシステム集団にサービスを提供するドメインコントローラーまたは認証エンドポイントのサブセットでNet-NTLMv1を無効にします。定期的なワークロードと周期的なワークロードの両方を捕捉するために、最低2〜4週間、認証失敗を監視します。

2. 障害分析と修復: 検出された各Net-NTLMv1認証試行について、ソースシステムまたはアプリケーションを特定します。修復経路ごとに障害を分類します:プロトコルアップグレード(推奨)、構成変更、またはネットワーク分離。所有権を割り当て、解決タイムラインを確立します。

3. 検証と拡大: 検出された障害の修復後、次のフェーズ(例:インフラストラクチャの25%)に無効化を拡大します。監視と修復のサイクルを繰り返します。

4. 完了と強化: すべての認証インフラストラクチャでNet-NTLMv1が無効になったら、廃止を再有効化またはバイパスしようとする試みを検出するための監視を実装します。

• 証拠と前提:* タイムラインとフェーズの割合(5〜10%、25%、50%、100%)は例示的なものであり、組織のリスク許容度、システムの重要性、修復能力に合わせて調整する必要があります。修復速度が高い組織はフェーズを圧縮できます。複雑なレガシーシステムを持つ組織はそれらを延長する可能性があります。

自動検出、アラート、条件付き修復

• 定義:* 自動検出システムは、Net-NTLMv1認証試行をリアルタイムで識別し、アラートから条件付き分離までの事前定義された応答をトリガーします。

• 技術実装要件:*

• プロトコルバージョンを捕捉するように構成された認証ログインフラストラクチャ(例:ドメインコントローラーのWindows Event ID 4624、または非Windows環境での同等のもの)

• リアルタイムパターン検出が可能なログ集約および分析プラットフォーム

• アラートルーティングと追跡のためのチケットシステム統合

• アップグレードに失敗したシステムを分離するネットワークセグメンテーション機能

• 運用パターン:*

1. アラートと通知モデル: Net-NTLMv1試行を検出し、定義されたSLA内(例:1時間以内)にシステム所有者または責任チームにアラートを生成します。迅速な調査を可能にするために十分なコンテキスト(ソースシステム、ターゲットリソース、タイムスタンプ)を含めます。

2. 自動チケット作成: 検出をITサービス管理システムと統合して、事前定義された重大度と割り当てルールを持つ修復チケットを作成します。

3. 条件付き分離(高リスク環境): 高セキュリティ環境または機密データを処理するシステムの場合、Net-NTLMv1試行を拒否し、監視された分離されたネットワークセグメントにトラフィックをリダイレクトするように認証インフラストラクチャを構成します。これにより、完全なサービス損失を許可せずに可視性を維持し、修復を可能にしながら、Net-NTLMv1認証の成功を防ぎます。

• 前提と制限:* このパターンは以下を前提としています:
• 認証ログが有効化され、集中化されている(異種環境では普遍的に真実ではない)
• ビジネス運用を中断することなく非準拠システムを分離するための十分なネットワークセグメンテーションが存在する
• 許容可能な時間枠内でアラートに対処する修復能力が存在する

これらの前提条件を欠く組織は、自動修復を実装する前にそれらを確立することを優先すべきです。

インベントリとライフサイクル統合

• 定義:* 認証可能なシステム、サポートされているプロトコル、廃止ステータスのライブインベントリであり、IT資産管理および廃止ワークフローと統合されています。

• 最小データ要素:*

• システム識別子(ホスト名、IPアドレス、資産タグ)

• サポートされている認証プロトコル(Net-NTLMv1、Net-NTLMv2、Kerberos、SAMLなど)

• 廃止ステータス(準拠、修復進行中、ブロック済み、廃止済み)

• 責任所有者またはチーム

• 最終検証日

• 運用統合ポイント:*

• 資産取得: 新しいシステムは、調達時に文書化された必要なプロトコルサポートとともにインベントリに追加されます

• 修復追跡: システムがアップグレードまたは再構成されると、廃止ステータスが更新されます

• 廃止: システムが廃止されると、その認証依存関係は解決済みとしてマークされ、アーカイブされます

• 前提:* このパターンは以下を前提としています:

• 資産インベントリの単一の真実の情報源を確立し、維持できる

• 認証プロトコルコンプライアンスの所有権と説明責任を割り当てることができる

• 既存のITサービス管理システムとの統合が実現可能である

連邦制または高度に分散化された組織では、統一されたインベントリを維持するには、技術的実装を超えたガバナンスの変更が必要になる場合があります。

トレーニング、文書化、変更管理

• 根拠:* 廃止の成功は、技術的要件、タイムライン、および異なる役割(アプリケーション所有者、システム管理者、サポートスタッフ)に必要な特定のアクションに対する利害関係者の理解に依存します。

• 必要なコミュニケーション成果物:*

• エグゼクティブサマリー: ビジネス上の根拠(セキュリティリスクの削減、コンプライアンス要件)とタイムライン

• 技術文書: プロトコルの違い、アップグレード手順、テストガイダンス、トラブルシューティング

• 役割固有のガイド: アプリケーション所有者(認証ライブラリのアップグレード方法)、システム管理者(ドメインコントローラーの構成方法)、サポートスタッフ(Net-NTLMv1障害のエスカレーション方法)のための個別の手順

• FAQとエスカレーションパス: 予想される質問と未解決の問題に対する明確な所有権

• 配信メカニズム:*

• 主要な利害関係者グループのための正式なトレーニングセッション

• 影響を受けるすべてのチームがアクセスできる文書リポジトリ

• リーダーシップと共有される定期的なステータス更新と進捗メトリクス

• 質問とエスカレーションのための専用コミュニケーションチャネル(例:Slack、メール配信リスト)

• 前提:* このパターンは以下を前提としています:

• 利害関係者がプロトコルレベルの変更を理解するのに十分な技術リテラシーを持っている

• コミュニケーションチャネルとトレーニング能力が存在する

• 組織文化がチーム間の調整をサポートしている

具体的な運用例:大規模金融機関

• コンテキスト:* 10,000以上のドメイン参加エンドポイント、複数のレガシーアプリケーション、および12か月以内にNet-NTLMv1廃止を必要とする厳格なコンプライアンス要件(PCI-DSS、SOX)を持つ金融機関。

• 実装タイムラインと結果:*

フェーズ	タイムライン	範囲	検出された障害	修復アクション	ステータス
パイロット	1か月目	ドメインコントローラーの10%(500エンドポイント)	47システム	23アプリケーションアップグレード、18構成変更、6システムをさらなる調査のために分離	フェーズ2に拡大
拡大1	2か月目	ドメインコントローラーの25%(2,500エンドポイント)	追加で12システム	8アプリケーションアップグレード、4レガシーシステムを交換予定	フェーズ3に拡大
拡大2	3〜5か月目	ドメインコントローラーの50%(5,000エンドポイント)	追加で3システム	2ベンダー管理システムでベンダーサポートが必要、1カスタムアプリケーションでコードレビューが必要	フェーズ4に拡大
完了	6〜12か月目	ドメインコントローラーの100%(10,000エンドポイント)	新しい障害は0;継続的な監視で2回の再有効化試行を検出	両方の試行は不正な構成変更に起因;修復およびログ記録	完全な廃止を達成

• 主要な運用上の決定:*

• インフラストラクチャ、アプリケーション、セキュリティチーム間で調整する権限を持つ専任の廃止リードを割り当てた

• ブロッカーのエスカレーション権限を持つ週次ステータス会議を確立した

• Net-NTLMv1試行の1時間以内にアラートを生成する自動監視を実装した

• 事業単位ごとの廃止進捗を示す公開ダッシュボードを維持し、コンプライアンスのためのピアプレッシャーを生み出した

• 結果と教訓:*

• パイロットフェーズでの47件の障害(パイロット範囲の4.7%)は予想よりも大幅に多く、段階的アプローチを検証した

• フェーズ2での追加の12件の障害(拡大範囲の0.48%)は、パイロット集団が代表的でなかったことを示した;その後のフェーズにはより多様なシステムタイプが含まれた

• フェーズ3での3件の障害(拡大範囲の0.06%)は真に稀なシステムを表していた;完全なインベントリ検索ではそれらを特定できなかった

• 総修復作業:インフラストラクチャ、アプリケーション、セキュリティチーム全体で約8 FTE月

• Net-NTLMv1廃止に直接起因する本番停止はなし

• この例に組み込まれた前提:*

• 組織は2〜4週間以内に障害に対処するのに十分な修復能力を持っていた

• 管理されたシステムに対してベンダーサポートが利用可能だった

• レガシーシステムはビジネス運用を中断することなく分離できた

• エグゼクティブスポンサーシップが12か月間にわたって取り組みを維持した

実行可能な推奨事項

1. 定義されたゲートを持つ複数フェーズの運用として廃止を計画する。 すべてのシステムで同時に無効化を試みないでください。フェーズの進行のための明確な基準を確立します(例:2週間未解決の障害がゼロ、95%のシステムが準拠として検証済み)。

2. 監視と修復のための専用リソースを割り当てる。 廃止はパートタイムの活動ではありません。明示的な権限と説明責任を持つ廃止リードを割り当て、継続的な監視と修復作業のための予算を確保します。

3. 明確な所有権とエスカレーションパスを確立する。 各システムまたはアプリケーションには、修復に責任を持つ識別された所有者が必要です。所有権が不明確または修復がブロックされているシステムのためのエスカレーション手順を定義します。

4. 廃止を資産ライフサイクル管理に統合する。 認証プロトコルコンプライアンスが他の資産属性とともに追跡され、廃止ワークフローに認証依存関係の廃止が含まれることを確認します。

5. 組織コンテキスト内で前提を検証する。 ここで説明されているパターンは一般化です。実装前に、前提条件(インベントリ能力、監視インフラストラクチャ、修復能力、組織構造)が存在するか、確立できることを確認してください。

非推奨化進捗の測定と検証

基礎的な前提と定義

Net-NTLMv1非推奨化の進捗測定には、観測可能な認証イベントとシステムインベントリ状態に紐づいた運用可能なメトリクスが必要である。本セクションでは以下を前提とする:(1)組織がNet-NTLMv1認証が可能なシステムの確定的なインベントリを保持している、または構築できる;(2)認証プロトコルの使用状況を捕捉するためのネットワーク監視インフラストラクチャが存在する、または展開できる;(3)修復アクション(プロトコルのアップグレード、システムの廃止、またはネットワーク分離)が個別に識別可能でタイムスタンプが付与されている;(4)ステークホルダーへの報告が文書化されたベースラインとともに定義された間隔で行われる。

測定が非推奨化の完了を加速し、後退を減少させるという根本的な前提は、2つのメカニズムに基づいている:可視性がリソース配分の意思決定を可能にすること、および説明責任が持続的な取り組みに対する組織的圧力を生み出すこと。しかし、この前提には条件が必要である:測定だけでは進捗を保証しない。組織はメトリクスを意思決定権限とリソース配分と結びつけなければならない。修復能力のない測定は、成果のないデータを生み出すだけである。

中核メトリクスと測定の前提条件

• インベントリカバレッジ*

定義:組織の認証スコープ内のシステムのうち、Net-NTLMv1依存性について評価されたシステムの割合。総システム数に対するパーセンテージで表現される。

測定の前提条件:

• 構成管理データベース(CMDB)または同等の記録システムで維持される確定的なインベントリが存在する
• 「評価」が運用上定義されている:直接的なプロトコル分析、ベンダードキュメントのレビュー、またはプロトコル機能を確認するネットワークトラフィック検査のいずれか
• システムが認証スコープ別に分類されている(例:ドメイン参加Windowsシステム、NTLMライブラリを持つUnixシステム、IoTデバイス、サードパーティアプリケーション)

測定方法:評価済みシステムをスコープ内の総システム数で除算する。定義された間隔で繰り返す(アクティブな非推奨化プログラムには週次を推奨)。

目標:プログラム開始から30日以内に100%のインベントリ評価。この目標は適切な人員配置とシステムドキュメントへのアクセスを前提とする。断片化されたIT環境(複数のドメイン、買収した子会社、シャドーIT)を持つ組織は60～90日を要する場合がある。

• 修復率*

定義:Net-NTLMv1依存と識別されたシステムのうち、修復を完了した(NTLMv2またはKerberosへのプロトコルアップグレード、システムの廃止、または補償統制を伴う承認されたネットワーク分離)システムの割合。

測定の前提条件:

• 修復アクションが完了タイムスタンプとともに記録されている
• 「完了」が定義されている:アップグレードの場合は新しいプロトコルによる認証の成功;廃止の場合はネットワークからの削除;分離の場合はネットワークセグメンテーションと代替認証プロトコルの強制
• システムが重要度別に階層化されている(本番、非本番、レガシー)。修復速度がカテゴリによって異なるため

測定方法:修復済みシステムを識別された総Net-NTLMv1依存システム数で除算する。システムカテゴリ別に個別に追跡する。

目標:非重要システムで月10%;重要システムで月5%。これらの目標はベンダーパッチが利用可能でテストウィンドウがスケジュールされていることを前提とする。ベンダーサポートがないシステムやカスタムアプリケーションを持つシステムはこれらの目標を満たせない可能性があり、代替緩和策(分離、交換計画)が必要となる。

• Net-NTLMv1認証トラフィック量*

定義:環境全体で検出されたNet-NTLMv1認証試行の絶対数。単位時間あたり(通常は1日あたり)。

測定の前提条件:

• ドメインコントローラ、認証プロキシ、またはNet-NTLMv1トラフィックが通過するネットワークセグメントにネットワーク監視が展開されている
• トラフィック分類がNet-NTLMv1をNTLMv2およびKerberosから正しく区別する(プロトコル対応監視またはパケット検査が必要)
• 修復開始前にベースライントラフィックが確立され、トレンド分析が可能になっている
• トラフィックには正当な認証と偵察または攻撃トラフィックの両方が含まれる可能性がある;量だけではセキュリティ態勢を示さない

測定方法:Net-NTLMv1プロトコル指標について認証ログまたはネットワークテレメトリをクエリする。日別に集計する。時系列としてプロットする。

目標:ゼロへの着実な減少。減少率は修復率と相関すべきである;システムが修復されるよりも速くトラフィックが減少する場合、未発見のシステムが独立して修復している可能性がある、またはトラフィックにNTLMの非認証用途(例:SMB署名)が含まれている可能性がある。トラフィックが予想より遅く減少する場合、未識別の依存関係または攻撃者が偵察のために意図的にNet-NTLMv1を使用していないか調査する。

• 検出カバレッジ*

定義:Net-NTLMv1認証トラフィックを検出およびログ記録できるネットワークインフラストラクチャの割合。

測定の前提条件:

• 検出ポイントが識別されている:ドメインコントローラ、認証プロキシ、ネットワークTAP、またはエンドポイントエージェント
• 検出機能がテストされている(例:テストNet-NTLMv1トラフィックを生成し、ログに表示されることを確認)
• カバレッジにはインバウンド認証(クライアントがサーバーに認証)とラテラルムーブメント(システム間認証)の両方が含まれる

測定方法:アクティブな監視を持つ検出ポイントを総認証インフラストラクチャコンポーネントで除算する。ネットワークベースの検出の場合、監視されたネットワークセグメントを総セグメント数で除算する。

目標:ドメインコントローラと重要なネットワークセグメント(機密データまたは重要な機能を処理するシステムを含むセグメントと定義)の100%。非重要セグメントはリスク許容度が許せばより低いカバレッジでもよいが、これは文書化すべきである。

• 修復時間(リードタイム)*

定義:Net-NTLMv1依存性の発見から修復完了までの経過時間。

測定の前提条件:

• 発見タイムスタンプが記録されている(例:インベントリ評価、ネットワーク検出、またはベンダー通知から)
• 完了タイムスタンプが記録されている
• リードタイムがシステムの重要度と修復方法(アップグレード vs. 廃止 vs. 分離)別に階層化されている

測定方法:各システムについて完了タイムスタンプから発見タイムスタンプを引いて計算する。カテゴリ別に集計し、中央値と95パーセンタイルを計算する。

目標:非重要システムで中央値30日未満;重要システムで中央値7日未満。95パーセンタイルは非重要システムで60日、重要システムで14日を超えないこと。これらの閾値を超えるシステムは、ブロッカー(例:ベンダーの遅延、テストのバックログ、リソース制約)を識別するためのエスカレーションをトリガーすべきである。

• 図11：廃止実行時の多層的リスク要因と相互影響関係*

実践における測定:例示的ケース

医療機関が以下のベースライン(第0週)でNet-NTLMv1非推奨化を開始する:

• 認証スコープ内の総システム数:2,847(Windowsドメイン参加システム、NTLM機能を持つUnixシステム、医療機器、サードパーティアプリケーション)

• インベントリ評価状況:18%完了

• 検出されたNet-NTLMv1トラフィック:1日あたり14,200認証試行

• 検出カバレッジ:87%(ドメインコントローラと主要ネットワークセグメントが監視されている;リモートサイトとレガシー医療機器ネットワークはまだ計装されていない)

• 第4週チェックポイント:*

• インベントリ評価:100%完了。発見:341システム(スコープの12%)がNet-NTLMv1をアクティブに使用。このうち89が重要(医療画像システム、EHRサーバー)、156が非重要(ワークステーション、テストシステム)、96がベンダーサポートのないレガシー。

• 修復進捗:28システム(Net-NTLMv1依存システムの8%)が修復済み。すべてNTLMv2にアップグレードされた非重要ワークステーション。

• Net-NTLMv1トラフィック:1日あたり13,800試行(2.8%減少)。わずかな減少は、修復されたシステムがトラフィック量の小さな部分を占めることを示唆;ほとんどのトラフィックは96のレガシーシステムと89の重要システムからまだ修復されていないものから発生。

• 検出カバレッジ:100%達成。リモートサイトと医療機器ネットワークが現在計装されている。

• 第10週チェックポイント:*

• 修復進捗:156の非重要システム(Net-NTLMv1依存システムの46%)が修復済み。修復時間の中央値:21日。重要システムの修復:89のうち34(38%)完了。重要システムの修復時間の中央値:18日(優先的なテストと変更管理により高速)。レガシーシステム:96のうち0が修復済み;分離と交換計画が進行中。

• Net-NTLMv1トラフィック:1日あたり4,100試行(ベースラインから71%減少)。トラフィック減少は非重要システムの修復と相関;重要システムのトラフィックは依然として高い。

• リードタイム分析:95パーセンタイル修復時間は非重要システムで35日(目標内)、重要システムで24日(目標内)。1つの重要システム(レガシーEHRインターフェース)が42日で目標を超過;エスカレーションによりベンダーパッチの遅延が判明。

• 第20週チェックポイント(最終状態):*

• 修復進捗:341のNet-NTLMv1依存システムのうち245(72%)が修復または廃止済み。96のレガシーシステムが専用ネットワークセグメントに分離され、分離境界で拡張認証保護(EPA)付きNTLMv2が強制されている。12ヶ月のタイムラインで交換調達が開始された。

• Net-NTLMv1トラフィック:メインネットワークで1日あたり0試行。分離されたレガシーセグメントで1日あたり340試行(予想され監視されている)。

• 検出カバレッジ:100%維持。

検証と解釈

測定の妥当性は一貫した定義と検出精度に依存する。組織は以下を通じてメトリクスを検証すべきである:

1. スポットチェック:「修復済み」と分類されたシステムのサンプルを手動で検証し、プロトコルのアップグレードまたは廃止を確認する。
2. トラフィック相関:検出されたNet-NTLMv1トラフィックをインベントリと相互参照し、まだ修復されていないシステムまたは未発見の依存関係を識別する。
3. ステークホルダーレビュー:技術およびビジネスステークホルダーに月次でメトリクスを提示し、解釈の不一致やデータ品質の問題を識別する。

メトリクスはその限界を認識して解釈すべきである:

• インベントリカバレッジは評価の完全性を反映するが、修復準備状況ではない。システムはNet-NTLMv1依存と評価されても、利用可能なパッチや交換オプションがない場合がある。
• 修復率は、残りのシステムがレガシーまたは重要で、より長いテストや交換計画を必要とする場合、プラトーに達する可能性がある。修復率の低下は必ずしもプログラムの失敗を示さない;予想される難易度曲線を反映している可能性がある。
• トラフィック量は、トラフィックが少数の高ボリュームシステムに集中している場合、修復率と線形に減少しない可能性がある。より速いトラフィック削減を達成するために高トラフィックシステムの修復を優先する。
• 検出カバレッジのギャップは盲点を作る。監視されていないネットワークセグメントには未発見のNet-NTLMv1使用が含まれる可能性がある。

• 図3：複雑な認証スタックにおけるNet-NTLMv1の多層的な依存関係と相互依存構造*

実行可能な示唆

組織は以下を行うべきである:

1. **修復開始前にベースラインメトリクスを確立する。**安定したベースラインを確立するために、少なくとも1週間、インベントリカバレッジ、Net-NTLMv1トラフィック量、検出カバレッジ、修復時間を測定する。
2. **アクティブな修復中は週次でメトリクスを追跡する。**週次のケイデンスにより、ボトルネック(例:テストの遅延、ベンダーの遅延、リソース制約)の迅速な識別が可能になる。
3. **月次でステークホルダーに進捗を報告する。**エグゼクティブスポンサーと技術チームにベースライン、現在の状態、トレンド、予測を伝える。リスクとリソースニーズを強調する。
4. **メトリクスを使用して修復戦略を調整する。**修復率が目標を下回る場合、原因(ベンダーの遅延、テストのバックログ、リソース制約)を調査し、リソースを再配分する。トラフィック減少が予想より遅い場合、高トラフィックシステムを優先する。
5. **前提と限界を文書化する。**メトリクスがどのように定義、測定、解釈されるかを明確に述べる。検出またはインベントリカバレッジの既知のギャップを文書化する。

---

廃止実行におけるリスクと軽減戦略

リスクフレームワークと前提条件

Net-NTLMv1の廃止は、積極的に特定、評価、軽減しなければならない運用上およびセキュリティ上のリスクをもたらします。本セクションでは以下を前提とします:(1)組織がNet-NTLMv1に依存するシステムとアプリケーションを特定している(上記の測定フレームワークを通じて);(2)修復アクション(プロトコルのアップグレード、廃止、隔離)には実行リスクが伴う;(3)攻撃者はNet-NTLMv1レインボーテーブルを所有しているか入手可能であり、パッチが適用されていないシステムを悪用する;(4)組織は認証ベースの攻撃を検出し対応するインシデント対応能力を持っている。

廃止の失敗は主にレガシーシステムの複雑さを過小評価し、リスク軽減への投資不足から生じるという基本的な前提は、大規模な廃止プログラム(例:Windows XPのサポート終了、TLS 1.0の廃止)からの経験的観察に基づいています。しかし、この前提には条件が必要です:技術的課題(例:ベンダーの不在、カスタムアプリケーションの依存関係)も廃止の遅延に寄与します。リスク軽減はすべての遅延を排除することはできませんが、その深刻度と期間を減らすことができます。

特定されたリスクと軽減戦略

• リスク1:未発見のNet-NTLMv1依存関係が認証障害を引き起こす*

• リスクの説明:* Net-NTLMv1に依存するシステムまたはアプリケーションが、インベントリ評価中に特定されないまま残っています。Net-NTLMv1が無効化されると(組織全体または特定のシステムで)、これらの未発見の依存関係が失敗し、認証障害とサービス中断を引き起こします。

• 可能性と影響:* レガシーシステム、サードパーティアプリケーション、またはシャドーITを持つ大規模で異種混在の環境では、可能性は中程度から高いです。影響は高いです:認証障害は重要なサービス(例:EHRアクセス、製造制御システム、金融取引)を無効化する可能性があります。

• 軽減戦略:*

• Net-NTLMv1を無効化する前に、徹底的な依存関係マッピングを実施します。複数の発見方法を使用します:(1)ネットワークトラフィック分析により、Net-NTLMv1トラフィックを生成するすべてのシステムを特定;(2)サポートされている認証プロトコルについてベンダードキュメントをレビュー;(3)Net-NTLMv1を無効化したステージング環境でのアプリケーションテスト;(4)システム所有者およびアプリケーションチームへのインタビュー。

• 変更を加える前に、少なくとも30日間Net-NTLMv1トラフィックを監視します。このベースラインは、どのシステムがNet-NTLMv1を積極的に使用しているか、どの程度の量かを確立します。この期間中にトラフィックを生成しないシステムは、おそらくNet-NTLMv1に依存していません(ただし、証拠の不在は不在の証拠ではありません;休止状態のシステムは修復後に起動する可能性があります)。

• ロールバック機能を備えた段階的な無効化アプローチを実装します。組織全体でNet-NTLMv1を無効化するのではなく、まずシステムまたはネットワークセグメントのサブセットで無効化します。認証失敗を監視します。失敗が発生した場合は、原因を調査し、無効化範囲を拡大する前に修復します。重要な依存関係が発見された場合にNet-NTLMv1を再有効化できる能力を維持します。

• カットオーバーウィンドウ中に24時間365日のインシデント対応チームを維持します。認証ログを監視し、リアルタイムで認証失敗に対応するオンコールスタッフを配置します。必要に応じてNet-NTLMv1を迅速に再有効化するためのエスカレーション手順を確立します。

• 残存リスク:* 徹底的な発見を行っても、特に資産の可視性が低い環境やカスタムアプリケーションでは、未発見の依存関係が残る可能性があります。組織は、ある程度の残存リスクは避けられないことを受け入れ、迅速な対応を計画する必要があります。

---

• リスク2:レガシーシステムをアップグレードできず、Net-NTLMv1のままにしなければならない*

• リスクの説明:* Net-NTLMv1に依存するシステムまたはアプリケーションは、次の理由でアップグレードできません:(1)ベンダーがシステムをサポートしなくなり、パッチが利用できない;(2)システムがカスタムビルドまたはサポート終了でアップグレードパスがない;(3)アップグレードには高価なハードウェアまたはソフトウェアの交換が必要;または(4)システムが非常に重要であるため、アップグレードのテストと展開のリスクが受け入れられないと判断される。

• 可能性と影響:* レガシーシステム(例:医療機器、産業制御システム、メインフレームアプリケーション)を持つ組織では、可能性は高いです。影響は中程度から高いです:これらのシステムがNet-NTLMv1を使用してメインネットワーク上に残っている場合、永続的なセキュリティ脆弱性を生み出し、組織全体のNet-NTLMv1廃止を妨げます。

• 軽減戦略:*

• レガシーシステムをアクセスが制限された別のネットワークセグメント(VLANまたは物理ネットワーク)に隔離します。レガシーセグメントからメインネットワークへの横方向の移動を防ぐために、ネットワークレベルの制御を実装します。

• 隔離境界で拡張認証保護(EPA)を備えたNTLMv2を強制します。これにより、レガシーセグメント上の攻撃者が、キャプチャされたNet-NTLMv1認証情報を使用してメインネットワーク上のシステムに認証することを防ぎます。EPAは認証をTLSチャネルにバインドし、リレー攻撃を防ぎます。

• レガシーセグメントに追加の監視とアクセス制御を実装します:(1)すべての認証試行を監視し、異常についてアラートを出す;(2)レガシーセグメントに認証できるシステムを制限する(例:指定された管理者のみ);(3)レガシーシステムへのすべてのアクセスをログに記録;(4)技術的に実現可能な場合、レガシーセグメントへのアクセスに多要素認証を実装する。

• レガシーシステムの交換または廃止のタイムラインを確立します。これらのシステムをメインネットワーク上に無期限に残すことを許可しないでください。交換または廃止の目標日(例:12〜24か月)を定義し、この目標を達成するための予算とリソースを割り当てます。

• 隔離がリスクを排除すると仮定しないでください。隔離は攻撃対象領域を減らしますが、それを排除するものではありません。攻撃者はレガシーセグメント上のシステムを侵害し、それをメインネットワークを攻撃するためのピボットポイントとして使用する可能性があります。攻撃者がレガシーセグメントを悪用しようとすることを想定し、警戒的な監視を維持します。

• 残存リスク:* 隔離されたレガシーシステムは潜在的な攻撃ベクトルのままです。環境に残っている期間が長いほど、累積リスクは高くなります。組織は交換または廃止のタイムラインにコミットし、それを実行する必要があります。

---

• リスク3:廃止が完了する前に攻撃者がNet-NTLMv1を悪用する*

• リスクの説明:* 攻撃者がNet-NTLMv1レインボーテーブルを入手し

結論と移行ロードマップ

脅威の状況と廃止の必要性

Net-NTLMv1の廃止は、推奨されるセキュリティ慣行から運用上の必須事項へと移行しました。レインボーテーブル、特にNet-NTLMv1認証交換から迅速な認証情報復元を可能にする事前計算済みハッシュテーブルの公開により、プロトコルのセキュリティモデルが依存する暗号学的前提が排除されます。Microsoftは2010年にNet-NTLMv1を非推奨とし、Windows 8およびWindows Server 2012でデフォルトで無効化しました(Microsoft, 2014)。しかし、後方互換性の要件とレガシーシステムの依存関係により、多くのエンタープライズ環境でその運用上の存在が長引いています。アクセス可能なレインボーテーブルリポジトリの出現は、リスク計算を根本的に変えます。このプロトコルは、理論的な弱点ではなく、実証可能で悪用可能な脆弱性を提示するようになりました。

移行フレームワーク:前提条件と事前条件

以下の移行ロードマップは次のことを前提としています:

1. 組織の範囲: 組織は、文書化されたドメインコントローラーインフラストラクチャとアプリケーションインベントリを持つWindowsベースのActive Directory環境を運用しています。

2. ベースライン認証アーキテクチャ: 現在のシステムは、Kerberos、NTLMv2、Net-NTLMv1の何らかの組み合わせを採用しており、フォールバック動作が文書化されています。

3. リソースの可用性: 移行の実行には、専任の人員、予算配分、および経営陣のスポンサーシップが必要です。これらのリソースを持たない組織は、進行する前に経営陣のコミットメントを確保することを優先すべきです。

4. 許容可能なリスク許容度: 組織は、脅威モデリングと規制要件(例:NIST サイバーセキュリティフレームワーク、業界固有のコンプライアンス基準)に基づいて、Net-NTLMv1のエクスポージャーがリスクフレームワーク内で許容できないと判断しています。

5. システムの置き換え可能性: システムの重要なサブセットは、12か月の期間内にアップグレード、隔離、または廃止できます。

これらの事前条件を満たすことができない組織は、このロードマップを実装する前に基礎的なギャップに対処する必要があります。

フェーズ1:評価と計画(1日目~30日目)

• 目的*: ベースライン状態を確立し、依存関係を特定し、詳細な移行計画を構築する。

• 1.1 環境監査*

環境全体でのNet-NTLMv1使用状況の包括的なインベントリを実施します:

• ドメインコントローラー構成: ドメインコントローラーのグループポリシーオブジェクト(GPO)を照会して、Net-NTLMv1サポート状態を特定します。Get-ADDomainおよびGet-ADGroupPolicy PowerShellコマンドレットを使用して、現在の認証ポリシー設定を文書化します。

• ネットワークトラフィック分析: パケットキャプチャまたはネットワーク監視ツール(例:Wireshark、ネットワークTAP)を展開して、アクティブなNet-NTLMv1認証交換を特定します。LM応答フィールドを持つNTLM Type 3メッセージをフィルタリングします。これはNet-NTLMv1の使用を示します(RFC 2478)。

• ドメインコントローラーイベントログ: セキュリティイベントログ(イベントID 4776 – NTLM認証試行)を有効化してレビューし、Net-NTLMv1認証を開始しているシステムを特定します。注意:イベントID 4776はデフォルトでNTLMv1とNTLMv2を区別しません。補足的なログ記録またはネットワーク分析が必要です。

• アプリケーション構成レビュー: アプリケーション構成ファイル、サービスアカウント、およびサードパーティ統合を監査して、明示的なNet-NTLMv1依存関係またはフォールバック仕様を確認します。

• 成果物*: Net-NTLMv1を使用しているシステム、アプリケーション、およびサービスを指定するインベントリ文書。使用頻度と影響を受けるネットワークセグメントを含みます。

• 1.2 重要度と置き換え可能性の評価*

特定された各システムについて、以下を文書化します:

• ビジネス上の重要度: 利用不可時の組織への影響に基づいて、ミッションクリティカル、重要、または非クリティカルとして分類します。

• アップグレードの実現可能性: システムが機能低下なしにNTLMv2またはKerberosをサポートするようにパッチ適用、更新、または再構成できるかどうかを判断します。ベンダー文書を参照し、非本番環境でテストします。

• 隔離の実現可能性: Net-NTLMv1を無効化できない場合でも、システムをアクセスが制限されたネットワークセグメントに配置して、エクスポージャーを削減できるかどうかを評価します。

• 廃止の実現可能性: システムの機能を最新の代替手段で置き換えることができるか、またはシステムが真にライフサイクル終了であるかを評価します。

• 成果物*: 各システムを4つのカテゴリのいずれかにマッピングする重要度マトリックス:(1)アップグレード可能、(2)隔離可能、(3)廃止可能、(4)さらなる分析が必要。

• 1.3 廃止ガバナンス構造*

正式なガバナンスを確立します:

• スポンサーシップ: CISOまたは同等の権限を持つ経営陣のスポンサーシップを確保します。

• オーナーシップ: インフラストラクチャ、アプリケーション、およびビジネスユニット間で調整する権限を持つ単一のオーナー(例:アイデンティティおよびアクセス管理リード)を指定します。

• 部門横断チーム: インフラストラクチャ、アプリケーション、セキュリティ、および事業継続性の代表者を含めます。

• エスカレーションパス: 例外、遅延、およびリソース競合に対する意思決定権限を定義します。

• コミュニケーション計画: ステークホルダーの更新、リスク報告、および進捗追跡のための頻度を確立します。

• 成果物*: 役割、責任、意思決定権限、およびコミュニケーションスケジュールを文書化したガバナンス憲章。

• 1.4 ターゲット認証アーキテクチャ*

廃止後の認証モデルを定義します:

• 主要メカニズム: サポート可能なすべてのシステムに対してKerberos(RFC 4120)。Kerberosは、NTLMバリアントよりも優れた相互認証、セッションキー確立、および委任機能を提供します。

• フォールバックメカニズム: Kerberosをサポートできないシステムに対して、拡張認証保護(EPA、RFC 6578)を備えたNTLMv2。EPAは、認証を基盤となるトランスポートチャネルにバインドすることで、中間者攻撃を軽減します。

• 非推奨メカニズム: Net-NTLMv1はグローバルに無効化されます。ただし、文書化されたビジネス正当化と補償統制を持つ明示的に隔離されたネットワークセグメントを除きます。

• レガシーサポートセグメント: レガシーシステムをアップグレードまたは廃止できない場合、制限されたアクセス、強化された監視、および期限付き例外(例:6か月のレビューサイクル)を持つ隔離されたネットワークセグメントを定義します。

• 成果物*: プロトコル階層、フォールバックロジック、および例外基準を指定する認証アーキテクチャ文書。

• 1.5 段階的移行計画*

以下を含む詳細な移行計画を構築します:

• フェーズシーケンス: システムの重要度と複雑さに基づいてフェーズを定義します(例:フェーズ1:非クリティカルシステム、フェーズ2:重要なシステム、フェーズ3:ミッションクリティカルシステム)。

• マイルストーン: 各フェーズの測定可能な完了基準を指定します(例:「フェーズ1のシステムの100%がアップグレードまたは隔離された」)。

• リソース配分: 各フェーズに必要な人員、予算、および外部ベンダーサポートを見積もります。

• リスク軽減: 各フェーズのロールバック手順、緊急時対応計画、およびコミュニケーションプロトコルを特定します。

• タイムライン: テスト、変更管理、および組織の能力を考慮した現実的なタイムラインを確立します。エンタープライズ環境では12か月のタイムラインが一般的です。範囲が小さい組織は6か月で移行を完了できる場合があります。

• 成果物*: ガントチャート、リソース配分、リスク登録簿、および成功基準を含む詳細なプロジェクト計画。

---

フェーズ2:修復と移行(31日目~90日目)

• 目的*: 初期修復を実行し、監視を確立し、移行メカニズムを検証する。

• 2.1 段階的Net-NTLMv1無効化*

ドメインコントローラーでのNet-NTLMv1サポートを段階的に無効化し始めます:

• フェーズ1(非クリティカルシステム): 非クリティカルシステムのみを提供するドメインコントローラーでNet-NTLMv1を無効化します。認証失敗を監視し、特定された依存関係を修復します。

• 無効化方法: ドメインコントローラーでグループポリシーオブジェクト「ネットワークセキュリティ:NTLM を制限する:受信 NTLM トラフィック」を「すべて拒否」に設定します。または、ドメインレベルで「ネットワークセキュリティ:NTLM を制限する:このドメインでの NTLM 認証」を「すべて拒否」に設定します(Microsoft, 2016)。

• 検証: 無効化後にNet-NTLMv1認証試行がログに記録されていないことを確認します。セキュリティイベントログ(イベントID 4776)とネットワーク監視を使用して検証します。

• 注意*: 無効化は、ロールバック機能を持つ制御されたフェーズで実行する必要があります。時期尚早または調整されていない無効化は、本番環境の停止のリスクがあります。

• 2.2 自動検出とアラート*

Net-NTLMv1トラフィックの継続的な監視を実装します:

• ネットワークベースの検出: ネットワーク監視ツールを展開して、LM応答フィールドを持つNTLM Type 3メッセージを特定します。検出されたNet-NTLMv1認証試行に対してアラートを構成します。

• ログベースの検出: ドメインコントローラーでセキュリティイベントログ(イベントID 4776)を有効化して監視します。Net-NTLMv1認証試行に対してアラートするようにSIEMまたはログ集約ツールを構成します。

• アラートしきい値: 予想されるレガシートラフィックと異常なアクティビティを区別するためのアラートしきい値を定義します。例えば、Net-NTLMv1トラフィックがベースラインを50%超えるか、予期しないネットワークセグメントから発信される場合にアラートします。

• エスカレーション手順: 調査タイムラインと修復責任を含む、アラートのエスカレーション手順を定義します。

• 成果物*: セキュリティ運用ランブックに文書化された監視構成とアラート手順。

• 2.3 依存関係の修復*

特定されたNet-NTLMv1依存関係に対処します:

• システムアップグレード: 「アップグレード可能」と分類されたシステムについて、NTLMv2またはKerberosサポートを有効にするために、ベンダー推奨のパッチ、更新、または構成変更を実行します。本番環境への展開前に、非本番環境で徹底的にテストします。

• アプリケーション再構成: 明示的なNet-NTLMv1依存関係を持つアプリケーションについて、アプリケーション所有者と協力して認証設定を再構成し、認証情報を更新するか、回避策を実装します(例:サービスアカウントの変更、認証情報の委任)。

• レガシーシステムの隔離: 「隔離可能」と分類されたシステムについて、ファイアウォール、VLAN、またはソフトウェア定義ネットワーキングを使用してネットワークセグメンテーションを実装し、アクセスを制限します。隔離範囲を文書化し、四半期ごとに例外をレビューします。

• システムの廃止: 「廃止可能」と分類されたシステムについて、廃止手順を実行し、ワークロードを最新の代替手段に移行します。

• 成果物*: 実行されたアクション、アップグレードされたシステム、隔離されたシステム、および廃止されたシステムを文書化した修復状況レポート。

• 2.4 ステークホルダートレーニング*

認証インフラストラクチャとアプリケーションサポートを担当する人員向けのトレーニングを実施します:

• インフラストラクチャチーム: 新しい認証アーキテクチャ、Kerberosトラブルシューティング、NTLMv2構成、および監視手順についてトレーニングします。

• アプリケーション所有者: 認証プロトコル要件、フォールバック動作、および認証失敗のトラブルシューティング手順についてトレーニングします。

• ヘルプデスク: 一般的な認証問題、トラブルシューティング手順、およびエスカレーションパスについてトレーニングします。

• 成果物*: トレーニング完了記録と能力評価。

• 2.5 進捗メトリクス*

メトリクスを確立し、追跡を開始します:

• 廃止カバレッジ: アップグレード、隔離、または廃止されたシステムの割合。

• Net-NTLMv1トラフィック量: 時間経過に伴うNet-NTLMv1認証試行の絶対量と相対量。

• 認証成功率: KerberosまたはNTLMv2(EPA)で成功した認証試行の割合。

• インシデント率: 認証関連のインシデントまたは停止の数。

• 成果物*: 週次または隔週で更新されるメトリクスダッシュボード。トレンド分析と差異説明を含みます。

---

フェーズ3:完了と検証(91日目~365日目)

• 目的*: Net-NTLMv1廃止を完了し、セキュリティ態勢を検証し、長期的なメンテナンス手順を確立する。

• 3.1 包括的な廃止*

明示的に隔離されたレガシーサポートセグメントを除くすべてのシステムでNet-NTLMv1無効化を完了します:

• ドメインコントローラー構成: 「ネットワークセキュリティ:NTLM を制限する:このドメインでの NTLM 認証」を「すべて拒否」に設定して、ドメインレベルでNet-NTLMv1を無効化します(Microsoft, 2016)。

• ワークステーション構成: 「ネットワークセキュリティ:NTLM を制限する:受信 NTLM トラフィック」を「すべて拒否」に設定して、すべてのワークステーションとサーバーでNet-NTLMv1を無効化します。

• 例外文書化: Net-NTLMv1が有効のままであるシステムまたはセグメントについて、ビジネス正当化、補償統制、およびレビュースケジュールを含む正式な例外登録簿を維持します。

• 注意*: ドメインレベルの無効化の前に、フェーズ2のすべての修復活動が完了し、検証されていることを確認してください。

• 3.2 検証と確認*

包括的な検証を実施します:

• トラフィック分析: ネットワーク監視を展開して、非隔離セグメントでNet-NTLMv1トラフィックがゼロであることを確認します。異常を調査して修復します。

• ログレビュー: ドメインコントローラーのセキュリティイベントログを監査して、非隔離セグメントでNet-NTLMv1認証試行がゼロであることを確認します。

• アプリケーションテスト: すべての重要なアプリケーションの機能テストを実施して、KerberosおよびNTLMv2(EPA)で認証が正しく機能することを確認します。

• 侵入テスト: ターゲットを絞った侵入テストを実施して、レインボーテーブル攻撃がキャプチャされた認証交換から有効な認証情報を生成しなくなったことを確認します。

• 成果物*: テスト結果、特定された問題、および修復アクションを文書化した検証レポート。

• 3.3 レガシーシステム管理*

隔離されたレガシーサポートセグメント内のシステムについて:

• アクセス制御: 隔離されたセグメントへの接続を制限する厳格なアクセス制御を実装します。ファイアウォールルール、ネットワークセグメンテーション、およびVPN要件を使用します。

• 強化された監視: 隔離されたセグメントとの間のすべてのトラフィックに対して、強化された監視とアラートを実装します。

• 補償統制: 補償統制(例:多要素認証、エンドポイント検出と応答、特権アクセス管理)を文書化して実装します。

• 定期的なレビュー: レガシーシステムの四半期ごとのレビューを実施して、アップグレード、置き換え、または廃止が現在実現可能かどうかを評価します。

• 期限付き例外: レガシーサポートセグメントのサンセット日を確立します(例:廃止完了から12～24か月)。更新されたビジネス正当化を伴う明示的な更新を要求します。

• 成果物*: レビュースケジュールを含むレガシーシステム管理手順と例外登録簿。

• 3.4 文書化と知識移転*

廃止プロジェクトを文書化し、長期的なメンテナンス手順を確立します:

• プロジェクト文書化: 学んだ教訓、遭遇した課題、および実装されたソリューションを記録します。

• 認証アーキテクチャ文書化: プロトコル階層、フォールバックロジック、および例外基準を含む新しいアーキテクチャを反映するように、組織の認証基準を更新します。

• 運用手順: 監視、アラート、トラブルシューティング、および例外管理の手順を文書化します。

• トレーニング資料: 新しい認証アーキテクチャと手順を反映するようにトレーニング資料を更新します。

• 成果物*: 知識移転と将来の参照に適した包括的な文書パッケージ。

• 3.5 長期的な監視とメンテナンス*

継続的な監視とメンテナンス手順を確立します:

• 継続的な監視: Net-NTLMv1アクティビティに対するネットワークおよびログベースの監視を維持します。検出された使用に対してアラートします。

• メトリクス追跡: 廃止メトリクス(認証成功率、インシデント率など)の追跡を継続して、後退を検出します。

• 定期的な監査: 認証構成とトラフィックの年次監査を実施して、廃止ポリシーへの継続的なコンプライアンスを確認します。

• ベンダー更新: ベンダーのセキュリティアドバイザリを監視し、セキュリティ態勢を維持するためにパッチを迅速に適用します。

• 成果物*: 標準的なセキュリティ運用に組み込まれた監視とメンテナンス手順。

---

リスク要因と軽減戦略

• リスク:Net-NTLMv1無効化中の本番環境停止*

• 軽減策: 非クリティカルシステムから始めて、段階的に無効化を実行します。各フェーズのロールバック機能(例:GPOロールバック手順)を維持します。本番環境への展開前に、非本番環境で広範なテストを実施します。

• リスク:未発見のNet-NTLMv1依存関係*

• 軽減策: 複数の検出方法(ネットワーク監視、ログ分析、構成レビュー)を使用して包括的な環境監査を実施します。初期監査で見逃された依存関係を特定するために、自動検出とアラートを実装します。

• リスク:レガシーシステムをアップグレードまたは隔離できない*

• 軽減策: 経営陣の承認を伴う正式な例外プロセスを確立します。補償統制(強化された監視、アクセス制限、多要素認証)を実装します。必須のレビューとサンセット日を伴う期限付き例外を確立します。

• リスク:組織の抵抗またはリソース制約*

• 軽減策: 経営陣のスポンサーシップを確保し、ビジネスケースを明確に伝えます。専任のリソースと予算を配分します。明確なガバナンスと説明責任を確立します。影響を受けるチームにトレーニングとサポートを提供します。

---

結論

Net-NTLMv1の廃止は、ほとんどのエンタープライズ環境において、12か月の期間内で運用上必要であり、技術的に実現可能です。レインボーテーブルの利用可能性により、Net-NTLMv1のセキュリティモデルが依存する暗号学的前提が排除され、継続的な使用はリスク管理の観点から弁護できなくなります。

組織は、環境評価とガバナンス確立から始めて、直ちに廃止計画を開始する必要があります。段階的な修復、継続的な監視、および正式な例外管理により、組織はセキュリティ目標と運用上の制約のバランスを取ることができます。廃止を迅速に完了する組織は、レインボーテーブル攻撃へのエクスポージャーを削減し、攻撃ツールが拡散し規制上の精査が強化されるにつれて激化する運用上の圧力を回避します。

技術的な道筋は明確です。組織的な必要性は緊急です。行動する時は今です。

レガシー認証スタックにおけるシステム構造とボトルネック

Net-NTLMv1が単独のプロトコルとして動作することは稀である。これは、ドメインコントローラー、レガシーアプリケーション、VPNコンセントレーター、サードパーティ統合を含む階層化された認証スタック内の一つのコンポーネントとして機能する。このアーキテクチャ上の相互依存性は、廃止のセキュリティ上の根拠が明白である場合でも持続する移行ボトルネックを生み出す。

• 主張*：プロトコル廃止の速度を決定するのは、技術的能力ではなくシステムアーキテクチャである。組織はNet-NTLMv1を直ちに無効化する技術的能力を有しているが、組織的およびアーキテクチャ上の制約により、サービス中断なしにそれを実行することができない。

そのメカニズムは依存関係の結合である。NTLMv2をネゴシエートできないアプリケーションやアプライアンスは、Net-NTLMv1が無効化されると認証に失敗する。これらの依存関係は頻繁に文書化されておらず、カットオーバーの試行中にのみ発見される。例としては、すでに事業を行っていないベンダーのレガシーエンタープライズリソースプランニングシステム、元の開発者が不在のカスタムビルドアプリケーション、標準ネゴシエーションが失敗した際にNet-NTLMv1にデフォルト設定されるファームウェアを持つネットワークアプライアンス、固定された認証スタックを持つ組み込みシステム（プリンター、アクセスコントローラー、センサー）などがある。

• 前提条件*：この分析は、組織がインフラストラクチャ全体にわたる認証依存関係の最新の文書を維持していないことを前提としている。これは、ほとんどのエンタープライズ環境の年齢と複雑さを考慮すると妥当な仮定である。

実際的な結果として、ドメインコントローラーレベルでNet-NTLMv1を無効化すると、依存関係が事前にマッピングされていなかったシステムにおいて連鎖的な認証失敗が引き起こされる。組織はその後、選択を迫られる：Net-NTLMv1を再度有効化してサービス継続性を維持するか、各破損した依存関係を特定して修復する間サービス中断を受け入れるかである。ほとんどの組織は前者を選択し、Net-NTLMv1の存在を無期限に永続化させる。

実行可能な前進の道筋には、3つの連続したステップが必要である：

1. 依存関係のマッピング：ドメインコントローラーに対して認証を実行する、またはNet-NTLMv1を直接使用するすべてのシステムの包括的な監査を実施する。これには、アプリケーション、ネットワークアプライアンス、VPNシステム、クラウド統合、IoTデバイスが含まれる。どのシステムがNTLMv2をサポートしているか、どのシステムがそれを有効化するために設定変更を必要とするか、どのシステムがNTLMv2機能を完全に欠いているかを文書化する。

2. 能力評価：NTLMv2サポートを欠くシステムについて、ベンダーアップデート、設定回避策、または置き換えが実行可能かどうかを判断する。各修復経路のタイムラインとリソース要件を確立する。

3. 段階的移行：下流の依存関係が最小限のシステムから始めて、最も複雑なシステムへと進む形で、廃止を段階的に順序付ける。このアプローチは、単一のカットオーバーイベント中に重要な文書化されていない依存関係を発見するリスクを軽減する。

• 図2：レインボーテーブルによる攻撃時間の短縮と従来手法との比較（従来：8時間～数日 → レインボーテーブル：秒単位/2分以内、時間短縮率：240倍以上）*

• 図1：レインボーテーブルによるNet-NTLMv1ハッシュの急速な解読脅威*

• 図13：Net-NTLMv1廃止の全体マイグレーションロードマップ（戦略的計画）*

• 図14：廃止完了後のセキュアな認証スタックの理想状態（コンセプトイメージ：AI生成）*