日本・欧州・韓国向けに車両を販売する完成車メーカーはWP29(自動車基準調和世界フォーラム)の「UN規則*1」(以下、WP29)への準拠が2022年以降求められます。本稿ではその準拠にあたって自動車サプライヤがどのような協力を求められる可能性があるのかを考察します。要点は以下の3点です。

  • WP29が適用される地域向け車両のECU開発に関わるサプライヤは、完成車メーカーからWP29への準拠を求められます
  • サプライヤがWP29に準拠するには完成車メーカー同様に、プロセス整備・体制立上げ・セキュア開発・セキュリティテスト・OTセキュリティ・PSIRTなど多くの活動に取り組む必要があります
  • Tier1サプライヤであっても車両全体のアーキテクチャを把握できない事は非常に多いパターンです。車両全体のリスク分析や侵入テストは出来ないため、自由な提案を求めてくる完成車メーカーなど関係者の期待値やスコープを明文化する必要があります

自動車サプライヤにとって、WP29は高みの見物で済むか?

自動車に対するハッキングは自動車業界のビジネス自体を脅かす可能性があると述べた本シリーズ企画の第1回『CASE時代の自動車におけるサイバーセキュリティの要諦』にて、自動車向けセキュリティに対する社会からの要請として完成車メーカーはWP29へ取り組むことが2022年7月以降に求められることを紹介しました。今回はその影響をサプライヤの観点でご説明します。なお、本シリーズの各連載記事は、ページ右側「関連コンテンツ」にリンクがまとめられています。ぜひ合わせてご覧ください。

まず、WP29についておさらいします。WP29は国連欧州経済委員会(UNECE)の作業部会29「自動車基準調和世界フォーラム」の略称です。自動車に係る基準の国際調和及び認証の相互承認を推進する組織ですが、直近では2020年6月に成立したサイバーセキュリティとソフトウェアアップデートに関する新たな国際基準(UN規則)を指す場面でも「WP29」の名称がそのまま使われています。

2021年3月時点では、日本、EU、韓国でこの国際基準が各地域の法規として適用される見込みです。「あったほうがよい」という推奨や各社の自主基準ではなく、法規となったことはビジネス上大きな意味を持ちます。

WP29が定めたサイバーセキュリティの要求事項は大きく2つに分けられます。

1つ目は組織に対するもので、自動車のサイバーセキュリティに関するプロセス、責任及び管理を明確にし、車両のライフサイクル全般にわたってサイバーセキュリティの管理を実施するCSMS(サイバーセキュリティマネジメントシステム)の確立を求めています。

2つ目は車両に対するもので、車両を構成する主要要素へのリスクアセスメント、リスク軽減、出荷後車両の保護、車両への攻撃監視などの実施による型式認証の取得を求めています。

ここでのポイントは、CSMS・型式認証ともに、完成車メーカーによるサプライヤ管理の実施を明確に求めていることです。ソフトウェア制御が増え続ける昨今の自動車開発においてはサプライヤがECU(Electronic Control Unit)のソフトウェアを開発することも多く、完成車メーカーはその開発を担うサプライヤを管理する必要があります。一方、外装などを担当するサプライヤであれば車両セキュリティとの関係が限定的であるため多くは求められないと考えられます(ただし、完成車メーカーのスタンスに依存します)。

よって、完成車メーカーへ納入している製品の種別によっては、サプライヤにとってWP29は無関係でない可能性が出てきます。この点については取引先である完成車メーカーの製品セキュリティ担当部門と綿密に連携し、DIA(Development Interface Agreement:開発協働契約書)などによる役割分担の明文化をお勧めします。

サプライヤには、どのような準備が必要か?

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

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

CSMSの確立(7.2章)

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

  1. セキュリティプロセス定義 (7.2.2.1)
  2. 設計開発・量産・アフターセールスの全フェーズにわたるCSMSの確立が求められます。継続的に安定した品質の製品を生み出すにはプロセスが必須であるため、サプライヤは完成車メーカーからセキュリティプロセスの定義を求められる可能性が高いといえます。

  3. リスク分析/対策(7.2.2.2)
  4. 製品開発のエンジニアリングチェーンにおける各フェーズで以下のことが求められます。

    • 対象となる車両型式における資産の特定
    • 資産に対するリスクと軽減策の分析
    • リスクの大きさに応じた対処方針の定義
    • そのリスクが適切に管理されていることの検証
    • 型式に対するセキュリティテスト
    • 対処方針が適切であることの検証
    • 出荷後におけるサイバーアタックの監視の実施

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

  5. サプライヤ管理(7.2.2.5)
  6. リスク分析/対策を、サプライヤ、サービスプロバイダや完成車メーカー子会社での作業においても適用することが求められます。この条項が、サプライヤが完成車メーカーからWP29に準拠した活動を求められる理由です。Tier1サプライヤの場合、完成車メーカーからの要求に対応しつつ、同時にTier2に対してWP29の適用要求を行なう必要があります。

  7. セキュリティ検査(7.2.2.4)
  8. 開発後のテスト及び車両出荷後に開発されたシステムにおける新たな脆弱性発見有無の監視が求められます。現在は完成車メーカー―サプライヤ間でテストケース/テスト結果のレビューが行われていないケースもありますが、今後はテスト結果を求められた際に迅速な提示ができるようサプライヤ側で保存が必要です。特にTier1サプライヤは完成車メーカーへの説明責任が発生するため、Tier2以下を巻き込んだ検査体制/システムの確立が急務となります。

  9. 脆弱性/インシデント情報対応(7.2.2.3)
  10. 脆弱性が発見された場合、リスクの大きさに応じた適切な対応策を時間内で実施することが求められます。サプライヤにおいては、セキュリティリサーチャーや完成車メーカーからの脆弱性発見連絡に対する速やかな対策提案や、自社開発のソフトウェアに含まれるOSSに既知の脆弱性が新たに発見されていないかの監視といった活動が必要です。この点については完成車メーカーの方針に従うことになりますが、責任範囲やそのコスト負担などは契約事項として明記します。

