October 5, 2023

SDVアプリケーションのセキュリティ対策における課題

サードパーティ サプライヤのサイバーセキュリティ対応にも注意が必要な理由

ソフトウェア・デファインド・ビークル（SDV）や関連する先進技術の数々により、"未来の自動車"が現実のものになりつつあります。2029年までには、新車の90%以上がSDVになると予測されています。SDVのアーキテクチャは、自動車の安全性を強化するだけでなく、消費者に対しても多くのメリットを提供できることから、自動車業界での導入が進んでいます。しかし、この進化に伴い、自動車が新たに危険なサイバーセキュリティの脅威に晒されているのも事実です。ISO/SAE 21434やUN-R155、中国のGB規格などのサイバーセキュリティ関連の規格や法規は、このような課題を克服するための土台となるものであり、業界として自動車のサイバーセキュリティ対応の見直しと改善を強く求めています。

自動車業界が直面する主な課題としては、サイバーセキュリティ人材の不足、研究開発コストの増大、サプライチェーン階層の見直し、更新が頻繁なソフトウェアのコンプライアンス対応、自動車のライフサイクル全体を通しての継続的なサイバーセキュリティの実現などがあります。

ハードウェアとソフトウェアの分離

SDV技術の登場により、サードパーティ サプライヤのアプリケーション設計において、オープンソースソフトウェアの自社開発での利用の増加やE/Eコストの削減のような変化が既に現れ始めています。さらに、仮想化技術により、ハードウェアとソフトウェアの分離が一般的になり、ECUの統合により、従来80～100個あったECUを、複数の仮想OSを実行する3つの主要なハイパーバイザーにまで集約することが可能となり、結果としてネットワークの分割が容易になりました。OSを共有する仮想マシン（VM）やコンテナのセキュリティを確保する必要性から、高パフォーマンスなコンピューティングやドメイン・コントローラの利用も広がっています。コンテナのランタイムシステムを使えば、ロードされたコンテナに自動的にセキュリティ制御を自動的に追加することができます。また、サプライヤーはSDKを使用することで、コンテナに組込み型のセキュリティを追加することも可能です。

自動車自体がサービス提供をするプラットフォームの役割を持つようになるにつれ、OEMやサードパーティのサプライヤは、セーフティクリティカルおよびプライバシー保護のためのサイバーセキュリティと併せて、オンデマンドな機能やアプリケーション、サービスなどもOTAアップデートを通じて提供し始めました。しかし、車載アプリケーションはサイバー攻撃に侵入口にもなりえます。そのため、サードパーティのサプライヤによって提供される、オープンソースのアプリケーションやセーフティクリティカルなアプリケーション、車載データアプリケーションは、モバイルとクラウドの両面からサイバーセキュリティを強固なものにしておく必要があります。

Tier 1による継続的セキュリティ検証

Tier1アプリケーションが市場シェアを拡大するにつれ、車載ソフトウェアのセキュリティリスクも増大しています。どの自動車も様々なサプライヤが作ったソフトウェアを搭載している可能性があり、なかにはサイバーセキュリティ対応が行き届かないほど小規模なサプライヤによるものも含まれているかもしれません。

ISO/SAE 21434とUN-R155は、サプライヤによるサイバーセキュリティ対応の水準の引き上げを目指すものであり、サプライヤのセキュリティ対応を検証し、サプライヤが提供するバイナリ内にサイバーセキュリティ上の問題が潜んでいないか検証することを要求しています。安全性とプライバシーが優先事項にあり、セーフティクリティカルなアプリケーションを強化し、顧客の車載データを漏えいから保護することが求められます。加えて、サプライチェーンの階層が従来のピラミッド型から協調的なフラット型に移行するのに伴い、自動車メーカーはセキュリティ対応をさらに強化し、継続的な管理を行う必要に迫られています。

各規格や法規への準拠のため、OEMは自身の開発プロセスを適合させるだけでなく、すべてのソフトウェアサプライヤに対して、必要な評価やテスト（全製品に対してのCSMS、TARA、ペンテスト）の実施を求めなくてはなりません。これらの要件を満たすには多大なリソースが必要であり、サイバーセキュリティ対応のプロセスを高速化するための新たな手段も必要になります。

自動化

製品セキュリティ全般（またはその大部分）を自動的に管理・確保ができて、さらには規格準拠に必要となる成果物も作成できる。そのようなプラットフォームを求める声が自動車業界で大きくなっています。コンセプト・設計から、製造後、廃車に至るまでの様々なフェーズで起こった事象や集めた情報を簡単に分析し、関連付けできるツールが求められているのです。

中国のGB規格を例としても分かるように、サイバーセキュリティ関連の規制要件は厳しくなる一方です。UN-R155の要件に加え、GB規格は車載マルウェア対策やアプリケーションの完全性のランタイム検証、さらにサードパーティ製アプリケーションの完全性の検証をOEMに対して求めています。SOP（Start of Producion）の遅れを避けるためには、現在の計画段階の一部として、サイバーセキュリティのコンプライアンス対応を考慮しておく必要があります。

Karamba Security社のホストIDPS自動化ソフトウェアである「XGuard」は、組込みセキュリティ制御に影響を及ぼすことなく、バイナリのホワイトリスティングおよびソフトウェアの制御フローの整合性（CFI）検証技術により、ECUをマルウェアやインメモリ攻撃から保護します。これにより、ECUの決定論的な保護と継続的なモニタリングを確実なものにすることができます。また、XGuardのバックエンドエンジンは、デバイス内のエージェントから信頼度の高いアラート情報を集め、車両およびフリートレベルで自動作成されるベースラインと照合します。XGuardはソースコードに手を加えることなく、ランタイムのファームウェア保護により、セキュア・ブート・メカニズムを強化することができるため、R＆Dへの影響を考慮する必要がありません。XGuardのCPU使用率は5%未満で、パフォーマンスへの影響もごくわずかです。

さらに、サードパーティ開発者向けのOEM開発ツールチェーンに、Karamba Security社の「VCode」 3.0プラットフォームを追加しておくことをお勧めします。VCodeを使うことで、サプライヤや自社製バイナリに含まれるセキュリティ上の脆弱性や設定ミスなどの問題を自動的に検出することができます。検出された問題は、こちらも自動的に生成されるSBOM（ソフトウェア部品表）に基づいて、優先順位付けされるようになっています。

VCodeは、Auto-ISACアラート、セキュリティ攻撃、バグバウンティやホワイトハットハッカーによる情報など、複数のデータソースからの脆弱性情報を集約する脆弱性管理システム（VMS）としても機能し、影響範囲や深刻度、攻撃を受ける可能性の度合いによって、脆弱性対応の優先順位を決定します。AUTOSAR、QNX、Linux、Android OSに対応が可能なうえ、VCode 3.0は脅威分析およびリスク評価（TARA）の自動実行や、ECUおよび車両タイプのアーキテクチャ・設計におけるリスク特定の機能も有しているため、リスクと悪用される可能性に応じて優先順位を付けて、問題修正を行うのに役立ちます。

Karamba Security社のソリューションは、コードの再コンパイルや変更を必要としません。セキュリティプロセスを追加するために、リリーススケジュールを遅らせる必要もありません。CI/CDパイプラインにシームレスに連携し、各種規格や法規に準拠した形で、包括的なサイバーセキュリティ対応を実現します。

Karamba Secuirty社のソリューション