自動車サプライヤに押し寄せるUN-R155への対応要求と、取りうる対応策

サプライヤ管理の一環として完成車メーカーからUN-R155へ準拠した運用を求められた場合、当該サプライヤは何をする必要があるのでしょうか。

具体的な要求事項について、UN-R155を俯瞰しながら検討してみましょう。前述の通り、UN-R155では大きくCSMSの確立（7.2章）と、型式認可の取得（7.3章）に分けて記載されており、CSMSに基づき車両開発を行なって型式認可を取得することを完成車メーカーに求めています。

CSMSの確立（7.2章）

要求事項は大きく4つにまとめられます。ここでは細かな点については言及せず大意とサプライヤに求められる可能性がある事項に絞って紹介します。詳細は原文をご確認ください。

1. セキュリティ管理体制の構築
   開発・生産の全フェーズにわたるセキュリティ管理が組織として確実に実施されるための体制構築が求められます。継続的に安定した品質の製品を生み出すにはセキュリティプロセスの明文化に加えてプロセスを実行するための体制構築が必須であるため、サプライヤは完成車メーカーからセキュリティプロセスと体制の定義を求められる可能性が高いといえます。
2. リスク特定・評価・管理及びセキュリティテストプロセスの定義
   • 対象となる車両型式におけるリスクの特定
   • リスクの評価・分類・処置決定
   • リスクが適切に管理されていることの検証
   • 対象となる車両型式におけるセキュリティテスト

   サプライヤの観点での資産やリスク全量の型式レベルの俯瞰は困難であるため、完成車メーカーの定義したリスク対処方針にしたがって実装及びテストを実施することになります。とはいえ、サプライヤは自社開発領域において更に詳細なリスク分析やテストが求められるでしょう。

3. サプライヤ管理プロセスの定義
   サプライヤ由来のリスクを管理することが求められます。この条項が、サプライヤが完成車メーカーからUN-R155に準拠した活動を求められる理由です。Tier1サプライヤの場合、完成車メーカーからの要求に対応しつつ、同時にTier2に対してUN-R155の適用要求を行なう必要があります。
4. 脆弱性／インシデント対応プロセスの定義
   脆弱性が発見された場合、リスクの大きさに応じた適切な対応策を時間内で実施することが求められます。サプライヤにおいては、セキュリティリサーチャーや完成車メーカーからの脆弱性発見連絡に対する速やかな対策提案や、自社開発のソフトウェアに含まれるOSSに既知の脆弱性が新たに発見されていないかの監視といった活動が必要です。この点については完成車メーカーの方針に従うことになりますが、責任範囲やそのコスト負担などは契約事項として明記します。

型式認可の取得（7.3章）

CSMSに従った車両開発が要求されています。具体的な内容の詳細は原文も併せてご確認ください。

さらに、車両セキュリティを網羅的に規定したISO/SAE 21434*2を参照すると上記以外にも、工場で脆弱性が作りこまれないための生産管理が求められています。ソフトウェアをサプライヤ側でインストールした上で完成車メーカーに納品する場合においては、同じく生産時のセキュリティ管理も完成車メーカーから確認される可能性があります。

UN-R155によって完成車メーカーが様々な活動をサプライヤに求める可能性があるものの、完成車メーカーがサプライヤ側に対応と責任を依頼するだけで実現できるような話ではありません。

サプライヤがUN-R155へ対応する際には、以下のような課題が想定されます。

1. 完成車メーカーが提示する膨大な仕様の意図を、サプライヤが正確に汲み取るのは困難UN-R155は大まかな方針を定義していますが、詳細な手順の定義については読み手に委ねられており、認証取得に際してはUN-R155の方針に沿っていることを完成車メーカーが論証しなければなりません。よって、仮に同じシステムに対して各完成車メーカーがリスク分析を行うとしても、リスクの評価は少しずつ違ってきます。対策においても、車両内アーキテクチャの業界標準化が進んでいないため各社各様です。更に、完成車メーカーはサプライヤの自由な提案を求めるために敢えて仕様を曖昧に記載するケースも多く、このような状況で、各仕様の意図をサプライヤが正確に汲み取るのは困難です。よって、効率的な仕様すり合わせが必須となります。
2. 車両全体の情報を持たないサプライヤがリスク分析を行なうのは困難昨今のTier1サプライヤはある程度車両内のまとまった単位で“システム提案”を行なうことが求められます。しかしTier1といえども自社のシステムに関連する情報しか持っておらずリスク分析の範囲は限定的です。車両全体の視点でリスク分析やセキュリティ検査を行えるのは完成車メーカーのみと考えるのが自然でしょう。つまり、車両全体レベルの分析・検査を完成車メーカーが実施し、それを踏まえてサプライヤが各システムに落とし込んでいく連携が必要です。また、自社が担当しない車両システムや完成車メーカーのバックエンドサーバと通信が発生する場合を見込んで、リスク分析のスコープを明確にしておくことも重要となります。
3. 自動車セキュリティの専門家が希少、かつITセキュリティ担当が担当するのも困難自動車セキュリティはカバーすべき範囲が広く、その対象となる項目も膨大であることから、まさに総合格闘技の様相を呈しています。ITセキュリティにおいてもガバナンス、テクノロジー、運用の全領域をカバーする必要がありますが、自動車セキュリティではテクノロジー領域に組込機器開発やCAN（Controller Area Network）などの特殊要素が加わります。よって、車両アーキテクチャ、ECU設計、無線通信などに精通した多様なエンジニアをアサインし、チームとして立ち向かう必要があります。「一体感のあるチームワークで価値を創出する」といった方針を打ち出すのは経営陣の重要な役割です。

上記の課題を解決するには、経営陣のサポートを得た上で、

• 設計・開発・検査・アフターセールスプロセスの変革
• 実行に向けたツール整備
• 教育を含む組織の強化

など、様々な施策を同時、かつ完成車メーカーからUN-R155準拠を求められるまでの限られた時間内で実施することが必要です。

特にTier1サプライヤにはガバナンスを強める完成車メーカーと、より詳細な仕様を求めるTier2サプライヤの間で板挟みの状態になるリスクがあります。こうした事態を避けるには、一定の設計力・技術力を持ち、Tier2サプライヤと一体となってエンジニアリング活動を推進する難易度の高い変革が必要です。

また、上記課題２で記載した通り、ソフトウェア開発を実施するサプライヤではリスク分析を十分に実施出来ない可能性があります。ソフトウェアのリスク対策に対する責任は多くの場合サプライヤ側に発生しますが、セキュアなコーディングは実施可能です。

仮に発注元から明確な仕様が提供されず十分にすり合わせが出来ないという状況になった場合、サプライヤはどういった対応と考慮をするべきでしょうか。まず言えることは、セキュリティ上の責任が自社に対してどのように発生するのかを意識的に把握し、そのうえでUN-R155対応に取り組むことが重要です。