OT 脆弱性管理｜止めない工場のパッチ判断と受入

2026年9月17日、CISAは8件のICS Advisoryを公開し、翌18日にはABBがFreelance向けの「Missing Length Check」をCVSS 9.2として掲載しました。OT 脆弱性管理で本当に難しいのは、深刻度の数字を並べることではありません。自社設備への適用有無を確かめ、安全と操業を守りながら、パッチまたは補完対策を証跡付きで完了させることです。本稿では、advisory受領からpatch/mitigation closureまでを5つのゲートに分け、止めにくい工場で実行できる判断と受入の型を示します。

OT 脆弱性管理は「CVSS順の即時パッチ」では完結しない

CISAやメーカーのadvisoryは、OT運用者にとって重要な早期警戒です。ただし、公開されたCVSS値は「自工場で今すぐ停止して更新する順番」そのものではありません。CVSSは技術的な深刻度を共通言語にする一方、対象製品が工場に存在するか、該当バージョンか、攻撃経路から到達できるか、その制御が安全機能や品質に何を及ぼすか、更新時に設備を止められるかまでは決めません。

今回の二つの公開情報は、この違いを説明する好例です。

高いCVSSを軽視してよいという意味ではありません。むしろ、高い深刻度を受け取ったときほど、慌てて本番へ適用するのではなく、適用判定、曝露評価、暫定防御、回帰試験、受入という一貫した運用に載せる必要があります。OTではサイバーリスクを下げる変更が、別の安全・品質・可用性リスクを生む可能性があるからです。

NIST SP 800-82 Rev. 3は、OTに固有の性能、信頼性、安全、可用性などの要求を踏まえたセキュリティを扱っています。NIST SP 800-40 Rev. 4も、パッチ管理を単なる配布作業ではなく、リスク対応を含む予防保全として整理しています。ISA/IEC 62443シリーズでは、資産所有者、サービス提供者、製品供給者などの役割をまたいだライフサイクル管理が重視され、ISA/IEC 62443-2-3はIACS環境のパッチ管理を扱います。したがって工場の実務では、「公開されたから入れる」でも「止められないから放置する」でもなく、判断を再現可能にする仕組みが必要です。

advisory受領からclosureまでを5ゲートに分ける

本稿では、工場の脆弱性対応を次の5ゲートで管理します。これは規格が指定する唯一の手順ではなく、現場導入のための例示モデルです。各社の安全規程、変更管理、品質システム、保全体制、ベンダー契約に合わせて承認者と期限を調整してください。

ゲート1：製品名だけでなく版・構成まで照合する

最初の作業はCVE番号をチケットにコピーすることではなく、対象資産を絞ることです。同じ製品系列でも、OS、ファームウェア、オプション、通信ドライバ、冗長構成、インストール方法によって該当性が変わります。資産台帳には少なくとも、メーカー、製品名、型式、ソフトウェアまたはファームウェア版、設置エリア、設備機能、ネットワークゾーン、資産オーナー、保守契約、最終バックアップ日を持たせます。

台帳に版が無い場合、「不明」は非該当ではありません。現場確認が必要な調査対象です。PLCやHMIの画面から版を確認するときも、制御に影響する操作を避け、ベンダー手順や保全手順に従います。遠隔からの自動スキャンは、機器の処理能力やプロトコル実装に影響する可能性があるため、OT環境での安全性を確認せずに実行しません。

適用判定は三つに分けると扱いやすくなります。

資産台帳の作り方そのものは、タイ工場のOT資産管理・棚卸しで詳しく解説しています。本稿で重要なのは、台帳を完成品として保管するのではなく、advisoryから対象設備へ到達する検索キーとして使えることです。

ゲート2：曝露・到達可能性と安全・品質・操業影響を分けて評価する

該当すると分かったら、次に「攻撃者や不正な通信が脆弱な機能へ届くか」を確認します。インターネット非接続だけで安全とは限りません。保守VPN、リモートデスクトップ、ジャンプホスト、エンジニアリング端末、USBメディア、上位MES/SCADAとの通信、他ラインからの横移動など、実際の経路を描きます。設定上は閉じているはずのポートも、現行ルールと通信ログで確認します。

