セキュリティ監視に関心がある方向けに、OT IDSとして無償・有償ツールの比較検証を行った結果を2回に渡り紹介します。2回目の今回は、有償の通信監視・分析ツールであるNOZOMI Networks Guardianを紹介します。

対象読者

パケットキャプチャを利用した通信監視に興味がある方
制御システムのセキュリティ対策に興味がある方

はじめに

サイバーディフェンス研究所の安井です。長年制御システムの開発に携わり、セキュリティ向上に取り組んできました。システム運用に影響を与えず、効果的なセキュリティ対策を実現することは業界の大きな課題です。

これまで、物理的・人的なセキュリティ対策と境界防御を行ったものの対策が有効に機能しているのか不安を感じている方も多いのではないでしょうか？そのような方への システム運用への影響の懸念を最小限に抑えられる次なる対策¹として、パケットキャプチャによる受動的な資産管理・通信監視ツールに注目しています。

過去には 無償の通信監視ツールを紹介²してきましたが、有償ツールとの比較も重要だと考え、2024年4月に無償OSSツール群のMalcolmとテリロジーさんからお借りした有償のNOZOMI Networks Guardian（以下、Guardian）との比較検証を行いました。その内容を２回に渡り紹介します。

1. Malcolm編：OSSのMalcolmの紹介と検証結果（前回記事）
2. Guardian編：有償のGuardianの紹介と検証結果（本記事）

どちらがよいのかの結論としては、予算がある組織にはGuardianのような使いやすい有償製品の利用をお勧めします。一方、限られた予算でも技術的な好奇心と工夫を楽しめる方は、OSSツールを検討するのもありではないでしょうか。

NOZOMI Networks Guardianとは

Guardianは、受動的なパケットキャプチャによる資産管理・セキュリティ監視が可能なツールです。NOZOMI Networks社が開発しており販売代理店を通じて販売されています。 詳しくは貸出しいただいたテリロジーさんの紹介ページをご覧ください。

検証

検証は、まず模擬制御システムに平常時の状態を確認し、その後、サイバー攻撃を行いどのような表示を行うかを確認しました。

対象システム

対象システムは、サイバーディフェンス研究所が作成した 模擬工場制御システムです。

通信パケットの取り込み方法

システムの通信パケットをOT IDSに取り込むイメージ図です。

制御システムのスイッチ(SW Hub)にミラーポート設定をして、スイッチに流れる全てのパケットをOT IDS(Guardian)に取り込み、資産管理とセキュリティ監視を実施しました。

まず平常時の画面を見てみる

この手のツールを使う時に、常時各種画面を見て回ることはしないですよね。特定のDashboard画面を表示しておき、異常な表示があれば詳細を確認するという運用が一般的だと思います。 なお本格的に運用する場合は、メール通知などのアラート通知機能も使いたいところですが本稿では割愛します。

ということで、はじめにGuardianのメイン画面とアラート画面で、何か検知をしていないか見てみます。

つぎに、アラート画面を見てみます。

アラート画面に何か表示しています。説明を見るとSuspect function code scan from host 192.168.100.204 on protocol modbus と表示しています。疑わしいファンクションコードとのことです。このような表示がされた理由は、SCADA Server(192.168.100.204)が、PLC(192.16.10.202)が対応していないmodbusのfunction codeでの問い合わせを送信していたためでした。modbusというのは制御システムのプロトコルの中では比較的メジャーなプロトコルですが、このように制御プロトコルの中のデータ内容まで見て指摘してくれることが有償製品の特徴の１つと思います。攻撃者がPLCの探索を目的としていろいろな命令を送った場合に対応していない命令ならアラートしてくれるわけです なお、本検証環境においてfunciton codeが対応していなかったのは工場制御システムの実装によるものなので、この環境ではサイバー攻撃の痕跡ではありません。

他に攻撃兆候らしきものは表示していません。

