OTインシデント4種 ― どれに先に動くべきかの読み方

OTの現場で起きるインシデントの多くは、Stuxnetのような派手なものではありません。OTインシデント4種類をもとに、先に動くべき対象の見極め方を紹介します。

OTシステムへの攻撃と聞くと、Stuxnetや発電所を停止させるマルウェアを思い浮かべる人が多いでしょう。しかしOTチームが日常的に対応しているものは、まったくそんな姿をしていません。そもそも攻撃ですらないことも少なくありません。

この記事では、OTで起こりうる4種類のインシデントを取り上げ、それぞれが何を示しているのか、そしてなぜ一番軽く見えるものが先に動くべき対象になりうるのかを見ていきます。

OTインシデント4種

多くのチームがこれを緊急度の高いものとして扱うのは、承認された時間枠の外で行われた保守アクセスだからです。これは2つのどちらかに帰結します ― 正規の業者が連絡なしに時間外に接続したか、あるいは別の誰かがその業者のリモートアクセス経路を使ったか。

危険なのは、リモート保守の経路が「正規の入口で、権限が大きく、他の入口ほど厳しく見られていない」傾向にあることです。攻撃者が侵入経路を選べるなら、まず狙いたいのはここでしょう。

Allow Listにないクライアントが、ゲートウェイへの接続を試みるケースです。実務上、最も多い原因は攻撃者ではありません ― 技術部門がITに知らせずに接続した新しい機器や、技術者のノートPCをOTネットワークに直接つないだ、といったものです。

それでも、多くのチームは緊急度の高いものとして扱います。システムから見れば、人が確認するまでその技術者と他の誰かを区別する手段がないからです。

ポーリング間隔が通常のベースラインから逸脱しているケースです。これは多くの場合、セキュリティ問題というより技術的な問題です ― 機器の劣化、ケーブルの不良、異常なネットワーク輻輳など。

そのため多くのチームは緊急度を低めに見ますが、それでも確認する価値はあります。ポーリングのリズムの乱れは、経路上に何かが割り込んだ最初の兆候であることがあり、別のケースでは機器の故障が近いという早期警告にもなります。それ自体に価値があります。

送信量が確立されたパターンから乖離しているケースです。テレメトリを日常的にクラウドへ送っている工場では、送信量の変化はソフトウェア更新やセンサー追加が原因のこともあれば、より悪いケースとして、送るべきでない場所にデータが向かっていることもあります。

こちらも、多くのチームは緊急度を低めに見ます。

インシデントの一覧には、たいていリスクスコアが付いていて、つい上から順に片づけたくなります。ここで、最もスコアの高い案件がすでにACK（対応者がついている状態）になっていて、それより低いスコアの案件がまだOpenのままになっている一覧を想像してみてください。

そうした状況は誤りではありません。実際のトリアージが数値だけでなく複数の要因で行われていることの反映です ― ACK済みの案件は外部の業者からの情報待ちかもしれませんし、Openの案件は今しがた入ってきたばかりかもしれません。

重要なのは、リスクスコアは並べ替えを助けるものであって、判断を代行するものではないということです。数値だけを追うチームは、スコアが低くても本当に重要なものを見落とします ― たとえば、わずかではあるものの1週間毎晩繰り返されているcloud egressの逸脱のような。

見比べると、セキュリティ製品の宣伝が真っ先に掲げる「マルウェアを検知」が1つもないことに気づきます。どれもそれまでの正常からの逸脱です。

これがOTセキュリティの核心です。ユーザーの振る舞いが絶えず変わるITネットワークと違い、OTシステムは毎日同じことを同じように行います。この一貫性が強みになります ― パターンから外れたものが、はるかにはっきりと浮かび上がるからです。

こうしたインシデントまで絞り込むフィルタリングの流れはOTにおける決定論的検知ルールの仕組みを、OTに独自のアプローチが必要な理由の全体像は製造業向けOTセキュリティをご覧ください。

zcrOTのIncidentsビューは、関連するマッチを1つのケースにまとめ、リスクスコア、severity、ステータス（たとえばOpen、ACK、Closed）、そしてイベントレベルの証拠まで遡れる参照コードを提供します。

Incidentsビューの仕組みを見るには、zcrOTデモをお試しください。ご自身のOTネットワークで何が上がってくるかを知りたい場合は、下記からお問い合わせいただくか、zcrOTのプランをご覧ください。

どの種類のイベントを自社でCriticalとすべきか、ご相談ください。無料でご相談いただけます。