ホワイトペーパー

はじめに

どのようにしてセキュリティリスクを予測し、軽減すればいいのか。業界標準である ISO®/SAE® 21434 や DO-356 に準拠するには、新製品の市場投入前にその問いに答えを出す必要があります。しかし、変更内容の文書化、追跡、実装、検証を支援する統合プロセスがなければ、それを実現するのは困難でしょう。このプロセスは業界によって TARA (Threat Analysis and Risk Assessment)、SRA (Security Risk Assessment) など、さまざまな名称で呼ばれています。SRA のモデルベース フレームワーク (図 1) を用いることで、ステップバイステップのガイド付きプロセスを通して、設計と安全性とセキュリティを密接に結び付けることができます。また、MATLAB® のさまざまな機能を活用すると、ニーズに応じて、簡単にプロセスをカスタマイズし、拡張・自動化することもできます。

「アーキテクチャ/実装モデル」と「セキュリティ目標」を入力として使用したセキュリティ分析プロセスのフローを示す図。「静的解析」フェーズの 3 つの重要なステップである、1) アセット、脅威、対策の提案、2) 脅威/リスクモデルの適用、3) セキュリティ目標をテストするためのモデル攻撃が含まれています。各フェーズを矢印でつなげて、ワークフローを示しています。

図 1. モデルベースのセキュリティ分析フレームワーク。

コンテキスト: 倉庫ロボット

このホワイトペーパーでは、リモートオペレーター、ソフトウェア アーキテクチャ、プラントモデル、カメラモデルで構成される倉庫ロボットの例を取り上げます (図 3)。ソフトウェア アーキテクチャの詳細 (図 4) を見ると、計画スケジューラと、計画、制御、位置推定器の各モジュールが組み込まれていることがわかります。

モデルベースのセキュリティ分析は、次のステップで構成されます (図 2 を参照)。

  1. アセットと脅威の特定
  2. セキュリティリスクの計算
  3. 対策の定義、実装、検証
セキュリティリスク管理のステップを示すフローチャート。アセットと脅威を特定し、セキュリティリスクを計算し、対策を定義して検証します。各セクションには、問題、リスク行列、防犯カメラなど、関連する画像が含まれています。

図 2. モデルベースのセキュリティ分析のステップ。

コントロールセンター、ロボット ソフトウェア アーキテクチャ、倉庫建物を含む倉庫ロボットシステムを示すシステム図。ロボットの制御、配置、ナビゲーションのデータフローが示されています。

図 3. 倉庫ロボットのアーキテクチャモデル。

倉庫作業ロボットのアーキテクチャ詳細図。ロボットの動作とタスクを管理する計画スケジューラ、位置推定器、制御モジュールを示しています。

図 4. 倉庫ロボットのソフトウェア アーキテクチャ。

セクション

アセットと脅威の特定

アセットと脅威を特定する際には、「何に保護が必要か」という問いが重要になります。理想を言えば、「システムに価値をもたらすもの」すべが保護の対象となります。しかし、システムの複雑さやコストの制約により、実際には安全性に関わる機能など、必要なものだけが保護の対象に選ばれます。これらの機能はアセットと呼ばれ、それぞれに以下のような保護すべきプロパティが 1 つ以上あります。

  • 可用性
  • 完全性
  • 真正性
  • 機密性
  • 否認防止
  • 認可

アセットの特定: 保護の対象

アセットの特定にはさまざまな手法があり、たとえば、ユーザーへの露出度の評価、データフローの調査、SBOM (Software Bill of Materials) の確認、安全機能における役割の考慮などがあります。簡単に言えば、外部入力を利用するすべてのコンポーネントを対象にする必要があります。

ロボットのソフトウェア アーキテクチャ内には、倉庫の天井カメラ (シミュレーション モデル) からの信号 (robotPosition) に依存する以下のようなコンポーネントがあります。

  • 計画スケジューラ
  • 位置推定器

