1. HOME
  2. コラム
  3. コラム
  4. CASE時代に不可欠なサイバーセキュリティ& 機能安全

CASE時代に不可欠なサイバーセキュリティ& 機能安全

  • LINEで送る
  • このエントリーをはてなブックマークに追加
CASE時代に不可欠なサイバーセキュリティ& 機能安全

自動車産業における「CASE」は、便利さや効率性を向上させる一方で、セキュリティや安全上の問題を引き起こす可能性があります。ここでは、ISO21434とISO26262に基づき、知っておくべきサイバーセキュリティエンジニアリングと機能安全エンジニアリングの類似点と相違点について説明します。



1.サイバーセキュリティと機能安全、エンジニアリングの共通アプローチ

 機能安全エンジニアリングでは、アイテム(車両レベルで機能を実装するコンポーネント)が故障しても安全かどうかを分析し、許容できないリスクがある場合は対策を検討して機能安全要求定義および機能安全アーキテクチャ設計を行います。サイバーセキュリティエンジニアリングでも同様に、アイテムに対するサイバーセキュリティリスクを分析し、許容できないリスクがある場合は対策を検討してセキュリティ要求定義およびセキュリティアーキテクチャ設計を行います。

 このように、サイバーセキュリティ&機能安全エンジニアリングは、どちらも「分析」をして、許容できないリスクがあればその対策を検討し「要求定義」および「アーキテクチャ設計」を行うという点で類似しています。

サイバーセキュリティと機能安全、エンジニアリングの共通アプローチ(システムズエンジニアリング、サイバーセキュリティエンジニアリング、機能安全エンジニアリング)


2.サイバーセキュリティと機能安全に共通する3つのプロセスと段階的詳細化

 機能安全と同様にサイバーセキュリティエンジニアリングも、「分析」、「要求定義」、「アーキテクチャ設計」の3つのプロセスが基本となり、これらの3つのプロセスをコンセプトフェーズから、システムレベル・ハードウェア/ソフトウェアレベルの製品開発フェーズを通じて実施し、段階的に詳細化していくという点も類似しています。

サイバーセキュリティと機能安全に共通する3つのプロセス(分析、要求定義、アーキテクチャ設計)と段階的詳細化

 以降、機能安全とサイバーセキュリティのコンセプトフェーズの活動について説明します。



3.機能安全のコンセプトフェーズ

 機能安全エンジニアリングのコンセプトフェーズのPFDは以下のようになります。

機能安全エンジニアリングのコンセプトフェーズのPFD(分析、要求定義、アーキテクチャ設計)

 機能安全のコンセプトフェーズは、上記のように「分析」「要求定義」「アーキテクチャ設計」に分類できます。「分析」に分類されるハザードの識別およびASILの決定の例を以下に示します。


ハザードの識別

 アイテム定義を入力として、HAZOPなどのハザード分析手法を用いてハザードを導出します。下表の「車両レベルの影響」に記載した項目がハザードの候補となります。さらに、ハザード候補を対象に「危険事象の可能性」を評価し、ありと判断したものをハザードとします。

アイテム定義を入力として、HAZOPなどのハザード分析手法を用いてハザードを導出

ASILの決定

 ハザード毎に危険事象を導出し、S,E,C分類に基づいてリスクアセスメントを実施してASILを決定します。

ハザード毎に危険事象を導出し、S,E,C分類に基づいてリスクアセスメントを実施してASILを決定


4.サイバーセキュリティのコンセプトフェーズ

 サイバーセキュリティエンジニアリングのコンセプトフェーズのPFDは以下のようになります。

サイバーセキュリティエンジニアリングのコンセプトフェーズのPFD(分析、要求定義、アーキテクチャ設計)

 サイバーセキュリティのコンセプトフェーズも、まずアイテムを定義します。次に、資産および損害シナリオの特定、インパクト評価、損害シナリオの特定、攻撃経路の分析、攻撃実現の可能性評価を通じてリスク値を決定します。そして許容できないリスクに対してはリスク回避やリスク低減などのリスク対応を決定して、サイバーセキュリティゴールおよびサイバーセキュリティクレームを規定し、サイバーセキュリティコンセプトを定義します。これらのプロセスは機能安全と同様に、「分析」「要求定義」「アーキテクチャ設計」に分類できます。

 次に、「分析」に分類される資産および損害シナリオの特定とインパクト評価、脅威シナリオの特定について説明します。


資産および損害シナリオの特定

 アイテム定義より資産を特定し、損害シナリオを特定します。損害シナリオを特定する際は、サイバーセキュリティの3つの属性のCIA(C:機密性、I:完全性、A:可用性)の観点で検討します。

