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

セキュリティ監視に関心がある方向けに、OT IDSとして無償・有償ツールの比較検証を行った結果を2回に渡り紹介します。初めの今回は、無償OSSの通信監視・分析ツール群であるMalcolmを紹介します。 文章構成は、有償のGuardianを紹介した2回目と同様にしているので、MalcolmとGuardianを比較されたい方は両方並べて読んでいただくとわかりやすいと思います。

対象読者

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

はじめに

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

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

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

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

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

OSSのMalcolmとは

Malcolmは、受動的なパケットキャプチャによる資産管理・セキュリティ監視が可能なOSSのツール群です。米国CISA(CYBERSECURITY & INFRASTRUCTURE SECURITY AGENCY)が公開し、アイダホ研究所が開発を支援しています。主要なツールは以下のとおりです。

SuricataとZeek

Suricataは通信監視・分析ツールであり、主に不審なコード一致のようなルールベースによるパケット分析により異常を検出します。 Zeekは通信監視・分析ツールであり、単純ルールにとどまらないパケット分析により異常を検出します。いずれも、検出結果はMalcolmのSecurity Overviewダッシュボード画面から見ることが可能です。

NetBox

NetBoxはネットワーク資産管理ツールで、一部自動化された資産管理台帳の作成が可能です。

Arkime

Arkimeは通信監視・分析ツールです。通信状況をネットワークトポロジ図として可視化でき、普段と異なる通信を容易に検出できます。

検証

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

対象システム

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

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

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

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

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

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

ということで、はじめにMalcolmのSecurity Overview画面で、Zeek,Suricataで何か検知をしていないか見てみます。

当然ながら、何も攻撃兆候らしきものは表示していません。

つぎに、平常時にどのような資産がネットワークにいるか見るためにNetBoxのDevice画面を見てみます。

はじめてNetBoxをみた時に、すでに自動でDevice一覧ができており、工場システムのSCADA HMI(192.168.100.5), SCADA Server(192.168.100.204), PLC(192.168.10.202)やルータが表示されています。 自動作成された段階ではStatusがstagedと表示されているので、正当な内容であれば手動でActiveとします。

こうすることで、OT系のネットワークのように基本的には正当のホストしか接続されていないネットワークであれば、すべてActiveな端末として表示された状態となります。 簡易的な資産管理台帳の出来上がりです。

後々、statusがstagedというものが出現すれば管理外の端末が接続された事になるので、セキュリティ監視の画面で詳細を調べてみようという運用が可能です。

以上の説明はNetBoxの機能のさわりの部分の紹介です。他にも手動での登録が必要になりますが物理的なデバイスの管理やデバイスとIPアドレスの紐付けなども行えるので興味ある方は調べてみてください。

つぎに、Arkimeの画面を見ていきます。先ほどNetBoxで見た資産一覧がどのような通信をしているかネットワークトポロジ図をArkime-Connections画面で見てみます。

工場システムのSCADA HMI(192.168.100.5), SCADA Server(192.168.100.204), PLC(192.168.10.202)が表示され、どのIPアドレス間で通信がされているかが分かります。

少し表示方法を変えて、IPアドレスだけでなく宛先ポート番号もあわせて表示してみます。

通信先のIPアドレスの横に宛先ポート番号も表示されました。ただ宛先ポート毎にシンボル(⚫️)を表示しているので直感的にネットワーク接続イメージが分かりにくいのは残念なところです。通信路にポート番号を羅列してもらえると見やすいのになぁと思います（これはGuardianと比較するときの前振りです）。

さらに、通信詳細をみるために、Arkime-Sessions画面を見てみます。

SCADA Server(192.168.100.204)とPLC(192.168.10.202)は、502/TCP で制御システム通信の中では有名なModbus/TCPで通信していることが分かります。

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

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

サイバー攻撃シナリオ

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

• USBからの侵入

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

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

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

検知の結果

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

USBからの侵入

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

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

