OT「Patch Management 」のエアギャップ環境向け活用：オフラインパッチ適用ワークフローのすべて

OTパッチ管理とは、生産プロセスに予期せぬダウンタイムや安全上のリスクをもたらすことなく、オペレーショナルテクノロジー（OT）および産業用制御システム全体において、ソフトウェアやファームウェアの更新を特定、優先順位付け、検証、および展開するプロセスです。エアギャップ環境では、インターネットに接続されたソースから隔離されたネットワークへパッチを移行する際、その隔離状態を損なうことなく、管理されたオフライン経路を確保することも必要となります。

主なポイント

• OTのパッチ管理は、単にITのパッチ管理のスケジュールを延長したものではありません。安全上の 依存関係、認定ベンダーによる構成、長い資産ライフサイクル、そして予期せぬ再起動に対するほぼゼロの許容度といった要因により、プロセスのほぼすべての段階が変化します。
• エアギャップ化されたネットワークでは、自動パッチ適用機能は利用できなくなりますが、パッチ適用の必要性がなくなるわけではありません。 ホームサーバーに接続できないエンドポイントは 、オフラインのリポジトリやオンプレミスの管理によって隔離ゾーン内で可視性が回復されない限り、クラウドベースのスキャンおよび更新サービスから除外されてしまいます。
• CVSSの深刻度だけでOTパッチの優先順位を決定してはなりません。エクスプロイトの 成熟度、ネットワークへの到達可能性、資産の重要度、および運用上のセキュリティへの影響は、スコアと併せて判断材料に含める必要があります。そうしなければ、評価が類似している2つの脆弱性に対して、誤った対応をとってしまう可能性があります。
• リムーバブルメディアは、単なる利便性ではなく、管理上の重要なポイントである。すべての パッチパッケージおよびそれを格納するデバイスは、ソースの検証、署名およびハッシュ値のチェック、ならびにマルウェア検査を経て、転送が許可されるまでは、信頼できないものとして扱うべきである。
• MetaDefender Endpoint™は、1つのエンドポイントエージェントを通じて、脆弱性およびパッチ管理、リムーバブルメディアの保護、BadUSB対策を実施し、 My OPSWAT™Central Management から一元的に状況を把握できますが 、ガバナンス、テスト、および ベンダーの承認については、引き続き組織の責任となります。

エアギャップ環境におけるOT（Patch Management ）とは何ですか？

OTパッチ管理では、ノートPC、デスクトップPC、ワークステーションなどのエンドポイントを含む重要資産に対する更新プログラムの特定、テスト、および展開が行われます。このプロセスにおいて、安全性と可用性は二次的な懸念事項ではなく、制約条件として扱われます。エアギャップネットワークでは、ベンダーの更新サーバーやクラウドベースの脆弱性フィードへのライブ接続がない状態で、同様のプロセスを実行する必要があります。

OTとITのPatch Management の違い

この2つの分野は、「脆弱性の露出を低減する」という目標を共有していますが、それぞれの分野を取り巻く制約は十分に異なるため、IT分野のパッチ適用ツールや実施サイクルをOT分野にそのまま適用することはできません。

従来のPatch Management がエアギャップネットワークで機能しなくなる理由

インターネットに接続できないエンドポイントは、クラウドベースの脆弱性スキャン、更新リポジトリ、およびポリシーの同期の対象外となります。つまり、ローカルで何らかの手段によってその対応範囲が復元されない限り、コンプライアンス報告からも除外されてしまうことになります。スプレッドシートを用いた手動でのパッチ適用は、しばらくの間は代用として機能するかもしれませんが、規模が大きくなると機能しなくなります。非公式なUSB の転送は記録されず、展開結果も記録されず、監査のたびに状況を再現する作業が必要になってしまいます。

オフラインのパッチリポジトリ、オンプレミスでの一元管理、および制御された転送経路により、エアギャップそのものを弱体化させるようなライブ接続を追加することなく、接続された環境においてクラウド自動化が提供するカバレッジを再現します。

Secure のオフラインOT「Patch Management 」アーキテクチャには何が含まれていますか？

