IoTエラーログフォーマット標準化について - ラック・セキュリティごった煮ブログ

デジタルペンテストサービス部の木田です。

ハンドル名のウケが悪かったので実名にて失礼します。

はじめに

昨年の10月(2020年10月)にITU-TにてIoT機器のエラーログフォーマットについて標準化が行われX.1367として勧告されました。この勧告においてIoT機器のエラーログフォーマットの標準化ならびにエラーコードの抽象化と標準化が行われ様々なIoT機器で構成される生産施設・工場やビルといった施設に対してSOCでの監視、攻撃兆候の発見、インシデントレスポンスの的確な対応を期待する事が出来ます。今回は、このX.1367勧告についてお話したいと思います。

X.1367とは

www.itu.int

正式には、Standard format for Internet of Things (IoT) error logs for security incident operations と命名されています。この名称のとおりここで定義されているのは以下の2点となります。

IoT機器用の標準化されたエラーコード
ログサーバに送信するためのJSONフォーマットのエラーレコード

エラーコードは8bitで表現されます。以下の図にあるとおり最低限のエラーコードとエラーメッセージの対比のみ定義されています。将来、X.1367のアップデートが必要な場合に拡張用のエラーコードならびにベンダー固有のエラーコードそしてこのエラーコードのいずれにも属さないエラーコードについては別途定義できるようになっています。

f:id:lac_devblog:20210816113216j:plain — X.1367 エラーコード表

f:id:lac_devblog:20210816113239j:plain — X.1367 エラーコード表

JSONフォーマットのエラーレコードは以下の図にあるとおりになります。詳細はまたこの後の章で説明します。このJSONのフォーマットは弊社（株式会社ラック）のJSOCで取り扱えるフォーマットでもあります。

f:id:lac_devblog:20210816113340j:plain — エラーフォーマットのJSONフォーマット

X.1367の目的

IoTエラーログフォーマットの標準化とX.1367の勧告まで推進した目的は以下のとおりです。

SOC/CSIRT/PSIRTでログの分析を可能にし、攻撃兆候の検知をできるようにする

これには、ログの仕様の統一化を行う必要があります。ログの仕様の統一が必要な理由としては次のとおりです。

IoTエコシステムの管理方式ならびにそのネットワーク構成が導入企業毎に異なる。
IoT機器の通信がIPとは限らない。これにより発生する問題として以下。

IPアドレス以外の識別子に因る。
IoT機器の識別が困難。
エラー発生のコンテキストが不明。

製品間のエラーコードの互換性を持たせる

IoT機器を製造しているメーカー（ベンダー）ごとにエラーコードの意味が不明であり、製品間のエラーコードの互換性を持たせる事を可能としています。例えば複数のベンダーからIoT機器を調達する場合、以下のような課題が発生します。

数バイト程度の製品固有のエラーコード。
同一メーカーであっても製品間のエラーコードの互換性は保証されない。

X.1367が想定しているシチュエーション

ここまで述べた仕様を既存のIoT機器に反映するには既に出回ったIoT機器の生産数やIoT機器そのもののリソース、ならびにIoT機器が設置されてからの年数などを考慮するとメーカー（ベンダー）への負担が大きくなります。今後、新しく設置されるIoT機器には上記の仕様が入っていると良いと思われます。ここでは、既存のIoT機器ネットワークにIoTゲートウェイを新たに設置し、そのIoTゲートウェイがIoT機器の異なるログを変換してJSONフォーマットでログサーバに送信することを想定しています。具体的な例として下図のような構成となります。

f:id:lac_devblog:20210816113447j:plain — 想定している構成

X.1367をサポートするIoTゲートウェイはまだ世の中で市販されていません。今後、市場においてニーズが増したときに多く生産・出荷されると想定しています。

事例１

攻撃者が外部から内部ネットワークに侵入し特定のIoT機器が不正コマンドを受診し、その応答として正常なエラーコードを送信しなかった場合。この場合、IoTゲートウェイが侵害されていなければ、IoTゲートウェイが任意のIoT機器が侵害された旨をログサーバに報告します

f:id:lac_devblog:20210816113536j:plain — 事例１の図

このときログサーバに報告する内容は以下のようになります。

f:id:lac_devblog:20210816113631j:plain — 事例１のときのJSONの内容

事例２

今度は、攻撃者が同様の方法で内部ネットワークに侵入しMCU2を改竄しMCU2を経由してIoTゲートウェイが正しく機能しなくなった場合を考えます。

f:id:lac_devblog:20210816113715j:plain — 事例２の図

このとき、IoTゲートウェイから正しいログをログサーバに送れなくなっているので、ネットワークに設置したIDS(侵入検知システム）が異常を察知し、それをログサーバに送信する事になります。

f:id:lac_devblog:20210816113751j:plain — 事例２のときのJSONの内容

おわりに

簡単な紹介におわりましたがIoTエラーログフォーマットが標準化される事によって今まで監視できていなかったIoT機器の監視が可能となり動作が可視化される事となります。それによって設置しているIoT機器の故障にはじまり、外部から攻撃されたときのセキュリティインシデントへの対応もスムーズに行える事となります。2020年10月という比較的最近に標準化された勧告ですが、これから先数百万台と増えるIoT機器の不正対策の一環として全てのIoT機器がX.1367に対応する事で弊社をはじめとする情報セキュリティ企業のセキュリティ監視ならびにインシデント対応の一助になれば幸いです。