そのうえで、影響を少なくとも四つに分けます。

1. 安全：誤動作、停止不能、保護機能への干渉、人や設備への危険につながるか。
2. 品質：レシピ、パラメータ、トレーサビリティ記録、検査判定の完全性を損なうか。
3. 操業：ライン停止、能力低下、手動運転、復旧時間の増加につながるか。
4. サイバー：権限取得、コード実行、サービス妨害、情報露出、横展開を許すか。

ここでCVSSはサイバー側の入力として活用します。しかし、CVSSが同じ二つの設備でも、SISと分離されローカル保守のみの検証設備と、複数ラインを束ね遠隔保守経路を持つ制御サーバーでは優先度が同じとは限りません。逆にCVSSが相対的に低くても、品質記録や安全に直結し、容易に到達でき、検知が難しい場合は早い対応が必要になり得ます。

判断会議では「高・中・低」だけを並べず、その結論を支える事実を書きます。例えば「外部到達不可」ではなく、「インターネットから直接到達不可。保守VPNからジャンプホストを経由するTCP通信は許可。多要素認証あり。対象PLCへの管理通信は保全時間帯だけ許可」と記載すれば、後日ルールが変わったときに再評価できます。

CVE トリアージの優先度は説明可能な式にする

工場独自の優先度モデルを使う場合、ブラックボックスの合計点より、判断要素を見える化した方が有効です。次は例示モデルであり、業界標準の配点ではありません。

「技術的リスク」と「変更リスク」を同じ表に入れると、なぜ即時適用しないのか、ではその間に何をするのかを説明できます。重要なのは、変更リスクが高いことを無期限延期の理由にしないことです。補完対策の責任者、期限、解除条件、次の停止枠を必ずセットにします。

停止できない期間はOT compensating controlでつなぐ

パッチが利用可能でも、連続生産、バッチ途中、認証済み構成、ベンダー立会い不足などの理由で、直ちに本番適用できないことがあります。その期間を「保留」とだけ記録すると、危険が見えなくなります。代わりに、脆弱な機能へ届く経路または悪用条件を具体的に減らす補完対策を設定します。

候補には、OT firewallの許可元・宛先・サービスの縮小、リモート保守の一時停止、ジャンプホスト経由の強制、管理アカウントの見直し、アプリケーション許可リスト、未使用サービスの停止、USB持込手順の強化、通信監視ルールの追加、バックアップ頻度の見直し、現場巡回の強化などがあります。ただし、advisoryの攻撃条件と関係のない対策を並べてもリスクは下がりません。例えばネットワーク経由の脆弱性に対して、到達経路を残したままログ監視だけを追加する場合、検知は改善しても防止にはなっていないと理解する必要があります。

補完対策のチケットには次を残します。

• どの攻撃経路または悪用条件を抑える対策か。
• どの設備・ライン・ネットワークゾーンに適用したか。
• 実施前後の設定と承認者。
• 正常通信や保全作業を妨げないことの確認結果。
• 有効期限と、誰が期限を追うか。
• パッチ適用後に解除するのか、恒久対策として残すのか。

補完対策は「パッチの代わり」ではなく、次の安全な変更機会までリスクを抑える橋です。ベンダーが回避策を示している場合は、それを第一候補として、現場構成への適用性を確認します。ベンダー推奨外の設定を行うなら、制御性能、サポート条件、規制・品質要件への影響を関係者で承認します。

ICS パッチ管理では本番前の回帰試験を設計する

一般ITのテストで「OSが起動した」「サービスが稼働した」だけでは、OTの受入条件として不足します。制御システムでは、通信タイミング、ドライバ互換性、画面表示、アラーム、時刻同期、レシピ配信、履歴収集、冗長切替、バックアップ復元などが工程全体の成立条件です。更新対象の機器だけでなく、その前後の依存関係を試験します。

