Stuxnetが変えたもの――産業制御セキュリティに残った教訓

STORY SO FAR

前回「Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」」で確認した論点を受け、この回ではStuxnetが変えたもの――産業制御セキュリティに残った教訓の後に何が変わり、何が残ったのか。を扱う。

Stuxnetの価値は、過去の秘密作戦を知ることだけにない。

現在の工場やインフラ設備を設計・保守する立場から見ると、Stuxnetは一つの設計レビュー教材になる。

USBメモリは管理されているか。Engineering Workstationは一般PCと同じ扱いになっていないか。PLCへ書き込める端末を誰が管理しているか。承認済みPLCプログラムの基準版はあるか。オンライン差分を確認できるか。HMIに表示される値を唯一の真実としていないか。安全保護が通常制御と同じCPU、同じネットワーク、同じEngineering Workstationへ依存していないか。

Stuxnetは、こうした問いを「理論上の脅威」ではなく、現実に物理設備へ到達した攻撃として突きつけた。

ICS-CERTは2010年度レビューでStuxnetを制御システム分野のwake-up callと位置づけ、「security through obscurity」はもはや選択肢ではないと述べた。現在のNIST SP 800-82 Rev.3も、OTを物理環境へ直接作用するシステムとして捉え、性能、信頼性、安全性を維持しながらセキュリティを設計する必要性を整理している。^[3]

本シリーズの最後に、Stuxnetの各段階を現在の防御へ変換する。

結論――Stuxnet後の本質は「境界防御」から「制御の完全性」へ広がった

Stuxnet以前から、産業制御システムのセキュリティ対策は存在した。

ネットワーク分離、ファイアウォール、アンチウイルス、アクセス制御などは重要だった。

Stuxnetが示したのは、それだけでは足りないということである。

攻撃者がEngineering Workstationへ入り、正規のSTEP 7通信を使い、PLCのコードと表示を同時に操作できるなら、防御側は「外から入れない」だけでなく、次を確認しなければならない。

• PLCへ誰が何を書き込んだか。
• 実行中ロジックが承認済み版と一致するか。
• ドライブやフィールド機器のパラメータが変わっていないか。
• HMI表示と物理プロセスが一致するか。
• 異常時に独立した保護が働くか。
• 復旧時に信頼できるgold copyへ戻せるか。

つまりセキュリティ対象が「ネットワーク」から「制御の完全性」へ広がった。

教訓1｜air gapは仕組みであって、宣言ではない

Stuxnetを語るとき、air gapは必ず登場する。

しかし「この設備はインターネットへつながっていない」という説明だけでは、防御状態を表せない。

実際のOTには、保守用ノートPC、USB、SDカード、バックアップ、ソフトウェア更新、ベンダー作業、設定ファイル、プリンタ、時刻同期、リモートメンテナンスなど、境界を横切る経路がある。

重要なのは、物理ケーブルの有無より、情報と変更がどこを通って制御系へ入るかを把握することだ。

実務では、データフロー図だけでなく「変更フロー図」を作るとよい。

PLCプログラムは誰が作るか。どのPCで編集するか。どう承認するか。どの媒体で現場へ持ち込むか。誰がダウンロードするか。古い版へ戻すときは何を使うか。

この流れの一つでも管理外なら、air gapの内側へ変更が入る経路になる。

教訓2｜Engineering Workstationは特権資産である

Engineering Workstationは一般のWindows PCに見える。

しかし権限は全く違う。

Office文書を編集する端末ではなく、PLCやDCSのプログラム、ハードウェア構成、通信設定、パラメータを書き換えられる。設備によっては、安全関連ロジックやドライブ設定へ到達することもある。

MITRE ATT&CK for ICSもEngineering Workstationを、制御システムの保守・設定・診断に使われ、PLCなどへ直接インターフェースする重要資産として整理している。

したがって、Engineering Workstationには少なくとも次の考え方が必要になる。

