はじめに

自動車産業は、高度なエンジニアリングとデジタルトランスフォーメーションが交差する地点にあります。車両が接続され、ソフトウェア駆動のプラットフォームへと進化するにつれて、サイバー攻撃の対象範囲は飛躍的に拡大しています。セキュリティ侵害はもはやデータ盗難に留まらず、車両の安全性や運行を脅かし、生命を危険にさらす可能性があります。

こうしたリスクに対応するため、自動車関連組織は包括的なサイバーセキュリティ戦略を実装しなければなりません。ISO/SAE 21434、サイバーセキュリティ管理システム（CSMS）、および自動車向けペネトレーションテストの3つの柱が、この取り組みの基盤を形成しています。本ブログでは、それぞれの柱を技術的に深掘りし、次世代車両の安全を確保する仕組みを解説します。

1. ISO/SAE 21434：自動車サイバーセキュリティ規格

ISO/SAE 21434とは？

ISO/SAE 21434は、「道路車両－サイバーセキュリティ工学」に関する国際標準規格であり、車両のライフサイクル全体（コンセプト、開発、生産、運用、保守、廃棄）を通じてサイバーセキュリティリスクを管理するための要件を定めています。

主な技術的要件

A. 脅威分析およびリスク評価（TARA）

目的: サイバーセキュリティの脅威や脆弱性を特定、評価し、優先順位を付けること。

手法:

• 攻撃ツリー：攻撃経路を視覚化

• HEAVENS：自動車向けに特化したリスク評価フレームワーク

• STRIDE：脅威を分類（なりすまし、改ざん、否認、情報漏洩、サービス妨害、権限昇格）

プロセス:

• 資産（ECU、通信バス、センサー等）を定義

• 脅威および脆弱性を特定

• 影響度と発生確率を評価

• リスク値と軽減優先度を割り当てる

B. セキュリティ目標および要件

• セキュリティ目標：TARAから導かれ、保護対象を明確化（例：OTAアップデートの機密性、CANメッセージの完全性）

• 技術的要件：

  • セキュアブートおよびセキュアなファームウェア更新

  • 車内および外部通信の暗号化保護

  • 診断やリモートアクセスの認証・認可機構

C. セキュアシステムアーキテクチャ

• 多層防御（ディフェンス・イン・デプス）：ネットワーク分割、アクセス制御、侵入検知など

• ハードウェアセキュリティモジュール（HSM）：暗号処理と鍵保管専用チップ

• セキュア通信：標準プロトコル（TLS、MACsec、IPsec）の活用

D. 検証および妥当性確認

• テスト：静的・動的コード解析、通信インターフェースのファズテスト、ペネトレーションテスト（第3章参照）

• トレーサビリティ：全てのセキュリティ要件に対して実装およびテスト証拠の追跡が可能であること

E. インシデント対応およびアップデート

• 脆弱性管理：新たな脅威の継続的監視

• インシデント対応：検知、報告、是正のための明確な手順

• OTAアップデート：遠隔ソフトウェア／ファームウェア更新の安全な仕組み（ロールバックや復旧機能含む）

2. CSMS：サイバーセキュリティ管理システム

CSMSとは？

CSMS（Cyber Security Management System）は、UNECE WP.29（R155）で義務付けられ、ISO 21434でも参照される組織的枠組みです。企業全体およびサプライチェーンにわたり、サイバーセキュリティを体系的に管理することを目的としています。

技術的実装

A. ガバナンスとポリシー

• サイバーセキュリティ方針：トップダウンでのコミットメント、文書化されたポリシー、明確な役割と責任の設定

• サイバーセキュリティ責任者：CSMS実施を統括する指名責任者

B. リスク管理プロセス

• 継続的なリスク評価：TARA活動を継続し、脅威インテリジェンスや脆弱性情報を統合

• リスク処理：優先順位付けと軽減計画、定期的な見直し

C. セキュア開発ライフサイクル（SDL）

• 要件定義：初期段階からセキュリティを組み込み

• 設計レビュー：各開発フェーズでのセキュリティアーキテクチャレビュー

• コードレビューおよびテスト：自動および手動によるセキュリティ評価

D. サプライヤーおよび第三者管理

• サプライヤー監査：Tier1/2のサプライヤーが安全な開発手法を遵守していることを確認

