WP29 CSMSに基づくセキュアな製品開発の実践―車載機器に対するファジングテストで押さえておきたいポイント

English

サイバーセキュリティに関連するリスクを処理し、自動車をサイバー攻撃から保護するための組織的なプロセス、責任、管理を明確化したリスクベースアプローチの管理システムであるCyber Security Management System（CSMS）。CSMSは自動車業界に対し、合理的に予見し得る車両のセキュリティリスクに、OEMによる十分な対策が施されていることを実証することを求めています。したがってUN-R155に準拠するには、TARA（脅威分析とリスクアセスメント）によって導き出されたセキュリティ対策に対して、「検証」と「妥当性確認」の2つの観点から「十分な対策の実証」を行うことが必要となります。

「検証」と「妥当性確認」には、脆弱性テストやペネトレーションテストなどがあります（「WP29 CSMSに基づくセキュアな製品開発の実践―脆弱性テスト／ペネトレーションテストの実践とポイント」参照）。これらのテストはさまざまな手法の組み合わせで実現されますが、本稿ではソフトウェアに潜む既知もしくは未知の脆弱性を発見するために、仕様外の動作を検出する手法である「ファジング」について紹介します。

車載機器に対するファジングの実践ポイント

ファジングを実施するにあたり、対象となる機器やソフトウェアに応じて検討しなければならないポイントがいくつかあります。これらは実施することが難しいだけでなく、開発者とテスト実施者、OEMとサプライヤーの間におけるミスコミュニケーションの発生につながる可能性があるため、注意が必要です。ここからは、ファジングを実践するにあたって、これらのステークホルダー間で共通認識として持っておくべき、あるいは合意しておくべきポイントについて解説します。

ファジング対象の選定

ファジングの対象や実施方法によっては、自身が開発および修正に関与していないプロトコルスタックやSoC（System-on-a-Chip）のファームウェアが異常検出の原因となることもあり、この場合の原因分析や修正対応はサプライヤー単独では困難となります。

そのため、ファジングを行う対象はサプライヤー自身が開発し、原因分析や修正対応が可能なソフトウェアとするべきです。一方でサプライヤーは、自身が開発していないソフトウェアをファジングの対象とする必要がある場合や、こうしたソフトウェアが原因と断定できる異常を検出した際の対応方針について、OEMと事前に合意しておくことが重要です。

テスターに与える情報

開発者は、ファジングを実行する前にテスターに対してどの程度情報を与えるか、検討しておく必要があります。テスターに与える情報に基づいた分類には「ブラックボックス」「グレーボックス」「ホワイトボックス」があります。

車載機器に対するファジングは、ソフトウェアの実装を把握していない「ブラックボックス」を前提としています。ファジングの手法の中には、前提知識を全く入力しない状態でランダムデータを入力するような手法もありますが、テストの効率は決して高いとは言えません。そのため、ファジングを効率的に実行するためには、実際はCANメッセージ仕様など、ソフトウェアが扱う非公開のプロトコルやデータ構造などを一部理解した上で行う、「グレーボックス」で実施されることが多いと考えられます。

「グレーボックス」によって機能に対応するソフトウェアがどのようなプロトコルおよびデータを解釈するのかを把握することは、テスト効率の向上に寄与するだけではありません。ソフトウェアの実装や弱点を推測し、考慮したファズデータ設計の高度化に寄与するほか、冒頭で述べた「対象機能が正しく実装されていること」をファジングによって確認したことを示す上でも効果的です。

テスト実施環境の検討

車載機器は単独で動作するものもありますが、多くの場合はCANバスをはじめとしたネットワークに接続されており、他のECU（Elecreic Control Unit）やセンサーなどと相互通信することで動作しています。そのため、ECUの仕様によっては、こうした周辺機器が正常に動作していないと正しく動作しない場合があります。したがって、テストを実施する際は、ECUが正しく動作する環境を整える必要がある場合があります。開発フェーズにもよりますが、大きく分けて以下の3つの環境が考えられます。

上記のうち、完成車両でテストできるのは原則OEMのみと考えられます。またテストベッド環境も、接続するハードウェアによっては、テストを行う場所や移動方法など、テスト環境のモビリティに影響します。
ファジングは対象となる機器のソフトウェアをテストするために、機器に対して直接的に入力し、出力を観測することから、完成車両や一部の物理接続による環境は接続用のハーネスや対象機器の搭載位置などがこれらを阻害する可能性があります。そのため、アクチュエータの表面的な動きから機械的に異常を判断することは容易ではありません。したがって、物理的な機器でなければ対象とするECUが正しく動作しないということが明確でない限り、ファジングはシミュレータを用いた周辺環境を再現したテスト環境で十分に対応できると考えられます。

シミュレーション環境は、周辺機器を含めたシステムが一定の条件を満たさないと動作状態にならない場合に、その条件を満たした状態を容易に作り出すことができ、こうした環境を設定ファイルなどにより共有することも可能です。一方で、テスターがシミュレータを保有していない場合に、ハードウェアも含めたシミュレータをテスターに提供することが可能かどうか、事前に検討しておく必要があります。