参考に、プロセス画面でmodbusでどのようなデータがやりとりされていたのかのサマリ情報も見ることができます。

Guardianは様々な制御プロトコルに対応されている模様ですが、modbusのようにメジャーなプロトコルについては、データ内容のサマリ情報まで見れるようです。 制御プロトコルの中のデータまで踏み込んだ監視をされたい方には有用な機能なのでしょう。

余談ですが、事情があり開示できないキャプチャファイルを取り込んで試したところ、非常にマイナーなプロトコルもグラフ画面ではプロトコル名を表示していたのは、ここまで対応しているのかと驚きました。ただ、プロセス画面には表示されなかったので対応範囲は様々なのだと思います。

次に、平常時にどのような資産がネットワークに接続しているか確認するためにアセット画面を見てみます。

はじめてアセット画面をみた時に、すでに自動で一覧ができており、工場システムのSCADA HMI(192.168.100.5), SCADA Server(192.168.100.204), PLC(192.168.10.202)やルータが表示されています。 自動作成された段階ではタイプ列が表示されていないものがあるので手動で正しい内容を設定します。

簡易的な資産管理台帳の出来上がりです。

次に、アセット画面で見た資産一覧がどのような通信をしているかネットワークトポロジ図をグラフ画面で見てみます。

工場システムのSCADA HMI(192.168.100.5), SCADA Server(192.168.100.204), PLC(192.168.10.202)が表示され、どのIPアドレス間で通信がされているかが分かります。 また、それぞれのノード間では、どのようなプロトコルで通信しているかが表示されています。例えば、SCADA Server(192.168.100.204)とPLC(192.168.10.202)の間はmodbusで通信していることが分かります。 このように、IPアドレス間のネットワークトポロジで、通信路にプロトコルを表示してくれるので直感的に理解しやすいと感じました。

有名どころではないプロトコルはotherと表示されているのでクリックしてみます。

右側に詳細情報が表示され、20295ポートで通信していることが表示されています。

さらに、通信詳細をみるために、ネットワークのリンク画面を見てみます。

各IPアドレス間で、どのようなプロトコルでどれだけのデータがやりとりされたかが表示されています。

学習機能について

ここで、Guardianの学習機能を説明します。Guardianには自動学習機能があります。

初期導入した際は、この学習機能で一定期間学習することで平常状態の通信状況を学習し、監視を始める際にプロテクト状態として監視をすることになります。

補足ですが、セキュリティコントロールパネルでは、学習期間からプロテクト状態への移行を自動でおこなう設定や、アラートの検知感度レベルの５段階設定など、初心者から有識者まで利用者ニーズによりそった設定項目がありました。ここら辺の設定のわかりやすさが、細かすぎずいい塩梅にユーザニーズを取り込んだのであろう使いやすさを考えた有償製品ならではと感じます。

攻撃兆候検知としての使いやすさ

ここからが、攻撃を試行した際の検知内容の紹介となります。

サイバー攻撃シナリオ

サイバー攻撃として２つのシナリオを用意しました。 　

• USBからの侵入

USBを挿して最終的に画面操作を乗っ取りシステムを停止する攻撃です。 詳細はyoutube動画でご覧ください⁴

• 攻撃端末をネットワークへ設置

ネットワークに攻撃端末を設置し、通信盗聴・解析した上で不正な制御命令を送信して不正制御する攻撃です。 詳細はyoutube動画でご覧ください⁵

検知の結果

ようやく本題の検知の結果です。 2つの攻撃シナリオの詳細ステップ毎に、どのような検知がされたか見ていきます。

USBからの侵入

STEP1: BadUSB⁶をSCADA HMIに挿しC2サーバと通信する

攻撃のSTEP1として、 BadUSBをSCADA HMIのPCに挿します。BadUSBに仕込まれたマルウェアが実行されC2サーバへ接続にいきます。これにより、C2サーバからSCADA HMIのコマンドライン操作が可能となります。