型式認証の取得(7.3章)

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

さらに、車両セキュリティを網羅的に規定したISO/IEC 21434*2を参照すると上記以外にも、工場で不正なソフトウェアをECUに注入されないためのOT(Operational Technology)セキュリティの整備が求められています。ソフトウェアをサプライヤ側でインストールした上で完成車メーカーに納品する場合においては、同じくOTセキュリティの整備状況も完成車メーカーから確認される可能性があります。

サプライヤがWP29対応を行なう際の考慮事項

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

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

  1. 完成車メーカーが提示する膨大な仕様の意図を、サプライヤが正確に汲み取るのは困難
  2. WP29は大まかな方針を定義していますが、詳細な手順の定義については読み手に委ねられており、認証取得に際してはWP29の方針に沿っていることを完成車メーカーが論証しなければなりません。よって、仮に同じシステムに対して各完成車メーカーがリスク分析を行うとしても、リスクの評価は少しずつ違ってきます。対策においても、車両内アーキテクチャの業界標準化が進んでいないため各社各様です。更に、完成車メーカーはサプライヤの自由な提案を求めるために敢えて仕様を曖昧に記載するケースも多く、このような状況で、各仕様の意図をサプライヤが正確に汲み取るのは困難です。よって、効率的な仕様すり合わせが必須となります。

  3. 車両全体の情報を持たないサプライヤがリスク分析を行なうのは困難
  4. 昨今のTier1サプライヤはある程度車両内のまとまった単位で“システム提案”を行なうことが求められます。しかしTier1といえども自社のシステムに関連する情報しか持っておらずリスク分析の範囲は限定的です。車両全体の視点でリスク分析やセキュリティ検査を行えるのは完成車メーカーのみと考えるのが自然でしょう。つまり、車両全体レベルの分析・検査を完成車メーカーが実施し、それを踏まえてサプライヤが各システムに落とし込んでいく連携が必要です。また、自社が担当しない車両システムや完成車メーカーのバックエンドサーバと通信が発生する場合を見込んで、リスク分析のスコープを明確にしておくことも重要となります。

  5. 自動車セキュリティの専門家が希少、かつITセキュリティ担当が担当するのも困難
  6. 自動車セキュリティはカバーすべき範囲が広く、その対象となる項目も膨大であることから、まさに総合格闘技の様相を呈しています。ITセキュリティにおいてもガバナンス、テクノロジー、運用の全領域をカバーする必要がありますが、自動車セキュリティではテクノロジー領域に組込機器開発やCAN(Controller Area Network)などの特殊要素が加わります。よって、車両アーキテクチャ、ECU設計、無線通信などに精通した多様なエンジニアをアサインし、チームとして立ち向かう必要があります。「一体感のあるチームワークで価値を創出する」といった方針を打ち出すのは経営陣の重要な役割です。

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

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

など、様々な施策を同時、かつWP29適用までの限られた時間内で実施することが必要です。

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

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

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

まとめ ――サプライヤが期待に応えるために求められる変革

WP29への対応は完成車メーカーに求められている法規ですが、サプライヤにおいても完成車メーカーの期待に応えるためには大きな変革が求められます。サプライヤの立場から完成車メーカーへ積極的な提案を展開することで、セキュリティ設計における生産性の向上やスコープ管理は可能になります。

2021年の現在は、完成車メーカーとサプライヤ間の役割分担について業界のコンセンサスが出来上がるまでの過渡期であるといえます。現時点において、両者間の認識齟齬に起因するリスクをサプライヤが管理するには、まずサプライヤ側が自社の整備状況を可視化するなどで把握し、果たすべき責任範囲を整理の上で継続的改善に取り組むことが重要です。

Source:

1 UNECE, 2020/6/25, “UN Regulations on Cybersecurity and Software Updates to pave the way for mass roll out of ‎connected vehicles” , 2021/2/20閲覧

2 ISO, “ISO/SAE DIS 21434 Road vehicles – Cybersecurity engineering , 2021/2/20閲覧

ニュースレター
最新コラム・調査をニュースレターで 最新コラム・調査をニュースレターで