CASE時代に不可欠なサイバーセキュリティ＆ 機能安全
自動車産業における「CASE」は、便利さや効率性を向上させる一方で、セキュリティや安全上の問題を引き起こす可能性があります。ここでは、ISO21434とISO26262に基づき、知っておくべきサイバーセキュリティエンジニアリングと機能安全エンジニアリングの類似点と相違点について説明します。
目次
１．サイバーセキュリティと機能安全、エンジニアリングの共通アプローチ
機能安全エンジニアリングでは、アイテム（車両レベルで機能を実装するコンポーネント）が故障しても安全かどうかを分析し、許容できないリスクがある場合は対策を検討して機能安全要求定義および機能安全アーキテクチャ設計を行います。サイバーセキュリティエンジニアリングでも同様に、アイテムに対するサイバーセキュリティリスクを分析し、許容できないリスクがある場合は対策を検討してセキュリティ要求定義およびセキュリティアーキテクチャ設計を行います。
このように、サイバーセキュリティ＆機能安全エンジニアリングは、どちらも「分析」をして、許容できないリスクがあればその対策を検討し「要求定義」および「アーキテクチャ設計」を行うという点で類似しています。
２．サイバーセキュリティと機能安全に共通する３つのプロセスと段階的詳細化
機能安全と同様にサイバーセキュリティエンジニアリングも、「分析」、「要求定義」、「アーキテクチャ設計」の３つのプロセスが基本となり、これらの３つのプロセスをコンセプトフェーズから、システムレベル・ハードウェア/ソフトウェアレベルの製品開発フェーズを通じて実施し、段階的に詳細化していくという点も類似しています。
以降、機能安全とサイバーセキュリティのコンセプトフェーズの活動について説明します。
３．機能安全のコンセプトフェーズ
機能安全エンジニアリングのコンセプトフェーズのPFDは以下のようになります。
機能安全のコンセプトフェーズは、上記のように「分析」「要求定義」「アーキテクチャ設計」に分類できます。「分析」に分類されるハザードの識別およびASILの決定の例を以下に示します。
ハザードの識別
アイテム定義を入力として、HAZOPなどのハザード分析手法を用いてハザードを導出します。下表の「車両レベルの影響」に記載した項目がハザードの候補となります。さらに、ハザード候補を対象に「危険事象の可能性」を評価し、ありと判断したものをハザードとします。
ASILの決定
ハザード毎に危険事象を導出し、S,E,C分類に基づいてリスクアセスメントを実施してASILを決定します。
４．サイバーセキュリティのコンセプトフェーズ
サイバーセキュリティエンジニアリングのコンセプトフェーズのPFDは以下のようになります。
サイバーセキュリティのコンセプトフェーズも、まずアイテムを定義します。次に、資産および損害シナリオの特定、インパクト評価、損害シナリオの特定、攻撃経路の分析、攻撃実現の可能性評価を通じてリスク値を決定します。そして許容できないリスクに対してはリスク回避やリスク低減などのリスク対応を決定して、サイバーセキュリティゴールおよびサイバーセキュリティクレームを規定し、サイバーセキュリティコンセプトを定義します。これらのプロセスは機能安全と同様に、「分析」「要求定義」「アーキテクチャ設計」に分類できます。
次に、「分析」に分類される資産および損害シナリオの特定とインパクト評価、脅威シナリオの特定について説明します。
資産および損害シナリオの特定
アイテム定義より資産を特定し、損害シナリオを特定します。損害シナリオを特定する際は、サイバーセキュリティの３つの属性のCIA（C：機密性、I：完全性、A：可用性）の観点で検討します。
インパクトの評価
４つのインパクトカテゴリ（S：安全性、F：金銭的、O：運用、P：プライバシー）それぞれの観点で、損害シナリオを評価します。なお、安全性に関するインパクト評価基準は、機能安全のSeverityを踏襲できます。
脅威シナリオの特定
損害シナリオを引き起こす脅威シナリオを特定します。
なお、脅威シナリオを特定する際には、例えばSTRIDEを用いることができます。 STRIDEとは、下記６つの観点の頭文字を取った脅威分析手法で、それぞれの観点から脅威を導出します。
５．サイバーセキュリティと機能安全の違い
サイバーセキュリティエンジニアリングと機能安全エンジニアリングは、時系列的には設計・テスト工程だけでなく、保守廃棄に至るまでのライフサイクル全体を対象にしているという意味で共通です。しかし、評価・対策の範囲には違いがあります。機能安全エンジニアリングでは「故障」によって生じる「安全」リスクを対象に評価して対策する一方で、サイバーセキュリティエンジニアリングでは、「サイバー攻撃」によって生じる「安全」「金銭的」「運用」「プライバシー」の４つのカテゴリにおけるリスクを対象に評価して対策を行います。
このような違いがあるので、サイバーセキュリティエンジニアリングは、機能安全エンジニアリングよりも広い視野を持って取り組む必要があると言えるでしょう。
６．サイバーセキュリティ＆機能安全エンジニアリングを円滑に遂行するために
サイバーセキュリティと機能安全エンジニアリングは、どちらもアイテム定義をもとに分析し、対策を講じます。分析を適切に実施するためには、要求およびアーキテクチャの可視化が必要です。可視化された要求・アーキテクチャをもとに分析することで、関係者間で共通理解が得られ、その後の適切な意思決定が行えます。『システムアーキテクチャ構築』の記事では、システムズエンジニアリングのアーキテクチャ構築プロセスを紹介しています。そちらの内容と合わせて、サイバーセキュリティ＆機能安全エンジニアリングの円滑な遂行を目指しましょう。
こちらからお願いします
７．コンサルタントが教える成功の秘訣
サイバーセキュリティエンジニアリングと機能安全エンジニアリングのプロセスは類似しており、どちらも「アイテム」をインプットとして「分析」し「要求定義」「アーキテクチャ設計」を行います。そのため、まずインプットとなる「アイテム」を正しく理解することが、サイバーセキュリティエンジニアリングや機能安全エンジニアリングを成功させるためにはとても重要となります。特に大規模・複雑な「アイテム」では、適切な抽象度で可視化することが求められます。
エクスモーションでは、USDMやMBSEなどサイバーセキュリティエンジニアリングや機能安全エンジニアリングにも活かせる実践的な技術の導入と支援を実施してきました。現場の状況に合わせた導入も得意としておりますので、ぜひ、私たちにお任せください。
エクスモーションが提供するセキュリティ関連サービス
サイバーセキュリティエンジニアリング対応成果物作成サービス
自動車－サイバーセキュリティエンジニアリング規格『ISO21434』等、サイバーセキュリティエンジニアリング規格のコンセプト定義/リスク分析/製品開発の各フェーズにおいて、規格に準拠するために必要となる成果物を作成します。
開発プロセス導入支援サービス
お客様の組織構造や既存の開発プロセスを考慮して、サイバーセキュリティエンジニアリング規格のコンセプト定義/リスク分析/製品開発のフェーズを実施する開発プロセスをどのようにすればよいかを、ご提案します。
要求 / 設計仕様書作成サービス
サイバーセキュリティエンジニアリング規格の入力となる成果物（既存システムの要求仕様書や設計書）が必要な場合、制御仕様書やソースコードといった下流の成果物からリバースしてシステムの要求仕様書や設計仕様書を作成します。
機能安全対応支援iso26262関連ソリューション
