LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック
テクニカルレポート | 

IoTエラーログフォーマットの標準化とX.1367勧告で、IoT機器を守る

2020年10月、ITU-T(International Telecommunication Union-Telecommunication Standardization Sector)にてIoT機器のエラーログフォーマットについて標準化が行われ、X.1367として勧告されました。

この勧告において、IoT機器のエラーログフォーマットの標準化ならびにエラーコードの抽象化と標準化が行われました。様々なIoT機器で構成される生産施設・工場やビルといった施設に対して、SOCでの監視、攻撃兆候の発見、インシデントレスポンスの的確な対応を期待することができます。

X.1367とは

X.1367は、Standard format for Internet of Things (IoT) error logs for security incident operationsと呼ばれ、正式に勧告されるまではX.elf-iotの略称で呼ばれていました。エラー・ログという単語から、X.1367は以下の2点について定義されています。

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

IoT機器用の標準化されたエラー・レコードの形式

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

Code Message Description
No Error (0x00-0x0F)
0x00 No Error No error occurs.
Communication (0x10-0x1F)
0x10 No Response No Response even though the request requires any responses.
0x11 Communication Failed Some problems for failing communication.
0x12 Link Down A network interface link is down.
0x1E Extended Reasons Prefix code for extended reasons.
0x1F Other Communication Reasons Other reasons related to communication.
Security (0x20-0x2F)
0x20 Authentication Failed Some problems of the authentication.
0x21 Certification Failed Some problems of the certification.
0x22 Encryption Failed Some problems of the encryption.
0x23 Authorization Failed Some problems of the authorization.

ログサーバに送信するためのJSON形式のエラー・レコードは以下のとおりで、詳細は後ほど説明します。このJSONの形式はラックのJSOCで取り扱えるフォーマットでもあります。

{
      "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|{},
}

X.1367による標準化の目的

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

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

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

  • IoTエコシステムの管理方式ならびにそのネットワーク構成が導入企業ごとに異なる
  • IoT機器の通信がIPとは限らない。これにより発生する問題として以下の3つ
    • 1.IPアドレス以外の識別子による
    • 2.IoT機器の識別が困難
    • 3.エラー発生のコンテキストが不明

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

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

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

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

ここまでに述べた仕様を既存のIoT機器に反映するとなると、メーカー(ベンダー)への負担が大きくなります。既に出回ったIoT機器の生産数やIoT機器そのもののリソース、ならびにIoT機器が設置されてからの年数などを考慮すると、コストがかかりすぎます。そのため、今後新しく設置されるIoT機器には、上記の仕様が入っていると良いと思われます。

ここでは、既存のIoT機器ネットワークにIoTゲートウェイを新たに設置し、そのIoTゲートウェイがIoT機器の異なるログを変換してJSON形式でログサーバに送信することを想定しています。具体的な例として下図のような構成となります。

X.1367で想定している構成

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

事例1

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

事例1の攻撃手口の概要

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

事例1の時にログサーバに報告する内容

事例2

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

事例2の攻撃手口の概要

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

事例2の時にログサーバに報告する内容

おわりに

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

この記事は役に立ちましたか?

はい いいえ