THE QUESTION
PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装について、この回が担う固有の論点は何か。
STORY SO FAR
前回「なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別」で確認した論点を受け、この回ではPLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装について、この回が担う固有の論点は何か。を扱う。
PLCへ不正なプログラムを書き込めたとしても、それだけでは長期間の攻撃は難しい。
設備に異常が出れば、保全担当者はEngineering WorkstationからPLCへオンライン接続し、プログラムやデータブロック、I/O、診断情報を確認する。見覚えのないコードが追加されていれば、その時点で侵入が疑われる可能性がある。
Stuxnetが特異だったのは、この「確認する側」まで攻撃設計に含めていたことである。
後期1.x系統では、STEP 7とPLCの通信を扱うWindows側DLLへ介入し、PLCへ送るデータとPLCから読み出すデータの一部を横取りした。古い0.5系統では、実際のプロセスが異常状態へ動いている間に正常時の入力値を再生し、運転員へ正常に見せる仕組みまで解析されている。
つまりStuxnetは、Manipulation of ControlとManipulation of Viewを組み合わせた。
本記事では、攻撃コードそのものの再現方法ではなく、制御システムのどの信頼関係が破られたのかを追う。
結論――「PLCを変える」と「PLCをどう見せるか」が一体だった
通常のPLC保守では、Engineering Workstationからオンライン接続し、PLC内のプログラムを読み出せば実行中のロジックを確認できると考える。
Stuxnetは、この前提を壊した。
Broadcom/Symantecの解析では、STEP 7からPLCへアクセスする際に使われるDLLをStuxnetが置き換え、正規DLLを別名で残したうえで、特定のPLC操作だけを横取りする構造が確認された。改変DLLは元の109個のexportを持ち、その大部分を正規DLLへ転送しつつ、PLCのコードブロックの読出し・書込み・探索に関係する16個を傍受した。
これによって、通常の操作は正常に見える。
しかし重要な操作だけはStuxnetが間に入り、PLCへ書く内容、PLCから返す内容を変更できる。
攻撃者にとって理想的なのは、PLCへ悪性ロジックを追加した後も、エンジニアがSTEP 7で確認したときにそのコードが見えない状態である。StuxnetのPLC rootkit機能は、その方向に設計されていた。
なぜEngineering Workstation側へ仕掛けるのか
PLC内部だけを改変すると、確認経路は攻撃者の支配外に残る。
エンジニアが別の信頼できるツールからPLCを読み出し、基準プログラムと比較すれば差分が見える可能性がある。
しかし、PLCを確認するためのSTEP 7側通信にマルウェアが入り込めば、話が変わる。
Engineering Workstationは、通常運転ではPLCへプログラムを書き、診断し、オンラインモニタを行う「信頼された管理端末」である。Stuxnetはその信頼点へ寄生した。
これは一般ITでいうrootkitと似ている。OS内部を改変し、ファイルやプロセスの一覧から自身を隠すrootkitは、監視ツールがOS自身から情報を得るという前提を利用する。StuxnetのPLC rootkitも、エンジニアがSTEP 7を通じてPLCを確認するという前提を利用した。
PLCの実体と、STEP 7から見えるPLCが同じだと信じている限り、隠蔽が成立する。
正規通信へ介入する強さ
制御システムでは、PLCへの書込みは通常、専用ソフトウェアと専用プロトコルを通じて行われる。
そのため、ネットワーク上で見慣れないプロトコルを使えば異常として検出しやすい。一方、正規Engineering Workstationが通常と同じ通信でPLCへアクセスしているなら、ネットワーク境界からは異常が見えにくい。
Stuxnetはこの点でも効率的だった。
攻撃者が独自のPLCプログラマを一から実装し、外部から直接PLCへ話しかける必要はない。STEP 7が持つ正規アクセス機能の途中へ割り込み、必要な部分だけを改変すればよい。
これは防御側に難しい問題を残す。
「通信元IPがEngineering Workstationだから許可」「プロトコルが正規だから許可」というルールだけでは、侵害されたEngineering Workstationからの悪性変更を区別できない。
送信元だけでなく、何を変更したか、変更が承認済みか、PLC内の最終ロジックが基準版と一致するかを確認する必要がある。
PLC側では何が変わったのか
Stuxnetは対象PLCへ複数のコードブロックとデータブロックを送り込み、既存の実行シーケンスへ自身の処理を組み込んだ。
MITRE ATT&CK for ICSでは、StuxnetがPLCのタスクを変更し、OB1などに介入して悪性コードがスキャンサイクルで実行される例として整理されている。
PLCは一般に、入力イメージを更新し、ユーザープログラムを実行し、出力イメージを更新するサイクルを繰り返す。そこへ追加ロジックが入れば、本来のプログラムが同じでも、特定条件で出力を差し替えたり、周辺装置へ別の指令を送ったりできる。
後期1.x系統では、この仕組みが周波数変換器への異常な周波数指令につながる。
古い0.5系統では、417 PLCを使ってバルブ状態を変更する攻撃が解析された。
ただし、ここで重要なのは具体的なコードブロックの書き方ではない。正規ロジックの横に、条件成立時だけ介入する別の制御経路を追加できたという構造である。
「正常時は何もしない」が隠密性を上げる
設備攻撃では、常に異常動作させるとすぐに見つかる。
モーターが毎日起動直後に暴走すれば、保全担当者は制御異常を疑う。バルブが常に不自然な状態なら、工程データの傾向から発見される。
Stuxnetの攻撃ロジックは、長い通常運転の中に短い異常操作を挿入する設計だった。
後期1.x系統の周波数操作では、通常運転状態を長く維持した後、短時間だけ周波数を大きく変え、その後また正常へ戻す。0.5系統でも、攻撃の前に正常状態を記録し、その値を後で運転員へ見せる仕組みが解析された。
この方式なら、設備の故障が「制御指令による意図的な異常」ではなく、「機械の偶発故障」「品質のばらつき」「センサー不良」に見える可能性がある。
サイバー攻撃の目的が一度の停止ではなく、長期的な設備劣化や工程妨害なら、隠密性は破壊力と同じくらい重要になる。
Stuxnet 0.5のreplayが示したもの
Stuxnet 0.5の解析で特に象徴的なのが、正常状態のスナップショットを保存し、攻撃中にそれをreplayする仕組みである。
Symantec/Broadcomは、0.5系統の417 PLC攻撃が、UF6を遠心分離機へ送るバルブの状態を操作すると同時に、システムの正常稼働時の値を記録し、攻撃中に正常値を再生する機能を持っていたと説明している。[2]
これが意味するのは、HMIや監視画面に表示される値が、現実のプロセスと一致しなくなることである。
運転員は画面を見て「正常」と判断する。しかし実際のバルブ状態や工程は異なる。
MITRE ATT&CK for ICSは、このような行為をManipulation of Viewとして整理し、Stuxnetを代表例に挙げている。
銀行強盗が監視カメラへ過去映像を流す比喩が使われることがあるが、制御設備ではもっと深刻である。監視値は単なる記録ではなく、運転員が次の操作を決める入力だからだ。
偽の正常値を信じた運転員が追加操作を行えば、異常を止めるどころか拡大させる可能性さえある。
I/O imageを操作する意味
PLCは物理入力を毎スキャン読み込み、内部の入力イメージへ保持し、プログラム演算後に出力イメージを更新する。
MITRE ATT&CK for ICSでは、StuxnetがI/O imageを操作する例も整理されている。出力側への書込みを横取りし、運転員から見える状態と実際に周辺機器へ送る指令の関係を変えることができれば、単純な「PLCプログラム差分」だけでは異常を見つけにくい。
ここで重要なのは、PLCのユーザープログラムとI/O状態を別々に考えることである。
制御エンジニアがプログラムを見て「この条件なら出力YはOFFになる」と確認しても、攻撃コードがその後段で出力イメージや周辺通信へ介入すれば、現実の出力は想定と違う可能性がある。
つまり検証対象は、ラダーやSTのソースコードだけでは足りない。
- PLCへ実際にロードされている全ブロック
- 実行順序
- 通信ブロック
- 強制I/O
- パラメータ
- 周辺ドライブ設定
- 物理センサーの実測
まで見なければ、異常の全体像を確認できない。
「画面が正常」は証拠にならなくなる
制御設備の障害対応では、HMIやSCADAのトレンドが重要な証拠になる。
温度、圧力、回転数、流量、バルブ開度、アラーム履歴。それらを見て、いつから何が変化したかを推定する。
しかしManipulation of Viewが成立すると、その証拠自体が汚染される。
Stuxnet 0.5のreplayは、この問題を現実の攻撃で示した。
防御側は「PLCが報告する値」と「独立した物理測定」を分離する必要がある。たとえば回転機械なら、PLC内部の回転数指令だけでなく、独立した振動監視、電流、機械保護装置、別系統の速度検出を組み合わせる。重要工程なら、Safety Instrumented Systemや独立保護層が同じEngineering Workstation・同じ通信経路に依存していないかを確認する。
これはサイバーセキュリティだけの話ではない。
プロセス安全の「独立保護層」という考え方と、セキュリティ上の信頼境界が重なる部分である。
なぜ異常が故障に見えるのか
機械設備はもともと壊れる。
ベアリングは摩耗し、ロータはアンバランスになり、センサーはドリフトし、インバータはトリップする。設備停止の原因は一つではない。
そこで攻撃者が短時間の異常指令を長い通常運転へ混ぜると、物理故障だけを見た保全担当者は、制御系への侵入より先に機械故障を疑う可能性がある。
さらにHMIの値まで正常に見えれば、制御側の疑いは弱くなる。
Stuxnetの恐ろしさは、一撃で設備を爆発させる派手さではない。故障原因の切り分けを誤らせ、攻撃と機械故障の境界を曖昧にできることにある。
これは長期間の妨害に向いている。
部品を交換して復旧しても、攻撃ロジックが残っていれば再発する。現場は「部品品質が悪い」「回転機械が不安定」と考え、根本原因のPLC改変へ届かない可能性がある。
防御側は何を基準に信頼すべきか
Stuxnet型の隠蔽に対抗するには、単一の画面や単一のEngineering Workstationを真実の源にしないことが重要になる。
まずPLCロジックのgold copy、承認済み基準版をオフラインで保持する。Engineering Workstation上のプロジェクトだけを正本にしない。
次に、PLCから読み出したロジックを別経路で比較できるようにする。可能ならハッシュ、署名、バージョン管理、変更承認と組み合わせる。
さらに、重要なプロセス値を独立した計測や保護装置から確認する。PLC/HMIの値が正常でも、モーター電流、振動、機械保護リレー、独立センサーが異常なら、制御系の信頼性を疑う。
Engineering Workstationについても、OS、アプリケーション、DLL、プロジェクト、接続履歴を一体で監視する必要がある。PLCだけを「設備」と考え、Engineering Workstationを単なる事務PCとして扱うと、Stuxnetと同じ信頼点を残す。
MITRE ATT&CK for ICSがStuxnetをModify Controller Tasking、Manipulation of Control、Manipulation of View、Masqueradingなど複数技法へ割り当てているのは、この多層性を示している。
「アラームを消す」のとは違う
監視偽装というと、HMIのアラームをOFFにする、警報履歴を削除する、といった単純な操作を想像しやすい。Stuxnetが示した問題はそれより深い。
アラームは、PLCやSCADAが受け取った値に対して条件判定した結果である。もし入力値そのもの、I/O image、PLCからEngineering Workstationへ返るコードやデータが偽られていれば、上位のアラームロジックは「正常値を正常と判定」してしまう。
この場合、アラーム設定をどれだけ厳しくしても検出できない。
たとえば実際の回転数が危険域へ変化しているのに、HMIへ渡る速度フィードバックが過去の正常値なら、上位監視は正常と判断する。実際のバルブが閉じられているのに、監視側へ「開」を返せば、運転員は流量低下の原因を別の場所に探すかもしれない。
これはフェイルセーフ設計の前提にも関わる。多くの異常処理は「センサー値は正しい」「PLC内部の状態は正しく読める」ことを暗黙に前提としている。その前提が攻撃で崩れるなら、重要保護機能は別系統のセンサー、ハードワイヤード保護、独立安全PLCなどへ分離する価値が高くなる。
現場のデバッグ手順を逆手に取れる
設備トラブルが起きたとき、制御エンジニアは普通、原因を上流から順に切り分ける。
まずアラーム履歴を見る。次にI/O状態を確認する。ラダーやFBをオンラインモニタし、条件がどこで成立しているかを見る。必要ならインバータやサーボのモニタ値を確認する。最後に機械側のセンサーや配線を測る。
Stuxnet型のManipulation of Viewは、この標準的なデバッグ手順を逆手に取れる。
Engineering WorkstationとPLCの間が侵害されているのに、その同じEngineering Workstationでオンラインモニタを続ければ、調査者は攻撃者が加工した情報を根拠に原因を探すことになる。結果として、PLCより下流の機械、センサー、ドライブ、配線を繰り返し交換し、真の原因へ届かない可能性がある。
このため重大なOTインシデントでは、通常故障時のデバッグ手順とサイバーインシデント時の証拠保全手順を分ける必要がある。疑わしいEngineering Workstationをそのまま修復・再起動して証拠を失う前に、ネットワーク隔離、ディスク保全、PLCプログラムの独立取得、ログ保存を行う。
設備復旧を急ぐ現場では難しい判断だが、再発性のある異常ほど「機械故障だけではない」可能性を残すことが重要になる。
fail-safeだけでは足りず、fail-secureとの両立が必要になる
従来の制御設計では、通信断やセンサー断線、CPU異常が起きたときに設備を安全側へ停止させるフェイルセーフが中心になる。ところがStuxnetのような攻撃では、通信もCPUも動き続け、値ももっともらしく見える。
つまり「壊れたら安全側」という設計に対し、「壊れていないように見せながら誤った指令を出す」という異常系が追加される。
この場合、単一PLCの自己診断だけでは不足する。重要な安全機能を同じCPU・同じEngineering Workstation・同じネットワークへ集中させていると、一つの侵害が制御と保護の両方へ波及する。
防御では、独立した安全系、物理的な上限保護、機械式保護、別系統の監視、変更権限の分離といった多層構造が効く。これはサイバー対策というより、本来の安全設計の思想を悪意ある故障モードへ拡張する考え方である。
Stuxnetが制御工学へ突きつけたのは、「誤動作」だけでなく「意図的にもっともらしく誤動作する」ケースを異常系へ加える必要性だった。
検証ポイント｜1.x系統と0.5系統の隠蔽を一つにしない
Stuxnetの解説では、「遠心分離機を高速回転させながら正常な速度を画面へ表示した」と一文で説明されることがある。
しかし公開解析を厳密に読むと、複数系統を分けた方がよい。
後期1.x系統では、315系PLCと周波数変換器への異常指令、STEP 7側から悪性PLCコードを隠すrootkit機能などが確認されている。[1]
0.5系統では417 PLCのバルブ操作と、正常プロセス値の記録・replayが明確に解析されている。[2]
どちらも「制御と監視を同時に欺く」という共通思想を持つが、技術実装を同一視するべきではない。
本CASEでは、確認された機能を系統ごとに記述し、「Stuxnetなら全部の機能を同時に使った」とは扱わない。
検証ポイント｜PLCプログラムを見ただけで完全検出できるとは限らない
PLCのオンラインプログラム比較は重要な対策である。しかしStuxnetは、Engineering Workstation側の通信を改変することで、その確認経路へ介入した。
したがって、侵害されたSTEP 7端末自身を使って「PLCに異常はない」と確認しても、その結果を無条件には信用できない。
これはインシデント対応で重要な原則につながる。
調査に使う道具が攻撃者に侵害されている可能性を考えること。
OTでは、予備Engineering Workstation、オフラインの基準プロジェクト、独立したPLCアップロード手段、機器ベンダーの検証ツールなど、別の信頼経路を確保しておく意味がある。
制御工学とセキュリティの境界が消えた
Stuxnet以前、PLCプログラムの品質管理は主に設備の可動率、安全性、保守性の問題として扱われ、Windowsマルウェア対策はIT部門の問題として分けられがちだった。
Stuxnetは、その分業の境界を壊した。
Engineering Workstationが感染すれば、Windowsのセキュリティ事故がPLCプログラムの完全性問題になる。PLCプログラムが改変されれば、インバータやバルブの異常動作が機械故障へつながる。HMI表示まで偽装されれば、運転員の意思決定も攻撃の一部になる。
つまり、異常系設計、フェイルセーフ、インターロック、変更管理、バックアップ、セキュリティ監視を別々に考えるだけでは足りない。
設備を守るには、「PCが侵害されても危険側へ行かないか」「PLCが改変されても独立保護が働くか」「監視値が偽られても物理異常を検出できるか」という多重故障の視点が必要になる。
これは制御設計者にとって、Stuxnetが残した最も実務的な教訓の一つである。
まとめ
Stuxnetが長期間気づかれにくかった理由は、単にコードを巧妙に隠したからではない。
PLCへ悪性ロジックを送り込む経路と、そのPLCをエンジニアが確認する経路を同時に支配した。後期系統ではSTEP 7とPLCの通信へ介入して悪性コードを隠し、0.5系統では実プロセスを操作しながら正常時の値をreplayする機能まで持っていた。
つまり、Stuxnetは「設備を変える」だけでなく、「設備がどう見えるか」も変えた。
制御システムでは、HMIの画面、PLCのオンラインモニタ、Engineering Workstationの読出し結果を、通常は現実の設備状態を知るための証拠として使う。Stuxnetは、その証拠生成経路自体を攻撃対象にした。
次の記事では、この隠蔽の先で何が起きたのかを見る。周波数変換器へ送られる指令が変わると、遠心分離機のような高速回転機械にはどのような物理的意味が生じるのか。ソフトウェアの命令が機械的ストレスへ変わる境界を、制御工学から追う。
FACT CHECK｜出典・参考資料
- [1] Symantec/Broadcom, Exploring Stuxnet’s PLC Infection Process
- [2] Symantec/Broadcom, Stuxnet 0.5: Disrupting Uranium Processing at Natanz
- [3] Symantec Security Response, Stuxnet 0.5: The Missing Link
- [4] MITRE ATT&CK for ICS, Stuxnet, Software S0603
- [5] MITRE ATT&CK for ICS, Manipulation of View, T0832
- [6] MITRE ATT&CK for ICS, Manipulation of Control, T0831
- [7] MITRE ATT&CK for ICS, Manipulate I/O Image, T0835
Stuxnet｜核施設を狙ったサイバー攻撃は何だったのか 第4回 全8回 全8回を見る
- 01 Stuxnetとは何だったのか――コンピューターから現実の設備へ
- 02 Stuxnet｜隔離された制御網へどう入ったのか――USBとゼロデイの侵入経路
- 03 Stuxnet｜なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別
- 04 Stuxnet｜PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装
- 05 Stuxnet｜遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作
- 06 Stuxnet｜なぜ標的はナタンズだと分かったのか――コードと設備構成の照合
- 07 Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」
- 08 Stuxnetが変えたもの――産業制御セキュリティに残った教訓