安全なオフラインアーキテクチャでは、パッチは一連の信頼境界を通過します。具体的には、インターネットに接続された取得ゾーン、隔離された検証・検疫ステーション、管理された転送チェックポイント、そしてOTネットワーク内で承認済みのパッケージを配布するオンプレミスの管理サーバーです。この一連のプロセスにおいて、どのコンポーネントも、生産用OT資産を外部のパッチソースに直接接続することはありません。

調達、検査、管理、導入の適切な位置づけ

• 取得と初期検証は、本番環境外で、ベンダーの更新プログラムを取得し、初期段階の署名およびハッシュチェックを実行するためのインターネット接続環境が整ったゾーンで行われます。
• オフラインパッチリポジトリでは、承認済みのオペレーティングシステムおよびサードパーティ製アプリケーションの更新プログラムを管理しており、バージョン管理、旧バージョンとの置き換え状況の追跡、および同期記録は、隔離されたネットワーク内で維持されています。
• オンプレミスでの一元管理では、クラウドサービスや外部のIDプロバイダー、コールホーム方式のライセンスに依存することなく、ポリシーの配布、展開のスケジュール設定、エンドポイントの状態の収集、およびレポートの作成を行うことができます。
• ポリシーの最終的な適用と展開は、ローカルのOT管理下にあるため、侵害されたり遅延が生じたりした外部ソースが、変更を本番環境に直接反映させることは決してありません。

リスクベースのオフラインOTパッチ適用ワークフローはどのように構築すればよいでしょうか？

再現性のあるオフラインパッチ適用ワークフローは6つの段階に分かれており、各段階において明確な決定事項、成果物、および承認記録が生成されるため、プロセスは最初から最後まで監査可能となります。

1. 資産の棚卸しと調査。 ハードウェアおよびソフトウェアのバージョン、ネットワークゾーン、安全機能、サポート状況などを記載した資産台帳を維持し 、ベンダーのアドバイザリやオフラインの脆弱性スキャン結果と照合して、適用すべき更新プログラムを特定します。

2. リスクの優先順位を付ける。 各パッチ候補について、深刻度スコアだけでなく、悪用可能性、影響範囲、資産の重要度、安全面への影響に基づいて評価を行い 、ワークフローに組み込む前に、ファームウェア、OS、およびベンダーサポートとの互換性を確認する。

3. パッケージの検証と承認を行う。 ソースの真正性、デジタル署名、および暗号ハッシュを検証し 、隔離されたステージング環境でマルウェアのスキャンを行い、正式な変更承認の前に代表的なテストを実行する。

4. 転送と準備。 承認済みのパッケージを管理されたリムーバブルメディアを介して転送し 、転送後に再検証を行い、デプロイメント期間に先立ってローカルに準備しておく。

5. 段階的に展開する。 承認されたメンテナンス時間帯に、対象エンドポイントを明確に定義し、対応している場合は自動インストール設定を適用し、再起動の制御および停止条件を設定した上で、パッチを展開する 。

6. 検証、ロールバック、および報告。 導入状況、サービスの健全性、および安全機能の動作を確認し 、受け入れ基準を満たさない場合は事前に検証済みのロールバックを実行し、その結果、例外事項、および監査審査のための証拠を記録する。

OTチームは脆弱性とパッチをどのように優先順位付けすべきか？

共通脆弱性評価システム（CVSS）の評価は、技術的な深刻度を抽象的な観点から表すものです。これには、プラントへの影響、悪用可能性、安全性への影響、あるいはダウンタイムのリスクなどは含まれていないため、スコアが類似している2つの脆弱性であっても、環境内の位置付けによって、OT（オペレーション技術）における対応策が大きく異なる場合があります。

OTパッチ優先順位マトリックス

サイバー攻撃の発生確率と運用上の影響を比較検討する優先順位マトリックスがあれば、チームは、重大度の高い発見事項をすべて同じように扱うのではなく、一貫した方法で意思決定を進めることができます。

