制御システムのセキュリティと対策技術OsecTのご紹介（後編）

こんにちは、イノベーションセンターの前田です。今回は、前回に引き続き、私のチームで開発中の制御（OT）システム向けセキュリティ対策技術OsecT（オーセクト）についてご紹介します。

前回の記事（前編）では、以下の内容をご紹介しました。

OTネットワークの概要
OTネットワークのセキュリティ対策と課題
OsecTの概要
OsecTのネットワーク可視化機能の詳細

本記事では、

OsecTの脅威検知機能の詳細

について、ご紹介します。

前編のおさらい

工場・ビル等のスマート化に伴い、OTネットワークのセキュリティリスクも高まっています。しかし、OTのネットワークは閉域ネットワークとして構築されてきたことや独自OS・プロトコルが多数利用されてきたことから、セキュリティ対策が進んでいない現状があります。こうした状況を受けて、NTT Comでは、OTのセキュリティ対策技術OsecT（オーセクト）を開発しています。

OsecTには、

守るべき資産や通信の可視化を行うネットワーク可視化機能と、
不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能）

の2つの機能があります。

以降では、OsecTの脅威検知機能の詳細について、開発の工夫点などを交えながらご紹介します。

※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。

脅威検知機能

OTの守るべき資産・ネットワークを可視化し、資産台帳の最新化や監視ポイントの明確化等が行えたら、次のステップとして有用なのが脅威検知機能になります。こちらの機能もネットワーク可視化機能と同様に、オフラインのトラヒックデータを元に定期アセスメント等で利用する使い方もできますが、リアルタイムのトラヒックデータをミラーリングで取り込んで脅威検知機能で処理し、発出されるアラートを監視する使い方が有効です。

OsecTでは、以下の7つの脅威検知機能を開発中です。機能毎にコンテナを分けることで、必要なものだけを選択して導入できる作りにしています。

また、各脅威検知機能は、次のいずれかに属しています。

学習期間を定めてその期間を正常状態として学習し、検知期間において、学習モデルと異なる振る舞いが観測された場合にアラートを発出する「アノマリ検知」
セキュリティの脅威につながる通信パターンやサポート切れのOS情報などを事前定義したルールに基づき検知期間の通信をチェックし、ルールにマッチした場合にアラートを発出する「ルールベース検知」

新規端末検知

こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{IPアドレス, MACアドレス}の組み合わせを学習して、学習モデルに登場しない{IPアドレス, MACアドレス}の組み合わせの通信が観測された場合にアラートを発出しています。

アラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、未学習の{IPアドレス, MACアドレス}の組み合わせに加えて、当該端末を特定しやすいように、MAC Vendorの情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、計画されていない端末がネットワークに接続された際などに早期発見することができます。

ネットワークホワイトリスト

こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。

OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。こちらの特徴を考慮せずにネットワークホワイトリストの学習モデルを作成すると、学習モデルの行数（テーブル数）が膨大になる問題があります。OsecTでは、こうしたサービスの通信を自動判別・集約して効率的に学習しています。

学習モデルは、例えば、以下のようなものが作成され、4行目や7行目が前述の仕組みで集約された箇所になります。

また、ネットワークホワイトリストのアラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示するようにしています。こちらのアラートを見ることで、平常時とは異なる宛先への通信や平常時に利用していない不審なサービスの通信などを早期発見できます。

OTコマンドホワイトリスト

こちらは、アノマリ検知に属し、OTプロトコルのL7情報を用いた脅威検知機能になっています。現在は、ビルのオートメーション・制御に利用されるBACnet/IPに対応しており、学習期間のトラヒックデータに登場する、{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。

OTコマンドホワイトリスト（BACnet/IP）のアラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示しています。こちらのアラートを見ることで、平常時とは異なるBACnetサービス（コマンド）通信の発生を早期発見でき、例えばビルシステムの保守作業スケジュール等と突合して適切な通信かを確認することで、異常を特定できます。

流量ベースライン検知

こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス}のペア毎に、各時間帯のトラヒック量（パケット数、バイト数）をベースに、各時間帯で取り得るトラヒック量の範囲（上限値と下限値）を推定して、その値を学習モデルとして保存します。検知期間では、学習されたトラヒック量の上限値を上回る/または下限値を下回る通信が観測された場合にアラートを発出します。また、OTでは決められた時間に機械的に通信する端末が多く存在するため、{src_ip, dst_ip}のペア毎に、各時間帯での通信の有無を学習して、平常時は通信が発生する時間帯にもかかわらず、通信が発生しなくなった場合にもアラートを発出しています。

