こんにちは！ITインフラやセキュリティの現場に配属されて間もない方、あるいは「なんだか急にOT（制御システム）やIoTのセキュリティも見るように言われたけど、何から手をつけていいか分からない…」と頭を抱えている方、いらっしゃいませんか？
オフィスのPCを守るのとは違い、工場の機械を動かす「SCADA（スカダ）」や産業用ネットワークの世界は、独特のルールと恐ろしいリスクが隣り合わせです。今回は、産業用プロトコル（S7やEtherNet/IPなど）の通信を監視する技術「DPI（ディープパケットインスペクション）」について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. そもそもSCADAと産業用プロトコルって何？（身近な例えで解説）
皆さんのご自宅を想像してみてください。玄関の鍵は頑丈なものをつけていますよね。では、リビングにあるエアコンや給湯器はどうでしょう？ リモコンさえあれば、誰でもボタン一つで動かせます。
工場の生産ラインや、ダム、発電所などの重要インフラ（これらをまとめてOT：Operational Technologyと呼びます）も、基本的には同じ構造をしています。
中央のコントロールルームにある司令塔（これがSCADAです）から、「バルブを開けろ！」「モーターの回転数を上げろ！」という指示を、現場の機械（PLC：プログラマブルロジックコントローラ）に向けて送っています。
このとき、司令塔と機械がおしゃべりするために使っている「共通の言葉」が、産業用プロトコル（S7、EtherNet/IP、DNP3など）です。
オフィスの通信と何が違うの？
通常のWebサイトを見る通信（HTTPなど）なら、変なデータが来たら「エラーです」と言って遮断しても、せいぜいページが見られなくなるだけです。
しかし、産業用プロトコルは違います。「ボイラーの温度を限界突破させろ」という不正なコマンドが機械に届いてしまったら？ 現実世界で大爆発や設備の破損という、取り返しのつかない物理的ダメージに直結してしまいます。これが、OTセキュリティが恐ろしい理由なんですね。
—
2. 泥棒を防ぐ「インターホン」の限界と、DPI（ディープパケットインスペクション）の正体
では、工場への不審者の侵入を防ぐために、従来の一般的な「ファイアウォール」を置いてみたとしましょう。
これは例えるなら、「制服を着た人なら誰でも通す、工場の正門の警備員」のようなものです。
警備員（従来のファイアウォール）は、通信の「宛先IPアドレス」や「ポート番号」だけを見て、「あ、この通信は社内から来たから通してよし！」と判断します。
しかし、もしその「社内の人」のパソコンがサイバー攻撃者に乗っ取られていたらどうなるでしょう？
警備員は「顔見知りだから」とすんなり通してしまいます。その結果、悪意ある人間がこっそり工場に入り込み、危険なコマンドを機械に送り放題になってしまうのです。
そこで登場するのが「DPI（ディープパケットインスペクション）」です！
DPIは、日本語に訳すと「パケットの深層検査」となります。
先ほどの例えで言うと、正門の警備員だけでなく、「荷物のカバンを一つずつ開けさせて、中身の書類や道具に『やばい命令書』が入っていないか一文字一文字チェックする超優秀な番人」です。
産業用ファイアウォールやIDS（侵入検知システム）に組み込まれたDPIエンジンは、ただ通信の宛先を見るだけでなく、パケットのペイロード（中身のデータ）まで覗き見ます。
例えば、Siemens社のPLCで使われるS7プロトコルであれば、「あ、今この通信、機械を『STOP（停止）』させるファンクションコード（命令）を送ろうとしているぞ！ しかも送信元はこのエリアの端末じゃない！」というところまで見抜いて、ガッチリと遮断してくれるのです。
—
3. 実務で役立つ！SnortルールによるS7プロトコルの異常検知設定
「理屈は分かったけれど、実際にどうやって設定するの？」という方のために、オープンソースのIDS（Snortなど）で使われるDPIルールのイメージを見てみましょう。
実務の現場では、産業用プロトコルのパケット構造（ヘッダーやファンクションコード）を解析し、特定の危険な操作を検知するルールをファイアウォールやIDSに流し込みます。
以下は、S7プロトコルにおいて、PLCを強制停止させるような不正なコマンドを検知するための設定サンプルです。
# ==========================================
# S7プロトコルの異常停止（PLC STOP）コマンド検知ルール
# ==========================================
alert tcp any any -> $PLC_NET 102 (
msg: "OT_SECURITY: 不正なS7 PLC停止コマンドを検知しました！";
flow: established, to_server;
# S7プロトコルのCOTpヘッダーおよびROSCTR（パケット種別）を検査
content: "|32|"; depth: 1; offset: 5;
# S7ファンクションコード "Job (0xf0)" および 停止要求のバイト列をキャッチ
content: "|f0|"; distance: 0; within: 5;
classtype: attempted-admin;
sid: 8000001;
rev: 1;
)パラメーターの解説（初心者向け）：
alert tcp any any -> $PLC_NET 102: 外部からPLCの標準ポートである102番ポートに向かうTCP通信をすべて監視します。content: "|32|";: S7プロトコルのマジックバイト（識別子）である0x32が含まれているかを確認しています。sid: 8000001;: このルールを識別するための独自のID番号です。社内でインシデント管理をする際にこの番号が手掛かりになります。
このように、DPIは「あらかじめ定義された安全なルール」に照らし合わせながら、産業用プロトコルの細かいバイト列をチェックしているのです。
—
4. 現場のインフラ担当者が直面する「DPI運用の泥臭い現実」と対策
教科書やカタログスペックでは「DPIを入れれば工場は安全！」と書かれていますが、現場のインフラ担当者である私たちは、もっと泥臭い現実に直面します。
1. 「誤検知（フォールポジティブ）」の恐怖
- 厳しすぎるDPIルールを設定したせいで、正規のメンテナンス作業の通信まで「異常なコマンドだ！」と勘違いされ、工場のラインが突然止まってしまった……。これは現場で最も恐れられる大惨事です。
2. レガシーシステムのブラックボックス化
- 稼働してから20年経つような古いPLCや、メーカー独自仕様のプロトコルが使われている場合、DPIのパーサー（解析プログラム）がうまく中身を理解できず、スルーしてしまうことがあります。
一歩ずつ進めるための実務アドバイス
いきなりすべての通信をDPIで「遮断（ブロック）」モードにするのは絶対にやめましょう。
まずは「検知（アラート）モード」で導入し、工場内でどんな通信が普段飛び交っているのかを数週間〜数ヶ月かけてじっくり観察してください。その上で、正規の通信パターンをホワイトリストとして地道に登録していくことが、現場を止めることなくセキュリティを向上させる王道であり、一番確実なアプローチとなります。
—
まとめ
今回は、産業用プロトコルのディープパケットインスペクション（DPI）について、家の防衛や警備員の例えを交えて解説しました。
- 従来のファイアウォールは「宛先を見るだけの正門の警備員」
- DPIは「カバンの中身の命令書まで細かくチェックする超優秀な番人」
- ただし、現場への導入時は「誤検知によるライン停止」に十分注意し、まずはアラート監視から一歩ずつ進めること！
OT・IoTセキュリティの世界は奥が深く、最初は難しく感じるかもしれませんが、実務の泥臭い経験を積むことで確実にスキルアップできます。焦らず、一歩ずつ安全なインフラを作っていきましょう！
コメント