パッチの適用を延期する場合、その例外措置には、責任者、技術的な根拠、有効期限、および相補的な統制措置が必要であり、攻撃活動の動向やベンダーのガイダンスに変更があった際には、その都度再検討を行う必要があります。恒久的で再検討されていない例外措置は、監査人が真っ先に発見する脆弱性です。

エアギャップ化されたOTネットワークへ、パッチを安全に適用するにはどうすればよいか？

パッチバンドルおよびそれを格納したリムーバブルメディアは、ポリシーによって検証されるまでは、いずれも信頼できないものとして扱う必要があります。検査を最優先とする保管の連鎖により、ファイルがOTネットワーク内で利用可能になる前に、その出所、完全性、および内容の安全性が確認されます。

• ソースの検証。 更新プログラムは、ベンダーのポータルまたは認証済みの配布チャネルからのみ取得し 、ソース、取得日時、パッケージのバージョン、および取得した担当者の氏名を記録してください。
• 署名およびハッシュの検証。 転送前に、デジタル署名、証明書の有効性、およびベンダーが公開している暗号ハッシュを確認してください 。有効な署名は真正性を裏付けるものですが、それだけでは、そのパッケージが特定のOT環境において安全であることを証明するものではありません。
• マルウェア検査。 ネストされたアーカイブ、インストーラー、スクリプト、ドライバを含むパッケージ全体を、隔離されたステージング環境でスキャンし 、不審な判定結果に対しては、あらかじめ定義された隔離および拒否措置を適用します。
• リムーバブルメディアおよびBadUSBに対する保護。 デバイスの認証とアクセス前のスキャンを必須とする ことで、感染したドライブや偽装されたデバイス（キーボードを装うBadUSB攻撃を含む）が、OTエンドポイント上で何らかの実行を行う前にブロックされます。
• 保管履歴記録。 メディアの識別情報、保管担当者、ハッシュ値、検査結果、承認、転送日時、および転送先を記録し 、監査の際にすべての転送履歴を再現できるようにする。

本番環境に支障をきたさずにOTパッチを展開するにはどうすればよいでしょうか？

検証済みのパッチの適用は、依然として運用上の変更であり、その導入を成功させるためには、脆弱性を解消することと同様に、プロセス管理、安全性、および復旧性を確保しなければならない。

• 代表的なテスト環境を構築する。 可能な限り、重要なハードウェア、OSのビルド、アプリケーション、通信環境を再現し 、テスト環境と本番環境で避けられない相違点については文書化する。
• 導入前に互換性を確認してください。 機器ベンダーのガイダンス、アプリケーションの認証、およびドライバーの依存関係を確認し 、パッチがベンダーがサポートする構成の範囲外となる場合は、追加の承認を義務付けてください。
• 展開は段階的に実施してください。 影響の少ない代表的な資産から始め 、結果を評価した上で、環境全体を一括で修正するのではなく、明確に定義された中断基準と緊急停止権限を設けつつ、段階的に拡大していきます。
• インストール作業および再起動を管理する。 対応している場合は、作業の妨げにならないインストール方法を採用し 、ベンダーのガイダンス、冗長性設計、およびプラントの承認に基づき、再起動を抑制または調整する。
• 正常動作を確認してから、ループを閉じる。 サービスの起動、制御ロジック、アラーム、および安全機能について、測定可能な受入基準に照らして確認し 、デプロイメント開始前に、構成のバックアップや復旧用メディアを含む、テスト済みのロールバック計画を準備しておく。

OTチームは、レガシーシステムやサードパーティ製アプリケーションにどのようにパッチを適用すべきか？

旧バージョンのオペレーティングシステムや特殊なエンジニアリング用アプリケーションが搭載された長期運用環境は、多くの場合、一般的なITパッチ管理ツールの対象外となるため、プログラムから完全に除外するのではなく、別途の対応策を講じる必要があります。