本レポートでは、この例に基づいて、これらのアセットに関連する信号の可用性、完全性、真正性の保護に焦点を当てます。なお、これらのアセットについては他にも保護すべきプロパティがあり、本来はシステム内のすべてのアセットについて、この分析を行う必要があります。

この分析全体を通じてトレーサビリティを確保するためには、Simulink Fault Analyzer™ の Safety Analysis Manager スプレッドシートを活用することが重要です。これらのアセットをスプレッドシートに追加する際には、System Composer™ のステレオタイプを使用します。「asset (アセット)」というステレオタイプをこれらのサブシステムに割り当てると、自動的にシートに追加されます。スプレッドシートでは、アセットタイプ、保護プロパティ、その他記録したい情報を管理することができます (図 5)。Requirements Toolbox™ を使用すると、アセットを特定された脅威に紐付け、分析全体をつなぐデジタルスレッドを作成できます。これにより、以下が可能となります。 

  1. 業界標準のトレーサビリティ要件への準拠
  2. 変更に対する影響分析の実施
スプレッドシートのスクリーンショット。2 つのアセット、「計画スケジューラ」と「位置推定器」が記載されており、いずれもプロセスに分類され、真正性、完全性、可用性にチェックが付いています。

図 5. アセット スプレッドシートの例。

脅威の特定: リスク要因

保護すべきアセットが特定できたら、次はこれらのアセットに対して想定される脅威を特定します。ソフトウェア セキュリティの脅威を特定する一般的な方法として、STRIDE モデリング フレームワークがあります。表 1 には、アセットに求められるプロパティと脅威が直接マッピングされています。

表 1

脅威、プロパティ、定義の対応表 (出典: Wikipedia)
脅威 プロパティ 脅威の定義
なりすまし 真正性 本来とは異なる事象や人物を装うこと
改ざん 完全性 ディスク、ネットワーク、メモリなどの情報を改変すること
否認 否認防止 行為を行っていない、責任がないと主張すること (正当または虚偽の場合がある)
情報漏洩 機密性 権限のない者が情報を入手すること
サービス拒否 可用性 サービス提供に必要なリソースを枯渇させること
特権昇格 認可 権限のない操作を許可してしまうこと

STRIDE に限らず、他の手法を使う場合でも、以前に特定したアセットのプロパティから自動的に脅威を提案する MATLAB 関数を記述することができます。たとえば、可用性に対応する脅威は、サービス拒否です。この用語には広い意味があるため、発生するリスクと対策を考えるためにより具体的にする必要があります。CAPEC™1、ATT&CK®2、EMB3D™3 といった脅威カタログを利用することで、脅威がどのようなものかより具体的な情報を得ることができます。この場合は、カメラから位置推定器への信号の妨害である可能性があります。

具体的な脅威を特定できたら、CAPEC エントリ (CAPEC-601 など) を使用して脅威スプレッドシートを更新します。アセットシートと同様に、脅威シートも分析全体に紐付けることで、トレーサビリティと影響分析が可能になります。

セクション

セキュリティリスクの計算

特定の脅威に対するリスクの計算には、主に 2 つの要素が関わります。1 つ目は実現可能性で、これは攻撃の難易度を表わします。2 つ目は影響で、結果の深刻度を評価します。

実現可能性: 攻撃の難易度

ISO 18045 の Attack Potential (攻撃ポテンシャル) 手法を活用することで、攻撃の実現可能性を以下の評価項目に基づいて体系的に評価することができます。

  • 専門技術: 攻撃者の技術レベルは?
  • 知識: どの程度の内部情報が必要か?
  • 装備: 攻撃の実行にどんなツールやハードウェアが必要か?
  • 所要時間: 脆弱性を見つけて攻撃を仕掛けるまでに、どのくらいの時間がかかるか?
  • 攻撃のタイミング: いつ、どのような状況で攻撃を実行できるか?

脅威スプレッドシート (図 6) には、考慮すべき各評価項目ごとに列が設けられており、MATLAB のカスタマイズ可能な数式によって実現可能性が自動的に計算されます。前述のとおり、Attack Potential 手法を用い、各評価項目の標準化された列挙値を合計することで実現可能性を算出します。

