6月9日に開催されたWebセミナー「TECH+フォーラム IT×OTセキュリティDays 2026 Jun. 事業を止めないセキュリティ OTセキュリティDay - 「なぜ」から考える脅威対策 -」の基調講演に、サイバーセキュリティアドバイザーの名和利男氏が登壇。数々のインシデント対応の最前線で得た知見をもとに、有事においてなぜ被害が拡大するのか、そしてOTを守るために見直すべき「前提」について語った。
なぜ被害は拡大するのか? 現場で露呈する「前提の破綻」
名和氏は冒頭、本講演の目的について「最新の攻撃手法や制御システムの脆弱性を解説するものではない」と説明した。実際のインシデント対応の現場において、攻撃者の手口以上に痛感するのは「自社が何を分かっているつもりでいたのか」「誰が何を決めることになっていたのか」「なぜ戻せるはずのものが戻らなかったのか」という事実だという。
「OTの脆弱性は、古い機器やパッチの未適用だけで説明できるものではない。平時においてあまり疑われなかった『おかしな前提』が、有事に1つずつ崩れていく。そこに被害が拡大する構造がある」と同氏は指摘する。ここで言う「おかしな前提」とは誰かを批判する言葉ではなく、平時には合理的だった想定が、有事のインシデント現場では通用しなくなることを意味する。同氏は、自社の対応を点検するための材料として、この「前提」を1つずつ見直していくことの重要性を説いた。
-
OT脆弱性に関する中核メッセージ
IT起点の侵害が「現場の操業判断」を止める
インシデント対応の現場で見えてくるのは、攻撃者の行動だけでなく、自社の想定や運用の癖である。昨今、DXの推進や遠隔保守、クラウド連携などにより、ITとOTの接点は増加している。これらは事業上不可欠な取り組みだが、被害の大きさは侵入経路そのものだけでなく、その後の切り離しや判断・復旧の設計に大きく左右される。
名和氏は、「IT起点の侵害は、現場の操業判断に変換される」と警鐘を鳴らす。制御システムが直接暗号化されるなどの被害に遭わなくても、周辺システムのエラーや事業機能の停止によって操業は止まり得るからだ。
例えば、認証基盤、業務システム、品質記録、出荷判定、保全業務など、事業継続に直結する要素がIT側で侵害されれば、設備自体は動いていても、「品質データが確認できない」「出荷判定ができない」といった理由で、事業としては停止と同じ状態に陥ってしまう。つまり、守るべき対象を「設備」から「事業機能」へと広げる発想の転換が強く求められているのである。
「接続」と「責任」の非対称性が生む“別々の地図”
なぜOT環境においてこうした問題が起きやすいのか。名和氏はその構造的な原因として、「接続が増えたが、責任設計が追いついていない」ことを挙げる。
データの連携や遠隔保守などシステム的な接続は進化しているにもかかわらず、インシデント時に「誰が止める権限を持つのか」「誰が復旧を承認するのか」といった責任設計はレガシーのまま残っていることが多い。システムはつながっているのに責任はつながっていないという非対称性が、有事における判断の遅れを招くのだ。
この結果として生じるのが、「経営・IT・現場・委託先が、それぞれ“別々の地図”を見ている」という状況だ。同じインシデントに直面しても、IT部門は「侵害範囲と証拠保全」を、現場は「操業・安全・品質」を、経営層は「供給責任と外部説明」を、委託先は「契約範囲と権限」を見ている。それぞれの視点はどれも正しいが、“1枚の地図”として統合されていないため、全体としての判断が止まってしまう。攻撃者は組織が描いた境界線ではなく、こうした運用上の抜け道を突いてくるのである。
有事に被害拡大を許す「5つのおかしな前提」
名和氏は、平時には通用していたが有事に崩れ去る「5つのおかしな前提」を提示し、これらが初動での確認作業や、封じ込めでの判断遅延、復旧の不確実性に変わってしまうと指摘した。
-
5つの“おかしな前提”
1. ネットワークは分離されている「はず」/ 2. 資産と接続は把握できている「はず」
構成図や資産台帳の存在は重要だが、それが有事に隔離や影響判断、復旧順序に使える粒度の情報でなければ有用ではない。「分離されていますか?」と問うだけでなく、「どこで誰が何のためにつないでいるのか」「有事に誰が止められるのか」まで検証する必要がある。監査目的でつくられた台帳ではなく、インシデント対応に使える情報へ変えることが不可欠だ。
3. 委託先が対応してくれる「はず」
作業は外部に委託できても、最終的な判断責任は自社に残る。平時の保守契約と有事のインシデント対応を混同してはならない。有事にはログ提供や緊急遮断、現地での復旧支援が必要になるが、システムの停止判断や再開判断、顧客・取引先への説明責任まで委託できるわけではない。委託先と「有事に一緒に動けるか」という協働の視点で、平時のうちに契約上の隙間を埋めておく必要がある。
4. 止めずに復旧できる「はず」
事業を止めたくないのは当然だが、有事になってから「止めるか・止めないか」を議論していては被害も広がり、判断の遅れも大きくなってしまう。全体停止を避けるためには、あらかじめ「どこまでなら止めるのか（縮退条件）」「誰が停止権限を持つのか」といった限定停止の範囲を決めておく「ダメージコントロール」の考え方が重要となる。止める判断を先に決めることが、結果として「止めない設計」になるのだ。
5. バックアップがあるから戻せる「はず」
バックアップは復旧のための材料であって、復旧計画そのものではない。OT環境においては、システムが起動することと、操業を再開してよいことはまったくの別物である。システムの復元後には、クリーンな状態の確認、品質データの整合性確認、設備の安全確認が必須であり、「誰が再稼働を承認するのか」までを含めた復旧設計が求められる。技術復旧と事業復旧を混同してはならない。
重要資産の一覧ではなく「事業停止点」から逆算する
これらの前提を踏まえ、名和氏は「事故前提」での設計の重要性を強調した。ここで言う事故前提とは、安全事故を容認することではなく、「サイバー侵害や障害が起きることを前提に、被害を限定化するための実務設計」のことだ。有事に組織が動くためには、「止める条件」「切り離す範囲」「戻す順序」の3つの動作が必要となる。検知や監視、バックアップは重要だが、それらを事業判断につなぐ“立て付け”がなければ対応は途中で止まってしまう。
-
有事に組織が動くための3つの動作
対策の出発点として、重要資産の一覧化も必要だが、それ以上に「事業停止点」を見ることが不可欠だ。「どの工程が止まるとどの製品に影響するのか」「どのシステムが止まると出荷判定が止まるのか」など、事業影響から逆算して優先順位を決めるべきだと同氏は説く。最も見たくない「停止ポイント」を、勇気を持って直視し、経営・IT・現場が同じ地図を見ながら対話することが求められる。平時から判断条件と権限を明確にしておかなければ、技術チームの努力が事業判断へと結び付かないのである。
自社が「分かっているつもり」になっているものは何か
最後に名和氏は、これからセキュリティ製品の導入や運用を進める前に、まずは自社の状況を見つめ直すための「迷ったときの5つの問い」を提示した。
1. 本当に分離されているか
2. 誰が接続を許可し、誰が止めるのか
3. 委託先は有事に何をしてくれるのか
4. どこを止めると、事業が止まるのか
5. 復旧は、誰が、どの順序で、何を根拠に承認するのか
「OTを守るとは、被害を事業停止に変えない構造をつくることだ」と同氏は語る。有事に止められる接続はどこか、委託先と同じ地図を見ているか、復旧承認を誰が担うのか。自社の現場、情報システム部門、経営層、そして委託先が同じ答えを出せるかを確認し、答えが揃わない部分を見直すことこそが、真のOTセキュリティ対策への第一歩となるだろう。
ライフネット生命が全部門参加型CSIRTで進める「全員主役」のセキュリティとは