メイン画面を見てみます。

メイン画面でなにか検知したようです。状況認識に赤で"There are 1 Unidentified Assets"と、不明なアセットが検出されたことを検知しています。これは怪しいかもしれません。リンク先があるのでクリックして詳細内容を確認してみます。

次にアラート画面を見てみます。

次に、資産管理のアセット画面を見てみます。

特になにも変化ないです。

グラフ画面を見てみます。

SCADA HMI(192.168.100.5)が4.XXX.XXX.XX)と通信していることがわかります。通信プロトコルがグラフ上はotherと記載されていますが、右の詳細をみると4441/tcpのポートで通信していることが分かります。

STEP2: C2サーバから攻撃ツールをダウンロードし実行します。

STEP2として、コマンドライン操作を使ってC2サーバから攻撃ツールをSCADA HMIにダウンロードし実行します。

メイン画面を見てみます。

次に、アラート画面を見てみます。

リスク値 10 と赤色表示されており、詳しくない人が見ても重大そうな脅威であることを訴えかけています。

今回使用した攻撃ツールはありふれたものですので、いろいろ検知してくれています。いかがですか？表示を見て何が起こっているかイメージつくでしょうか？基本英語表記で一見すると何を意味しているか分からないかも知れませんが、ChatGPTなどを利用すればセキュリティ専門家でなくとも怪しさは理解できると思います。 いくつか解説すると、 "Suspicious transfer of malware ・・http://4.XX.XXX.XX:8000/reverse.exe ・・・ GET operation" という内容が追加されています。4.XX.XXX.XXから8000ポートでreverse.exeというファイル名のマルウェアがダウンロードされたようです。 その下に、"Reverse TCP Shell・・remotely control"という表示もあり、リバースシェルで遠隔操作を可能にされていることを示しています。

グラフ画面も見て見ます。

残りの攻撃も続けてみます。

STEP3: 管理者権限を取得し画面操作可能な状態にする

STEP3として、攻撃ツールを操作して管理者権限を取得しリモートデスクトップ機能を有効化して、リモートデスクトップ接続し遠隔からSCADA HMIの画面操作を可能な状態にします。

このときは、追加で何かを検知するということはありませんでした。

STEP4: 画面操作し工場を停止する

STEP4として、遠隔からSCADA HMIの画面を操作して、工場を停止します。遠隔から画面を乗っ取り停止操作している様子の画面が以下です。

このときは、追加で何かを検知するということはありませんでした。

USBからの侵入のまとめ

USBからの侵入は、STEP1:インターネット上のC２サーバとの接続時の「新たな通信の発生」、STEP2:C2サーバからダウンロードした攻撃ツール（マルウェア）の「怪しい通信内容」が検知されたことがわかります。 後半のSTEP3以降は、あらたな通信路を作成しておらず目立った怪しい通信を実施していないため攻撃活動を検知していないのだと予想できます。

防御策について軽く記載しておくと、制御系の外部へつながる通信ルートを、内向き、外向きともにファイアウォールで遮断しておけば防げることが分かると思います。 実際の運用を考えると、最初のSTEP1の検知の段階で、怪しいと気づいて怪しい通信先との通信を遮断し、怪しい通信を発信している対象を調査するなどの行動に移れれば、被害発生まで至る前に攻撃を防ぐ事ができ、この手のツールを使っていて良かったなと思えるわけです。

攻撃端末をネットワークへ設置

ここから2つめの攻撃です。だんだん疲れてきた頃かと思いますが、1つめとは異なる情報も出てくるので一休みして続きをどうぞ。 前回OSSのMalcolmの記事を見ていただいた方には、目立った違いも見えてくると思います。

STEP1: 攻撃端末をLANケーブルでネットワークへ接続

STEP1として、攻撃端末をスイッチの空きポートにLANケーブルで接続します。ブロードキャストやマルチキャストなど何かしらのパケットが攻撃端末に流れ込んで来るのでネットワークセグメントが分かります。慎重な攻撃者ならこの段階ではネットワークに全くパケットを送信しません。