理想は、同型機、仮想環境、ベンダー検証環境など、本番から隔離された環境でパッチパッケージを確認することです。完全な複製がない場合でも、ベンダーの対応表、設定バックアップ、重要通信の一覧、代表的なI/Oや画面操作、復元手順を使い、確認可能な範囲と未確認リスクを明示します。「試験環境が無い」を試験ゼロの理由にせず、何を別手段で検証し、何を本番停止枠の初期確認へ移すかを決めます。

回帰試験の最低セット

試験パッケージの入手経路と完全性も管理します。正規のベンダーポータルから取得し、電子署名やハッシュが提供される場合は確認します。パッチファイルをインターネット接続端末からOTへ移す場合、承認済みの中継・媒体・マルウェア検査手順を使います。誰が、いつ、どのファイルを、どの環境へ持ち込んだかを記録すれば、後日の不具合調査にも役立ちます。

OT patch acceptanceは停止枠・ロールバック・証跡を一体で扱う

回帰試験に合格しても、実施計画が曖昧なら本番変更は安全になりません。OT patch acceptanceでは、変更開始前に「中止条件」と「戻す条件」を決めます。開始後に現場の雰囲気で判断すると、残り時間が少ないために不具合を抱えたまま続行する圧力が生じます。

本番実施票には次を含めます。

1. 対象設備、現行版、適用版、advisory/CVE、変更責任者。
2. 生産停止、仕掛品、ユーティリティ、安全隔離、品質リリースの条件。
3. 設定・プログラム・レシピ・データのバックアップと復元確認。
4. 実施手順、ベンダー連絡先、現場と制御室の連絡系統。
5. 各工程の予定時間、判断ポイント、中止時刻。
6. ロールバック手順、旧版パッケージ、必要な権限と媒体。
7. 適用直後、試運転、初品、定常運転での確認項目。
8. 補完対策を解除または継続する条件。
9. 証跡の保存先、受入署名、資産台帳の版更新。

パッチが正常にインストールされたというログだけでcloseしないことが重要です。脆弱性が解消されたこと、工程機能が受入条件を満たすこと、監視に新しい異常がないこと、資産台帳と構成管理が更新されたこと、期限付き補完対策が処理されたことまで確認します。更新が失敗して旧版へ戻した場合も、技術的には「復旧成功」でも脆弱性対応は未完了です。新しい期限、補完対策、ベンダー照会を設定してチケットを継続します。

工場 脆弱性対応の役割分担を一枚にする

OT 脆弱性管理が滞る主因は、ツール不足よりも「誰が決めるのか」の曖昧さです。ITセキュリティはadvisoryを見つけられても、対象ラインの停止可否や制御の合格条件を単独では決められません。保全は設備を熟知していても、全社の脅威情報やネットワーク経路を持っていない場合があります。製造、品質、安全、IT、OT、ベンダーをつなぐ単一のケースオーナーが必要です。

この表も例示です。大切なのは役職名ではなく、最終判断者が明記され、担当者不在時の代理が決まり、advisory改訂を再投入できることです。複数工場を運営する企業では、中央チームがadvisoryを正規化し、各工場が適用性と操業条件を回答する形にすると、同じ調査の重複を減らせます。一方、中央が「全拠点に一律適用」と判断すると、現場固有の版・構成・停止条件を見落とします。中央は共通情報と最低期限を提供し、拠点はローカル事実と実施証跡を返す分担が現実的です。

ケース台帳は「ステータス」より判断履歴を重視する

ダッシュボードにOpen、In Progress、Closedだけを表示しても、監査や事故対応では十分ではありません。後から必要になるのは「その時点で何を知り、誰が、どの根拠で、どのリスクを受容したか」です。最低限、次の項目を一つのケースにひも付けます。

• advisoryのURL、発行元、公開日、改訂番号、取得日時。
• CVE/CVSSなど発行元が示す技術情報。転記元を残す。
• 対象資産、版、構成、場所、機能、オーナー、適用判定。
• ネットワーク経路、認証、境界、防護、持込経路。
• 安全、品質、操業、サイバーの影響評価と承認。
• ベンダー回答、パッチ入手先、対応版、前提条件。
• 補完対策、期限、設定差分、解除条件。
• 回帰試験、本番変更、ロールバック、受入の記録。
• close理由と再開条件。advisory改訂を検知した場合のリンク。

