なぜ工場フロアはネットワーク上で最も脆弱な標的なのか

私が話をするセキュリティチームの多くは、それなりのITハイジーンを持っています。エンドポイントにEDR、WindowsイベントログをインジェストするSIEM、WebアプリケーションにWAF。ところが、工場フロアで何が稼働しているかを聞くと、返ってくる答えはたいてい「Siemens S7と三菱のSCADA、あとは正直よく分からない」というものです。

「SOCがある」と「OT環境の可視性がある」の間にあるギャップ — そこに本当のリスクが潜んでいます。

日本企業のタイ拠点という文脈では、このギャップはさらに重要な意味を持ちます。NISC（内閣サイバーセキュリティセンター）の重要インフラ防護ガイドラインはOTセキュリティに明示的に言及しており、J-SOXの内部統制要件は製造拠点のOTシステムにも及びます。OTの可視性がないことは、セキュリティ上のリスクであるだけでなく、コンプライアンス上のリスクでもあります。

アーキテクチャの問題

パデューモデル（ISA-99）は、OTとITを分離して維持するために設計されました。理論上は、Level 0〜2が物理プロセス（PLC・センサー・アクチュエーター）、Level 3が製造オペレーション（MES・ヒストリアン）、Level 4以上がエンタープライズITで、3と4の間にDMZが置かれます。インターネットから直接PLCに触れるものは何もない — というのが設計思想です。

実際には、その境界はここ15年で侵食されてきました。理由はひとつの言葉に集約されます：リモートアクセス。

プラントエンジニアは自宅からヒストリアンにSSHで接続する必要がありました。ベンダーは自社機器のファームウェアを更新するためにVPNアクセスが必要でした。経営陣はERPにリアルタイムのOEEダッシュボードを求めました。それぞれは合理的なビジネス要求でした。しかし積み重なった結果、パデューモデルは穴だらけになりました。

現実として残るのは、以下のような工場ネットワークです：

2009年製ファームウェアのPLCがModbus TCP上で認証なしで稼働
Windows Server 2012 R2（EOL、未パッチ、L3とL4の両方に存在）で動くヒストリアン
ベンダーが設定したまま誰もローテーションしていない認証情報でOTセグメントに直接接続するベンダーVPNコンセントレーター
メールチェックとHMI操作を同じワークステーションで行うオペレーター

これは仮定の話ではありません。私が見てきたほぼすべての工場がこの状態です。

攻撃者が実際にやること

OT攻撃が工場フロアから始まることはほとんどありません。IT攻撃と同じ場所から始まります — フィッシング、公開されたRDP、侵害されたベンダーアカウント — そこからピボットします。

典型的な経路：

ITエンドポイント（Windowsワークステーション、メールサーバー）の侵害
ヒストリアンまたはエンジニアリングワークステーション（ブリッジマシン）へのラテラルムーブ
OTセグメントの列挙：ポート502のModbus、44818のEtherNet/IP、DCOMのOPC-DAをスキャン
プロセスのマッピング：このPLCは何を制御しているか？セットポイントを変更すると何が起きるか？
ランサムウェアの展開（ヒストリアンを暗号化して身代金要求）、またはプロセスへの直接介入

Stuxnetはステップ5です。現在の攻撃者のほとんどはステップ4で止まり、ランサムウェアに向かいます。リスクが低く収益が早いからです。しかしステップ5の能力は実在し、ほとんどのプラントマネージャーが認識しているよりも参入障壁は低くなっています。

標準的なITセキュリティツールでは検知できない理由

EDRはPLC上で動きません。脆弱性スキャナーをPLCに向けるとクラッシュさせます — アクティブスキャンはPLCのTCPスタックが処理できないプローブパケットを送信するからです。

OTには異なるアプローチが必要です：

パッシブ監視のみ。 ネットワークをタップ（SPANポートまたはネットワークTAP）し、トラフィックを生成せずに観測します。ZeekはこのためのツールとしてOSSの中で最良の選択肢です。一部の商用ツール（Claroty、Dragos、Nozomi）はOTプロトコルデコーダーを標準で備えています。

プロトコル認識型の検知。 稼働中の工場における通常のModbusトラフィックは非常に反復的です — SCADAが同じコイルを同じ間隔で一日中ポーリングします。異常とは：午前2時に新しいソースIPがModbus WRITE MULTIPLE REGISTERSを送信すること、通常は現れないファンクションコード（FC 8、診断）が突然現れること。これはシグネチャベースの検知ではなく、行動ベースラインです。

アセット中心のアラート。 ITではユーザーにアラートを出します。OTでは物理機器に紐付いた特定のIP/MACの組み合わせ — アセットにアラートを出します。「PLC-04が10.0.1.88から非要請接続を受けた」は対処可能です。「異常なModbusトラフィックを検知」では対処できません。

Wazuhを使った現実的な出発点

