前書き

前々職および前職で所謂「国際標準」に携わる機会があったのですが、それが世の中に知られるのはごく僅かに感じています。自分の関係する話題しか扱えませんが、今後、弊社から「国際標準」の紹介をしていきたいと思います。皆様の参考になれば幸いです。

はじめに

この記事ではIoTエッジデバイスに変更を加えず、インターネットとIoTエッジデバイスネットワークを仲介するIoTGWに少しだけ機能を追加することで、IoTエコシステムに対するセキュリティ攻撃のインシデントハンドリングをするための要件を定義したITU-Tの勧告(Recommendation) ITU-T X.1367: Standard format for internet of things error logs for security incident operationをご紹介します。IoTエッジデバイスに要求を送信する装置(主にIoTGWを想定)やIoTエッジデバイスネットワーク内の不正検知システム(IDS)とそれらを制御する上位システムにこの勧告の要件に従って機能を実装することにより、より正確にIoTエコシステムへのセキュリティ攻撃を検知したり、攻撃者の追跡をしたりすることが出来るようになります。

対象読者

• IoTエコシステムを運用するユーザ。
• IoTGW、IoTエッジデバイスネットワーク用IDSを製造する事業者。
• IoTの運用をサポートするためのサービスを提供しているクラウド事業者。
• セキュリティオペレーションセンター(SOC)サービスを提供する事業者

この記事で分かること

• 勧告 ITU-T X.1367 の概要
• この勧告がどのように機能するのか？

現在のIoTエコシステムの状況

IoTは様々な要素から構成されます。リソースがリッチなものもあればプアなものもあります。インターネットプロトコル(IP)で直接通信するような装置であれば、大抵の場合syslog(IETF RFC 5424)を取り扱うことが出来るので、それらのマナーに従い適切なログを送信することで、SOCの監視ログに統合することが出来ます。

しかし、IoTエッジデバイスの場合、非常に小さな主記憶装置やストレージがプロセッサと共に1チップに納められたマイクロコントローラユニット(MCU)が用いられます。確かに最近のMCUはセキュリティ機能として暗号分を取り扱うハードウェアアクセラレータや、主記憶上のセキュア空間を設定するような機能も実装され始めていますが、セキュリティ攻撃を防いだり、MCU内部へ侵入されたことを検知したりするのは、コンピュータリソースの都合で難しい状況です。一部例外はありますが、その場合はコストの問題になります。そのため、一度セキュリティ攻撃者がIoTGWに侵入すると、IoTエッジデバイスへの攻撃をSOCが検知するのは難しい状況です。

例えば、勧告で説明している、ある工場において複数のIoTエコシステムを導入した図1の例を見てみましょう。

図1: 複数のIoTエコシステムを導入した工場 (ITU-T X.1367からの引用)

これらのシステムが工場内単一LANで動作し、そこに従業員用のPCが接続されていたならば、図2のように攻撃者はそのPCを通じて容易に工場内のIoTエッジデバイスに攻撃できることになります。

図2: 攻撃者が複数のIoTエコシステムを跨いで攻撃している様子(ITU-T X.1367からの引用)

この時、IoTエッジデバイスは様々なエラーを発行する可能性がありますが、以下の2点でSOCによる分析を妨げています。

• 各エラーの書式が製造業者やIoTエコシステムごとに異なっており、SOCの統合分析の妨げとなる。
• 各エラーはそのエッジデバイス固有のコードで記されることが多いため、一見してどのタイプのエラーかを判断するのが困難である。

勧告 ITU-T X.1367 の概要

この勧告は、先の節で述べた2つの課題を解決するため、IoTエッジデバイスが発行するエラー情報を標準化するための標準エラーログフォーマットと、製造業者やデバイス毎に異なるエラーコードを標準化するための標準エラーコードを定義しています。その他、これらの使い方や、どのように機能するのかという例示により構成されています。

具体的に見ていきましょう。まずは標準エラーログフォーマットを以下に示します。フォーマットは型指定のための正規表現拡張がされたJSONで示しています。

{ 
    "Timestamp": "^([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\.[0-9]{+})Z$", 
    "Reporter": {}, 
    "Protocol": String, 
    "Requester": {}, 
    "Responder": {}, 
    "Error Code": "/^[0-9A-F]^{+}$/", 
    "Error Message": String, 
    "Description": String | {}, 
}

図3: 標準エラーログフォーマット (ITU-T X.1367からの引用)

注目してほしいのはReporter, Requester, Responderと3つの装置を記述するところと、Error Code, Error Messageです。Error CodeとError Messageは後ほど説明します。