• レガシーOSのエンドポイントについては、更新プログラムを選択する前に、エディション、アーキテクチャ、およびベンダー承認済みのベースラインに関する正確なインベントリが必要であり、そのプロセスにはオフラインパッケージのサポートとロールバック機能が組み込まれている必要があります。
• ブラウザ、ランタイム、リモートアクセスツールなどのサードパーティ製アプリケーションは、多くの場合、OSのネイティブな更新チャネルの対象外となるため、独自のバージョン検出、依存関係の解決、およびオフラインインストーラーのサポートが必要となります。
• パッチを適用できないシステムであっても、ドキュメントは必要です。パッチ適用が不可能な理由や安全でない理由、責任ある管理者、レビューの日程、および置き換えや移行のロードマップを明記する必要があります。
• ネットワークのセグメンテーション、アプリケーションの許可リスト、リムーバブルメディアの制限といった補完的な対策は、パッチを適用できない資産に対するリスクを軽減しますが、根本的な脆弱性を解消するものではなく、脅威の状況の変化に応じて定期的な見直しが必要です。

OT「Patch Management 」は、監査対応可能なコンプライアンス証拠をどのように生成できるのでしょうか？

証拠の集中管理により、コンプライアンス報告は、監査が予定されるたびに手作業で情報を再構築する作業ではなく、パッチ適用ワークフローの日常的な成果物となります。

• 保存すべき記録：資産の 範囲、脆弱性の状況、承認、ファイルのハッシュ値、署名結果、検査結果、メディアの活動状況、展開結果、例外、およびロールバックイベント。これらすべてに、特定可能なタイムスタンプが付与されているもの。
• カバレッジ指標： 在庫のカバレッジ、パッチの適用率、期限切れの是正措置、および例外事項を追跡し 、サイトおよび資産の重要度ごとに分類することで、集計された割合によって重大な影響を及ぼすギャップが見落とされないようにする。
• リスク低減の指標： パッチ適用までの時間とエクスポージャー・ウィンドウの数値を、ロールバック率や予期せぬダウンタイムの数値と照らし合わせて分析する 。これにより、パッチの適用が早かったとしても、それがシステムの不安定化を招く場合は、決して成功とは見なされない。
• フレームワークとの整合性： 資産リスト、リスク評価、変更管理、および監視の実践を、IEC 62443 および OT セキュリティに関する最新のガイドラインである NIST SP 800-82 リビジョン 3 の関連する目標に照らし合わせて確認します 。フレームワークとの整合性は監査を支援するものであり、それ自体が認証に代わるものではなく、またコンプライアンスを保証するものでもありません。

エアギャップ環境向けのOTPatch Management ソリューションをどのように評価すべきか？

特定の製品について検討に入る前に、ベンダーに依存しない要件に基づいて評価を行うべきです。具体的には、完全なオフライン動作、オンプレミスでの一元管理、幅広いエンドポイントおよびアプリケーションの対応範囲、周辺メディアの保護、そしてクラウドに依存することなく監査対応可能な証拠を生成する一元的なレポート機能などが挙げられます。

• オフラインでの動作は、単なる仮定ではなく、実証済みであること。 インターネットに接続された製品がオフラインでも同様に動作すると安易に受け入れるのではなく、エアギャップ環境下での実証を求める 。
• Endpoint およびアプリケーションの対応範囲。 組織内で導入されている Windows、macOS、Linux、およびレガシーシステムに対する実際のサポート状況を確認します 。これには、オフラインパッケージ形式やロールバックの可視性も含まれます。
• 周辺メディアの保護。 ファイルへのアクセス前に、プラットフォームがデバイスを認証し、スキャンを行い、BadUSBに対する防御機能を備えていることを確認してください。 転送処理を、独立した、接続されていないツールに任せるようなことは避けてください。
• 一元化されたレポート作成とガバナンス。 ロールベースのアクセス権限、展開状況、例外ワークフロー、および証拠データのエクスポートについて、単に正常に実行されたケースだけでなく、メディアの拒否やインストール失敗といったシナリオも想定してテストを行う 。

MetaDefender （Endpoint ）が、予防を最優先とするオフラインパッチ適用ワークフローをどのようにサポートするか