攻撃端末から新たなパケットは流れ出てこないため、当然ですが何も検知しません。

STEP2: ホスト検出

STEP2として、攻撃端末に適当なIPアドレス(192.168.100.40)を割り当てた後、arpパケットを使いネットワークセグメントに繋がっているホストのIPアドレスを見つけます。192.168.100.5, 192.168.100.204, 192.168.100.239, 192.168.100.254のアドレスが発見されます。

この状態で何か検知できているでしょうか？まずはメイン画面を見てみます。

STEP3: ポートスキャン

STEP3として、発見したホスト(192.168.100.204)に対してどのようなサービスが動いているか確認するためにポートスキャンをします。詳細なタイミングなどは敢えて伏せておきます。

例によって、まずはメイン画面を見てみます。

特に変化は見当たりません。アラート画面も変化ないので省略します。

次に、グラフ画面を見ます。

赤色の怪しい端末(192.168.100.40)がSCADA Server(192.168.100.204)に対し多量の通信をしていることが分かります。明らかに怪しいです。

通信の詳細を確認するためにネットワークのリンク画面を見てみます。

こちらの画面でも同じく新しく現れたリンクが赤色表示しており怪しい端末(192.168.100.40)がSCADA Server(192.168.100.204)の多量のプロトコル(ポート)向けに通信していることが分かります。明らかに怪しいです。

補足：一般に、サイバー攻撃では、ネットワークに侵入できたらホスト検出、ポートスキャンという順に探索活動を進める事が多いです。今回は派手に短時間で多量のスキャンを行いましたが攻撃者が通信監視されている可能性を疑う慎重な攻撃者である場合、ゆっくりとポートスキャンを行うことで検知されにくくしようとすることも考えられます。しかし、ここで示したように、普段利用していない通信の発生に着目していれば、新たな端末の出現や新たなリンクの出現で発見できるものです。 なお、ここで紹介する攻撃に関しては、以降の攻撃は、ポートスキャンを行わなくても実行することが可能ですが、一般的な攻撃手順であるポートスキャンがどのように検知されるかを見るためにSTEP3を手順にいれました。

STEP4: 中間者攻撃による盗聴

STEP4として、中間者攻撃によりSCADA Server(192.168.100.204)とPLCの間の通信を攻撃者端末で中継し盗聴します。中間者攻撃の詳細は敢えて伏せておきます。 盗聴したパケットの内容を解析し、監視・制御のパケット構造を理解します。

メイン画面を見てみます。

メイン画面でなにか検知したようです。状況認識に赤で"There are 4 Unidentified Assets"と、不明なアセットが検出されたことを検知しています。これは怪しいかもしれません。リンク先があるのでクリックして詳細内容を確認してみます。

では、アラート画面を見てみます。

"acting as a MITM, its victims are 192.168.100.204, 192.168.100.239"と表示されています。MITMはMan In The Middleの略で中間者攻撃という意味であり、被害者が192.168.100.204と192.168.100.239であることを示しています。リスク値10と表示しているので誰が見ても危険な攻撃であることが一目瞭然です。

グラフ画面も見てみましょう。

192.168.100.204, 192.168.100.239が赤色表示となっており、かつ通信相手もおかしな表示となっています。これは中間者攻撃でMACアドレスが偽装された影響です。

STEP5: 通信改ざん

STEP5として、中間者攻撃で中継して盗聴しているパケットの内容を改ざんします。改ざんの目的は、SCADA HMIの画面に正常状態が継続していると思わせる事です。

この段階では何も検知しません。　STEP4から通信の流れは変わっておらず、通信パケットのアプリケーション層の部分の内容が普段よく使われる正常値に書き換えられているだけのためと思われます。

STEP6: 不正な制御命令送信

