マルウェアの教訓に学ぶセキュアなPLCの開発

マルウェア名発見年主な標的攻撃の目的・影響技術的な特徴とPLC開発への示唆Stuxnet2010イランの核燃料施設（Siemens製PLC）物理的破壊。遠心分離機の回転数を不正に操作し、物理的に破壊。PLCルートキット。USBで侵入し、エンジニアリングPC上のDLLをハイジャックしてPLCの不正ロジックを隠蔽。
【教訓】 PLCに接続するPCのセキュリティが、PLC自身のセキュリティに直結することを示した最初の事例。Industroyer2016ウクライナの電力網大規模停電。電力システム用の標準プロトコルを悪用し、配電網の遮断器を遠隔操作。プロトコル話者。脆弱性ではなく、認証なきプロトコル（IEC-104等）の「仕様」を悪用。
【教訓】 プロトコルスタックの実装において、セキュアでない仕様の悪用リスクを考慮する必要性を提示。Triton / TRISIS2017サウジアラビアの石油化学プラント（Schneider Electric製SIS）安全システムの無効化。事故を防ぐ最後の砦である安全計装システム（SIS）を狙い、大災害を引き起こすことを意図。ファームウェアへのバックドア。独自プロトコルをリバースエンジニアリングし、コントローラのメモリに直接ペイロードを注入。
【教訓】 ファームウェアの完全性を保証するセキュアブートや署名検証の重要性を突きつけた。PIPEDREAM / INCONTROLLER2022(未展開で発見)多様な産業セクターのPLCを標的とした汎用的な攻撃ツールキット。モジュール型フレームワーク。CODESYSやOPC UAなど、複数ベンダーが利用する共通のランタイムやプロトコルを狙う。
【教訓】 サードパーティ製コンポーネントが深刻なサプライチェーンリスクとなり得ることを証明。IOCONTROL2024米国・イスラエルの水道施設、燃料管理システム等（Linuxベース機器）システムの機能停止、プロパガンダ表示、情報窃取。汎用Linuxバックドア。特定のPLCプロトコルではなく、広く普及した組み込みLinuxを標的とする。
【教訓】 PLCのOSが汎用化することで、ITの世界の脅威がそのままOTの世界に持ち込まれる現実を示した。

罪1: 無防備な通信チャネル

• 現象: StuxnetはエンジニアリングPC上のDLLをハイジャックし、PLCとの通信に割り込みました。PIPEDREAMは、CODESYSやOPC UAの正規の通信ポートを通じてPLCを完全に制御しました。
• 本質的な弱点: PLC側が、通信相手であるPCやソフトウェアを無条件に信頼している点です。通信経路の暗号化や、通信相手の認証が行われていないため、「正規のフリをした」攻撃に対して全くの無防備でした。

罪2: 認証なきプロトコル

• 現象: Industroyerは、IEC-104/61850といった電力システム用の標準プロトコルを悪用し、停電を引き起こしました。
• 本質的な弱点: これらのプロトコルは、性善説に基づいていた時代の設計であり、コマンドの送信元を認証する仕組みを持ちません。攻撃者は、単にプロトコル仕様に準拠したコマンドを生成・送信するだけで、PLCに致命的な操作を実行させることができました。

罪3: 改ざん可能なファームウェア

• 現象: Tritonの攻撃者は、Schneider Electric社のSISのファームウェアをリバースエンジニアリングし、メモリに直接バックドアを注入しました。
• 本質的な弱点: PLCの最も根幹であるファームウェア自体に、自己防衛機能が欠けていました。電源投入時にファームウェアの完全性を検証するセキュアブートや、実行中に不正な変更を検知するランタイム整合性監視が存在しなかったため、深層レベルでの改ざんを許してしまいました。

罪4: 脆弱な物理セキュリティへの過信

• 現象: Tritonの攻撃成功の要因の一つに、コントローラの物理キースイッチが「PROGRAM」モードのままだったことがあります。
• 本質的な弱点: 「キースイッチさえRUNモードにしておけば安全」という、物理的な保護への過信です。リモートからキースイッチの状態を監視・警告する仕組みや、たとえPROGRAMモードであっても、重要な操作には追加のデジタル認証を要求するような多層防御の思想が欠けていました。

罪5: 不透明なソフトウェア・サプライチェーン

• 現象: PIPEDREAMは、多くのベンダーが利用するサードパーティ製ランタイム「CODESYS」を標的としました。
• 本質的な弱点: 自社製品に組み込んでいるOS、ライブラリ、ミドルウェアといったサードパーティ製コンポーネントの脆弱性を、メーカー自身が完全に把握・管理できていないという問題です。ソフトウェア部品表（SBOM）の不在は、自社製品が抱えるリスクを不透明にしています。

罪6: 不十分な監査証跡（フォレンジックの困難さ）

• 現象: 多くのインシデントにおいて、攻撃後に「いつ、誰が、何をダウンロードし、何を変更したのか」を正確に追跡することは極めて困難でした。
• 本質的な弱点: PLCが、セキュリティイベントに関する詳細なログを、改ざん不可能な形で記録・保持する能力を持たない点です。これでは、インシデントの原因究明や、被害範囲の特定、再発防止策の策定が著しく妨げられます。

罪7: 汎用OSの脆弱性の継承

• 現象: IOCONTROLは、特定のOTプロトコルではなく、組み込みLinuxを搭載した多様なOT/IoTデバイスを標的としました。
• 本質的な弱点: リアルタイムOSからLinuxのような汎用OSへとPLCの基盤が移行する中で、ITの世界で知られている脆弱性や攻撃手法が、そのままOTの世界に持ち込まれている現実です。汎用OSの利便性と引き換えに、その広大な攻撃対象領域（Attack Surface）を管理する必要に迫られています。

• 第3部: 次世代セキュアPLCのための開発戦略
• グループA: 製品本体に組み込むセキュリティ (Product Security)
• グループB: セキュアな開発環境とプロセス (Secure Development Process)
• グループC: 人と組織の体制強化 (People & Organization)
• 結論: 今後のPLC