Technical Information
車載セキュリティテストに関するベリサーブの取り組み
自動車業界はCASE（Connected, Autonomous, Shared & Services, Electric）の時代を迎え、クルマとその周辺システムの開発は複雑化が進み、セキュリティに対するリスクも増大しています。
ベリサーブでは2005年からセキュリティ事業を展開しており、車載システム関連についても日々充実を図っています。図1は、クルマの開発を取り巻く状況と当社のサービスを図式化したものです。品質向上と効率向上というお客様のご要望に対して、プロダクト品質支援、プロセス品質支援、そして三つ目のサービスとして、セキュリティ支援を提供しています。
このようなサービスを提供するに当たり、経済産業省の情報セキュリティサービス基準審査登録制度に申請し、審査登録委員会の審査を経て一定以上の品質を満たした脆弱性診断サービスの提供ベンダーとして登録しています。またセキュリティに関するサービスを提供する部門において、情報セキュリティマネジメントシステムの認証規格であるJIS Q 27001:2014 （ISO/IEC27001:2013）認証（ISMS認証）を取得しています。
株式会社ベリサーブ
ソリューション事業部
長谷川 邦幸
自動車業界については、最近の傾向として、サイバーセキュリティに関する協定規則（UN-R155）への適合およびISO/SAE 21434への準拠に関するご相談を多くいただいています。
2020年6月、国際連合欧州経済委員会自動車基準調和世界フォーラム（WP29）においてUN-R155が採択されました。
日本においても、UN-R155に適合するための法改正があり、無線によるソフトウェアアップデートに対応した新型車両については2022年7月から適用されます（継続生産車は2024年7月から適用）。
また、車両電気電子（E/E）システムの開発に関わるOEM、サプライヤー向けのサイバーセキュリティのガイドライン規格として、
ISO/SAE 21434:2021が2021年8月31日に発行されています。
本講演は、UN-R155認証取得の手段として多くの企業が適合を進めている自動車のサイバーセキュリティに関するISO/SAE 21434という規格の概要より、セキュリティテストの位置付けを確認し、その具体的なテストの手法であるペネトレーションテストとファジングについて、当社の実践例をご紹介したいと思います。
※この記事は、『ベリサーブ オートモーティブ カンファレンス 2021』の講演内容を基にした内容です。
ISO/SAE 21434の概要
ISO/SAE 21434※1 では、クルマの企画から製品開発、運用、廃棄に至るライフサイクル全般に及ぶサイバーセキュリティ要求が定義されています。1～4章が概要、5～15章が要求事項という構成になっており、これを実際のライフサイクルとの関係性に合わせてマッピングしたのが図2です。
開発のフェーズに特化した部分を少し掘り下げてみましょう（図3）。まず9章のコンセプト（Concept）には、OEMがクルマを企画する際の要求が定義されています。「9.3 アイテム定義」では、車両の中のアイテム、例えば自動運転などを定義し、その機能やアーキテクチャを考えます。次の「9.4 サイバーセキュリティゴール（Cybersecurity goal）」では、アイテムに対して脅威分析・リスクアセスメントを実施してリスクに対する必要な対策と目標を設定し、最終的に「9.5 サイバーセキュリティコンセプト（Cybersecurity concept）」で機能サイバーセキュリティ要求（FCR：Functional cybersecurity requirement）を作成します。
OEMが作成したFCRが自社の開発部門もしくはサプライヤーに渡り、10章の製品開発フェーズに入ります（図4）。「10.4.1 設計」では、FCRの実装を考慮した技術サイバーセキュリティ要求（TCR：Technical cybersecurity requirement）を作成しますが、この際に脆弱性分析を実施します。ここでは、攻撃の経路を検証する攻撃経路分析、攻撃実現可能性の評価などを実施し、リスクに応じて設計の見直しを行います。
設計においてサイバーセキュリティ面で問題がないと判断したら実装に移り、「10.4.2 統合及び検証」でセキュリティテストを実施します。ここでは5種類のテストが定義されていますが、本講演では名前だけではその内容が想像しづらいと思われるペネトレーションテストおよびファジングについて詳しく解説します。
※1：本記事のISO/SAE 21434の日本語訳については、以下の日本規格協会の訳を参考にしている。
ISO/SAE 21434:2021 自動車-サイバーセキュリティエンジニアリング
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=ISO%2FSAE+21434%3A2021
ペネトレーションテスト
ペネトレーションテストは攻撃者の視点からシステムを調査し、実際に侵入を試みるテスト手法です。図5は、アメリカ国立標準技術研究所（NIST）の「SP 800-115 Technical Guide to Information Security Testing and Assessment」からの引用で、テストのプロセスを示しています。最初に攻撃の計画を立案、システムの弱点を探索して攻撃を行い、その結果を分析して攻撃を繰り返し、脆弱性を検証します。
ペネトレーションテストは、必ずしもブラックボックスで行う必要はありません。「ISO/SAE 21434 Annex E サイバーセキュリティ保証レベル」では、攻撃者はターゲットに対してある程度の知識を持っていると想定しています。また、攻撃者側にはある意味無限に時間がある一方、お客様やベリサーブのようなベンダーはテストの時間が限られています。そのため、攻撃者が時間をかければ見つけられるレベルの情報は事前に開示し、その上で攻撃を実施するグレーボックステストというのが、一番費用対効果が高いと私たちは考えています。
出典：アメリカ国立標準技術研究所 情報セキュリティテスト、アセスメントの技術的ガイド
（https://csrc.nist.gov/publications/detail/sp/800-115/final）を元に一部加筆
ペネトレーションテストの実践例
ここからは、車両のECUを対象としたペネトレーションテストの一例をご紹介します。クルマからECUを抜き取り、さらに中の基板からチップを外してファームウェアを抽出し、ファームウェアから得た情報をもとに攻撃を行うことを想定しています。
ファームウェアの抽出
チップを外すための道具としてヒートガン、はんだごて、ペンチ、ピンセットを用意します。まずヒートガンで基板に熱を加えてハンダを溶かし、チップを分離します。チップの接合面に汚れが付いていると読み取りに支障が出るため、なるべくキレイにしておくのも一つのポイントです（図6）。
チップをアダプターにセットし読み取り装置に取り付け、USBでPCと接続し、ツールを利用してファームウェアを抽出します（図7）。
ファームウェアの解析
図8は、セキュリティテストによく使われる「Kali Linux」の画面で、ここに含まれる「binwalk」というツールでファームウェアのイメージファイル※2 を解凍しファイル・ディレクトリの一覧として表示しています。この図では重要な設定ファイルなどが配置されることの多い
”/etc”というディレクトリの内部を表示しています。当該ディレクトリに存在するテキストファイルに機微な情報が含まれていればこの時点で読めてしまいますし、また、バイナリファイルを入手して中身を解析することも可能です。
※2：外部記憶装置に保存されているすべての内容を、ディレクトリ構造を保ったまま一つのファイルとしてまとめて保存したもの
脆弱性調査とエクスプロイトコード
ファームウェア内のファイルが入手できたら、脆弱性を見つけてエクスプロイト（攻撃）コードを作成し、実際に攻撃を試みます。システムの脆弱性調査の場合、スクリプトファイルを解析して得られた暗号化アルゴリズムから復号用のスクリプトの作成や、パスワードを暗号化して記述しているシャドウファイルが見つかればブルートフォース（総当たり）攻撃を実行するなどして、パスワードの解析を試みます。
バイナリファイルに対しては、同じアーキテクチャ上で動作させデバッガで解析することもできます。また、Hex-Rays社の「IDA Pro」というツールを使ってアセンブリコードから脆弱性を探したり、バイナリファイルに含まれるOSS（Open source software）をSynopsys社の「Black Duck」などのツールで特定し、既知の脆弱性について検索したりして、見つかった脆弱性を利用した攻撃を行います。
ファジング
既知の脆弱性というのは氷山の一角に過ぎず、実際にはそれをはるかに上回る数の未知の脆弱性が存在します。ファジングは、こうした未知の脆弱性、潜在的な脆弱性を発見するためのテスト手法です。
具体的には、ファズ（予測不能な入力データ）をシステムに与えて意図的に例外処理を発生させ、その挙動を確認します。
ファズの例としては、プロトコル上の標準や製品の仕様を満たさない、あるいは違反するデータで、極端に長い文字列や上限を超えた数値、許可されていない特殊文字などが挙げられます。
ファジングの種類と検出できる問題
ファジングで代表的なのはプロトコルファジング・ファイルファジング・APIファジング・UIファジングの四つで、いずれも要求された仕様を逸脱するデータを投入するものです。このうちプロトコルファジングについては、業界ごとにさまざまな通信プロトコルが使われているため、製品でどのようなものが使われているのかを把握しておくことが大事です。
図9は、Ari他（2018）の「Fuzzing for Software Security Testing and Quality Assurance, Second Edition」p.29 のFigure1.10に記載されたファジングで検出できる問題の一覧です。実際のテストではcrashes（クラッシュ）やDenial of Service（DoS、サービス拒否）、つまりプログラムやシステムが異常終了もしくは無反応になる、といったものが多くを占めます。
※参考：書籍「Fuzzing for Software Testing and Quality Assuranse, Second Edition」p.29
ファジングを実施する前に検討すべき事項
ファジングについては、対象とするインターフェース、送信するファズの内容、結果の判定方法が重要なポイントとなります。
対象インターフェース&プロトコル
機器の持つインターフェースを列挙し、検討漏れがないようにします。また、そのインターフェースで使われるプロトコルに違反し例外を出す必要があるため、プロトコルの仕様も確認します。
ファズデータの種類
ファズデータはツールでの生成も可能で、車載関連ではSynopsys社の「Defensics」などが多く使われています。適切なデータを生成するために、ツールに任せるだけではなく、人の観点での補足も大事です。
監視方法
どのような問題を検出するのかを事前に決めておくことが重要です。監視にもツールを利用できますが、自動での判定には限界があるため、やはり人による確認が必要になります。一般的には三つの方法があります。検出する問題について最適なものを組み合わせることをお勧めします。
- ●システムモニタリング（システム内プロセス、ログの監視）
⇒ 検出する問題：クラッシュ - ●リモートモニタリング（ネットワーク応答の監視）
⇒ 検出する問題：サービス拒否、性能低下、応答遅延、機密情報の漏洩 - ●アプリケーションモニタリング（デバッガなどによるアプリ操作の監視）
⇒ 検出する問題：改ざん、破棄、異常
脆弱性スキャンとの違い
脆弱性スキャンは既知の脆弱性を発見するのが目的で、入力インターフェースやコンソール内でのスキャンを実行します。一方、ファジングは未知の脆弱性の発見を目的に、入力インターフェースに対して例外データを送って反応を確認します。この点が二つのテスト手法の違いです。
ファジングテストの実践例
図10は、実際のファジングテストの様子です。「Defensics」が動作するPCをターゲット機器とアダプター経由で接続し、ファズを送信して反応を確認します。アダプターを交換することで、さまざまな機器のファジングが可能です。
おわりに
図11は、ISO/SAE 21434の要求とベリサーブが提供するサービスの対応表です。全体的なコンサルティングからPSIRT支援、個別の脅威分析・脆弱性分析やテスト支援まで幅広く対応していますので、ご興味がございましたら、ぜひお声がけいただければ幸いです。当社の35年以上に及ぶ検証分野での実績と技術を生かし、今後も品質・安全・セキュリティの三つの要素を守るため、より良いサービスを継続的に開発・提供していきます。
この記事をシェアする