• 用途を限定する。
• 不要な一般Web閲覧やメールをさせない。
• 管理者権限を常用しない。
• アプリケーション実行を制限する。
• USB等の媒体を管理する。
• PLCへの書込み権限を必要な担当者だけに絞る。
• イメージバックアップと復旧手順を持つ。
• OSとエンジニアリングソフトの更新可否を設備影響と合わせて管理する。
• ログと変更履歴を残す。

「PLCは堅牢だから大丈夫」ではなく、PLCを書き換えられるPCを守る。

Stuxnetの入口から得られる最も直接的な教訓である。

教訓3｜PLCプログラムを資産として管理する

多くの設備では、PLCプログラムのバックアップは存在する。

しかし「最新だと思うフォルダ」があるだけでは、セキュリティ上のgold copyにはならない。

重要なのは、どの版が承認済みか、いつ誰が変更したか、実機と一致しているかを追跡できることだ。

理想的には、ソースファイルをバージョン管理し、リリース時にハッシュを記録し、変更理由と承認者を残す。ベンダー固有のバイナリ形式であっても、ファイル単位のSHA-256やリリース番号を管理できる。

さらに、定期保全や異常時にPLCからアップロードした実体と基準版を比較する。

StuxnetはEngineering Workstation側の読出しを隠すため、同じ侵害端末だけに依存した確認には限界がある。重大インシデント時は、独立した検証環境や別端末からの取得を検討する。

PLCプログラムは単なる「ソフトのバックアップ」ではない。

設備の動作仕様そのものである。

教訓4｜ドライブ・リモートI/O・機器パラメータまで基準化する

PLCプログラムだけが制御状態ではない。

VFD、サーボ、ロボット、安全機器、計装機器にもパラメータがある。PLCが正常でも、ドライブ上限周波数や加減速時間が変更されれば物理挙動は変わる。

Stuxnetの物理攻撃が周波数変換器へ到達したことを考えると、重要パラメータのbaseline管理は合理的である。

設備引渡し時に、PLC、HMI、VFD、サーボ、ネットワーク機器、Safety PLCなどの設定を一式で保存し、リビジョンを揃える。

復旧時に「PLCだけ戻したが、VFDは現場で変更されたまま」という状態を避ける。

サイバーインシデントがなくても、保守性を大きく上げる対策である。

教訓5｜ネットワーク分離は必要。ただし変更経路と組み合わせる

Stuxnet後、「air gapは無意味」という極端な言説も出た。

それは正しくない。

NIST SP 800-82 Rev.3やCISAのICS Recommended Practicesでも、セグメンテーションやdefense-in-depthは依然として基本である。^[3]

企業IT、DMZ、OT上位、セル/エリア、コントローラ層を分け、通信を必要最小限にすることで、攻撃者が横移動できる範囲は狭くなる。

ただし分離だけに依存しない。

USBからEngineering Workstationへ入る経路が残るなら、ネットワーク境界を迂回できる。逆にUSBを禁止しても、常時接続のリモート保守VPNが無制限なら別の入口になる。

したがって、ネットワーク経路、物理媒体、保守経路を一つのattack surfaceとして管理する必要がある。

教訓6｜「正規通信だから安全」を捨てる

Stuxnetは、STEP 7とPLCの正規通信へ介入した。

これはOT監視に重要な示唆を持つ。

不審なIPアドレスや未知ポートだけを検知しても、侵害済みEngineering Workstationから正規プロトコルで行われる変更は見逃す可能性がある。

必要なのは、通信の意味を見ることだ。

PLCへのプログラムダウンロードが通常時間帯に行われたか。誰の作業だったか。設定変更が予定作業と一致するか。普段は読出しだけの端末が書込みを始めていないか。

OTでは、正常通信の中に危険操作が含まれる。

そのため資産情報と変更管理をネットワーク監視へ結びつける価値がある。

教訓7｜HMIやPLCの値を唯一の真実にしない

