2022年10月にWebセミナー「DX Future Days 2022」が開催されました。
自動運転などの技術が進化する一方、サイバーセキュリティリスクに対応した車の開発が求められています。本セッションでは、自動車のサイバーセキュリティに関する国際規格ISO/SAE 21434および業界での開発モデルのデファクトスタンダードであるAutomotive SPICE for Cybersecurityの特徴や、開発者の立場に応じた活動を進めるためのアプローチについて解説しました。

• 開催日時

  10月19日（水）、10月20日（木）

• 会場

  オンライン開催

• 主催

  株式会社日立ソリューションズ

• 共催

  株式会社日立ソリューションズ東日本、株式会社日立ソリューションズ西日本
  株式会社日立ソリューションズ・クリエイト、株式会社日立ソリューションズ・テクノロジー

新海 良一
株式会社日立ソリューションズ
モビリティソリューション本部　オートモティブソリューション部
主任技師

講演の冒頭で、日立ソリューションズのモビリティ事業の概要を紹介。「ビッグデータの収集・解析などのソリューションをはじめ、豊富な開発経験に基づくコンサルティングや、開発に必要なツール類をパッケージで提供するなど、スマートモビリティ社会の実現のために必要な活動を支援しています」と新海良一は説明しました。

例えば、車と周辺機器の情報をネットワークで連携し、より高度で安全な自動車の制御システムを開発するためのプラットフォームや、独自開発ツールを用いて効率的な開発を支援するモデルベース開発ソリューションを紹介。AIを活用して仕様書などの記載内容を分析、不具合につながるような記載を自動的に抽出するプロジェクト状況可視化システムもその一例です。

また、機能安全やAutomotive SPICE、サイバーセキュリティ規格などへ対応するためのプロセス構築支援やコンサルティングサービス、アセスメントサービスを提供する自動車関連規格準拠支援ソリューションを用意。新海は「組み込み分野の開発経験を生かした開発支援や、最先端技術を活用した幅広い開発環境とツールの提供など、多種多様な製品・サービスを組み合わせ、トータルソリューションを提供する総合的なSI力が当社の強みです」と強調しました。

続いて、車の開発でサイバーセキュリティ対応が重要になる中、日本では、自動車向けのサイバーセキュリティ規格「UN-R155/156」を国内法規として準拠することを表明。2024年7月以降は既に市場で販売されている自動運転車にも適用されるほか、2026年5月以降はすべての車に適用される予定であることを踏まえ、「UN-R155/156の要求仕様では、国際規格のISO/SAE 21434の参照を求める部分もあり、ISO/SAE 21434に対応する開発が重要になります」（新海）と補足しました。

ISO/SAE 21434ではサイバーセキュリティ管理のために、品質管理システムの確立と維持についても要求事項として定義。品質管理を支援する規格として、IATF 16949などとともにAutomotive SPICEが記載されています。これに対して新海は「Automotive SPICE for CybersecurityはISO/SAE 21434との親和性が高く、これらの規格とモデルを組み合わせた製品開発を行っていくことが重要です」と指摘しました。

新海は、ISO/SAE 21434とAutomotive SPICE for Cybersecurityの構造について説明を続けます。ISO/SAE 21434ではアイテム、コンポーネント、サブコンポーネントに分かれた構造であるものの、要求事項のサイバーセキュリティ仕様ではシステム開発、ソフトウェア開発の異なる活動が1つの要求事項の中に定義されています。このため「実開発では、アイテム、システム、ソフトウェア開発といった開発者の立場の違いにより、設計・開発活動が異なることを理解、整理する必要がある」と新海は強調しました。

一方、Automotive SPICEの構造は、システム開発、ソフトウェア開発の各プロセス群が定義されています。ただ、Automotive SPICE for Cybersecurityで新たに追加されたサイバーセキュリティ関連のプロセス群は、システム開発とソフトウェア開発の違いを考慮した構造になっておらず、1つの基本プラクティスの中に定義されています。

例えば、アイテム、システム、ソフトウェア開発レベルで行われるサイバーセキュリティゴールの導出やサイバーセキュリティ要件の導出についても、1つのプラクティスとして定義。そこで、「Automotive SPICE for Cybersecurityにおいても、アイテム、システム、ソフトウェア開発の立場の違いによる異なる活動の整理が必要です。さらに要求事項やプラクティスの記述順序は活動の順序を表すものではないため、開発において活動順序や活動の呼び出し関係を正しく理解する必要があります」（新海）と解説しました。

こうした活動順序や活動の呼び出し関係を理解するためのアプローチとして、プロセスを可視化するPFD（Process Flow Diagram）があります。アイテム、システム、ソフトウェア開発といった異なる立場に応じ、Automotive SPICE for Cybersecurityの基本プラクティス（BP）とISO/SAE 21434の要求事項（RQ）、作業成果物（WP）についてPFDを活用し、情報を整理するというものです。

PFD活用事例として、SEC.1サイバーセキュリティ要件抽出におけるアイテムレベルとシステム開発レベルの違いを説明。「アイテムレベルでは、サイバーセキュリティゴールとサイバーセキュリティ要件の導出を2段階に分けて整理することがポイント」（新海）と加えました。

その進め方は、脅威分析とリスクアセスメントの実施で生成されたサイバーセキュリティシナリオ登録と、アイテム定義を入力情報として、サイバーセキュリティゴールを導出。さらに、そのサイバーセキュリティゴールを入力情報としてサイバーセキュリティ要件を導き出し、アイテムレベルのシステム要件仕様書を作成します。

システム開発レベルにおいては、アイテムレベルで作成されたサイバーセキュリティコンセプトを入力情報として、システム開発レベルのサイバーセキュリティ要件を導き出し、システム要件仕様書を作成。また、アイテムレベルでは脅威シナリオとサイバーセキュリティゴール、およびサイバーセキュリティゴールとサイバーセキュリティ要件との紐付け、システム開発レベルでは、サイバーセキュリティコンセプトとシステム開発レベルのサイバーセキュリティ要件との紐付け、とトレーサビリティ管理の対象物が異なることにも注意が必要です。

そして、Automotive SPICE for CybersecurityのBPとISO/SAE 21434のRQなどをまとめたサイバーセキュリティ対応活動の考慮点を図示。新海は「アイテムレベルとシステム開発レベルの異なる活動をどのように進めていくかが理解できると思います。モビリティに関連する国際規格や開発モデルの対応支援など、お客様のニーズに合わせたソリューションを用意していますので、ご活用ください」と述べ、講演を締めくくりました。