ISO/SAE 21434について

Clause 1:スコープ

第1節では、道路車両にどのタイミングで規格が適用されるかについて規定している。
また、最後にサイバーセキュリティに関連する特定の技術については規定していない旨が明記されている。

Clause 2:規範的参考文献

第2節では、ISO/SAE 21434が参考にしている文献が明記されている。
具体的にはISO 31000とISO 26262 のClause 3である。
Clause 3で説明している用語はISO 31000を参照している。
またClause 5のサイバーセキュリティリスク管理もISO 31000を準拠する旨の要求がある。
ISO 26262はサイバーセキュリティ評価やリスク評価の要求として参照されている。

Clause 3:用語と略語

ここでは規格内に使用されている用語と略語について解説されている。
定義次第では規格策定者の意図と異なる方向に誘導されることや理解の相違につながる可能性があるのでClause 3は重要である。一般的な用語や略語と、ISO/SAE 21434で使用されている用語の定義が異なる場合があるので注意して用語と略語を確認頂きたい。

Clause 4:一般的な考慮事項

第4節ではISO/SAE 21434を適用するにあたって考慮するべき点が記載されている。
例えば、サービスパーツを含む、道路車両内または道路車両に関わるサイバーセキュリティ関連のアイテム及びコンポーネントがISO/SAE 21434の対象で、車両外のシステムは対象ではないことや、CSMS(Cyber Security Management System)がサプライチェーン全体に適用されることなどが示されている。

Clause 5 : 全体的なサイバーセキュリティ管理

第5節ではサイバーセキュリティ開発活動を可能にするためには、まずは組織としての管理体制を構築する必要があることが記載されている。
組織の全体的なサイバーセキュリティ管理はISO 31000(リスクマネジメント規格)に準拠することを要求される。また、組織のサイバーセキュリティ監査は独立性を要求されており、品質管理規格に準拠した監査に含めることができる。管理システムとしては、問題管理、変更管理、文書管理、構成管理、要件管理、サプライヤー管理、リスク管理をサポートする為の国際標準または同等の基準(Automotive SPICE?等)に従って管理システムを確立及び維持することを要求される。最後の節としてはツール管理についての要求としてサイバーセキュリティに影響を与える可能性のあるツールを管理することと、サイバーセキュリティインシデント対応の修復アクションをサポートする為の適切な環境が再現可能であることを求められる。

Clause 6 : プロジェクト依存のサイバーセキュリティ管理

第6節はプロジェクト依存のサイバーセキュリティ管理についての要求の説明が記載されている。
プロジェクトに依存するサイバーセキュリティ管理には責任の割り当てと、理論的根拠に基づいたサイバーセキュリティ計画で定義されている再利用、コンテキスト外の開発といった調整が適用できる。
また、サイバーセキュリティ計画で定められたタイミングで、サイバーセキュリティ評価がアイテム又はコンポーネントに対して実行されるかどうかを決める為に、理論的根拠に基づく判断が行いを実施することを要求される。サイバーセキュリティ評価は独立して実施するため、責任者は組織内の品質保証部門の人、別のチーム又は部門の人、または独立した第三者のいずれかが実施する。
最後の節で開発後のリリースはサイバーセキュリティ評価と開発後のフェーズのサイバーセキュリティ要件が特定されレビューが実施されていることが承認の基準である。

Clause 7 : 継続的なサイバーセキュリティ活動

第7節は全てのライフサイクルのフェーズで実行する、継続的なサイバーセキュリティ活動の要求事項について規定している。具体的な活動内容は、サイバーセキュリティ監視とサイバーセキュリティイベントの評価、脆弱性分析、脆弱性管理の4つである。
この活動には、アイテムとコンポーネントの考えられる緩和策サイバーセキュリティ情報を収集することと、収集したサイバーセキュリティ情報をトリアージすることが目的の一部として定められている。この活動はClause.5や9、10と組織のサイバーセキュリティ管理やコンセプトフェーズ、開発フェーズの成果物を入力とする場合がある。

Clause 8 : リスクアセスメント手法

第8節は組織がサイバー攻撃よって利害関係者が影響を受ける可能性のある範囲を決定するための手法を説明している。ここでいう利害関係者は道路利用者として定義されている。説明されている手法は、資産(サイバー攻撃から守るべき情報および機能としてのアイテム)の特定と脅威シナリオの特定、脅威の評価(損害の大きさを定める)、攻撃パス分析、攻撃の実現可能性の評価、リスクの決定、リスク対策の決定である。
まずは資産の特定でアイテム定義を作成し、その定義に基づき作成した作業成果物ベースで脅威シナリオを導く。導出された脅威を安全性、財務、運用、プライバシーの独立した影響カテゴリ(S,F,O,P)で分けた後に4段階(Severe , Major , Moderate , Negligible)で影響を評価する。また、アイテム定義と脅威シナリオを分析し攻撃パスを特定する。次に特定した攻撃パスから実現可能性を評価する。評価方法は共通脆弱性評価システム CVSS ( Common Vulnerability Scoring System)などが推奨されている。リスクと実現可能性の評価が完了すると、評価した影響と攻撃パスを基にリスクを決定する。ここでは5段階(1が最低で5が最高のリスク)に分けてリスク値を決定する。最後にここまで分析し評価してきた作業成果物を用いてリスクへの対応を決める。対応は回避、軽減、共有もしくは移転(保険)、保持が要求されている。