MalcolmのSecurity Overviewを見てみます。

なにか検知したようです。右側のName部分を見ると"ET HUNTING Powershell Conn・・"とPowershellで外部との通信が発生したことを検知しています。これは怪しいかもしれません。 同じページの下方のlogs部分でこの通信の詳細を見るとSCADA HMI(192.168.100.5)と4.XXX.XXX.XXが通信したことが分かります。

次に、資産管理のNetBoxの画面を見てみます。

特になにも変化ないです。MalcolmのNetBoxのデフォルトインストール設定では、一定以上の通信量がないと新たなDeviceとして自動検出はしない模様です。

MalcolmのArkime-Connections画面を見てみます。

SCADA HMI(192.168.100.5)が4.XXX.XXX.XX)と通信していることがわかります。

通信内容の詳細を見るためにMalcolmのArkime-Sessions画面を見てみます。このときフィルタ条件で4.XXX.XXX.XXのアドレスの通信を指定します。

SCADA HMI(192.168.100.5)と4.XXX.XXX.XXが、TCPの4441ポートを使って通信したことが分かります。 画面の右上の世界地図を見ると米国が黒塗りされていることから4.XXX.XXX.XXは米国のサーバのようです。 平常時に制御システムがインターネットと通信することはないので、明らかに怪しいです。

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

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

MalcolmのSecurity Overviewを見てみます。

今回使用した攻撃ツールはありふれたものですので、いろいろ検知してくれています。いかがですか？右側のName部分の表示を見て何が起こっているかイメージできるでしょうか？基本英語表記で一見すると何を意味しているか分からないかも知れませんが、ChatGPTなどを利用すればセキュリティ専門家でなくとも怪しさは理解できると思います。いくつか解説すると、Categrory "A Network Trojan・・"は明らかなマルウェア検出です。一方で"Not Suspicious Traff・・"は疑わしい通信ではないです。このように全てが危険というわけでもないため、どの表示が危険かを読み取る能力は必要となります。

残り画面も見てみましょう。 MalcolmのArkime-Connection画面を見てみます。

特に変化ないようです。

通信内容の詳細を見るためにMalcolmのArkime-Sessions画面を見てみます。このときフィルタ条件で4.XXX.XXX.XXのアドレスの通信を指定します。

SCADA HMI(192.168.100.5)と4.XXX.XXX.XXが、4441/tcp以外にも8000/tcp, 10001/tcpのセッションが増えています。完全に怪しいです。

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

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

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

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

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

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

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

####### USBからの侵入のまとめ

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

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

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

ここから2つめの攻撃です。だんだん疲れてきた頃かと思いますが、1つめとは異なる情報も出てくるので一休みして続きをどうぞ。

####### 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のアドレスが発見されます。

この段階でも何も検知しません。　新たなパケットが流れてきているので検知してくれてもよさそうなものですが、たぶん以下のような理屈で検知していないのでしょう。

arpはIPアドレスを宛先とした通信を行いません。Malcolmは、IPアドレスで新たなホストの出現を検知しているようですので攻撃端末を検知できなかったのでしょう。

####### STEP3: ポートスキャン

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

MalcolmのSecurity Overviewを見てみます。

ポートスキャンが実施されたことを表示しています。画面下部の詳細を見るとどういうタイミングでパケットが流れたからポートスキャンと判断したかの理由も記載されています。

この段階でサイバー攻撃の探索活動がされていることが明白です。

MalcolmのArkime-Connections画面を見てみます。

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

通信内容の詳細を見るためにMalcolmのArkime-Sessions画面を見てみます。

こちらの画面でも同じく怪しい端末(192.168.100.40)がSCADA Server(192.168.100.204)の多量のポート向けに通信していることが分かります。明らかに怪しいです。

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

Netboxの画面では192.168.100.40という管理外の端末が検出されています。

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

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

この段階では何も検知しません。　通信の流れが変わっているので検知してくれてもよさそうなものですが、たぶん以下のような理屈で検知していないのでしょう。