「非該当」で閉じるケースにも根拠が必要です。たとえば対象版が存在しない、該当コンポーネントがインストールされていない、対象機能が無効である、ベンダーが構成非該当を確認した、などです。単に「現場から問題なしと回答」と書くと、担当者が変わったときに再利用できません。

30・60・90日の導入モデル（例示）

すべてを一度に整備しようとすると、最初のadvisoryが台帳整備待ちになります。次の段階は導入例であり、業界平均や必須期限ではありません。

最初の30日：入口と責任を一本化する

• CISA、主要メーカー、保守会社の通知先を定義する。
• advisoryの重複をまとめる単一キューとケースIDを作る。
• 重要設備のメーカー・製品・版・オーナーを優先確認する。
• Applicable / Not applicable / Unknownの判定基準を決める。
• 緊急連絡、リスク受容、停止枠調整の責任者を決める。

31〜60日：曝露評価と補完対策を標準化する

• 代表ラインで通信経路と保守経路を可視化する。
• firewall制限、遠隔保守停止、監視強化などの標準変更票を作る。
• 補完対策に有効期限と解除条件を必須化する。
• ベンダーへの照会テンプレートを作り、回答をケースへ保存する。
• 安全・品質・製造を含む短時間のトリアージ会議を定例化する。

61〜90日：試験・受入・指標を閉じる

• 代表的なPLC/HMI/サーバー構成の回帰試験票を作る。
• バックアップからの復元とロールバックを実地確認する。
• 停止枠の変更計画へ脆弱性案件を接続する。
• 「advisory受領から適用判定まで」「期限切れ補完対策」「証跡不備」など、自社判断に役立つ指標を定義する。
• close済みケースを抜き取り、根拠と証跡をレビューする。

平均日数だけを短くする目標は危険です。簡単な非該当判断を大量に閉じれば数字は改善しますが、重要設備のUnknownが残るかもしれません。件数、年齢、重要度、判定確度、補完対策期限、次の停止枠を組み合わせて見ます。

既存の3つの仕組みとの境界を明確にする

OT 脆弱性管理は単独で成立しませんが、周辺活動と混ぜると責任が曖昧になります。

まず、OT資産管理は「何が、どこに、どの版で存在するか」を提供します。本稿のワークフローは、その情報を使ってadvisoryの適用性を判定し、変更後の版を台帳へ戻します。

次に、OTサイバーインシデント対応訓練は、侵害や停止が起きた場合の連絡、意思決定、復旧を検証します。脆弱性ケースで作ったバックアップ、連絡先、ロールバック、ネットワーク分離の手順は訓練の現実的な材料になりますが、訓練をしただけで個別の脆弱性がcloseするわけではありません。

そして、FAシステムインテグレーター向けセキュリティRFPは、調達時に通知、サポート期間、パッチ提供、SBOM、リモートアクセス、試験支援などを要求する入口です。本稿は、契約後に実際のadvisoryが届いてから、工場がどう処理するかを扱います。調達、資産、運用、復旧をつなぐことで、メーカー通知がメールボックスで止まらず、現場の変更管理まで届きます。

よくある失敗と修正方法

失敗1：CVSSが高い順に停止要求を出す

現場は「セキュリティは操業を理解していない」と感じ、以後の通知を防御的に受け取ります。修正策は、CVSSを入口として維持しつつ、適用確度、到達可能性、安全・品質・操業影響、変更リスクを並べ、優先理由を一文で説明することです。

失敗2：インターネット非接続を非該当理由にする

保守VPN、持込PC、USB、上位システム、他ゾーンからの経路を見落とします。修正策はデータフローと管理経路を確認し、「直接到達不可」と「一切到達不可」を区別することです。

失敗3：パッチ待ちを無期限の例外にする

ベンダー回答待ちや停止枠待ちが積み上がります。修正策は、補完対策、ケースオーナー、期限、次回レビュー、予定停止枠を一つの例外記録にまとめることです。

失敗4：インストール成功でcloseする