Stuxnet 0.5のreplay機能と、MITRE ATT&CK for ICSが整理するManipulation of Viewは、監視値そのものが攻撃対象になることを示す。

重要プロセスでは、PLC/HMIとは独立した物理監視が意味を持つ。

回転設備なら振動監視、機械保護、独立速度検出。プロセス設備なら独立圧力計、流量計、安全計装などである。

もちろん、すべてを二重化すればよいわけではない。

重要なのはcommon causeを減らすことだ。

二つのセンサーが同じPLCへ入り、同じプログラムで処理され、同じHMIへ表示されるなら、PLC侵害時には同じ影響を受ける。

安全性が重要な機能では、センサー、ロジックソルバ、出力、電源、ネットワーク、Engineering Workstationまで、どこに共通依存があるかを確認する。

これはIEC 61511/61508などの機能安全で考える独立性とも接点がある。^[1]

教訓8｜フェイルセーフへ「悪意ある故障」を加える

従来の異常系設計は、断線、停電、CPU停止、通信異常、センサー故障などを想定する。

Stuxnet型攻撃では、CPUはRUN、通信も正常、センサー値ももっともらしいまま、制御だけが意図的に変えられる。

つまりfail-safe設計へ、新しい故障モードを追加する必要がある。

• 不正な設定値
• 正常範囲に見える悪性シーケンス
• アラーム抑制
• I/O image操作
• HMIへのreplay
• 正規Engineering Workstationからの不正ダウンロード

これらをFMEAやHAZOPのような異常分析へ組み込めば、セキュリティと安全を別々の表で管理するより実態に近づく。

教訓9｜バックアップは「ある」だけでなく、復旧可能でなければならない

Stuxnet型インシデントでEngineering WorkstationやPLCが侵害された場合、最終的には信頼できる状態へ戻す必要がある。

そのためには、gold copyだけでなく復旧手順が必要になる。

どの順番でPCを再構築し、エンジニアリングソフトを入れ、PLCプログラムを戻し、ドライブパラメータを復元し、通信設定を確認し、試運転するか。

バックアップが古い。ライセンスがない。インストーラが見つからない。古いWindowsでしか動かない。ドライブ設定ファイルの版が違う。

OTでは、この種の復旧障害が現実的に起こる。

NIST SP 800-82が可用性・安全性・信頼性を重視するのは、ITと違って「止めて再インストール」で済まないからである。

復旧訓練まで含めて初めてバックアップは対策になる。

教訓10｜パッチ適用だけではOT防御にならない

StuxnetではWindowsゼロデイが大きな役割を持ったため、OSパッチは当然重要である。

しかしOTでは、24時間稼働、ベンダー認証、古いOS、長い設備寿命などの理由で、ITと同じ速度で更新できない場合がある。

そのとき必要なのが補完統制である。

ネットワーク分離、アプリケーション許可、USB制御、不要サービス停止、通信監視、Engineering Workstation限定、ジャンプホスト、変更承認などを組み合わせる。

CISAがdefense-in-depthを推奨する理由はここにある。

一つの防御が破られても、次の層で止める。

Stuxnetは複数の防御を順番に越えたからこそ成功した。防御側も単一の対策へ依存しない方がよい。

教訓11｜資産台帳はセキュリティの基礎データになる

StuxnetはCPU型式、通信モジュール、VFDなどの構成情報を使って標的を選んだ。

防御側も、同じレベルで自分の設備を把握する必要がある。

どのPLCがどのCPUか。ファームウェアは何か。どのEngineering Workstationが管理するか。どのネットワークへ接続するか。どのVFDやSafety PLCがあるか。サポート終了日はいつか。

資産台帳がなければ、新しい脆弱性が出ても対象設備を検索できない。

逆に台帳があれば、「この脆弱性はS7-300だけ」「このWindows版だけ」「この通信モジュールだけ」といった影響範囲を早く絞れる。

資産管理は地味だが、Stuxnet型攻撃への対応速度を決める。

教訓12｜ITと制御・保全の連携が必要になる

