ISO/SAE21434とは - 理数の散策路

概要
章構成

概要

ISO/SAE21434とは、自動車の電気・電子システムに対するサイバーセキュリティ観点でのプロセス定義やリスク管理を定めた国際規格です。2021年に正式発効されており、第三者による認証制度があります。

背景

自動車業界のCASE（コネクテッド・自動化・シェアリング・電動化）の普及によるシステムの高度化、利便性の向上を受けて、サイバーセキュリティの脅威が発生する可能性が高まってきています。

そのため、サプライチェーンを含めた開発から生産、市場での運用など、製品のライフサイクル全体を考慮したリスク管理や、セキュリティレベル向上を担う社内組織の設置が必要となってきています。

国際標準

UNECE（国連欧州経済委員会）の作業部会WP29（自動車基準調和世界フォーラム）は以下の規則を策定しました。

UN-R155	サイバーセキュリティマネジメントシステム（CSMS）車両型式
UN-R156	ソフトウェアアップデートマネジメントシステム（SUMS）車両型式

ISO/SAE21434は、UN-R155で要求されているサイバーセキュリティマネジメントシステム（CSMS）を構築する上での参照規格となっています。ISO/SAE21434への準拠は必須ではありませんが、要件の多くがISO/SAE21434に基づいてCSMSを導入することで適合し易くなります。

日本での UN-R155への適合状況は以下になります。

2022年７月：OTA（無線によるデータ送受信）対応の新型車への適合が義務化
2024年１月：OTA非対応の新型車への適合が義務化
2024年７月：OTA対応の継続生産車への適合が義務化
2026年：OTA非対応の継続生産車への適合が義務化

章構成

ISO/SAE21434は全15の章から構成されます。分類としては、５章～８章がセキュリティマネジメント、９章がコンセプトフェーズ、10章～11章が製品開発（設計）フェーズ、12章～14章が運用フェーズとなります。

セキュリティマネジメント

５～８章は、セキュリティマネジメントシステムを構築するために、組織が取り組むべき内容が要求事項として記載されています。

組織のサイバーセキュリティ管理（５章）

組織のサイバーセキュリティ管理では、設計から廃棄までのライフサイクルの各段階において、適切なポリシ、ルール、およびプロセスを策定します。サイバーセキュリティを組織全体の文化およびガバナンスの一部として確立することを目指します。

プロジェクト依存のサイバーセキュリティ管理（６章）

プロジェクト依存のサイバーセキュリティ管理では、特定プロジェクトのサイバーセキュリティ開発活動のマネジメント要件を扱います。

ソフトウェア開発ではコンポーネントなどを再利用することがありますが、元のコンポーネントで考慮されていない脆弱性を作り出す懸念があります。そのため、流用したコンポーネントが十分なレベルのサイバーセキュリティを達成していることを示す必要があります。

分散型サイバーセキュリティ活動（７章）

サイバーセキュリティ活動の分散では、サプライヤの候補選定や管理、開発フェーズごとの合意および役割の定義、プロジェクトにおける責任範囲の明確化などについて述べられています。

継続的なサイバーセキュリティ活動（８章）

継続的なサイバーセキュリティ活動では、特定のプロジェクトを含め、全ての製品のライフサイクルにおいて、以下のようなサイバーセキュリティ活動の必要性が述べられています。

サイバーセキュリティ監視
サイバーセキュリティイベントの評価
脆弱性分析
脆弱性マネジメント

コンセプトフェーズ

コンセプトフェーズでは、脅威の洗い出しやリスクアセスメントを行うことで、サイバーセキュリティゴールとサイバーセキュリティ・コンセプトを設定します。コンセプトフェーズの流れは以下になります。

アイテム（開発範囲）の定義
サイバーセキュリティ･ゴールの設定
サイバーセキュリティ･コンセプトの設定

アイテムの定義

セキュア開発の対象となるアイテムと運用環境の境界（アイテム境界）を明確にします。運用環境には、車両内部の他のアイテムや車両外部のシステムが該当します。

アイテムの意図した機能（例：保守用など）は、サイバー攻撃に悪用される可能性があることを留意する必要があります。アイテム境界は、サイバー攻撃の入口（アタックサーフェス）となるため、侵入経路（アタックパス）の特定に重要です。

サイバーセキュリティゴールの設定

サイバーセキュリティゴールとは、脅威シナリオから資産を保護するための要件です。脅威分析とリスク評価（TARA、15章参照）を実施し、リスク対応で「軽減」が選択された場合は、このサイバーセキュリティゴールを設定する必要があります。

一方、リスク対応で「共有」または「保持」が選択された場合は、サイバーセキュリティクレイムを設定します。サイバーセキュリティクレイムとは、「共有」または「保持」を選択した根拠で、以降のモニタリングや脆弱性管理の対象となります。

サイバーセキュリティコンセプトの設定

サイバーセキュリティコンセプトとは、サイバーセキュリティゴールを達成するための技術的、運用的なサイバーセキュリティ要求です。サイバーセキュリティ要求は、アイテム内の構成要素（エレメント）に対して設定されます。

製品開発・妥当性の確認フェーズ

製品開発フェーズでは、企画・設計・実装・検証の各フェーズで必要となるセキュリティ施策を定義します。製品開発は以下の流れになります。

セキュア設計
セキュアコーディング
セキュリティテスト
セキュリティ妥当性確認

セキュア設計

設計段階では、セキュリティ・コンセプトに基づいてシステム全体の設計を行います。設計段階で組み込まれた脆弱性は、製品開発全体のコストやスケジュールに大きなインパクトを与えるため、設計段階のセキュリティ品質を向上させることは重要になります。

