Jeep Cherokeeの遠隔操作※1に代表される自動車関連の攻撃手法や脆弱性が毎年報告されています。昨今は、自動車の「走る、曲がる、止まる」といった基本機能が「自動で走る、自動で曲がる、自動で止まる、つながる」といった進化を遂げつつあることで、車内有線通信（CANなど）を対象にした直接接続による攻撃だけでなく、無線通信（セルラ、Wi-Fi、Bluetooth など）や車載のリッチOS（Linux、Android Auto）を対象とした攻撃や脆弱性も報告されており、自動車セキュリティの重要性がより一層高まっているように感じます。
※１ Charlie Miller & Chris Valasek, ”REMOTE EXPLOITATION OF AN UNALTERED PASSENGER VEHICLE”, Black Hat USA, 2015.
自動車のサイバーセキュリティの脅威が拡大する中で、車両のサイバーセキュリティに関する国連規則UN-R155が2020年に採択され、セキュアな自動車開発が義務化されることになりました。特に、日本では世界に先駆けて一部の車両型式に本法規が適用され、EUでも2022年7月から一部車両型式に適用が開始されました。国連規則UN-R155と型式認証についてはこちらの記事を参照ください。
自動車サイバーセキュリティのプロセス構築方法｜CS法規対応の勘所
前述の記事で書かれるように、UN-R155ではセキュアな自動車を開発するための体制とプロセスについての要件（Requirement）が書かれています。その一つに、ライフサイクルを通してリスクアセスメントおよびリスクへの適切な対処と管理を行うことが求められています。
具体的には、自動車に想定されるリスクを特定、分析、評価し、その結果に従ってリスクを低減する、取り除く、保有するなどの対処を行うことでリスクを管理することが必要になります。このようなリスク管理の取り掛かりとして、ライフサイクルの初期段階であるコンセプトフェーズでリスクアセスメントを行うプロセスが一般的であり、手戻りの少ない効率的かつ効果的な自動車のセキュリティ開発に結びつくといえます。
本記事では、リスクアセスメントをコンセプトフェーズの開発現場に導入する際の課題とポイントについて説明します。
自動車開発における脅威分析とリスクアセスメント
本題に入る前に、自動車開発のリスクアセスメントについて簡単に触れておきます。リスクアセスメント活動は、ISO/SAE 21434※2の中で、『脅威分析とリスク評価（TARA：Threat Analysis and Risk Assessment）』として要件（Requirement）と推奨（Recommendation）がまとめられています。
※2： 自動車の電気／電子システムのサイバーセキュリティ観点についてまとめたもので、UN-R155に対応する上で参考となる国際規格
TARAはコンセプトフェーズから呼び出されていることが規格で明示されていることから、開発初期段階においてもリスクの対処あるいはセキュリティ対策を導出する重要な活動の位置づけにあります。また、TARAは次の図に示す活動が軸となって構成されています。
図：自動車開発におけるTARAプロセス例
TARAは、一部の車両型式を対象にUN-R155の適用が義務化された2022年現在において、完成車メーカで試行段階、あるいはすでに製品開発に取り入れられていると考えられます。サプライヤ各社も、完成車メーカが実施したTARA結果の裏付け、コンテキスト外開発（先行品、汎用コンポーネント開発など）を想定した活動としてプロセス構築または試行段階にあることが推測されます。
しかしながら、機能安全などの既存プロセスを模すことができる他の活動とは異なり、TARAはセキュリティ特有の活動であることから、開発現場に浸透させることが非常に難しく、セキュリティ経験の浅い設計開発者にとってはわからないことが多いこともあり、課題のある活動といえるかもしれません。
開発現場への導入における課題とポイント
TARAを導入しようとする開発現場では、次のような課題に直面することが推測されます。
- 課題① 手法や考え方が開発現場に浸透しない
- 課題② 脅威の考慮漏れや誤ったリスク評価といったTARA結果の妥当性に関する不安が拭えない
以下では、それぞれの課題とポイントについて考察していきます。
課題① 手法や考え方が開発現場に浸透しない
プロセス文書や手順書を整備し、それらにそって分析や評価を行おうとしたものの、手順書に併記されるサンプルのように進まないといった経験はないでしょうか？
自動車のセキュリティ開発が本格化されて日も浅く十分なノウハウが蓄積されていない状況から、各社の手順書だけでなく、公開されている既存のフレームワークの事例や考え方からヒントを得ようとする開発現場もあると思います。
しかしながら、参考とする既存のフレームワークや実施方法はWebアプリケーションやその他のIT製品を対象としていることが多く、分析事例や考え方をそのまま自動車向けとして参考にできない場合もあります。
手順書に併記されたサンプル通りに進まない例の一つとして、プロセス文書や手順書だけでは、TARA成果物の記載粒度が不明瞭であったり、どこまでの情報を記載すればよいのかわからなかったりといったことがあげられます。例えば、
- 資産を洗い出すために分析対象の情報を定義しようとしたが、どういった粒度でどのような情報を定義すればよいのかわからずに、開始前につまずくことが考えられます。基本的には、ユースケース、機能、データフローといった情報を資産および脅威を洗い出すのに十分なレベルで定義できていればよいといえます。
しかしながら、ここで定義した情報は、詳細攻撃を分析する際の前提情報やリスク対処を考える際の根拠として利用することも考慮する必要があり、運用環境（バックエンドサーバや外部デバイスとの依存関係 など）、既存のセキュリティ機構についても明確にすることが重要になります。
自動車は、セルラ、Wi-Fi、Bluetooth、USB、CAN、Ethernetと多様なインターフェースを有し、リッチOSを搭載するユニット、GW、組込み系など多様なユニットから構成され、診断、EV、OTA、自動運転と多様なユースケースを提供します。そのため、既存のフレームワークから得られる知見だけでなく、自動車特有の情報を定義することが必要になります。
例えば、セルラ通信を利用する場合は、モバイルアプリなどと同様に、サービスプロバイダにより提供されるセキュアな閉域網を利用するといったセキュリティ機構を定義します。その一方で、EVのような自動車特有の例では、チャージングステーションといった自動車特有の環境におけるセキュリティ機構を定義する必要があります。 - どういった粒度でどういった資産を洗い出せばよいのかも悩むかもしれません。リスクを漏れなく洗い出すためには、すべての資産を洗い出すことが必要になります。
しかしながら、細かな粒度で資産を洗い出すと、TARA全体のコストも膨大になりがちです。明確な基準を設定することは難しいですが、妥当な粒度で資産を洗い出すことが重要です。
例えば、資産に関連する被害、脅威、攻撃を思い浮かべながら洗い出すことで、資産の粒度が細かくなり過ぎるのを防げる可能性があります。また、既存のフレームワークを参考にできる場合もあります。
手順書に併記されたサンプル通りに進まない他の例として、リスク対処を検討する際の根拠づけに悩むかもしれません。リスクを保有する場合は、監視や脆弱性管理の目的から、その論理的根拠を残す必要があります。例えば、IT製品などにはなかった自動車特有の「Safety（安全）」の観点から、次のようにリスクを保有する根拠にできる場合があります。
- 根拠例：
フェイルセーフなどの機能安全機構により、適切な時間内に検出と安全状態への移行が可能であれば、従来の故障時同等の安全が確保される
これらの課題は、プロセス文書や手順書から読み解くことが難しく、TARAが現場に浸透しにくい理由と考えます。先達や経験から解決されるものともいえますが、自動車のサイバーセキュリティ開発が本格化してから日も浅く十分なノウハウがたまっていない開発現場もあると思います。
TARAプロセスを現場エンジニアに浸透させるための近道は、自動車向けとして作成されたHEAVENS、EVITAなどから自動車におけるリスクアセスメント手法の考え方と事例を学ぶとともに、他の製品を対象としたフレームワーク、実施方法、評価基準との比較により、自動車特有のポイントを理解することです。
課題② 脅威の考慮漏れや誤ったリスク評価といったTARA結果の妥当性に関する不安が拭えない
TARAが開発現場に浸透したとしても、脅威の考慮漏れや誤ったリスク評価が起きる可能性が完全に取り除かれたとはいえません。その場合、「セキュリティ対策の漏れ」、「過剰なセキュリティ対策」につながる可能性があります。
一つの理由としては、リスクアセスメントがコンセプトフェーズで一度だけ行われる活動になっていることが考えられます。設計仕様が明確になり利用できる情報が増えた場合に、リスクアセスメントを見直すことで、分析や評価結果が現実的なものに近づいていきます。リスクアセスメントが一回限りの活動とならないようなプロセスが必要になります。
もう一つの理由として、自動車に関連する攻撃・脆弱性を設計開発者がイメージできないことが考えられます。例えば、脅威や攻撃を分析する手法として、STRIDE、Attack Tree、5Wなどの体系化したアプローチがありますが、いずれも具体的な脅威や攻撃をイメージできていないと脅威の考慮漏れや非現実的な攻撃、偏った攻撃の導出につながる恐れがあります。また、リスクの過大／過小評価につながる可能性もあります。
リスクを見積もる際は、発生可能性（攻撃実現可能性）を一つの要素としますが、その評価には「攻撃に必要な知識」「攻撃に必要なツール」といった攻撃についての知見を根拠とすることが多くあります。
例えば、Wi-Fi、Bluetooth、CANを対象とする攻撃は、PoC※3、ツール類、手順が公開されていたり、比較的安価に入手できたりすることがあり、専門的な知識や特殊な機器が必要ない場合があります。それとは逆に、公開されている攻撃PoCを製品環境に合わせてカスタマイズしないといけない場合もあります。そのため、攻撃手法やツールについての知識がないと、誤った評価を行う可能性があります。
これらのことから、設計開発者はTARA手法を学ぶだけでなく、自動車の攻撃のトレンドや攻撃の実例に関する知識を獲得することも必要と考えます。公開されている攻撃PoCなどを試行してみて、実際の攻撃パスを理解することも妥当な分析、評価を行う上で必要です。
※3 脆弱性の確認、攻撃実現性を確認するための実証コード
おわりに
本記事では、新型車への適用を皮切りにUN-R155への対応が求められる昨今において、TARAを現場導入する際に生じる課題について考察しました。TARAはセキュリティ特有のプロセスであるため、本記事で触れた課題以外にも多くの困りごとが発生することが考えられます。
このような背景を受けて、株式会社NDIASは自動車分野を中心としたセキュリティサービスを提供する企業として、次のようなサービスの提供を行っております。
- リスクアセスメント研修サービス（2022年9月にサービスリリース）
自動車向けとして提案されたフレームワークの解説、他業界のフレームワークとの比較を通して、自動車向けのTARAのポイントを学ぶことができます。さらに、TARAを試行するグループワークや自動車の攻撃と脆弱性についての解説を教育コンテンツに含めることも可能であり、業務内で実際に活用できる知見の獲得にもつながります。 - 自動車セキュリティ教育
自動車セキュリティに必要となる基礎的な知識と攻撃手法を習得するためのハンズオントレーニングです。自動車の持つインターフェース（セルラ、Wi-Fi、Bluetooth、CAN、NFC、IP）と各ECUを構成するハードウェアとソフトウェアを対象にコースは構成されます。 複雑化する自動車に対するハッキング手法をハンズオンを通して体験しながら学ぶことで、現実にそった脅威分析やリスク評価を行うための知見の獲得にもつながります。 - 開発プロセス構築コンサルティング
UN-R155およびISO/SAE 21434を考慮したプロセス構築をご支援いたします。 特に、コンセプトフェーズのご支援、TARA結果のアセスメントといった経験と車両／ECUセキュリティ評価による自動車の攻撃／脆弱性の知見から、TARAプロセスだけでなく開発現場での導入についてもアドバイザリーとしてご支援可能です。