Stuxnetは、IT部門だけでも制御部門だけでも完結しない。

Windows脆弱性や証明書、マルウェア解析はITセキュリティの領域である。STEP 7、PLC、PROFIBUS、VFD、インターロック、機械保護はOT・制御の領域である。

インシデント時には両方が必要になる。

IT側が「感染PCを初期化」すると、PLC変更履歴やフォレンジック証拠を失う可能性がある。制御側が「とりあえずバックアップを書き戻す」と、感染したEngineering Workstationから再び悪性変更を入れる可能性がある。

平常時から、誰が判断し、何を保存し、どこで設備を止めるかを決めておく必要がある。

MITRE ATT&CK for ICSでStuxnetが残した位置

現在のMITRE ATT&CK for ICSでは、Stuxnetは一つのTechniqueではなく、複数の技法の具体例になっている。

Manipulation of Control、Manipulation of View、Modify Controller Tasking、Masqueradingなどである。

これはStuxnetの歴史的意味をよく表している。

事件は一つだが、攻撃構造は再利用可能なパターンへ分解された。

防御側は「Stuxnetのファイル名を検知する」のではなく、

• PLCロジックの不正変更
• 正規Engineering Workstationからの異常操作
• プロセス値の偽装
• 制御出力の不整合

といったTechniqueを監視する必要がある。

マルウェア名は変わっても、制御システムを攻撃する方法の一部は残るからである。

現在の工場で優先順位をつけるなら

すべての対策を一度に導入するのは現実的ではない。

そこでStuxnetの攻撃チェーンを逆向きに使い、優先順位をつけられる。

第一優先は、PLCを書き換えられるEngineering Workstationと保守経路の把握である。

第二に、PLC/HMI/VFDなど重要設定のgold copyと変更管理を整える。

第三に、IT-OT境界とセル間のネットワーク分離、不要通信の削減を行う。

第四に、USBやベンダーPCなどオフライン経路を管理する。

第五に、重要設備では独立保護・独立監視を確認する。

第六に、ログ・時刻同期・インシデント対応手順を整え、異常時に証拠を残せるようにする。

この順序なら、アンチウイルス製品の追加だけで終わらず、設備の変更権限と復旧能力を先に固められる。

段階的に改善するなら、最初は「見える化」から始める

既設設備に理想的なOTセキュリティを一度で入れるのは難しい。10年、20年使う設備では、PLCやHMIを簡単に更新できず、停止時間も限られる。そこで改修を段階化する方が実運用に合う。

第1段階では、資産と変更経路を見える化する。PLC、HMI、Engineering Workstation、ネットワーク機器、VFD、安全機器の一覧を作り、誰がどこから変更できるかを整理する。ここは設備停止なしでも進めやすい。

第2段階では、バックアップと基準版を整える。プログラム、設定、ライセンス、インストーラ、復旧手順をセットで保管し、実機との差分を確認する。

第3段階では、ネットワークとアカウントを絞る。不要通信を閉じ、Engineering Workstationの用途を限定し、リモート保守やUSBの例外運用を明文化する。

第4段階で、重要設備の独立監視、変更検知、OT向け監視センサーなどを追加する。

第5段階では、設備更新のタイミングでsecure-by-designへ移行する。旧機種では実装困難だった署名付きロジック、より強い認証、セキュアブート、暗号化通信などを、新規設備仕様へ入れる。

この順序なら、最初から大規模なセキュリティ製品導入へ走らず、現在の制御設計と保守運用を把握したうえで投資できる。Stuxnetの教訓を実装するうえで最も重要なのは、新しい装置を買うことより、何を信頼して設備を変更しているかを把握することである。

検証ポイント｜「Stuxnet対策製品」を入れれば終わりではない

Stuxnetの検体そのものは古い。

現在のOSやセキュリティ製品なら、2010年当時の脆弱性や既知シグネチャに対処できる。

しかしStuxnetの教訓は、同じファイルを防ぐことではない。