死活監視方法の検討

ファジングを実施する上で重要なポイントとなるのが、機器異常の観測（死活監視）方法です。ファジングは機器の振る舞いから異常を判断するため、製品によってはその仕様に合わせた監視方法を選択する必要があります。例えば、CANインタフェースを持つ制御用ECUに対してファジングを行う場合、異常と判断する要素として、以下のような事象が考えられます。

• 周期送信メッセージが途絶えた
• 周期送信メッセージの周期が閾値を超えた
• 応答を伴うメッセージに対して期待値とは異なる応答があった
• 応答を伴うメッセージに対して応答がタイムアウトした

ECUがアクチュエータなど何らかの制御機能を持っている場合、その機能の信号線を観測する方法を考えることもできます。この場合は、対象に合わせた測定器（例：オシロスコープ）が別途必要になる場合もあります。

また、死活監視方法が適切であるかどうか、留意する必要があります。極端な例ですが、TCP/IPを利用するアプリケーションに対してファジングを行う際に、ICMP Echoによる死活監視を行っても、ICMPはアプリケーションよりも下位のレイヤーで動作している別のソフトウェアによって実現されているため、アプリケーションの異常（例：プロセスの異常終了）を正しく検知することはできません。

異常が発生した際のオペレーションについて検討しておくことで、より効率的にテストを進めることができます。通常、異常を検知したツールはその時点で動作を停止します。なぜなら、原因にかかわらず、異常が確認された時点でそのソフトウェアは正しい状態ではない可能性が高いためです。テストを再開するためには、機器やプロセスの再起動といったオペレーションが必要となりますが、これらも、対象によっては自動化を検討できる場合があり、ファジングの実行に必要な工数をさらに削減することが期待できます。異常時におけるオペレーションを自動化できれば、ツール単独でテストを実行できるため、多くのファズデータを入力しなければならないなど、単純に入力時間を要するテストのようなケースには特に効果的です。

境界値テストとの違い

ファジングにおいて設定する値の中には、単体・結合テストに用いられる境界値テストで使用される値が含まれることがあります。一方でファジングは開発者が意図しないソフトウェアの異常な振る舞いを発見することを目的としていることから、値の設定思想が境界値テストとは異なります。例えば、境界値テストの同値クラス分類では、ソフトウェアの出力変化が指標となりますが、ファジングの場合は、ソフトウェアがデータをどのように解釈するかを考慮した値を指標とします（桁あふれが起こる前後の値や書式文字列など）。したがって、境界値テストとファジングテストで重複するデータを用いることケースもありますが、これらは本質的には異なるテストと言えます。

ファジングの結果と役割分担

前述のとおり、ファジングはデータ構造やソフトウェアがデータをどのように解釈するかを考慮して行われます。しかし、原則として可用性レベルでしか異常を判断することができないため、任意コードの実行や機密情報の漏洩などへの悪用可能性について判断することはできません。これは、ファジングは入力に対して得られる出力により、異常を判断しているということに起因します。

例えば、あるファズデータによってプロセスが強制終了した場合、機器の表面上の振る舞いとしては、プロセスが終了したことにより、該当する機能からの応答が得られなくなったということであり、これによって異常を判断します。しかしその事象が発生した原因には複数の要因（例：リソース不足、メモリ破壊、設計ミスによって仕様外の終了条件を満たした）が考えられ、これらを表面上の振る舞いから判断することはできません。

したがって、異常動作に対する原因調査とその結果に基づいたトリアージや、異常動作の原因が任意コード実行などのリスクの高い攻撃可能性を含んでいるかどうかなどを調査するためには、機器のデバッグ情報など、さらなる解析や分析のための追加情報が必要になります。

これらの対応は、根本的な原因箇所を把握するためにソースコードを確認できる、機器の開発者が行うことになります。したがって、事後の調査をするためにも、ファジングにより異常が検出された際は、テスターはその再現性を確認しておくことが重要です。ただし、メモリリークやレースコンディションのような、時間経過やタイミングによって起こる問題が原因の場合、特定のファズデータでは異常が発生せず、再現性が安定しない場合があります。異常が発生するファズデータがすぐに特定できないような現象が発生した場合は、開発者とテスターが連携し、再現性や原因を特定する作業を行った方が効率的なケースもあります。

WP29 CSMS対応ツール活用メリットを2分で解説

自動車に関する国際法規であるWP29 UNR155に適合するため、車両OEMとサプライヤーは、適切なサイバーセキュリティ要件を導出し、それを満たす製品を開発することが求められています。PwCが提供する「WP29 Cyber Security Management System（CSMS）支援プラットフォーム」は、セキュアな製品開発において最も重要である脅威分析を効率的に実施するためのウェブツールであり、脅威や攻撃に関する最新の情報を提供します。

詳細はこちら