リスクが許容できるレベルに低減できるまで、セキュリティコンセプト、セキュア設計、脆弱性分析、対策検討のサイクルを繰り返すことによって、設計段階で発生する脆弱性を取り除きます。

セキュアコーディング

ソフトウェアを実装するフェーズでは、設計書に従いセキュアコーディングを行います。セキュアコーディングとは、サイバー攻撃に耐えられる堅牢なプログラムを書くことで、実装段階で発生する脆弱性に対する施策となります。

セキュアコーディングにはコーディングルールが必要になります。自動車業界で一般的に利用される CERT-C/C++ や MISRA-C/C++ などのコーディングスタンダードをベースとし、必要に応じて自社の事情に合わせてルールを策定します。

また、プログラムの堅牢性を確認するため静的解析ツールの利用を検討します。仮に静的解析ツールが「重要度=低」と判定した問題でも、自動車の場合は人命にかかわる被害が発生する可能性があるため注意が必要です。

セキュリティテスト

セキュリティテストでは、上流工程で脆弱性が組み込まれていないか確認を行います。システムレベルのテストには主に、脆弱性診断とペネトレーションテストの２つがあります。

脆弱性診断
上流工程で想定された脅威への対策が適切に実施されているを確認するテストです。想定外の脅威については検出できませんが、チェックリストを作成することが可能で、網羅性があることがメリットとなります。
ペネトレーションテスト
攻撃による達成目標を定め、そのための攻撃（評価）を行うテストです。テスト内容に網羅性はありませんが、攻撃者目線で評価を行うことができ、上流工程での検討漏れを確認できることがメリットとなります。

ハードウェアを対象としたテストの観点は以下になります。

内部のプリント基板などから製品仕様が推定されないか？
デバッグポートなどから内部情報に不正にアクセスされないか？
実装されたソフトウェアの抽出や分析がされないか？

ソフトウェアを対象としたテストの観点は以下になります。

標準インタフェースから不正アクセスされないか？
不要なサービスが起動していないか？
ソフトウェアに既知の脆弱性が存在しないか？

セキュリティ妥当性確認

開発 V モデルの左側のサイバーセキュリティに関する製品仕様と、V モデルの右側の検証活動が対になっています。コンセプトフェーズ（９章）、製品開発（10章）、セキュリティ妥当性確認（11章）の対応は以下の通りです。

【要件・設計】	⇔	【検証・確認】
セキュリティコンセプト（９章）	⇔	セキュリティ妥当性確認（11章）
システムアーキテクチャ設計（10章）	⇔	システムの結合検証（10章）
HWアーキテクチャ設計（10章） SWアーキテクチャ設計（10章）	⇔	HWの結合検証（10章） SWの結合検証（10章）

生産・運用・保守・廃棄フェーズ

製造・運用・保守・廃棄フェーズでは、セキュアに開発された車両をセキュアな状態に保つことを目的として活動します。以下の内容が挙げられます。

製造作業を行う工場に対して、暗号鍵管理システム導入などセキュア化を行う。
ユーザ運用中では、車両に対するサイバー攻撃などの脅威を監視する。
車両に脆弱性などの問題が見つかった場合は迅速な対応（インシデント対応、ソフトウェアアップデート等）を行う。
サポート終了への対応や安全に廃棄できるよう対策を行う。

脅威分析及びリスク評価手法

脅威分析及びリスク評価（TARA、Threat Analysis & Risk Assessment）では、車両にどのような有害性や危険性があるか評価し、脅威から何を守るのか、どの程度の損害が見込まれるのかなど評価を行います。

この15章には、８章の脆弱性分析や９章のセキュリティゴールの設定で必要とされるリスク評価の手法が共通部品として記載されています。脅威分析とリスク評価の流れは以下になります。

資産識別
脅威シナリオ特定
インパクト評価
攻撃経路分析
攻撃実現可能性の評価
リスク値の決定
リスク対応の決定

尚、コンセプトフェーズで具体化できないリスクでも、開発プロセスが進むにつれ明確になる場合があるため、その後の各開発フェーズにおいて繰り返しリスク分析を行い、リスクを管理していく必要があります。

資産識別

保護すべき対象となる資産を定義し、以下の内容を確認します。

サイバーセキュリティプロパティ
セキュリティの３要素である機密性、完全性、可用性を特定する。
ダメージシナリオ
車両や道路の利用者に与える有害な影響を特定する。

脅威シナリオ特定

脅威シナリオとは、対象となる資産と、資産の侵害されるサイバーセキュリティプロパティ、サイバーセキュリティプロパティが侵害される原因（サイバー攻撃など）を特定します。脅威の洗い出しには脅威分析モデル（STRIDE）などが利用されます。

インパクト評価

脅威シナリオのインパクト評価を実施します。インパクト評価は、Safety（傷害度）、 Financial（金銭的ダメージ）、Operational（自動車の機能）、Privacy（車両利用者のプライバシー侵害）の４つの観点に対し、Severe/Major/Moderate/Negligible の４段階で評価します。

重大度	Safety	Financial	Operational	Privacy
Severe	致命的	克服困難で壊滅的	操作不能状態	重大な影響
Major	重度	克服可能な実被害	一機能喪失	深刻な影響
Moderate	軽度または中程度	限定的な資金投入で克服可能な不都合	一部機能の喪失、性能劣化	一定の不都合
Negligible	傷害なし	ダメージなし	影響なし	侵害なし