OTでは、工場等が稼働している日なのか、非稼働の日なのかによって、通信量や頻度の傾向が大きく異なる場合があるため、こちらの機能では、非稼働日や非稼働の時間帯を設定できるようにしています。非稼働日・時間帯の場合は、稼働日とは別のベースライン（上限値と下限値）を作成して検知に利用します。

流量ベースライン検知のアラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、送信元IPアドレス、宛先IPアドレス、アラート種別（上限値を上回った/下限値を下回った/通信が停止した）、データ種別（パケット数/バイト数）、観測した通信量、学習された通信量の上限値、学習された通信量の下限値、通信断の判定に利用されるカウンタの値などを表示しています。また、他の脅威検知と同様に、IPアドレスにマウスカーソルを合わせた際の端末情報の吹き出し表示もあります。例えば、画像の2行目では、2019/08/20 6:30において、10.1.0.232から10.1.0.55へのパケット数が学習された上限値の483個に対して、10052個観測されており、上限値を超えたことでアラートが発出されています。

流量ベースライン検知ではさらに、通信量の変化や異常性を分かりやすくするために、次のような時系列グラフで、観測された通信の詳細を確認できるようにしています。こちらのグラフでは、赤線が学習された上限値、青線が学習された下限値、黒線が観測値を表しています。また、グラフ上の点にマウスカーソルを合わせることで、観測された値や通信に含まれるサービスの内訳を吹き出しで表示しています。さらに、こちらの画面で分析に必要な情報が極力完結するように、画面右には、送信元IPアドレスと宛先IPアドレスに紐づく端末の詳細情報を表示しています。こちらのアラートや通信の詳細ページを見ることで、平常時からの急激な通信量の増加や攻撃等でのシステム停止による通信断などを早期発見できます。

周期異常検知

こちらは、アノマリ検知に属し、BACnet/IPに特化した脅威検知機能となっています。学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、信号処理技術を用いて、通信周期（60秒に1回、通信発生など）を抽出して学習します。検知期間では、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}毎に、通信周期を抽出し、学習された周期と比較して、周期外の通信が発生した場合、または周期的な通信が消失した場合にアラートを発出します。

こちらは、NTTの社会情報研究所で考案された技術がベースとなっており、複数のビルの通信データを分析して得られたノウハウに基づき、アルゴリズムの構築、特徴量・各種パラメータの設定を行っています。

周期異常検知の学習モデルは、次のようになっています。こちらでは、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、学習された通信周期(PRI)、学習時に非周期として判定された通信数(non_periodic)、最終判定されたモデル(period=通信に周期性あり、non=通信に周期性なし、period_and_non=通信に周期性ありとなしが混在)などを表示しています。学習された通信周期(PRI)の項目は、(時間間隔, 通信回数)で表記されるようになっており、例えば、(62, 3)は、62秒毎に3回ずつの通信が発生することを意味しています。また、周期性なしの場合は(-1, 1)が表示されます。なお、1行目の[(62, 3), (-1,1)]は、通信を分解した際に、周期性のある通信と非周期の通信が混在していることを意味しています。

また、周期異常検知のアラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、アラートの内容(Non Periodic communication=周期外通信の発生、Lost Communication=周期通信の消失)、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ、ホバーで端末の詳細情報を表示しています。こちらのアラートを見ることで、BACnet/IPにおける不正なコマンドの挿入や通信断を早期発見できます。

サポート切れOS端末検知

こちらは、ルールベース検知に属します。サポート切れOSの一覧表を事前ルールとして保持しており、検知期間のトラヒックデータの中に登場する{IPアドレス, MACアドレス}の組み合わせ毎にOSを推定し、サポート切れOSの一覧表の内容とマッチする場合にアラートを発出しています。

