脆弱性スキャナーが産業用機器にCVSSスコア10の深刻な脆弱性を検出しました。レポートが上司の受信箱に届き、「なぜこの重大な脆弱性を放置しているのか」と問い詰められます。通常のIT環境であれば、パッチを当ててチケットをクローズすれば済む話です。しかし、OT環境や稼働中の製造施設でICSを扱う場合、それほど単純にはいきません。
以下は、「この検出結果は、我々の環境において実際に悪用可能な脆弱性なのか」という問いに答えるために筆者が活用しているフレームワークです。
1. デバイスが実在し、使用中であることを確認する
2. 脆弱な機能がインストールまたは有効化されているかを検証する
3. ネットワークから到達可能かどうかを確認する
4. すでに適用されている仮想的・技術的な緩和策を把握する
5. 攻撃経路と悪用可能性を追跡する
6. リスク受容という選択肢があるかどうかを判断する
7. 検出結果が有効かつ悪用可能であれば、修正対応を行う
インベントリの整備から始める
作業に取りかかる前に、まず正確かつ最新の資産インベントリが必要です。小規模な施設であれば、スプレッドシートやシンプルな資産管理ツールで対応できることが多いです。一方、PLCが数千台、SCADAコンピュータが数百台、HMIや無数のスイッチ・ファイアウォールが存在する大規模施設では、手動での管理は困難で非効率です。担当者が変更や追加を記録することに頼るのではなく、環境全体とネットワークを自動スキャンするツールの活用を推奨します。
インベントリが整備されていれば、重大な検出結果があったデバイスを検索してその詳細情報を確認できます。検出結果に記載されているIPアドレスと場所に、そのデバイスは実際に存在していますか？ICS環境ではネットワーク変更、ネットワーク切り離し、あるいは誰にも知らせないままの構成変更が頻繁に起こることで知られています。そのデバイスがどのくらいの期間設置されているか、最後にパッチが当てられたのはいつか、どのネットワークセグメントに属しているかを確認してください。PLCネットワーク上にあるのか、NATされたネットワーク上にあるのか、それともすべてが相互通信するフラットなVLAN上にあるのかを把握しましょう。
脆弱性スキャナーが示す場所にデバイスが存在し、IT機器から到達可能な場合、特にインターネットからアクセスできる場合は深刻な問題です。一方で、ファイアウォールルールなどの緩和策により、ローカルマシンからもアクセスできない状態になっているケースも少なくありません。緩和策が存在するか、あるいは隔離されている場合は、悪用不可能である可能性を示す最初の根拠となります。
脆弱な機能が実際に存在するかを確認する
脆弱性スキャナーは「これらの問題を直接テストしたのではなく、アプリケーションが自己報告するバージョン番号のみに基づいている」と注記することがよくあります。つまり、スキャナーはアプリを検出してバージョン番号を確認し、そのバージョンに対応するCVEが存在することを確認したに過ぎません。
筆者も最近、この典型例に遭遇しました。レポートに7つの異なるバージョンのAdobeが表示され、そのすべてに何らかの脆弱性があるとされていたのです。しかし実際にそのユーザーのコンピュータを調べると、古いバージョンの痕跡は見当たりませんでした。再起動後に再テストすると、それらの検出結果は消えていました。OT環境でこれを手作業で確認するには、定期的なシャットダウンやダウンタイムを待つ必要があり、数週間かかる場合もあります。ダウンタイムを待っているために脆弱なソフトウェアやコンポーネントの存在を確認できないとしても、それを理由に調査を止める必要はありません。
ネットワーク到達性と既存の緩和策
このセクションでは、脆弱性が実際に悪用可能かどうかを判断するための手順を説明します。ITネットワークやオフィスネットワークから対象資産に到達できますか？もしできるなら、それは悪用の現実的な経路となります。製造業の問題点は、OTネットワークがインターネットリソースへのアクセスを許可していたり、ベンダーがリモートからトラブルシューティングできるよう設定されていたりする点にあります。
これにより、まったく新たな要素が加わります。資産がインターネットから到達可能であれば、インターネット接続さえあれば誰でもアクセスできることになります。どのように対策を講じますか？非常に具体的なファイアウォールルールとアクセス制御が必要です。shodan.ioで自社のパブリックIPアドレスを検索し、何が表示されるか確認してみてください。悪用可能性についてより具体的なイメージが掴めるはずです。外部からの悪用を防ぐ最善策は、資産が外部リソースに接続できないようにし、不正なソースからのインバウンドアクセスをブロックすることです。
このコンテキストにおける最適な緩和策は以下のとおりです。
アクセス制御を備えたネットワークセグメンテーション：理想的には、ITネットワークとOTネットワークの間に、ジャンプボックスまたはジャンプサーバーを設置したDMZを構築します。適切に設定することで認証レイヤーが追加され、認証不要な脆弱性が追加レイヤーを突破できなくなります。
ファイアウォールおよび資産上でのアクセス制御：OTネットワークの多くは場当たり的に構築されており、適切なDMZやジャンプサーバーが存在しないケースも多くあります。その場合は、ファイアウォールのACLを活用し、可能であれば資産側のファイアウォールも設定することが最善策です。特定のポートやIPアドレスをブロックするのは、通常これらの方法で簡単に実現できます。
強力かつ固有のパスワード：デフォルトアカウント、パスワード未設定の管理者アカウント、ベンダーアカウントなどは、往々にして放置されたままチェックされません。これらのアカウントが無効化されているか、適切な認証情報が設定されているかを必ず確認してください。パスワードは複数の単語を組み合わせた「パスフレーズ」にする必要があります。単純なパスワードの使い回しをやめ、「TheGrassIsGreenerOnTheOtherSide」のようなフレーズを作成しましょう。管理にはパスワードマネージャーの利用を推奨します。
攻撃経路の検証
これは難しい作業になる場合があります。すべての脆弱性に明確な攻撃経路があるわけではないからです。その特定のCVEがどのように悪用されるかを丁寧に調べてください。攻撃経路に関するレポートを確認しましょう。特定のポートが必要ですか？特定のサービスやソフトウェアの起動が前提条件ですか？
例として、CVSSスコア9.8のCVE-2025-27495を見てみましょう。この脆弱性の攻撃経路は非常に明快です。ポート8000がデフォルトで開放されており、攻撃者はインターネットからそのポートにデータを送信できる環境さえあれば、サーバーを乗っ取ったり、データを消去したり、OTネットワークへの横展開を行ったりできます。
このような脆弱性に対する即時対応策は以下のとおりです。
- サーバーの動作に明示的に必要なトラフィック以外について、ファイアウォールでポート8000をブロックする。
- ソフトウェアにパッチを当てる。メンテナンスウィンドウを調整してパッチを適用することを検討してください。OT環境でのパッチ適用は、テスト環境や開発環境がない場合にリスクを伴うことがあります。パッチ適用によって問題が発生した際に復元できるよう、事前にサーバーの最新バックアップを取得しておいてください。
- サーバーがネットワーク上で適切にセグメント化されていることを確認する。制御対象の資産または必要な情報源とのみ通信できる状態にするべきです。
- コンピューター上のすべてのアカウントに、機能に必要な最小限の権限のみが付与されていることを確認する。
これらの緩和策を実施したら、必ず文書化しておきましょう。これが上司に報告できる具体的な成果物となります。
修正完了まで、リスクを受容できるか
資産が脆弱で悪用可能であっても、しばらくの間は緩和も修正もできないケースがあります。PLCであれば、特に急な依頼ではパッチ適用の時間を確保するのは困難です。Windows XPのコンピュータやHMIであれば、そもそも利用可能なパッチが存在しません。こうした場合はどうすればよいでしょうか。選択肢は「何もしない」か「修正するか」の二択ではありません。
リスク受容は、ITおよびOTのリーダーシップ、運用担当者、法務が関与する正式なプロセスです。リスクの内容、実施している補完的な管理策（例：強化されたモニタリング、ログとトラフィックの追加チェック、追加の保護レイヤーの導入）、管理策の責任者、そして再評価の期日を明記した書面による記録を残す必要があります。
総まとめ
このフレームワークの目的は、すべての検出結果を言い訳で片付けることではありません。「現在の環境と対策を踏まえて、これは悪用可能なのか」という問いに答えるためのツールを提供し、問題が悪用可能である場合に解決または緩和するための出発点を示すことにあります。適切なACLを備えた2つのファイアウォールで3つのネットワーク奥に隔離されたCVSSスコア10の脆弱性と、インターネットからアクセス可能なフラットネットワーク上にデフォルトパスワードのまま存在するCVSSスコア10の脆弱性とでは、リスクがまったく異なります。
ドキュメントは強力な味方です。パズルの各ピースを一つひとつ丁寧に確認し、インベントリ、アカウント、パスワードなど、現状の対策内容を文書化してください。それをもとにダッシュボードや経営層向けサマリーなどを作成し、どこにギャップがあるかをリーダーシップに示すことができます。
翻訳元: https://www.helpnetsecurity.com/2026/06/04/ot-vulnerability-management-process/