通信、アラーム、履歴、品質データ、冗長切替の不具合を見逃します。修正策は技術適用と工程受入を分け、設備オーナーが受入条件を確認してから閉鎖することです。

失敗5：advisoryの改訂を追わない

対象版や緩和策が更新されても、過去の非該当判定が残ります。修正策は発行元IDと改訂番号をキーにし、改訂を同一ケースへ追記して再判定条件を明確にすることです。

OT 脆弱性管理の実装チェックリスト

FAQ：OT 脆弱性管理とICS パッチ管理

Q1. CVSS 9以上なら工場を止めて即日パッチすべきですか？

CVSSが高いadvisoryは速やかな評価対象ですが、数字だけで停止と適用を決めるべきではありません。まず製品・版・構成の適用性と到達可能性を確認し、安全・品質・操業への影響を評価します。即時適用できない場合は、根拠のある補完対策、責任者、期限、停止枠を設定します。これは延期の正当化ではなく、安全に完了するための管理です。

Q2. 工場 脆弱性対応で資産台帳が不完全な場合はどうしますか？

「版不明」を非該当として閉じず、Unknownとして期限と担当者を付けます。重要設備から現物、バックアップ、ベンダー保守記録を照合し、確認できた情報を台帳へ戻します。advisory対応を台帳品質の改善サイクルとして使うのが実務的です。

Q3. OT compensating controlはパッチの代わりになりますか？

通常は恒久的な代替ではなく、安全な変更機会までの橋です。advisoryの悪用条件に対応する経路制限、アクセス制限、監視などを選び、有効期限と解除条件を持たせます。製品供給者が恒久的な緩和策を指定している場合は、その位置づけと残存リスクを確認します。

Q4. OT patch acceptanceの合格条件は誰が決めますか？

OTセキュリティだけでなく、設備・システムオーナー、制御、保全、製造、品質、安全の関係者が決めます。サイバー上の更新成功に加え、制御、I/O、通信、アラーム、履歴、レシピ、冗長、復旧、初品確認など、対象工程に必要な条件を変更前に定義します。

Q5. ベンダーのパッチがまだ無い場合、ケースは閉じられますか？

単に「パッチなし」で閉じるのは適切ではありません。ベンダーの緩和策、到達経路の制限、機能停止、監視、代替機・更改計画などを評価し、残存リスクを権限者が承認します。再確認日とadvisory改訂の監視を設定し、条件が変われば再開します。

Q6. CISAやメーカーの通知を毎日見るだけで十分ですか？

通知監視は入口にすぎません。重複排除、資産との照合、影響評価、補完対策、試験、停止枠、本番受入、台帳更新まで一つのケースとして追跡して初めて運用になります。通知件数ではなく、適用判定の確度と未完了リスクを管理してください。

まとめ：CVSSを入口にし、操業判断を証跡で閉じる

OT 脆弱性管理の目的は、すべてのパッチを最速で入れることでも、停止を避けるために更新を先送りすることでもありません。advisoryを自社資産へ正確に結び付け、到達可能性と安全・品質・操業影響を評価し、停止までの補完対策を置き、隔離環境で回帰試験を行い、ロールバック可能な停止枠で受け入れることです。CISAの8件のICS AdvisoryやABBのCVSS 9.2のような通知は、判断の開始点です。最終的な優先度とcloseは、自工場の事実と承認可能な証跡で決めます。

TOMAS TECHでは、OT資産台帳がまだ完全でない段階でも、advisory受付、CVEトリアージ、ネットワーク到達性確認、補完対策、回帰試験票、停止枠でのパッチ受入までを現場の変更管理に合わせて整理できます。タイ工場で「どの設備から始めるか」を検討している段階でも、お問い合わせからご相談ください。

参考情報

1. CISA: CISA Releases Eight Industrial Control Systems Advisories, 17 September 2026
2. ABB: Cyber Security Alerts and Notifications
3. NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
4. NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
5. ISA: ISA/IEC 62443 Series of Standards
6. CISA: Foundations for OT Cybersecurity—Asset Inventory Guidance
7. CISA: Secure by Demand Guide
8. NIST: Operational Technology Security Publications