中間者攻撃はarpパケットを悪用する攻撃です。 arpはIPアドレスを宛先とした通信を行いません。Malcolmは、IPアドレスで新たなホストの出現を検知しているようですので攻撃端末を検知できなかったのでしょう。

####### STEP5: 通信改ざん

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

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

####### STEP6: 不正な制御命令送信

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

この段階では何も検知しません。　攻撃パケットは、送信元IPアドレスが偽装されているため正規のSCADA Server(192.168.100.204)から正規のPLC(192.168.10.202)に向けて送られていると認識されたため発見できなかったのでしょう。

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

攻撃端末をネットワークへ設置は、STEP3:ポートスキャンの「怪しい通信内容」が検知されたことがわかります。 しかし、STEP3の補足で記載したとおりSTEP3のポートスキャンがされず、STEP1,2,4,5,6の順で攻撃が行われた場合、この一連の攻撃は発見できませんでした。 このように全ての攻撃が発見できるわけでは無い例を示すためこのシナリオを選んでみました。これもGuardianとの比較の前振りです。 攻撃の被害イメージが掴めなかった方もいると思います。そのような方は、攻撃シナリオで紹介したこちらのyoutube動画⁵を見ていただくと、こんなに危険な攻撃でも気づきにくい事もあるのだというイメージが掴めると思います。

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

操作していての応答速度としては、MalcolmのSecurity Overviewを見ているだけであればストレスを感じることはありませんでした。 一方で、Arkimeの操作は、今回の検証の環境では遅いと感じました。この程度の非常にシンプルな画面で遅いと感じるので大規模なシステムだと心配です。 これもGuardianとの比較の前振りです。 これらは、あくまで感覚論ですのでご自身で試すことをお勧めします。

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

Malcolmは、CISAの紹介ページの冒頭で 「強力で簡単に導入可能」 と書かれているとおり、OSSのツール群にしては比較的簡単にインストールが行えます。ただし、注意が必要なのは多量なメモリが必要という点です。参考までに、本稿では16GBメモリのノートPCに32GBメモリ増設し48GBのメモリ環境で検証を実施しています。

また、インストール時に、さまざまなオプション選択を聞かれますが何を選択すればよいか迷われると思います。人により必要な機能は異なるため本稿では細かな手順は示しませんが、本稿作成時のインストール設定ポイントを以下参考に記載しました。

• インストールの最初にdocker groupにnon-rootユーザを追加する。
• いくつかの質問が表示されるが基本Returnを押す。
• OT/ICSの項目は全てyes,NetBoxの項目は全てyes,
• オンラインのキャプチャはyesとしてキャプチャするためのNICを指定する。

おわりに

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

なお、この検証は、Malcolmの各ツールを初期インストールした状態で行っています。カスタマイズすればさらに検知できることも増えるとは思いますが、初期状態でこの程度検知できるのだと理解ください。 また、本検証の環境は、サイバー攻撃の流れをイメージしてもらうために用意したものであり、攻撃されるシステムの環境は脆弱な環境としてあり、検証に使用した攻撃ツールは一般的なWindowsのアンチウィルスソフトウェアが有効であれば検知隔離してくれるような基本的なツールを使用してあります。

感想や質問がありましたらお気軽に問い合わせへお寄せください。次回に反映できるものあれば反映したいと思います。 次回は、有償のGuardianの内容になります。　今回との違いにも着目して紹介しているので合わせてご覧ください。

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

セキュリティ監視に関心がある方向けに、OT IDSとして無償・有償ツールの比較検証を行った結果を2回に渡り紹介します。2回目の今回は、有償の通信監視・分析ツールであるNOZOMI Networks Guardianを紹介します。 文章構成は、OSSのMalcolmを紹介した1回目と同様にしているので、MalcolmとGuardianを比較されたい方は両方並べて読んでいただくとわかりやすいと思います。 ...

io.cyberdefense.jp

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