アイテム定義より資産を特定し、損害シナリオを特定

インパクトの評価

 4つのインパクトカテゴリ(S:安全性、F:金銭的、O:運用、P:プライバシー)それぞれの観点で、損害シナリオを評価します。なお、安全性に関するインパクト評価基準は、機能安全のSeverityを踏襲できます。

4つのインパクトカテゴリ(S:安全性、F:金銭的、O:運用、P:プライバシー)それぞれの観点で、損害シナリオを評価

脅威シナリオの特定

 損害シナリオを引き起こす脅威シナリオを特定します。

損害シナリオを引き起こす脅威シナリオを特定

 なお、脅威シナリオを特定する際には、例えばSTRIDEを用いることができます。 STRIDEとは、下記6つの観点の頭文字を取った脅威分析手法で、それぞれの観点から脅威を導出します。

脅威シナリオを特定する際の脅威分析手法STRIDE


5.サイバーセキュリティと機能安全の違い

 サイバーセキュリティエンジニアリングと機能安全エンジニアリングは、時系列的には設計・テスト工程だけでなく、保守廃棄に至るまでのライフサイクル全体を対象にしているという意味で共通です。しかし、評価・対策の範囲には違いがあります。機能安全エンジニアリングでは「故障」によって生じる「安全」リスクを対象に評価して対策する一方で、サイバーセキュリティエンジニアリングでは、「サイバー攻撃」によって生じる「安全」「金銭的」「運用」「プライバシー」の4つのカテゴリにおけるリスクを対象に評価して対策を行います。

 このような違いがあるので、サイバーセキュリティエンジニアリングは、機能安全エンジニアリングよりも広い視野を持って取り組む必要があると言えるでしょう。

サイバーセキュリティエンジニアリングと機能安全エンジニアリングの違い


6.サイバーセキュリティ&機能安全エンジニアリングを円滑に遂行するために

 サイバーセキュリティと機能安全エンジニアリングは、どちらもアイテム定義をもとに分析し、対策を講じます。分析を適切に実施するためには、要求およびアーキテクチャの可視化が必要です。可視化された要求・アーキテクチャをもとに分析することで、関係者間で共通理解が得られ、その後の適切な意思決定が行えます。『システムアーキテクチャ構築』の記事では、システムズエンジニアリングのアーキテクチャ構築プロセスを紹介しています。そちらの内容と合わせて、サイバーセキュリティ&機能安全エンジニアリングの円滑な遂行を目指しましょう。

サイバーセキュリティエンジニアリング&機能安全エンジニアリングを円滑に遂行するためにには、要求およびアーキテクチャの可視化が必要


サービスに関するご相談は
こちらからお願いします


7.コンサルタントが教える成功の秘訣

コンサルタント 一ノ瀬 直也

 サイバーセキュリティエンジニアリングと機能安全エンジニアリングのプロセスは類似しており、どちらも「アイテム」をインプットとして「分析」し「要求定義」「アーキテクチャ設計」を行います。そのため、まずインプットとなる「アイテム」を正しく理解することが、サイバーセキュリティエンジニアリングや機能安全エンジニアリングを成功させるためにはとても重要となります。特に大規模・複雑な「アイテム」では、適切な抽象度で可視化することが求められます。

 エクスモーションでは、USDMやMBSEなどサイバーセキュリティエンジニアリングや機能安全エンジニアリングにも活かせる実践的な技術の導入と支援を実施してきました。現場の状況に合わせた導入も得意としておりますので、ぜひ、私たちにお任せください。

機能安全の専門コンサルタント 一ノ瀬 直也


エクスモーションが提供するセキュリティ関連サービス

サイバーセキュリティ&機能安全成果物作成サービス

サイバーセキュリティ規格や機能安全規格のコンセプトフェーズ/製品開発フェーズにおいて、規格に準拠するために必要となる成果物を作成します。

サイバーセキュリティ&機能安全開発プロセス導入支援サービス

お客様の組織構造や既存の開発プロセスを考慮して、サイバーセキュリティ規格や機能安全規格のコンセプトフェーズ/製品開発フェーズを実施する開発プロセスの導入を支援します。

要求/設計仕様書作成サービス

サイバーセキュリティ規格や機能安全規格の入力となる成果物(既存システムの要求仕様書や設計書)が必要な場合、制御仕様書やソースコードといった下流の成果物からリバースしてシステムの要求仕様書や設計仕様書を作成します。

機能安全対応支援iso26262関連ソリューション

  • LINEで送る
  • このエントリーをはてなブックマークに追加