Clause 9 : コンセプトフェーズ

第9節では実際のプロジェクトでISO/SAE 21434の規格を適用する流れが書かれている。
ISO 26262で言うPart.3に似た内容となっており、Clause.8で書かれているリスクアセスメント手法を用いて最終的にアイテムレベルでのサイバーセキュリティ目標(ゴール)とサイバーセキュリティ要件(コンセプト)を決定し、アイテムまたは運用環境に割り当てることが要求されている。ただし、ISO 26262に準拠した機能安全などのべつのプロセスで作成したアイテム定義の範囲や他アイテムとの境界とは異なる場合があるので注意する必要がある。
コンセプトフェーズで作成された作業成果物は以降のフェーズの開始地点となるので、重要なものである。

Clause 10 : 製品開発フェーズ

第10節ではVモデルの左側に該当する設計領域から右側に該当する統合及び検証について規定している。第9節で割り当てたサイバーセキュリティ要件と上位レベルからのアーキテクチャ設計を開発レベル(システムレベルやハードウェアレベル、ソフトウェアレベル)に適用する。そして開発レベルに合わせたサイバーセキュリティ要件とアーキテクチャ設計を脆弱性分析することで、脆弱性を特定、管理し、サイバーセキュリティ要件とアーキテクチャ設計を改良することで洗練されたサイバーセキュリティ要件とアーキテクチャ設計を作成する。脆弱性分析を繰り返すことで洗練されたサイバーセキュリティ要件とアーキテクチャ設計は次に統合と検証が実施される。ここでは設計の実装とコンポーネントの統合が、洗練されたサイバーセキュリティ要件とアーキテクチャ設計に準拠しているか確認する。
システムレベルでの車両との統合や検証が含まれる場合もあるので注意する必要がある。
また、このテストで脆弱性が特定された場合は、Clause.7に則って管理する。

Clause 11 : サイバーセキュリティ妥当性確認フェーズ

第11節は車両レベルでのアイテムのサイバーセキュリティ検証のための活動について規定されている。この活動は、ドメインレベルのコンポーネント統合(Clause.10)が完了した後に実施する。生産および運用車両を想定した確認の為、この時使用する車両は生産車両相当でテストする必要がある。
ここではサイバーセキュリティ目標とサイバーセキュリティコンセプトの検証、アイテムがサイバーセキュリティ目標を達成しているかの検証、残留リスクが今日可能であることを確認することが目的である。
仮にここでサイバーセキュリティ目標が未達、もしくはリスクが許容範囲ではない場合はコンセプトフェーズもしくは製品開発フェーズからやり直す可能性がある。

Clause 12:生産

生産には、アイテムまたはコンポーネントの製造、組み立て、または構成が含まれる。
第12節では開発後のサイバーセキュリティ要件がアイテムまたはコンポーネントに適用され、アイテムまたはコンポーネントが生産中に悪用されないように、脆弱性が追加されないようにするために生産管理計画を策定する。
計画の内容は本番環境に割り当てられた開発後のサイバーセキュリティ要件や、それを達成するために必要な設置手順の概要、達成しているかを確認する方法、不正な変更を防ぐためのコンポーネント保護対策の説明などが要求されている。

Clause 13:運用と保守

第13節ではサイバーセキュリティインシデントの対応と更新についての要求がされている。サイバーセキュリティインシデント対応は、組織がサイバーセキュリティイベントに対応するときに発生する。ただし、サイバーセキュリティイベントがインシデントのレベル未満の場合は第7節に従って管理すること。
また、更新は開発後のアイテムまたはコンポーネントのハードウェアまたはソフトウェアに加えられた変更である。組織は脆弱性が見つかった時や機能の改善、安全性に問題があった場合、更新を発行することができる。ただし、コンセプト、開発、産フェーズでの更新は変更管理で実施することも可能性である。

Clause 14:廃車

廃車の措置は、アイテムまたはコンポーネントのライフサイクルの一部であり、コンセプトフェーズまたは開発フェーズで検討する必要がある。
廃車はサポート終了とは異なる。ここでの目的はアイテムまたはコンポーネントを安全な方法で廃車することである。廃車によるサイバーセキュリティへの影響はClause.9またはClause.10で検討することが要求されている。

Clause 15:分散サイバーセキュリティ活動

第15節では分散型のサイバーセキュリティ活動の要件を指定し、サイバーセキュリティ活動に対する顧客とサプライヤー間の相互作用、依存関係、責任を定義することが目的である。
たとえば、Tier-1は開発中のOEMのサプライヤーになることができ、別の契約関係では、Tier-1はコンポーネントのTier-2の顧客になることができる
サイバーセキュリティインタフェース契約で顧客とサプライヤーは分散サイバーセキュリティ活動を指定することが要求されている。
最終的に各々の責任はサイバーセキュリティインタフェース合意書に明記される。