リスクと実現可能性の詳細がまとめられた脅威分析表のスクリーンショット。

図 6. 評価項目と実現可能性が強調表示された脅威スプレッドシート。

影響: 深刻度

すべての脅威には、潜在的な影響、つまり結果が伴います。この例では、影響が安全面から評価されており、既存の安全性分析 (ハザードアセスメント) の影響評価がそのまま活用されています。ただし、これは簡略化されたものになります。通常、影響は、運用、財務、プライバシーの各側面からも評価されます。

ハザードアセスメント (図 7) では、位置センサーの機能障害の深刻度は S3 から S5 の範囲になっています。簡潔にするために、これらのうち最も高い値をサービス拒否攻撃 (DoS) の影響として採用します。

ロボットのハザードアセスメント表のスクリーンショット。計画と位置センサーにおける機能障害と、影響、深刻度、発生、リスク、緩和策を示しています。

図 7. ロボットのハザードアセスメント。

リスクの計算と対応

実現可能性と影響の評価が完了したら、MATLAB の別の数式によってリスクが自動的に計算されます。この例では、リスクは実現可能性と影響を掛け合わせて計算されています。

リスク許容度に応じて、どのようにリスク対応を行うかを判断することができます。このスプレッドシート (図 8) のリスク対応は、次の特性のいずれかを示しています。

  • 回避: リスクを完全に回避する必要がある (例：機能自体を削除する)
  • 低減: 技術的な対策を講じてリスクを低減する必要がある
  • 移転: リスクを保険会社、ユーザー、サードパーティなどに移転する
  • 保有: 特に対応せず、「現状のまま」リスクを受容する
  • 該当なし: このシステムには該当する脅威が存在しない

注: 回避ならびに低減のリスク対応は、いずれも技術的要件につながります。

「DoS on Position Estimator」や「Tampering on Position Estimator」などの脅威が記載されたスプレッドシートのスクリーンショット。攻撃の専門性やリスクの詳細が示されています。警告が強調表示され、選択されたステータスのリスクレベルが高すぎることを指摘しています。

図 8. 脅威スプレッドシートのリスク対応。

リスクの計算や、脅威・アセット・その他の要素間の関係は、グラフとして可視化できます。これにより、それぞれが全体のリスクにどのように寄与しているかを把握することができます。グラフには各関係の重要度に関する情報が示されるため、作業の優先順位を決定する際に活用できます。図 9 から分かるように、DoS は改ざんよりも大きな脅威となっており、優先的に処理する必要があります。これは、DoS の深刻度 (S5) が、改変の深刻度 (S4) より高いためです。

倉庫作業ロボットのアーキテクチャにおけるアセット・脅威・位置推定器間の関係を可視化した図。脅威ごとに優先順位が示されており、「DoS on Position Estimator」が優先度 1、「Tampering on Position Estimator」が優先度 2 としてマークされています。

図 9. リスクの可視化。

セクション

対策の定義、実装、検証

カメラから位置推定器への信号を妨害する (DoS) リスクを軽減するには、実現可能性を下げる対策を講じることでリスクを緩和できます。この例では、緊急ブレーキを追加することで影響を抑えました。この対策は、対策シート内のリンクを通じて、脅威スプレッドシートまで追跡することができます (図 10)。各対策はセキュリティ目標に紐付けられており、少なくとも 1 つ以上の派生要件があります。この例では、要件は「妨害の検出から 1 秒以内にロボットを停止させる」ことで、トレーサビリティと影響分析にも紐付けされています。

さまざまな脅威に対するリスク評価を示した表のスクリーンショット。攻撃の専門性、実現可能性、リスクレベルなどの詳細が記載されています。「Emergency brake to detect and stop spinning」とラベル付けされた対策から関連する脅威に向けて矢印が示され、そのリンクが強調表示されています。

図 10. 対策から脅威へのリンク。

一貫性と完全性のチェック