MetaDefender Endpoint™は、OPSWAT が提供する高度なエンドポイント保護ソリューションであり、外部メディアを介した脅威からエンドポイントを保護し、デバイスのコンプライアンスを監視し、脆弱性を検出し、インターネット接続環境およびエアギャップ環境の両方でパッチ適用を可能にします。980以上のアプリケーションおよびオペレーティングシステムの脆弱性を検出し、580以上のサードパーティ製アプリケーションおよびOSの更新に対する自動パッチ適用を実現します。また、メンテナンス時間帯にオペレーターの画面操作を中断させない「ディストラクションフリー・パッチング」機能を備えています。

リムーバブルメディア保護機能は、Metascan™（Multiscanning ）およびDeep CDR™テクノロジー（MetaDefender ）に基づいて動作します。Endpoint は、すべてのファイルがスキャンされ、安全であることが確認されるまで、USB ドライブへのアクセスを自動的に検出してブロックします。また、エンドポイント上でファイルを最初に実行する必要なく、BadUSB、ラバーダッキー、その他のデバイスなりすまし攻撃から防御します。

一元化された可視性を実現するのは、My OPSWAT™Central Management です。オンプレミスまたはクラウドで利用可能なこのソリューションは、インターネット接続に依存することなく、ポリシーを配布し、導入状況を収集し、サイト全体にわたってレポートを作成するため、セキュリティチームは1か所から、孤立した複数のOT拠点にわたって同一のオフラインワークフローを実行することができます。

エアギャップ型OT環境におけるMetaDefender Endpoint の使用タイミングPatch Management

• OTまたはICS環境には信頼性の高いインターネット接続がないため、クラウドベースの脆弱性スキャンやパッチの配信はそこには届きません。
• セキュリティおよびOT運用においては、OSやサードパーティ製アプリケーションのパッチ適用に加え、リムーバブルメディアやBadUSBへの対策も網羅した単一のワークフローが必要です。
• コンプライアンス要件では、単なる導入ログだけでなく、パッチのライフサイクル全体にわたる監査対応可能な証拠が求められています。
• 複数の孤立した拠点において、各拠点とインターネットとの間にライブ接続を確立することなく、一元的なポリシー管理とレポート機能が必要とされています。

MetaDefender （Endpoint ）が、My （OPSWAT Central Management ）による一元的な可視性を活用し、エアギャップ化されたOT環境において、脆弱性およびパッチ管理、リムーバブルメディアの保護、BadUSB対策がいかに適用されるかをご覧ください。

よくある質問

OTチームは、CVSSスコアだけではなく、悪用可能性、資産の重要度、安全性への影響、および運用リスクに基づいて、パッチの優先順位をどのように決定すべきでしょうか？

既知の悪用状況、ネットワークへの到達可能性、安全性または生産への影響をCVSSスコアと併せて検討し、その上で、発生の可能性と影響を「緊急パッチ適用」から「文書化されたリスク受容」に至る具体的な対応策に割り当てる優先順位マトリックスに基づいて判断を下す。

パッチを適用できないレガシーなOTシステムや、ベンダーによるサポートが終了したOTシステムを保護するには、どのような補償措置が有効でしょうか？

ネットワークのセグメンテーション、アプリケーションの許可リスト化、リムーバブルメディアの制限、プロトコルのフィルタリング、および監視機能の強化により、パッチを適用できない資産に対するリスクを低減できます。ただし、これらは根本的な脆弱性を解消するものではないため、責任者を明確にし、見直し時期を設定する必要があります。

運用上の混乱を防ぐために、OT環境におけるパッチテストおよび展開のワークフローにはどのような要素を含めるべきでしょうか？

代表的なテスト環境、ベンダーのガイダンスに基づく互換性検証、リング方式による段階的な導入、再起動の調整管理、および導入後の定量的な健全性チェック。

組織は、OTパッチ管理ソリューションを選定する際、どのような機能を評価すべきでしょうか？

実証済みのオフライン動作、オンプレミスでの一元管理、幅広いOSおよびサードパーティ製アプリケーションへの対応、リスク評価のためのvulnerability detection 、無人パッチ適用および業務を中断させない導入・実行制御、外部メディアおよびBadUSBへの保護、そしてクラウドに依存することなく監査対応可能な証拠を生成する一元的なレポート機能。