スウェーデン王立工科大学(KTH)の研究者たちは、セグメント化された産業ネットワークを模したコンテナ環境を構築し、14日間の稼働期間中に繰り返し攻撃を仕掛けました。そこで取得した通信トラフィックを使って、いつ介入すべきかを自律的に判断する防御エージェントを訓練しました。
このエージェントは、各区間ごとに6つの数値を観測します。ネットワークのセグメントをまたぐパケット数と、個々のマシンへの/からのパケット数です。これらの数値から、侵入者がどこまで侵入を進めているかを推定し、行動を起こします。
エージェントが取れる行動は、「何もしない」「3台ある監視ホストのうち1台をリセットする」「2つある水槽プロセスのうち1つをリセットする」「監視サブネットと制御サブネットの全ホストを一斉にリセットする」の4種類です。リセットを行うと、対象機器は再起動し、認証情報が更新され、IPアドレスが変更されます。リセットによって産業プロセスが一時的に中断することもあります。パケット数を読み取ったエージェントが稼働中のプロセスを強制的に再起動させると決めれば、プラントはその停止を受け入れることになります。
侵入対応のユースケースにおけるOTインフラ構成(出典:研究論文)
この分野の従来研究の多くは、攻撃者が「見える」ことを前提にしている
産業システムにおける侵入対応の強化学習に関するこれまでの研究は、エージェントがシステムの状態や攻撃者の行動を直接観測できることを前提にしているものがほとんどでした。研究者らはこの前提を「非現実的」と指摘し、部分観測性をモデル化している研究であっても、その観測モデルがどのように導き出されたのかを説明していないケースが多いと述べています。そこで研究チームは、模擬ネットワークを30秒間隔で稼働させ、4万件のデータを収集することで、実際に観測モデルを測定しました。それでもデータ量としては十分とは言えませんでした。システム全体の状態とトラフィックの変動の関係をモデル化するには、およそ1億件の測定データが必要になるためです。そこで研究チームは、より単純な指標、すなわち攻撃者の行動単独とトラフィックの変動との関係を推定することにしました。パケット数自体は実測値ですが、そのデータからモデルが導き出せることは、本来数学的に求められる水準には及びません。
得られた結果と、その根底にある前提
研究者らが訓練した3種類のエージェントのうち、最も性能が高かったものは、ネットワークの状態に関する500通りの推定値を常時保持し、区間ごとに更新した上で、その圧縮版を方策(ポリシー)に入力する仕組みを採用していました。このエージェントは、観測履歴の生データをそのまま方策に入力する他の2つのエージェントを上回る成績を収め、システム状態を完全に把握できるベースラインエージェントの性能に肉薄しました。なお、方策に入力する履歴を1区間分から4区間分に増やすと、かえって性能は悪化しました。
ただし、この推定の仕組みには一つ落とし穴があります。エージェントは推定値を更新する際に、システムがどう推移するかをモデル化した上で計算を行いますが、そのモデルには攻撃者の行動パターンも組み込まれているのです。つまり、完全可視性を持つベースラインに最も近い性能を発揮したエージェントは、自らが防御しようとしている敵の行動記述をもとに動いていることになります。
実環境への応用可能性
テスト用ネットワークは、監視ホスト3台、PLC2台、水槽2基という構成でした。2台のHMIはいずれも脆弱な認証情報のままHTTPで稼働しており、エンジニアリングワークステーションはSSH・Telnet・SMBを稼働させ、脆弱な認証情報に加えてCVE-2017-7494の影響も受ける状態でした。研究者らは、このモデルが他の構成や別の攻撃手法にも一般化できるかどうかについては検証していません。
こうした仕組み一式を抜きにしても応用可能な考え方が、「ビリーフ・トラッキング(信念追跡)」です。学習型エージェントと、論文で示されたより単純な閾値ベースラインは、いずれも各資産について侵入がどこまで進行しているか(未発見・スキャン済み・悪用済み・調査済みという段階)を確率分布として保持し、各段階にコストに応じた重み付けを行っています。あるホストが悪用された確率を表示するコンソールであれば、強化学習を使わずとも構築可能です。
研究者らは実装を公開しており、パートナー企業と共同で産業用テストベッドにこの手法を適用する検証を計画しています。今後の課題として運用上の安全性を挙げており、これが防御側の戦略として許容される行動範囲を制約する要因になると指摘しています。
翻訳元: https://www.helpnetsecurity.com/2026/09/14/ot-intrusion-response-agent/