このフォーマットはReporter, Requester, Responderと3つの装置から構成されていることが分かります。その役割ですが、Reporterはエラーを検知した時にそれをこの標準エラーログフォーマットに変換して、クラウドなどのログサーバにsyslogなどで通知する装置です。インターネット到達性があることが前提なので、固有IDはIPアドレスを割り当てます。通常はIoTGWが担いますが、IoTエッジデバイスネットワークに設置されるIDSでもこの役割を担うことが出来ます。RequesterとResponderはそれぞれ要求を送信した装置と、その要求に応答した装置です。固有IDはIoTエッジデバイスネットワークで割り当てられる固有IDを想定していて、各装置が送信した生のデータを16進数の文字列として記録します。これにより、後で述べる標準エラーコードでエラーの概要を知るだけでなく、具体的な装置間の通信もセキュリティアナリストが調査出来るようになっています。

次に標準エラーコードを以下に抜粋を示します。

表1: エラーコードとエラーメッセージ(ITU-T X.1367からの抜粋引用、説明はこの記事で翻訳)

センサーの読み取り値を要求したり、アクチュエータにある動作を要求する場合、要求と必要であれば引数が連接されてReporterからResponderに送信されます。その時、要求や引数がResponder側で受け入れできない場合、各製造業者で定めたそれに対応するエラーコードを送信することになります。Reporterはそれらのエラーコードから上記の標準エラーコードへ変換する表を持ち、それに応じて標準エラーコードに変換して標準エラーログフォーマットを構成しログサーバに送信します。

この標準エラーログフォーマットおよび標準エラーコードの構成により、IoTエッジデバイスには何ら変更を加えず、IoTGWやIDSに変換表とフォーマット充足機能およびsyslogを実装するだけで、一般的なコンピュータネットワークの監視体制の中にIoTのエラーを組み込むことが出来るようになります。また、SOCは組織全体のコンピュータネットワーク上で動作しているファイアウォール、プロキシ、IDSなどのログをIoTのログと統合して監視することが出来るため、IoTへの攻撃に関する攻撃者の痕跡をより詳細に追求できるようになります。

一つ例を見てみましょう。図4は攻撃者がIoTGWを攻略し、MCU2に対して偽の証明書をIoTGW経由でMCU2に送信した状況を図示したものです。

図4: 攻撃者がIoTGWを攻略した後、偽の証明書をMCU2に送信した場合(ITU-T X.1367からの引用)

MCU2は製造業者が定義したエラーコード「00000010000c」を要求を送信してきたIoTGW側に返信しますが、IoTGWは攻略済みのためこれを無視します。これは2015年にジープチェロキーが外部からハック可能だった報告書の状況と類似しています。この時IoTGWは無反応ですが、IDSがエッジデバイスネットワーク側に導入されていた場合、これがエラーを検知してクラウド側のログサーバにエラーログを通知することが出来ます。もし、このようなシステムが導入されていたら、仮に車載システムにおけるIoTGWに相当するDCM(Data Communication Module)やナビユニットが攻撃者によって攻略されても、エラーを検知し、それをSOCが知る手段を維持することが出来ます。

この勧告に従った実装について一つ懸念があるとすれば、IoTエッジデバイスから発行されるエラーがかなりの量になることが予想されることです。ほとんどはsyslogで言うinformationレベルですが、SOCでどのように取り扱うのが良いかは今後の課題となります。

まとめ

• ITU-T X.1367 Standard format for internet of things error logs for security incident operationを紹介した。
• ITU-T X.1367がどのように機能するかを説明した。
• IoTエッジデバイスエラーはそれなりの量が発行されるので、SOCでどのように取り扱うかが課題となる。

謝辞

この勧告の提案は、私が2018年ごろから活動を始め、何度もジュネーブに訪れては国際舞台で英語で議論する貴重な経験を得ることが出来ました。本勧告はNPO日本ネットワークセキュリティ協会(JNSA)の皆様、国立研究開発法人情報通信研究機構(NICT)の皆様、一般社団法人情報通信技術委員会の皆様および株式会社ラックの皆様のご協力の下で採択に至ったものです。ここに改めて謝意を申し上げます。

参考ページ

• ITU-T X.1367: Standard format for internet of things error logs for security incident operation (2020)
• syslog(IETF RFC 5424) (2009)
• WIRED: 走行中のクルマ乗っ取りに成功：「コネクテッドカー」のバグ（動画あり） (2015)
• C.Miller, C.Valasek: Remote Exploitation of an Unaltered Passenger Vehicle (2015)