このホワイトペーパーでは、脅威の特定、リスク評価、許容限度を越えたリスクへの対策の定義を取り上げてきました。次のステップは、対策の開発となります。セキュリティ目標を次の工程に進める前に、以下の点を確認して、脅威とリスクモデルが妥当であることを検証します。

  • 各アセットに対して少なくとも 1 つ以上の脅威が特定されている (完全性の観点)
  • すべての脅威が確認されている
  • リスクが高すぎる場合には対策が割り当てられている
  • 要件 (セキュリティ目標など) が作成され、対策に紐付けられている
  • 脅威、アセット、モデル、安全性分析間でリンクが途切れていない

単一の関数呼び出しを用いて、すべての検証を行い、プロット (図 11) を生成することができます。

「脅威とリスクモデルの検証」というタイトルの棒グラフ。分析シートごとの検出件数が表示されています。アセット、脅威、対策、ロボットのハザードアセットの状況が、緑、オレンジ、赤で示されています。

図 11. 脅威とリスクモデルの検証。

対策の実装

対策の定義が完了したら、それをモデルに実装する段階となります。コントローラーの Simulink® モデルで、MATLAB を使用して、関数ブロックを追加します (図 12)。このブロックはトレーサビリティを確保するために要件に紐付けされます。

safetyLock と emergencyBrake のコンポーネントを含む緊急ブレーキシステムの実装を示す図。右側のパネルには、緊急ブレーキの機能の概要と説明が表示されており、「Emergency Brake Active」へのリンクが強調表示されています。

図 12. 要件が紐付けされている緊急ブレーキの実装。

検証と妥当性確認

対策の実装が完了したら、次のステップとして、攻撃をモデル化し、対策の機能を検証します。この作業には Simulink Fault Analyzer を活用して、攻撃のモデリングとシミュレーションを行います。図 13 は、攻撃をモデル化する際に使用する設定内容を可視化したものです。

モデル要素に故障を追加するためのダイアログボックス。故障名や動作などのプロパティが列挙されています。故障は指定したシミュレーション時間にトリガーされるように設定されており、動作タイプは [Stuck-at-Ground] です。

図 13. トリガーが強調表示された故障ダイアログボックス。

故障を有効にしてモデルを実行した後は、図 14 のように シミュレーション データ インスペクター (SDI) を使用して信号を詳細に確認することができます。図 15 で示すように、Navigation Toolbox™ を用いて攻撃時の応答を可視化することもできます。これらのツールを使用すると、意図したとおりに対策が機能していることを視覚的に検証できます。このワークフローは、Simulink テスト マネージャーのフレームワークを通じて拡張することで、すべての機能が適切に検証されていることを確認できます。

ロボットの位置推定器への DoS 攻撃を示す、グラフィカル解析のスクリーンショット。一番上のグラフは攻撃がいつ注入されたかを示し、中間のグラフはロボットがいつ停止したのかを示しています。

図 14. 攻撃が注入されたタイミングを示す Simulink データインスペクター。

図 15. 対策が適用された攻撃 (左) と適用されていない攻撃 (右) の可視化。

セクション

まとめ

モデルベースのセキュリティ分析フレームワークは、組み込みトレーサビリティ、コンプライアンスに向けたカスタマイズ性、プロセスを自動化する能力を備えたワークフローを実現することで、設計と分析の一貫性を確保します。この合理化されたワークフローを通じて、設計の初期段階に検証と妥当性確認を行うことでプロセスが加速し、開発期間の短縮とコスト削減の両方が実現します。潜在的な脅威の発見から、リスクの定量化や評価、対策の有効性の定義やシミュレーションに至るまで、このエンドツーエンドのアプローチによってセキュリティプロセス全体を確実にカバーすることができます。

セクション

参考文献

  1. The MITRE Corporation.“CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™).”2025 年 3 月 18 日閲覧。

  2. The MITRE Corporation.“MITRE ATT&CK®.”2025 年 3 月 18 日閲覧。

  3. The MITRE Corporation.“MITRE EMB3D™.”2025 年 3 月 18 日閲覧。