STEP6として、攻撃者端末から制御命令のパケットを作成しPLC(192.168.10.202)に対して送信します。このとき発見されることを回避するため、送信元IPアドレスは正規の送信元(192.168.100.204)に偽装します。

この段階では何も検知しません。送信された攻撃は既にSTEP4の段階で検知済みの攻撃ルートを使っての攻撃であるためと思われます。

攻撃端末をネットワークへ設置のまとめ

攻撃端末をネットワークへ設置は、STEP2:ホスト検出、STEP3:ポートスキャン、STEP4:中間者攻撃による盗聴の「怪しい通信内容」が検知されたことがわかります。 このようにGuardianは、MACアドレスレベルで通信状況の変化を検出するため、STEP3だけでなくarpを使ったSTEP2,STEP4の攻撃も検出してくれています。

ここまで監視されていると攻撃者の目線からすると、検知されずに潜伏することや、検知され対策されてしまうまでに攻撃目標に到達することの困難さが推測できるのではないでしょうか。

補足1:操作性からみた画面操作の応答速度について

ここまでの検証を行ってきてストレスを感じることはありませんでした。 これらは、あくまで感覚論ですのでご自身で試すことをお勧めします。

補足2:環境構築について

Guardianは、本来はアプライアンス製品版がメインとのことでしたが、今回の検証は、手軽に実施したいため仮想マシン版をお借りし、自前で用意したVMプラットフォームに復元しましたが特段の問題なく構築が行えました。なおマニュアルは検証用のため英語版でしたが、正規購入製品には日本語マニュアルも添付されているそうです。

おわりに

今回は、OT IDSとして有償のGuardianを紹介しました。 いかがでしたでしょうか？通信監視がされると攻撃者がよほど慎重に攻撃しない限り攻撃兆候が発見される様子がイメージついたでしょうか？決まった通信しか行わないOTのネットワークでは通信監視により比較的容易に攻撃兆候は発見できるように思います。

なお、この検証は、Guardianを初期インストールした状態で行っています。カスタマイズすればさらに検知できることも増えるとは思いますが、初期状態でこの程度検知できるのだと理解ください。

また、本検証の環境は、サイバー攻撃の流れをイメージしてもらうために用意したものであり、攻撃されるシステムの環境は脆弱な環境としてあり、検証に使用した攻撃ツールは一般的なWindowsのアンチウィルスソフトウェアが有効であれば検知隔離してくれるような基本的なツールを使用してあります。

２回の比較のおわりに

以下リンクの前回OSSのMalcolmの記事も読んでいただいた方は、OSSのMalcolmとの相違点も感じることができたのではないでしょうか？

OT IDS比較検証：OSSのMalcolmと有償のNOZOMI Guardian - 1.Malcolm編 -

セキュリティ監視に関心がある方向けに、OT IDSとして無償・有償ツールの比較検証を行った結果を2回に渡り紹介します。初めの今回は、無償OSSの通信監視・分析ツール群であるMalcolmを紹介します。 ...

io.cyberdefense.jp

付加価値的な部分に少し触れておくと、長期運用する上では、運用のしやすさという点が重要となると思います。筆者自身長期運用比較したわけではないため試用してみての感想レベルですが、複数人で組織的に運用するのであればGuardianの方が扱いやすいと思います。わかりやすくする工夫が随所にみられますので。 本文にも少し書きましたがユーザニーズを取り込んだのであろう気の利いた機能がわかりやすく利用できるようになっていると感じました。

一方、Malcolmは様々なオプション機能があっても機能を見つけて使いこなすことのハードルが高いと思います。逆にそれらを使いこなすことが好きな方には、コスト面を考えればMalcolmを試す価値はあるのではないでしょうか。

この記事が多くの方の参考になれば幸いです。

最後に、NOZOMI Networks Guardianを貸出いただき今回の検証と結果の公表を快諾いただいた販売代理店のテリロジーの皆様に感謝を申し上げます。