• コンポーネント検証：提供されたハードウェア・ソフトウェアモジュールのセキュリティテスト

E. インシデントおよび脆弱性管理

• SIEM統合：リアルタイム監視のためのセキュリティ情報イベント管理システム

• インシデント対応手順書：コミュニケーションルールやエスカレーションルートを含む対応フロー

• 事後分析：根本原因分析と教訓の共有

F. トレーニングと意識向上

• 社員教育：エンジニアや開発者、サポートスタッフ向けの定期的なセキュリティ研修

• フィッシング訓練：ソーシャルエンジニアリング攻撃に対する組織の準備状況をテスト

G. ライフサイクル管理

• トレーサビリティ：サイバーセキュリティ活動の全工程にわたる文書化と追跡

• 継続的改善：インシデントや新たな脅威に基づくプロセスの見直しと強化

3. 自動車向けペネトレーションテスト

自動車ペンテストとは？

自動車ペネトレーションテストは、車両システム、ECU、ネットワーク、接続サービスに対して実際の攻撃を模擬的に実施し、脆弱性を事前に発見し対処する手法です。

詳細なテスト手法

A. 車内ネットワークの侵入テスト

• CANバス攻撃：

  • メッセージ注入（センサー情報のなりすまし）

  • リプレイ攻撃（有効なメッセージの再送）

  • サービス妨害攻撃（バスの過負荷）

• LIN、FlexRay、Automotive Ethernet：

  • プロトコル特有の脆弱性や不適切な分離の検証

B. ECUのセキュリティテスト

• ファームウェア解析：

  • バイナリのリバースエンジニアリング

  • ハードコードされた認証情報、不安全な更新機構、デバッグコードの検出

• 物理的攻撃：

  • デバッグポート（JTAG、UART）へのアクセス

  • サイドチャネル攻撃やフォールトインジェクション

C. テレマティクスおよびインフォテインメント

• 無線インターフェーステスト：

  • Bluetooth、Wi-Fi、セルラー、NFCの脆弱性評価

  • ペアリング、認証、暗号化の攻撃

• OTAアップデートのセキュリティ：

  • 更新サーバーや配信機構に対する中間者攻撃やロールバック攻撃の検証

D. クラウドおよびモバイル連携

• APIセキュリティ：

  • バックエンドAPIの認証、認可、データ検証の問題検出

• モバイルアプリのペネトレーション：

  • アプリのリバースエンジニアリング

  • 車両やクラウドとの通信解析

  • 不安全な保存や通信の特定

E. レポートおよび修正

• 技術報告書：

  • 攻撃証明付きの詳細な調査結果、リスク評価（CVSSなど）、修正提案

• 再テスト：

  • 修正内容の検証および回帰テスト

トリオの連携

統合されたセキュリティアプローチ

• ISO 21434は、セキュアな車両設計のための技術要件と枠組みを提供

• CSMSは、これらの要件を組織やサプライチェーン全体で管理・実行し継続的に改善

• ペネトレーションテストは、両者の効果を実環境で検証し、セキュリティ対策の堅牢性を保証

具体的なワークフロー例

開発段階:

• TARAにより、ECUの不正再プログラミングリスクを特定

• ISO 21434でセキュアブートと暗号認証が義務付けられる

• CSMSが内部チームとサプライヤーでの実装・テストを管理

• ペンテスターがセキュアブートの突破や不正ファームウェア注入を試み、発見事項は製品化前に対処

量産後:

• CSMSが新たな脆弱性を監視し、OTA更新を調整

• 定期的かつ大規模アップデート後にペンテストを実施

• 新たな攻撃が確認された場合はインシデント対応計画を発動

現実的な課題とベストプラクティス

よくある落とし穴

• 不十分な脅威モデリング：一般的なモデルに頼りシステム固有の分析が不足

• サプライヤーリスク：第三者コンポーネントの監査・テスト不足

• 継続的なテスト欠如：ペンテストを一度きりの活動として扱う

• インシデント対応の遅れや不備

ベストプラクティス

• 早期にセキュリティを統合：概念設計段階からTARAおよびSDLを開始

• 自動化の活用：コード解析、ネットワーク監視、脆弱性スキャンの自動化ツール利用

• 部門間の連携：エンジニアリング、IT、セキュリティの壁を取り払い協力