すでにITでWazuhを運用しているなら、専用のOTプラットフォームを購入せずにOTへ拡張できます。Dragosほどのカバレッジにはなりませんが、タイの日系工場の多くが今直面している問題は「エンタープライズOT XDRが必要」ではなく「可視性がゼロ」です。

推奨する開始アーキテクチャ：

flowchart TD
  subgraph OT["OT Network (Level 2/3)"]
    PLC1["PLC (Modbus TCP)"]
    PLC2["PLC (EtherNet/IP)"]
    HMI["HMI Workstation"]
    SCADA["SCADA / Historian"]
    OT_SW["OT Switch (SPAN port)"]

    PLC1 --> OT_SW
    PLC2 --> OT_SW
    HMI --> OT_SW
    SCADA --> OT_SW
  end

  subgraph SENSOR["Passive Sensor (DMZ)"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor\n(modbus.log / conn.log)"]
    AGENT["Wazuh Agent"]

    TAP --> ZEEK
    ZEEK --> AGENT
  end

  subgraph SOC["SOC Backend (IT Network)"]
    WAZUH["Wazuh Manager\n(OT Detection Rules)"]
    OS["OpenSearch / Kibana\n(OT Dashboard)"]
    IRIS["DFIR-IRIS\n(Case Management)"]
    PD["PagerDuty\n(Alerting)"]

    WAZUH --> OS
    WAZUH --> IRIS
    WAZUH --> PD
  end

  OT_SW -->|"SPAN (read-only)"| TAP
  AGENT -->|"Encrypted log shipping"| WAZUH
  SCADA ---|"Bridge host\n(monitored)"| IT_FW

  IT_FW["Firewall / DMZ"]
  IT_FW --> WAZUH

まず作成すべきWazuhルール：

メンテナンスウィンドウ外でのModbus FC 5（Write Single Coil）またはFC 15（Write Multiple Coils）に対するアラート
既知のPLCアドレスと通信する新しいソースIPに対するアラート
OTとITの両サブネットに存在するヒストリアンが業務時間外にITサイドのホストから接続を受けた場合のアラート
EtherNet/IP List Identityブロードキャスト（一般的な偵察ステップ）に対するアラート

ModbusのWazuhルールセットはデフォルト配布には含まれていません — カスタムデコーダーを書く必要があります。Modbus TCPペイロードはTCPストリームのバイト7から始まり、ファンクションコードはPDUの最初のバイトです。Zeekのmodbus.logはすでにこれをパースした状態で提供します。

最も難しい部分：ラインを止めずにインシデント対応する

OTのインシデント対応は、ITのIRにはない制約があります。生産稼働中にPLCを隔離することはできません。プロセスを実行中のHMIをリイメージすることもできません。OTでは可用性が機密性と完全性より優先されます — エンタープライズITの逆です。

つまり、IRプレイブックはインシデント発生前に、セキュリティチームだけでなくオペレーションとの協同で作成しておく必要があります。各アセットについて：隔離のブラストレディウスは何か？統制されたシャットダウンを誰が承認するか？SCADAが落ちたときの手動フォールバックは何か？

日系タイ工場においては、これらの決定が日本本社の承認プロセスを経る場合があります。その承認経路をプレイブックに明記しておくことが、インシデント発生時の対応速度を大きく左右します。

どこから始めるか

ITシステム部門内でビジネスケースを構築しようとしているIT/OTエンジニアにとって、最も摩擦の少ない出発点はパッシブOTアセットディスカバリーです。エージェント不要、アクティブスキャン不要、本番ネットワークへの変更なし。OTスイッチにTAPを設置してZeekを2週間稼働させるだけです。

得られるもの：

完全なアセットインベントリ（デバイスタイプ、IP、MAC、プロトコル、特定できればベンダー）
通信マトリクス（誰が誰と、どのプロトコルで、どの頻度で通信しているか）
異常ベースライン

このアウトプットだけで、多くの場合、次フェーズの予算承認には十分です。ほとんどのプラントマネージャーは自社のOTネットワーク上に何があるか知りません。ネットワークマップとして視覚的に示すことで、脅威レポートでは伝えられない形でリスクを具体化できます。

まとめ

OTセキュリティはもはや特殊な領域ではありません。ツールは大きな予算なしに導入できるほど成熟しており、脅威は「後回し」を正当化できないほどリアルです。今後24ヶ月以内にOT標的型ランサムウェアの被害を受ける工場の大半は、ギャップを認識していながら行動しなかったところになるでしょう。

良いニュースは、ベースラインが低いことです。どんな可視性でも、ないよりはるかにましです。すべてを一度にやる必要はありません — パッシブTAP、Zeekセンサー、よく書かれたWazuhルールをいくつか、そこから始めてください。それだけで東南アジアの産業サイトの80%より前に進めます。

Simplico Co., Ltd. はタイおよび東南アジア全域の製造業・重要インフラ向けにOT/ITセキュリティインフラを構築しています。OT環境の評価にセカンドオピニオンが必要でしたら、お気軽にご連絡ください。日本語・英語・タイ語でご対応します。

関連サービス