CPS(IoT/OT)セキュリティ 2026.01.09

OT/ICSとITシステムのインシデントレスポンス

はじめに

本記事では、OT/ICSとITシステムのインシデントレスポンスの違いについて、ランサムウェアのケースを題材とし、マクニカセキュリティ研究センターの柳下が考察します。

1.OT/ICSシステムのインシデントレスポンスについて

OT/ICSのシステムでは、WindowsやLinuxベースのマシンを使っている場合でも、ベンダーの動作保証範囲では、セキュリティ製品も含めてソフトウェアを自由にインストールすることができません。そのため、OT/ICSの基本的なログとして、次のようなヒストリアンのデータを調査して、いつからどのシステムがどのような手法で侵害されたのかを調査し始めます。

ヒストリアンのデータ例

データログ
Timestamp　　　　　　　　　TagName　　　　　　　Value Quality
2026-01-05 08:00:00.000 PLC1.Pump01.Speed_RPM   1480 Good
2026-01-05 08:00:01.000 PLC1.Pump01.Speed_RPM   1482 Good
2026-01-05 08:00:02.000 PLC1.Pump01.Speed_RPM   1479 Good
2026-01-05 08:00:03.000 PLC1.Pump01.Speed_RPM 　　0 　Bad (Comm Loss)
2026-01-05 08:00:04.000 PLC1.Pump01.Speed_RPM   1481 Good

システムログ
[2026-01-05 07:59:58] INFO HistorianService: Data collection started
[2026-01-05 08:00:03] WARN DataCollector: Lost connection to PLC1
[2026-01-05 08:00:04] INFO DataCollector: Connection to PLC1 restored
[2026-01-05 08:05:12] INFO ArchiveManager: New archive file created

アラームとイベントログ
Timestamp　　　　　　　　　Alarm Name 　 State 　 Severity　Source
2026-01-05 08:10:15.221 Pump01_HighPressure　ACTIVE 　High　　PLC1
2026-01-05 08:10:45.876 Pump01_HighPressure　CLEARED　High　　PLC1
2026-01-05 08:12:02.114 Tank02_LowLevel 　　　ACTIVE　　Medium PLC2

ヒストリアンからは、いつ頃からシステムが正常稼働していないのか、どのシステムが最初に停止したのかといった調査を行います。その他に、目視でコントローラや各ホストの画面を見て、ランサムノートから攻撃者を把握します。

昨今のケースでは、ランサムウェアによってログやバックアップデータまで暗号化や消去されるケースが多く、目視できる表示画面の他に開けるヒストリアンがなく、初期調査すら難しいケースも想定されます。また、ヒストリアンがある場合でも、システムの稼働関連のログが中心となるため、どのように侵入してきたのか、暗号化されたファイルを自力で復旧できる可能性があるかといった調査を行う事ができません。そのため、侵害されたホストからディスクやメモリイメージを収集してフォレンジック調査を行い、イベントログのリモートログオンの履歴、ファイルの書き込まれたタイムライン、ランサムウェアの回収と解析などの調査を行って、侵入経路や自力でのファイル復号の可否などを明らかにしていきます。

組織がランサムウェアに侵害されるケースでは、1台のホストのファイルが暗号化されるだけで済むケースはなく、つながったネットワークにあるすべてのホストのファイルが暗号化される傾向にあります。フォレンジック調査の対象とする台数も悩ましいところです。また、昨今ではDX構想のもと、OT/ICSも企業のIT側のネットワークと接続される傾向にあり、攻撃者がIT側のネットワークから侵入した後、OT/ICS側のネットワークにリモートログオンして侵害するケースがあり、次のようなIT側のインシデントレスポンスも必要になる場合が想定されます。

2.ITシステムのインシデントレスポンスについて

Windows/Linux/Macといった一般的な端末について、最近では各ホストにEDRの導入が進んでおり、ネットワークにもトラフィックを監視するNDRが導入されているケースもあり、それらがクラウドにアップロードしたログを調査します。特に、EDRのログからは、どのIPアドレスから、どのユーザアカウントを使って、いつから侵入があり、どうやってランサムウェアが実行されたかといった知見が得られます。

ただし、攻撃も高度化しており、EDRの入っていないホストを狙ってランサムウェアを実行する、EDRでも検出の難しいLOTLで組織内を移動して最後にランサムウェアを実行する、EDR自体を無効にしてEDRログをクラウドにアップロードさせないといった手法で、検出回避や解析妨害をしてくるケースが増えています。また、クラウドにアップロードされたEDRログの保存期間が短く、侵入からランサムウェア実行までの全体像までは調査できないというケースもあります。

NDRが導入されている場合は、EDRのそれら弱点をカバーしてネットワークの視点から侵入経路を調査しますが、それでも調査が難しい場合は、インシデントレスポンスを行っているセキュリティベンダーに調査を依頼します。ベンダーは各ホストで実行できるインシデントレスポンスツールを持っており、組織の端末に対してツールを実行してイベントログやファイル書き込みのタイムライン、ランサムウェアのファイルなどを収集して侵入経路などの調査を行うことができます。各ホストからディスクやメモリイメージを収集するフォレンジックまで至らず、ツールによる情報収集で最終調査まで完了することも多々あります。

3.さいごに

OT/ICS側でのインシデントレスポンスは、ITのインシデントレスポンスと比較して、次のような難しさがあります。

OT/ICSのホスト端末にセキュリティ製品の導入が難しい
ITで使うインシデントレスポンスツールが使えない可能性がある
ヒストリアンは稼働関連のログが中心となるため、侵入経路などの調査には不十分
ヒストリアンも暗号化される可能性がある

このような難しさに対して、OT/ICSネットワークにIDSなどのネットワークセンサーを設置することで、日常的な攻撃検出に活用するだけでなく、事後に侵入経路の分析といった調査にも活用でき、OT/ICSのインシデントレスポンスの難しさを緩和するソリューションとなっています。