別のゼロデイ、別のEngineering Software、別のPLC、別のプロトコルでも、同じ攻撃構造は再現できる。

したがって対策は、特定マルウェアのシグネチャから、変更管理・資産管理・多層防御・独立監視へ移す必要がある。

検証ポイント｜セキュリティ強化で安全性を落としてはいけない

OTでは、セキュリティ対策そのものが設備可用性や安全へ影響する。

無計画なパッチでEngineering Softwareが動かなくなる。EDRの負荷で古いHMIが不安定になる。ファイアウォール設定変更で安全通信が止まる。USB全面禁止で緊急復旧用バックアップを使えなくなる。

NIST SP 800-82 Rev.3がOT固有の性能・信頼性・安全性を前提にしているのはこのためである。

良いOTセキュリティは「厳しく制限すること」ではない。

必要な制御・保守機能を維持しながら、信頼できる変更経路へ限定することである。

まとめ――Stuxnetが残した本当の変化

Stuxnetは、サイバー攻撃で物理設備を壊せることを初めて思いつかせた事件ではない。

しかし、Windowsの侵入、Engineering Workstation、PLCの標的識別、制御ロジック改変、Manipulation of View、物理設備への指令という一連の攻撃を、現実のマルウェアとして世界へ見せた。

その結果、OTセキュリティの中心課題は「工場ネットワークを外部から隠す」だけでは済まなくなった。

守るべきものは、PLCを書き換える権限、実行中ロジックの完全性、ドライブや機器パラメータ、監視値の信頼性、独立保護、そして信頼できる復旧状態である。

Stuxnetから十年以上が経っても、この構造は古くなっていない。

NIST、CISA、MITREが現在のOTセキュリティでdefense-in-depth、資産管理、変更管理、バックアップ、ネットワーク分離、制御・表示の完全性を重視する理由は、Stuxnetのような攻撃が「理論上できる」ではなく「実際にできた」からである。

CASE061を通して見えてくるのは、コードそのものより、制御システムが持つ信頼の連鎖である。

USBを信頼する。Engineering Workstationを信頼する。Engineering Softwareを信頼する。PLCから返る値を信頼する。HMI表示を信頼する。上位指令をVFDが信頼する。

Stuxnetは、その信頼を一段ずつ利用した。

だから現在の最適な防御は、一つの強い壁を作ることではない。

一つの信頼点が破られても、次の層で検出し、危険側へ進ませず、信頼できる状態へ戻せる設備にすること。

それがStuxnetの後に残った、産業制御セキュリティの最も実務的な教訓である。

RELATED FILES

• Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」

FACT CHECK｜出典・参考資料

1. [1] U.S. Department of Homeland Security / ICS-CERT, ICS-CERT – 2010 Year in Review
2. [2] CISA, ICS Recommended Practices
3. [3] NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
4. [4] MITRE ATT&CK for ICS, Stuxnet, Software S0603
5. [5] MITRE ATT&CK for ICS, Manipulation of View, T0832
6. [6] MITRE ATT&CK for ICS, Manipulation of Control, T0831
7. [7] MITRE ATT&CK for ICS, Modify Program, T0889
8. [8] MITRE ATT&CK for ICS, Workstation, Asset A0001

Stuxnet｜核施設を狙ったサイバー攻撃は何だったのか 第8回 / 全8回 全8回を見る

1. 01 Stuxnetとは何だったのか――コンピューターから現実の設備へ
2. 02 Stuxnet｜隔離された制御網へどう入ったのか――USBとゼロデイの侵入経路
3. 03 Stuxnet｜なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別
4. 04 Stuxnet｜PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装
5. 05 Stuxnet｜遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作
6. 06 Stuxnet｜なぜ標的はナタンズだと分かったのか――コードと設備構成の照合
7. 07 Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」
8. 08 Stuxnetが変えたもの――産業制御セキュリティに残った教訓

タグ

air gap defense-in-depth Engineering Workstation ICS OTセキュリティ