WP29 CSMSに基づくセキュアな製品開発の実践―製品開発におけるセキュリティ対応の概要

自動運転車の実用化が迫る中、自動車業界では自動運転技術の国際基準を策定し、標準化を進める動きが活発化しています。自動運転自動車の安全性を維持するには、適切なサイバーセキュリティ対策とソフトウェアアップデートが欠かせません。以前はハッキング行為も自動車と物理的な距離が近くなければできませんでしたが、近年は無線通信（Over-The-Air）によるソフトウェアのアップデートシステムを悪用することによる、遠隔地からの攻撃の可能性も指摘されています。

こうした状況を踏まえ、｢自動車基準調和世界フォーラム（WP29）｣では、2016年から国連法規基準についての議論が始まり、2020年6月には自動車サイバーセキュリティに関する国際基準が成立しました。日本でも2021年に道路運送車両法が改正され、2022年7月からは無線によるアップデート機能を持った新規発売車種に対して、車両セキュリティ法規を順守する義務が生じます。さらに2024年7月からは、搭載されている機能にかかわらず、全車種に対して同法規が適用される予定です。

では、自動車OEMやサプライヤーが同法規に対応し、セキュアな製品を開発するためにはどのような点に留意すべきなのでしょうか。今回から4回にわたり、「WP29 CSMS^※1」に適応した製品を開発するにあたってのポイントを、実践的な視点から紹介していきます。

第1回ではセキュアな開発の概要とともに、製品開発時に重要要素となる「脅威分析」と「検証／妥当性確認」について解説します。

セキュア開発の全体像とこれからの課題

最初に、WP29のサイバーセキュリティ法規の要求事項を簡単に紹介しましょう。WP29で規定された法規は、「製品ライフサイクルを包含したCSMSを構築すること」および「サイバーセキュリティに関して十分に考慮できているかを実証すること」を求めています。しかし、具体的に「何を利用し、どのような製造プロセスを構築すればよいか」までは明示されていません。

そのギャップを埋めるものとして活用されているのが、車両サイバーセキュリティに関する国際標準規格「ISO/SAE 21434」です。ISO/SAE 21434には、車両の企画・開発から生産、廃棄まで、製品ライフサイクル全体を包含したセキュリティ確保のための7つの要求事項が示されています。具体的には、設計時の脆弱性分析や実装時のセキュアコーディングなど、サイバーセキュリティ活動のエビデンスを集積することで、必要な品質が保たれていることを証明するというアプローチをとっています。

ISO/SAE 21434は、従来から使用されているV字開発プロセスを踏襲しています。脅威分析とリスクアセスメントを起点とした企画フェーズから、設計・実装・検証確認といった開発フェーズ、生産・運用保守・廃棄といった開発後のフェーズまで、各フェーズで実施する活動を定義しています。

ISO/SAE 21434を満たすうえで重要なのは、最初の要件定義フェーズ（業務プロセスの定義と各製品での実施）で実施する「脅威分析とリスクアセスメント」と、テストフェーズで実施する「検証と妥当性確認」です。なぜならISO/SAE 21434のアプローチは、チェック項目を挙げてそれが守られているかどうかを確認するのではなく、リスクに基づいて想定される脅威を分析し、それに対してセキュリティ要件を決定するからです。ですから、その起点となる脅威分析の品質が、直接的にサイバーセキュリティ品質全体、ひいては製品のセキュリティレベルに直結するのです。

また、WP29の対応の難しさとして挙げられるのが、リスクベースで自らが脅威を特定し、どの程度の対策を講じるかを決定しなければならないことです。「守るべき対象は必要十分か」「対策は十分であり、適切か」といった検証に対し、エビデンスに基づいたロジカルな説明ができるだけの分析を、OEMやサプライヤーが積み重ねていかなければなりません。したがって起点となる脅威分析と、現象であるテスト（検証／妥当性確認）が非常に重要になるのです。

脅威分析とリスクアセスメント

では、脅威分析とリスクアセスメントではどのようなことを実施すべきでしょうか。

脅威分析とリスクアセスメントはセットで考えられており、一般的にはTARA（Threat Analysis and Risk Assessment）と呼ばれ、複数の作業プロセスやクライテリア（評価基準）が求められる活動全般を指します。TARAには会社組織としてどこまで対応すべきかの判断基準を定義する「組織としての方針」と、資産の識別や攻撃パス分析などを実施する「分析プロセス」の2つの側面があります。

組織としての方針を定義するのは経営層の役割です。想定される損害をどのように評価するのか、何をリスクと捉え、どこまで対応していくかという判断は、セキュリティ担当者個人に委ねられるのではなく、会社として共通の基準を策定すべきです。そのうえで経営層はリスクレベルを算定し、何を最優先に対応するのか判断する必要があります。

一方、分析プロセスには専門的な知識やスキルが求められ、活動範囲は広範にわたります。分析プロセスで実行するのは以下の内容です。

資産の識別：開発車両の機能やシステム構造を整理し、守るべき情報資産と機能資産を洗い出す。
脅威シナリオ：識別した資産に対し、起こり得るセキュリティ上の脅威を特定する。その際、必要に応じて各脅威の顕在化条件も分析／整理する。
攻撃パス分析：想定される脅威に対し、誰がどのように攻撃してくるか、その攻撃手法を洗い出す。そして、攻撃を実現するための手順や条件を明確化する。
損害シナリオ分析：脅威シナリオで想定した攻撃を受けた場合、どのような被害が発生し、どの程度の損害を被るかを予測分析する。
サイバーセキュリティ要求事項：攻撃パス分析で洗い出した攻撃手法に対し、抜け／漏れのないセキュリティ対策を講じられるよう要求事項を決定する。

この中で特に重要となるのが、資産の識別と攻撃パス分析です。次回以降は、この2つをどのように実施していくかを詳説していきます。

WP29対応への素朴な質問

質問

WP29対応にはどの程度のレベルで取り組むべきでしょうか。自社の基準が業界全体の基準から著しく逸脱していないか心配です。

回答

現時点においてはWP29対応で「ここまでやれば大丈夫」という基準はありません。なぜならそうした基準は、技術水準や攻撃コードの存在といった周辺環境の変化に応じて変化するからです。ですので、現時点でやるべきことは、各ステップでの検証を積み重ね、「検証しましたよ」というエビデンスを積み重ねていくことです。

将来的に自動運転自動車が世の中に普及すれば、事例をもとに「どこまでやるべきか」という共通認識が生まれるでしょう。個人的な見解ですが、その際に必要になる情報共有の仕組みは、政府が構築するのではと期待しています。PwCとしては、自動車会社やOEMベンダーなどとともに、情報共有を進めていく活動を続けていきたいと考えています。

※1 CSMS（Cyber Security Management System）：サイバーセキュリティに関連するリスクを処理し、自動車をサイバー攻撃から保護するための組織的なプロセス、責任及び管理を明確化したリスクベースアプローチの管理システム。

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

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

詳細はこちら

車両サイバーセキュリティの未来

車両のデジタル革命によって、次世代のモビリティ社会が形作られる一方で、各国の政策や規制により変化の速度が決定されている面があります。その要因の一つがサイバーセキュリティへの懸念です。
車両サイバーセキュリティに関する国際規格や製品ライフサイクルにおける重要論点の解説やクライアントとの対談を通じ、車両サイバーセキュリティの将来をひもときます。

詳細はこちら