前編でご紹介したネットワーク可視化機能でも、OS推定情報を表示していますが、あちらは主に定期アセスメント等で利用することを想定しているため、様々なメトリックを利用して、少しでも古いOSの疑いがあれば表示するようにしているのに対して、脅威検知機能は主にリアルタイムにアラートを監視する使い方を想定しているため、運用者の負担を軽減する（誤検知を減らす）ように、確実性が高く、改ざんが困難なメトリックのみを利用してOS情報を推定しています。

サポート切れOS端末検知のアラート画面は、次のようになっています。こちらでは、当該通信が発生した時刻、{IPアドレス, MACアドレス}の組み合わせ、OS情報に加えて、当該端末を特定しやすいように、MAC Vendorとホスト名の情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、サポート切れのOSを利用する端末がネットワークに接続された際に早期発見できます。

シグネチャ検知

こちらは、ルールベース検知に属します。セキュリティの脅威につながる通信パターンの情報（シグネチャ）を事前ルールとして保持しており、シグネチャの内容に合致する通信が観測された場合に、アラートを発出しています。

こちらの機能では、オープンソースのIT向けIDS(Intrusion Detection System)である「Suricata」と、Proofpoint社が配布しているルールファイル（シグネチャ）を利用しています。ルールファイルには、セキュリティの脅威につながる通信パターンを表すルールが複数記載されていますが、一例を挙げると、次のようなものがあります。

alert http $HOME_NET any -> any any (msg:"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"; flow:established,to_server; content:"Authorization|3a 20|Basic"; nocase; http_header; content:!"YW5vbnltb3VzOg=="; within:32; http_header; content:!"Proxy-Authorization|3a 20|Basic"; nocase; http_header; threshold: type both, count 1, seconds 300, track by_src; reference:url,doc.emergingthreats.net/bin/view/Main/2006380; classtype:policy-violation; sid:2006380; rev:13; metadata:created_at 2010_07_30, updated_at 2020_08_28;)

Suricataのルールのフォーマットは、以下のようになっています。

action: シグネチャにマッチした際のアクション（例では、alert）
header: ルールを適用するプロトコル、IPアドレス、ポート番号、通信の向き（例では、http $HOME_NET any -> any any）
rule options: オプション（例では、(msg: から 28;) までの括弧で囲まれた部分）

上記の例は、http通信かつ監視対象のネットワークから任意のポート、宛先への通信を検査し、rule optionsで指定された条件を満たした場合に、"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"(ベーシック認証でHTTPパスワードが暗号化されていないことを検出したという意味)のアラートを発出するルールになっています。

rule optionsには、細かなマッチ条件などを;で区切って複数指定可能で、例えば、

flow:established,to_server; content:"Authorization|3a 20|Basic";

の部分は、フローが確立していてclient→server方向であること、ペイロードに"Authorization: Basic"が含まれること、を表しています。正確なルールの読み方は、公式ドキュメントをご参照ください。

OsecTでは、Suricataの出力結果を、次のようなアラート画面として表示しています。こちらでは、当該通信が発生した時刻、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、プロトコル、マッチしたルールの内容とカテゴリ、Severity（1: high, 2: medium, 3: low）を表示しています。また、他の脅威検知機能と同様に、極力こちらの画面だけで必要な情報を確認できるように、ホスト情報をホバー表示しています。こちらのアラートを見ることで、脆弱性を含む古いJavaの利用や平文でのパスワードのやり取りなど、セキュリティの脅威につながる通信の発生を早期発見できます。

アラート統合画面

OsecTでは、ここまでにご紹介した7つの脅威検知機能のアラートをまとめて確認できる画面も作成しています。こちらは、日常的にアラートを監視する際にメインで利用する画面をイメージして作成しています。送信元IPアドレスや宛先IPアドレスなどの条件を設定して、アラートをフィルタリングできるため、特定のIPアドレスに着目して、複数の脅威検知のアラートの有無を横断的に確認したい場合などにも利用できます。

最後に

今回は、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの脅威検知機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。本記事の内容が、ご検討のお役に立ちましたら幸いです。また、本記事の感想やフィードバックもお待ちしております。

※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非こちらからご応募頂けますと幸いです。