THE QUESTION
遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作について、この回が担う固有の論点は何か。
STORY SO FAR
前回「PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装」で確認した論点を受け、この回では遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作について、この回が担う固有の論点は何か。を扱う。
Stuxnetを「コンピューターウイルスが遠心分離機を壊した事件」と説明すると、最も重要な一段が抜け落ちる。
Windows上のコードは、そのまま機械を回せない。PLCも、それだけではロータを回せない。物理的な回転を変えるには、PLCから周波数変換器へ指令が渡り、周波数変換器がモーターへ供給する電力を変え、モーターが遠心分離機を駆動する必要がある。
Stuxnetの後期1.x系統で解析された攻撃は、この制御チェーンを狙った。
特定のS7-300系PLCとPROFIBUS構成、特定メーカーの周波数変換器、そして通常運転の周波数帯が一致した場合に、Stuxnetは長期間の通常運転へ短い異常周波数を挿入する。Symantec/Broadcomが解析した値には1410 Hz、2 Hz、1064 Hzが含まれていた。[1]
しかし、この数字を「遠心分離機が1410回転/秒で回った」と読むのは誤りである。ここでいうHzは周波数変換器の出力周波数であり、実際の機械回転数はモーター極数、すべり、駆動系などで決まる。
本記事では、Stuxnetがソフトウェアの値をどう物理的ストレスへ変換したかを制御工学の側から見る。
結論――攻撃したのは「PLC」ではなく、閉ループの物理プロセスだった
StuxnetはPLCへコードを書いた。それは事実である。
しかし攻撃の目的はPLCを故障させることではない。
PLCは制御の中継点で、最終的に変えたいのは回転機械の動作だった。
制御チェーンを単純化すると、次のようになる。
Engineering Workstation → PLC → PROFIBUS → 周波数変換器 → モーター → 遠心分離機
PLCは周波数変換器へ速度に関係する指令を出し、周波数変換器はモーターを駆動する。モーター回転が遠心分離機のロータへ伝わる。
Stuxnetは、この正規の制御経路へ不正な値を入れた。
だから設備側から見れば、インバータが壊れたわけでも、PLC CPUが停止したわけでもない。機器は「与えられた指令」を実行している。その指令を作るロジックが侵害されていた。
この構造は、OT攻撃を理解するうえで非常に重要である。
周波数変換器はなぜ狙いやすいのか
周波数変換器、VFDは、交流モーターの速度やトルクを制御するために出力周波数と電圧を変える装置である。
一般の設備では、ポンプ、ファン、コンベヤ、スピンドルなど多くの用途で使われる。PLCから通信やアナログ信号で速度指令を受け、設定された加減速時間、上限周波数、電流制限などに従ってモーターを運転する。
正常な制御であれば、PLCから来た速度指令は工程要求に対応している。
しかしPLC側が侵害されると、VFDにとっては「正規PLCから届いた正規形式の指令」に見える。
VFD自身が、上位指令の業務的な正当性を判断することは通常できない。
たとえば上位から高い周波数指令が来ても、それがVFDの設定上限内であり、モーター電流などが保護範囲を超えなければ、VFDは指令どおり動こうとする。
つまり攻撃者は、VFDのファームウェアを直接侵害しなくても、PLCを支配することで物理出力を変えられる。
807〜1210 Hzという条件が示すもの
Symantec/Broadcomの解析では、Stuxnetは周波数変換器が存在するだけでは攻撃を開始せず、対象ドライブの出力周波数が807〜1210 Hzの範囲にあることなどを条件としていた。
この値は、一般的な50/60 Hzのモーター運転から見ると非常に高い。
もちろんVFDの出力周波数と機械の実回転数は同一ではない。それでも、このような高周波数域を通常運転とする用途が特殊であることは分かる。
攻撃コード側がこの範囲を確認することには二つの意味がある。
第一に、標的設備をさらに絞り込める。
第二に、物理攻撃ロジックが「通常状態」を把握したうえで動くため、標的外で誤作動しにくくなる。
Stuxnetは、特定の部品構成と運転領域がそろうまで待った。これは単なる破壊コードというより、対象設備の運転条件を含んだ制御アプリケーションに近い。
1410 Hz、2 Hz、1064 Hzは何を意味するのか
Symantecが公表した解析では、Stuxnetは長い通常運転の中で、出力周波数を短時間だけ1410 Hzへ上げ、その後別のタイミングで2 Hzまで落とし、さらに1064 Hzへ変えるといった操作を行う。
ここで重要なのは、単一の「最大速度へ暴走させる」攻撃ではないことだ。
高速側への変化と、極端な低速側への変化が組み合わされている。
回転機械にとって、急激な速度変化は機械的・電気的ストレスになり得る。ロータ、軸受、駆動系、モーター、電源系は、通常運転の速度範囲と加減速パターンを前提に設計される。
遠心分離機のような高速回転体では、回転数の変化が遠心力、振動、共振、軸受負荷へ影響する。遠心力は回転角速度の二乗に比例するため、速度変化の影響は線形ではない。
ただし、公開されたStuxnet解析だけから各ロータに発生した応力値や破壊モードを一意に計算することはできない。実機の寸法、材質、ロータ設計、制御特性が必要だからである。
したがって本記事では、「1410 Hzなら何Nの応力で必ず壊れる」といった推測はしない。
確認できるのは、攻撃コードがVFD出力周波数を正常範囲から意図的に外し、機械へ異常な運転状態を与えるよう設計されていたことである。
周波数と回転数を混同してはいけない
制御分野では基本的な点だが、Stuxnet解説では混同されやすい。
VFDの出力周波数が1410 Hzだからといって、モーター軸が1410回転/秒、すなわち84,600 rpmで回ったと単純には言えない。[1]
同期速度は、交流モーターの極数と周波数から決まり、誘導機ならすべりもある。さらに遠心分離機側の駆動構造が存在すれば、その関係も考慮する必要がある。
一方で、Stuxnet解析に現れる「807〜1210 Hz」「1410 Hz」などの値が、一般の低速産業モーターとは異なる特殊な高速用途を示すfingerprintとして有効だったことは理解できる。[1]
ここでは数値を、実回転数の直接値ではなく、VFDへ与える電気的制御量として扱うのが正確である。
なぜ一度に止めず、何週間・何か月も待つのか
攻撃目的が単なる設備停止なら、PLCへ侵入した直後に異常指令を出す方が簡単である。
Stuxnetはそうしなかった。
通常運転を長く続け、特定のタイミングだけ異常操作を入れ、再び正常に戻す設計だった。
この時間設計には、隠密性の意味がある。
設備が即座に全停止すれば、制御システムへの攻撃が疑われやすい。逆に、複数の遠心分離機が時間を置いて故障し、部品交換が増え、原因が振動や品質問題に見えるなら、攻撃の存在は発見されにくい。
回転機械では、異常運転がその場で破断へ直結するとは限らない。疲労や摩耗、軸受へのダメージが蓄積し、後で故障として現れることもある。
そのため、「Stuxnetが指令を変えた瞬間＝遠心分離機が破壊された瞬間」と固定しない方がよい。
攻撃コードは物理ストレスを与える条件を作った。実際の故障は、機械側の状態と時間を経て発生する。
インターロックはなぜ止めなかったのか
制御エンジニアなら、「そんな異常速度を出したら上限リミットやインターロックで止まるのではないか」と考える。
その疑問は正しい。
通常、VFDには周波数上限、過電流、過電圧、過熱などの保護があり、PLC側にも速度上限や運転条件のインターロックを設けられる。機械側にも振動や速度の保護がある場合がある。
しかし保護が存在することと、悪性指令を必ず防げることは同じではない。
保護上限が正常運転より十分高く設定されていれば、プロセス上は危険でもVFDとしては許容範囲内の指令を受け入れる可能性がある。PLC側のインターロックが同じ侵害されたプログラム内にあれば、攻撃コードがその条件を回避または無効化する余地がある。
また、設備保護と生産制御が同じセンサー、同じPLC、同じ通信に依存していれば、一つの侵害が複数層へ波及する。
この点は現代のOTセキュリティでも重要である。
安全側へ止める保護機能が、通常制御と同じ信頼境界に入っていないか。
サイバー攻撃を異常系へ加えると、従来のフェイルセーフ設計を再点検する必要が出てくる。
物理量を独立監視する価値
PLCが送った周波数指令と、実際の機械状態が一致するかを別系統で監視できれば、Stuxnet型攻撃の検出余地は増える。
たとえば高速回転機械なら、実速度、振動、軸受温度、モーター電流、保護リレーの状態などが候補になる。
重要なのは、これらすべてを同じ侵害されたPLC経由で見るだけにしないことである。
PLCが「速度正常」と報告しても、独立振動監視が急変を検出すれば矛盾が生まれる。VFDの指令周波数と実回転の関係が通常と違えば、設備異常を疑える。
Stuxnet 0.5のreplay機能が示したように、監視値そのものが偽られる可能性があるなら、異なる物理原理・異なる制御経路から得た値を突き合わせる意味が大きくなる。
これは「センサーを二重化すればよい」という単純な話ではない。
二つのセンサーが同じPLCへ入り、同じ悪性ロジックで処理されるなら、表示側では同時に偽装される可能性がある。独立性をどこまで確保するかが設計上の論点になる。
0.5系統のバルブ攻撃とは別物である
ここで再び系統を分ける必要がある。
本記事の中心は、後期1.x系統で解析された315系PLCと周波数変換器への攻撃である。
Stuxnet 0.5で解析された417系攻撃は、同じ「遠心分離機を妨害する」目的に見えても、方法が違う。0.5ではUF6供給に関係するバルブ状態を操作し、正常時のプロセス値を記録・replayするロジックが確認された。
つまり、一方は回転駆動条件へ介入し、もう一方はプロセスの流れと監視へ介入する。
この二つを分けると、Stuxnet開発者が「一種類の破壊方法」だけを試していたのではなく、対象工程の異なる制御点を研究していた可能性が見えてくる。
ただし、両系統が同時期に同じPLCで同時実行されたという意味ではない。
サイバー攻撃というより、不正な制御変更として考える
制御設計者がStuxnetを理解するには、「マルウェア」という言葉を一度外してみると分かりやすい。
仮に、悪意あるエンジニアがPLCプログラムへ次のような仕様変更を密かに入れたとする。
- 特定の設備構成だけで有効になる。
- 通常は既存ロジックをそのまま動かす。
- 長時間待ってから短時間だけ速度指令を異常値へ変える。
- 操作後は元の指令へ戻す。
- オンライン確認では変更箇所を見えにくくする。
これは、不正な「設備改造」である。
Stuxnetは、その改造作業を人が現場で行う代わりに、Windows感染とPLCコード注入によって自動化したと考えられる。
そう見ると、防御策も変わる。
アンチウイルスだけでなく、PLCプログラムの変更管理、オンライン差分、ダウンロード権限、ドライブパラメータ監視、変更後試験、異常トレンド検出が必要になる。
つまりセキュリティを、IT部門だけの「ウイルス対策」から、設備変更管理の一部へ組み込む必要がある。
「速度指令を変える」だけではなく、制御ループを乗っ取る
VFDを使う設備では、単に周波数を指定するだけでなく、運転許可、正逆転、加減速、異常リセット、速度フィードバック、トルクや電流監視など複数の信号が関係する。上位PLCは、それらを組み合わせて一つの運転シーケンスを作る。
Stuxnetの物理ペイロードを理解するときも、「周波数設定値を一回書き換えた」と考えるより、正規シーケンスの途中へ別の制御ロジックを挿入したと考える方が近い。通常時は既存プログラムを通し、攻撃条件が成立したときだけ指令の一部を置き換える。攻撃が終われば正規制御へ戻る。
これは運転員から見ると厄介である。恒常的な設定ミスなら、立上げ時から挙動がおかしい。断線なら通信異常が出る。VFD故障ならアラーム履歴が残る。しかし上位PLCが正常な通信を使って一時的に異常指令を出す場合、ドライブ側には「上位から来た指令を実行した」という記録しか残らない可能性がある。
そのため原因解析では、VFDの故障履歴だけでなく、当時の指令値、PLCロジック、通信データ、Engineering Workstationの変更履歴を同じ時間軸で見る必要がある。OTインシデントで時刻同期が重要になる理由の一つもここにある。
加減速時間や機械保護も攻撃面になる
実設備では、速度指令が変わっても、VFDが設定された加減速時間に従って出力を変える。したがって物理ストレスは、最終周波数だけでなく、どの勾配で速度を変えるか、何秒保持するか、何回繰り返すかで変わる。
高速回転機械では、特定速度域を通過するときの振動や共振、ロータの安定性が設計上の問題になる。通常運転では、危険な速度域を素早く通過する、あるいはそもそも運転点にしない設計があり得る。攻撃者が速度プロファイルを自由に変えられるなら、こうした機械設計上の前提を崩せる。
ただし、公開Stuxnet資料だけでNatanzの各遠心分離機に設定されていた加減速時間や保護定数まで確定することはできない。本記事で言えるのは、VFD指令を長期かつ条件付きで変えるコードが存在し、機械側の通常運転条件を外すことを意図していた、という範囲である。
この不確実性を残すことは重要だ。制御工学では、同じ周波数指令でも、モーター定数、機械慣性、負荷、制御方式、保護設定によって結果が変わる。Stuxnetの物理効果を説明するときも、ソフトウェアの数値と機械破壊を一対一で短絡させてはいけない。
故障解析では「原因」と「誘因」を分ける必要がある
仮に遠心分離機の軸受やロータが故障したとしても、故障した部品だけを見れば、通常の機械故障と区別できない可能性がある。
軸受損傷、アンバランス、摩耗、接触、疲労は、サイバー攻撃がなくても起こる。Stuxnetが行ったのは、それらの故障モードを生み得る異常運転条件を意図的に作ることだったと考えられる。
したがって事故解析では、破損部品を最終原因とせず、その前にどの運転履歴があったかを確認する必要がある。これは一般の設備トラブルと同じである。ベアリングが壊れたから「ベアリング不良」で終わるのではなく、潤滑、芯出し、振動、負荷、速度履歴、温度を遡る。Stuxnetの場合、その履歴を作った上位PLCロジックまで遡る必要があった。
この視点を持つと、OTサイバー攻撃は機械保全と切り離せないことが分かる。サイバー側のログと、振動計・電流・温度・交換履歴などの保全データを別々に保存しているだけでは、後から因果関係を再構成しにくい。
攻撃者側にも実機試験が必要になる理由
物理設備を狙うコードは、PC上だけでテストして完成させるのが難しい。PLCプログラムが正しく動いても、VFDやモーターが想定どおり応答するとは限らないからである。
通信タイミング、PLCスキャン、ドライブ応答、加減速、保護、機械慣性、異常復帰など、実機または高精度な模擬環境で確認しなければ分からない要素が多い。Stuxnetのコードが特定のPLC・通信・ドライブ条件を細かく確認していた事実は、開発者が対象設備をかなり具体的に想定して試験していたことを示唆する。
2012年の帰属報道では、米国側が実物に近い遠心分離機を使って試験したという証言が報じられた。ただしこれは技術解析から直接分かる事実ではなく、匿名関係者を含む報道Evidenceである。CASE061-07では、このような「コードから分かること」と「作戦関係者の証言として報じられたこと」を分ける。
技術面だけでも、Stuxnetが単なるマルウェア開発ではなく、制御システムの統合試験に近い工程を必要とした可能性は高い。対象ハードウェアを細かくfingerprintする理由も、試験済みの構成でのみ確実に動かしたいと考えれば理解しやすい。
検証ポイント｜1410 Hzは「壊れる固有周波数」だと断定できない
Stuxnetの1410 Hzという値は非常に印象的である。そのため、「遠心分離機の共振周波数を正確に突いた」と説明されることがある。
しかし、公開されたSymantec解析だけから、1410 Hzが特定ロータの固有振動数そのものだったと断定することはできない。
VFDの電気出力周波数、モーター回転数、遠心分離機の機械共振は別の量である。実機設計が非公開である以上、数値の直接対応を外部から確定するには限界がある。
確認できるのは、Stuxnetが通常運転範囲を把握し、それを外れる高低の周波数指令を意図的に挿入したことだ。
そこから「機械的ストレスや工程妨害を狙った」と判断するのは妥当だが、特定の破壊モードを数値だけから断定しない方が正確である。
検証ポイント｜「1000台を一度に壊した」ではない
StuxnetとNatanzを扱う報道では、約1000台の遠心分離機が影響を受けたという数字が頻繁に登場する。
しかし設備側の故障・交換は時間をかけて発生し、IAEAの報告は施設全体の設置・稼働状態を示すもので、各故障の原因をStuxnetと一対一で認定する事故調査報告ではない。
したがって「Stuxnetがボタン一つで1000台を同時破壊した」という描写は避けるべきである。
より確実に言えるのは、StuxnetのPLCペイロードが遠心分離工程に適合する特殊なVFD条件を確認し、出力周波数を意図的に変化させる物理妨害ロジックを持っていたこと、そしてその標的構成がNatanzの公開情報と強く整合することである。
正確な損傷台数と遅延効果は、別のEvidence層として扱う必要がある。
設備設計としての教訓
Stuxnet型の攻撃を現在の産業設備へ置き換えると、重要な問いは「PLCを侵害されるか」だけではない。
PLCが侵害されたとき、どこまで物理出力を自由に変えられるか。
VFDの上限周波数は機械的限界に合わせて設定されているか。PLCから変更できないローカル保護はあるか。安全速度監視や独立保護はあるか。異常な加減速を検知できるか。設備が停止したとき、PLCプログラムだけでなくVFDパラメータの変更履歴も確認できるか。
こうした設計は、通常故障にも効く。
サイバーセキュリティのためだけに新しい保護を増やすのではなく、本来の設備安全・保全性の強化と重ねることが合理的である。
Stuxnetが示したのは、ソフトウェアの一行が物理出力へ届く制御系では、その一行も機械設計の一部だということだった。
まとめ
Stuxnetの物理攻撃は、Windowsから遠心分離機へ直接命令したわけではない。
Engineering Workstationを経由してPLCへ入り、PLCからPROFIBUS上の周波数変換器へ指令し、VFDがモーターの電気条件を変え、その結果として高速回転機械の運転状態を変えた。
攻撃は長い通常運転へ短い異常操作を挿入し、高速側と低速側の変化を組み合わせた。これにより、即時の全停止ではなく、設備へ断続的な物理ストレスを与えながら原因を見えにくくすることができた。
ここで重要なのは1410という数字そのものではない。
ソフトウェアの条件判定が、PLC出力、ドライブ指令、モーター、回転機械という物理チェーンへつながっていたことである。
次の記事では、この攻撃がなぜNatanz向けだと判断されたのかをさらに詰める。PLC型式、カスケード数、164台構成、IAEA資料――コード内のfingerprintと実在設備の一致を、推測と確認事実に分けて照合する。
FACT CHECK｜出典・参考資料
- [1] Symantec/Broadcom, Stuxnet: A Breakthrough
- [2] Nicolas Falliere, Liam O Murchu, Eric Chien, Symantec, W32.Stuxnet Dossier , Version 1.4, 2011
- [3] Symantec/Broadcom, Stuxnet 0.5: Disrupting Uranium Processing at Natanz
- [4] MITRE ATT&CK for ICS, Stuxnet, Software S0603
Stuxnet｜核施設を狙ったサイバー攻撃は何だったのか 第5回 全8回 全8回を見る
- 01 Stuxnetとは何だったのか――コンピューターから現実の設備へ
- 02 Stuxnet｜隔離された制御網へどう入ったのか――USBとゼロデイの侵入経路
- 03 Stuxnet｜なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別
- 04 Stuxnet｜PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装
- 05 Stuxnet｜遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作
- 06 Stuxnet｜なぜ標的はナタンズだと分かったのか――コードと設備構成の照合
- 07 Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」
- 08 Stuxnetが変えたもの――産業制御セキュリティに残った教訓