現在のコネクテッドカーやソフトウェア・デファインド・ビークルは、しばしば「走るコード」と表現されます。もしそれが的確な表現であるならば、最新世代の商用車、特に電動トラック（eトラック）や自動運転トラックは「走るスーパーコンピューター」と呼ぶべきでしょう。

トラック向けの車載およびリモートのソフトウェアシステムの数は増加しており、運送会社は業務効率の向上や安全性の強化を図ることが可能となっています。一方で、このような車両のコネクティビティにより、機密情報の窃取、車両運行状況の追跡、さらには重要機能の不正操作を目的としたサイバー脅威にさらされる機会も増加しています。さらに、商用車は一般的な乗用車に比べてはるかに長距離を走行し、耐用年数も長いことから、サイバーリスクがより一層高くなっています。

こうした動向を反映する形で、全米貨物輸送協会（NMFTA）が発表した最新のトラック業界向けサイバーセキュリティ動向レポートでは、2025年のトラック業界における最重要課題の１つとしてサイバーセキュリティを挙げています。

Cyber attacks トラックへのサイバー攻撃が及ぼす高額な損失 trucks carry a hefty price tag

サイバーセキュリティの重要性がこれほどまでに高まっている背景には、商用車やトラックがサイバー攻撃を受けた際に発生する甚大な経済的損失があります。たとえば、新車のクラス8トラックの平均価格は10万ドル以上、ゼロエミッショントラックに至っては40万ドル以上に達することもあります。さらに、これらのトラックが輸送する貨物自体も数十万ドル相当の価値を持つ場合があります。つまり、サイバー攻撃によって商用車やその積載貨物が盗難・不正操作された場合、その被害額は極めて大きなものになるということなのです。

確かに、セミトレーラーそのものを盗むのは乗用車を盗むよりもはるかに困難です。しかし、今日のサイバー窃盗は、実際に車両を奪わなくても成り立ってしまいます。なぜなら、トラック輸送の運行を妨げることで、即座に深刻な影響を事業に与えるからです。つまり、車両をハッキングして無力化し、車両の解放と引き換えにフリート事業者や自動車メーカーに身代金を要求すれば十分なのです。このようなランサムウェア攻撃は、一般の乗用車では大きな金銭的効果は見込めないかもしれませんが、例えば50万ドル相当の生鮮食品を積んだ商用車のオーナーであれば、支払いに応じる可能性は高くなります。さらに、ランサムウェア攻撃が長期間にわたり、トラックフリート全体が数週間にわたり運用できなければ、運送会社によっては事業継続が不可能になるリスクすらあります。

コネクテッドカーを上回る広範な攻撃対象領域

商用トラックには、フリート管理システムなどの複雑で大規模なコネクテッドシステムが搭載されています。これらのシステムの多くは地域ごとの規制によって義務付けられており、潜在的なサイバー脅威に対して広範な攻撃対象領域を生み出す要因となっています。実際、一部の運輸規制では、運転時間を記録するためのELD（電子記録装置）やその他のテレマティクス機器の搭載が義務付けられています。

こうしたサードパーティ製の機器は、多くの場合、車両の生産後にフリートの所有者によって後付けされます。そのため、これらのデバイスは自動車メーカー（OEM）のサイバーセキュリティ管理プロセスには含まれておらず、通常はサプライチェーンにも組み込まれていません。このため、OEMが車両全体のサイバー保護を確実に担保することは困難となり、結果として攻撃対象領域がさらに広がる要因となっています。

トラックがハッキングされたときの危険性

コネクテッドカーと同様に、コネクテッドトラックの分野でも日々新たなソフトウェアの脆弱性が発見されています。これらの脆弱性を悪用して、ハッカーがブレーキやステアリングなどのセーフティ関連システムや制御システムを侵害したり、また個人情報などへ不正アクセスする恐れがあります。

大型商用車はその巨大なサイズと重量ゆえに、万が一ハッキングによって重要な車両システムが乗っ取られた場合、その被害や危険性は大きくなります。たとえば、15トンのセミトレーラーが高速走行中に衝突事故を起こせば、生命に関わる危険性が想起されますし、そのサイズのトラックが危険な薬品を輸送していた場合には、さらにひどい被害をもたらす恐れがあります。

将来的に自動運転トラックの普及が進めば、精巧に仕組まれたハッキングによって都市全体の物流に影響する事態も想定されます。また、想定されるシナリオとして、犯罪者やテロリストにより複数のトラックが同時に橋や主要な高速道路のジャンクションで停止または立ち往生させられた場合、救急隊や警察といった緊急車両が特定の地域や重要インフラ施設にアクセスできなくなる恐れがあります。

データプライバシーもまた、重要な懸念事項のひとつです。現在のトラックは、膨大な量のデータを生成・収集しており、その中にはビジネス上の機密情報や個人に関するデータも含まれています。ハッカーは脆弱性を悪用して、トラックが輸送している貨物の内容、配送スケジュール、さらには運転手に関連する個人識別情報（PII）などのデータへ不正アクセスする恐れがあります。

トラックの電子記録装置（ELD）を標的としたハッキング

商用トラック特有のハッキングシナリオとして考えられるのが、ELD（電子記録装置）の不正操作や無効化です。国によっては、ドライバーが1日に運転できる時間の上限が法令によって規定されており、その運転時間はELDによって自動的に記録されます。しかし、もしこのELDが改ざん・無効化された場合、ドライバーはシステムをごまかして、１日の上限を超えた運転時間を記録することが可能となってしまいます。こうした不正行為により、公共の安全を脅かすということ以外にも、フリートオーナーに対しても法的責任や罰金などが発生する恐れがあります。

商用トラックメーカーが検討すべきサイバーセキュリティ対策

UNR 155 や ISO/SAE 21434 に代表される自動車サイバーセキュリティのために規定された新たな規制・標準は、コネクテッドカーやトラックをサイバー攻撃から保護し、車両の安全性を確保することを目的としています。残念ながら、これまで確認できる限り、これらの規制は比較的低いセキュリティレベルを設定しています。規制の求める要件を単に「チェックボックスを埋める」形で満たすだけでは、実際の脅威に対して車両を防御するには不十分であることが近年急増している車両へのサイバー攻撃からも明らかです。

増大するサイバー脅威から自社のフリートを守るために、トラックメーカーは専用のサイバーセキュリティ保護メカニズムを導入する必要があります。乗用車および商用トラック向けにサイバーセキュリティソリューションを実装してきた経験から、こうした戦略を構築する上での基本的な要素を以下にご紹介します。

セキュリティ・バイ・デザインの導入

「セキュリティ・バイ・デザイン」のアプローチは、自動車ソフトウェア開発のあらゆる段階においてセキュリティ対策を自動的に組み込むことを目的としており、トラックメーカーはセキュリティを強化するとともに、開発サイクルの短縮を図ることが可能になります。開発初期のアーキテクチャ設計段階から、実際のコーディング前までに潜在的な脅威や脆弱性を事前に特定・把握するため「脅威分析およびリスク評価（TARA：Threat Analysis and Risk Assessment）」を実施することが重要です。さらに、TARAプロセスを自動化することで、OEMは品質の向上と市場投入までの時間短縮を同時に実現でき、トラックのライフサイクル全体にわたってTARAを継続的に更新していくことも可能になります。

車載IDPS（侵入検知・防御システム）の組み込み

自動車向けに特化した高度な侵入検知·防御システム（IDPS：Intrusion Detection and Prevention System）は、トラックの車載ネットワークやECU（電子制御ユニット）をサイバー攻撃から保護する手段です。自動車用IDPSは、車載通信をリアルタイムで監視し、あらかじめ定義されたルールに基づいて異常な通信を検出します。不審なトラフィックはリアルタイムで遮断されるか、クラウド上のフリート監視セキュリティオペレーションセンターに送られ、分析と対応が行われます。IDPSは自動車のイーサネットやCANネットワークの保護以外にも、テレマティクスやインフォテインメントなどの外部と接続するホストECUの保護にも適用可能です。

脆弱性の特定と対策のためのペネトレーションテストの実施

ペネトレーションテストは、開発ライフサイクル全体を通じて、車両のソフトウェアおよびハードウェアに潜む脆弱性を特定するための一般的な手法です。トラックメーカーは、ECUレベルおよび車両レベルでのテスト、またコードレビューに対応した自動車向けペネトレーションテストサービスやツールを活用すべきです。また、既知の自動車テストケースに基づく自動化ファジングテストを導入することで、開発初期段階においてゼロデイ脆弱性やコンフィグレーションミスを発見することが可能になります。

脆弱性のスキャン

コネクテッドトラックのセキュリティ確保と規制への適合を実現するためには、車載ソフトウェアにおける脆弱性の発見と緩和が重要です。そのためには、サプライチェーン全体にわたるすべてのソフトウェアコンポーネントに対し、サイバーセキュリティの状況を可視化できる脆弱性管理ツールが有効です。こうしたツールは、AUTOSAR、Linux、Androidなどのバイナリからのソフトウェア部品表（SBOM：Software Bill of Materials）の自動抽出に対応し、さらに既知および私的な脆弱性データベースに基づく継続的な脆弱性スキャンを実施できる必要があります。

商用車フリートの保護に向けたVSOCの確立

多くの商用トラックOEMは、リアルタイムでサイバー攻撃を監視・分析・対応するために、専用の車両セキュリティオペレーションセンター（VSOC：Vehicle Security Operations Center）の構築を進めています。
これらのVSOCは、車両フリートに搭載されたセンサーやコンポーネントから生成される非常に多くのデータを収集・分析するXDR（Extended Detection and Response）プラットフォームを使用しています。高度なAI分析技術を用いてデータを分析、異常を検出し、サイバーアナリストが迅速な調査と対応を実行できるようインサイトを生成します。

トラックフリートのサイバーセキュリティ対策に最適なプロセスの確立やふさわしいツールの導入をご検討中ですか？ぜひお気軽にお問い合わせください。

The post トラックのサイバーセキュリティ：脅威に立ち向かう appeared first on PlaxidityX.

このテクノロジーによって、非常に素晴らしいことが実現するわけですが、技術的な欠陥やセキュリティ侵害があった場合、どういったことが起こるのでしょう？誤作動を起こしたUberの自動運転車により歩行者が死亡する事故が2018年に起きましたが、これは憂慮すべき問題です。ウェブにすべてが接続された世界で、悪意のあるハッカーがADASシステムにアクセスし、自動車が見て感知しているものを操作したら、どういった事態が起きるのでしょう？当社ではこの問いに答えるため、車載用グレードのイーサネットカメラでPoC（概念実証）を行い、カメラをハッキングするにはどれだけの労力が必要なのか、そしてハッキングによってどの程度のダメージが引き起こされるかを調査することにしました。

設定

リサーチでは、スタンドアロンの車載グレードイーサネットカメラ（法的な理由で、ブランド名を開示することはできません）を使用しました。このカメラは現在量産されているもので、リアビューカメラとしてOEMに採用されています。このカメラは私たちがコンバーターを使用してコンピューターへ接続したBroadR-Reachイーサネットインターフェイスを備えています。カメラはADAS ECU （クライアント）に相当するバーチャルマシン（VM）にライブビデオフィードをストリーミングする一方、同じネットワーク上にある2つめのVMは侵害されたECUをシミュレートしました。ホストマシンはこれらのVMとカメラを同じネットワークにつなぐスイッチとして使用されました。この設定は下の図1と2に示されています。

図1：ネットワーク設定：ハッカーは侵害されたECUを用いてサイドから悪意のあるデータを注入する。

図２：物理的設定：電力ケーブルとBroadR-Reachケーブルに分岐するケーブルにカメラは接続している。電力ケーブルは外部電源に、BroadR-Reachケーブルはコンピューターにつなぐためコンバーターに接続されている。

車載カメラの仕組みを理解する

最初のステップでは、コンピュータシステムを攻撃しようとする場合と同様、車載イーサネットカメラの仕組みを理解することから始めました。まずカメラがネットワークとどのように通信するかを確認しようとしたところ、2つのオープンUDPポートがあるのを発見しました。

ポートの1つはDHCPの実装に使用されており、電源に接続すると、カメラはUDPブロードキャストパケットを送信しIPアドレスを受信しました。DHCP「サーバー」がADAS ECUに実装されており、応答データの中でIPアドレスを送信することによってそのリクエストに応答しました。2つ目のポートはコマンドとコントロール（C&C）に使用され、ADAS ECUは、例えばビデオストリーミングの開始コマンドや停止コマンドを送信することでカメラと通信していました。

カメラのコマンドを理解し再現できるようになった後、ビデオストリーミングの中で送信されている実際のデータの調査に移行しました。ほとんどのイーサネットカメラではTSN（Time-Sensitive Networking）はビデオの転送にAVB プロトコルを用いています。このプロトコルは、ヘッダーおよびデータペイロードの2つの部分から構成されています。ヘッダーの長さは、ペイロードによって異なります。ペイロードは事前定義されたさまざまなオーディオまたはビデオ形式にすることができます。このカメラでは24バイトのヘッダー、 JFIF （JPEG File Interchange Format：JPEGファイル交換形式）のペイロードが使用されていました。

図3：Wiresharkパケットキャプチャ

上の図3はカメラのライブストリーミングからのWiresharkパケットキャプチャを示しています。パケットの最初の14バイトは通常のイーサネットフレームで、それにパケットデータが続きます（青で強調表示）。データは24バイトのヘッダーを備え、実際のペイロードはスタートマーカ（SOI）から始まり、白で強調表示されています。「JFIF」インディケータはオレンジ色で表示されています（この文字列はJFIF基準に従ったヌル終端なので00バイトを含みます）。

つまり、カメラは十分な速さで継続的に静止画像を送信することで、ライブビデオストリーミングに見えるものを作り出しているのです。画像データは MTU (maximum transmission unit：最大転送ユニット)より大きいため、すべての画像はパケットに分割され、クライアントが再構成します。

ADAS ECUに対する攻撃

今までのところで、カメラがどのようにネットワークと接続し通信するのかを説明しました。さて、いよいよお楽しみの始まりです！このカメラはJFIF形式を用いているので、デフォルトでビデオストリーミングの画像送信を簡単に阻害する方法があります。JFIF規格は2バイトをSOIに2バイトをエンドマーカ（EOI）に含めることで機能します。これらは常にそれぞれ0xFFD8と0xFFD9でなければなりません。私たちは、Pythonのscapyライブラリを使って、ストリームを受信しているクライアントに1 万分の 1 秒ごとにEOIバイトを挿入する単純な関数を作成しました。その結果は図4に表示されています。

The post 車載イーサネットカメラに対するハッキング appeared first on PlaxidityX.

UNR 155やISO/SAE 21434などの自動車サイバーセキュリティ規制は、コネクテッドカーをサイバー攻撃から保護し、車両の安全性を確保することを目的としています。本ブログ記事では、急速に拡大する自動車規制の状況について、サイバーセキュリティマネジメントシステム（CSMS）に焦点を当て、そのようなシステムを導入する際の最善の方法について実践的なアドバイスを提供します。

高まる自動車サイバーセキュリティの必要性

コネクテッドカーとソフトウェア・デファインド・ビークル（SDV）は、今までの運転スタイルを一変させています。戦闘機の10倍のコード行数を持つ今日のSDVは、「車輪にコードが乗っている 」とも形容されます。

車両に搭載されるソフトウェアが多ければ多いほど、リスクは大きくなります。新しいソフトウェアの脆弱性は定期的に公表され、事実上すべてのブランドの何百万台もの自動車に影響を及ぼしています。ソフトウェアの脆弱性やオープンソース·コードをハッカーに悪用されると、セーフティクリティカルなシステム（ブレーキ、ステアリングなど）を侵害したり、個人データにアクセスしたり、あるいは遠隔地から自動車を始動させたりすることもできます。 例えば、最近公表された起亜コネクト·システムのソフトウェアの脆弱性では、ハッカーがGPS経由で車の位置を追跡し、ドアの開錠と施錠、エンジンの始動·停止などの操作が可能であることが明らかになりました。

このような課題は、今後ますます増加すると予想されます。自動運転車は、V2Xやその他のテクノロジーを使ってインフラや他の車と通信しながら、現在のSDVよりも数倍多くのコードを使用することになるためです。未来の自動車の安全性とセキュリティを確保するために、OEMは安全なソフトウェア開発プロセスを導入する必要があります。

規制当局の期待に対応すること

このようなリスクの高まりを受けて、近年、自動車のサイバーセキュリティ対策に関する標準や規制は大きく変化しました。特に、UNR 155/156やISO/SAE 21434は共に、サイバーセキュリティを考慮した開発プロセスや製品を確実にするために、自動車メーカーにとって事実上の指針となっています。

これらの規制やその他の世界的なサイバーセキュリティ指令は、OEMとそのサプライヤーが製品を開発・管理する方法に多大な影響を与えています。UNR 155は、潜在的なサイバー脅威を検知し、サイバー攻撃から車両を保護するためのリスクベースの管理フレームワーク（別名サイバーセキュリティマネジメントシステム、CSMS）の導入をOEMに求めています。

UNR155は、開発、生産、ポストプロダクションの各段階で実施すべきプロセスを規定していますが、そのようなプロセスを実行するために使用すべき特定のツールや製品については規定していません。UNR156は、ソフトウェア更新管理システム（SUMS）の要件を規定しています。これらの規制を合わせると、業界に新たな基準を設けることになり、OEMは自社の自動車がサイバーセキュリティとソフトウェア更新に関する厳格な基準を満たしていることを実証する必要があります。

ISO/SAE 21434 は、UNR 155 を補完する世界的な業界標準です。この規格は、コンセプト、製品開発、生産、運用、保守に関するサイバーセキュリティリスク管理のエンジニアリング要件を規定しています。ISO/SAE 21434は、乗り物や輸送手段を含む車両と自動車のセキュリティ保護に取り組み、サイバーセキュリティを車両の製品開発プロセスに統合するためのガイダンスを提供しています。

UNR 155とISO/SAE 21434の違い

UNR 155とISO/SAE 21434は密接に結びついていますが（例えばTARAに関して、ISO/SAE 21434はUNR 155から参照されています）、相違点もあります。以下の表はいくつかの重要な点についてまとめました。

UNR155が規制要件を定めているのに対し、ISO/SAE21434は自動車サプライチェーン全体でこれらの要件を実施するための、より詳細な枠組みを提供していることがわかります。

UNR 155とISO/SAE 21434は規制のごく一部に過ぎない

現在、ほとんどの自動車メーカーは、UNR 155/156やISO/SAE 21434などのサイバーセキュリティ規制・標準に準拠する必要性を十分に認識しています。しかし、これらの規制や標準はごく一部に過ぎません。世界規模では、自動車業界に関連するサイバーセキュリティ規制、基準、ガイドライン、ベストプラクティスは数十にもなります。一部を以下に紹介します。

GB/T

中国版UNR155として知られているGB/Tは、すでに非常に成熟した段階にあり、2025年に発効する予定です。これらの規格は、電気自動車のリモートサービスと管理システムのサイバーセキュリティに関する要求事項と試験方法、車両のサイバーセキュリティに関する一般的な技術要求事項、車両ゲートウェイのサイバーセキュリティに関する技術要求事項と試験方法などを規定しています。

ASPICE for Cybersecurity

Automotive SPICE® (Software Process Improvement and Capability Determination)は、自動車業界が要求する品質と安全基準を満たすソフトウェア製品を開発するために、自動車ソフトウェア開発組織が従うべき一連のプロセスと手法を定義したものです。ASPICEは、要求事項の抽出からソフトウェアのテストと検証に至るまで、ソフトウェア開発ライフサイクル全体をカバーしています。サイバーセキュリティ対応のためにASPICEの拡張版が2022年2月に発行されました。OEMやサプライヤのベースラインとして機能するこの拡張版は、要求事項の抽出、サイバーセキュリティの実装、リスク処理の検証、リスク処理の妥当性確認など、サイバーセキュリティ評価の新たな分野を定義しています。

ENISA 

欧州連合サイバーセキュリティ機関（ENISA）は、欧州全体で高いレベルで共通のサイバーセキュリティ基準を実現することを目的とした欧州連合の機関です。2004年に設立され、EUサイバーセキュリティ法によって強化されたENISAは、EUのサイバー政策に貢献し、サイバーセキュリティ認証制度によってICT製品、サービス、プロセスの信頼性を高めています。

NIST 

NIST サイバーセキュリティ・フレームワークは、あらゆる規模の企業がサイバーセキュリティ・リスクをよりよく理解し、それを管理、低減し、ネットワークとデータを保護できるように支援するものです。NIST サイバーセキュリティ・フレームワークは、以下に示す5 つの中核的機能、あるいは柱に基づいて構築されています。 特定（Identify）、保護（Protect）、検知（Detect）、対応（Respond）、復旧（Recover）です。

OEMにとっての規制遵守の意味

UNR155は、2024年7月にすべての新車に対して発効されました。これに伴い、OEMはUNR155加盟国（EU加盟国など）で販売・登録されるすべての新車について、UNR155型式認証要件に適合していることを証明する必要があります。これは世界の自動車産業にとって大きな節目であり、自動車バリューチェーン全体にとって大きな重要な課題として、真摯に取組みが行われてきました。

OEMは現在、型式認証を取得するためにコンプライアンス準拠の証明が必要であり、ソフトウェアサプライヤに対しても、車両の設計、開発、運用、保守のプロセスにサイバー耐性を組み込むことを要求しています。

そして、この大きな変化が及ぼすビジネスへの影響はすでに現れています。昨年末、ポルシェはベストセラーのICEエンジン搭載SUV「マカン」の販売終了について、サイバーセキュリティ規制のため2024年春に欧州連合内の市場から撤退すると発表しました。ポルシェは、新しい規則に準拠するために必要なアップデートが非常に複雑かつ高コストになるためと説明しています。同様の動きは、VWやアウディの車種でも見られており、この例が特別なのではなく、その他の類似の発表のうちのひとつに過ぎないといえます。

サイバーセキュリティマネジメントシステム（CSMS）とは？

CSMSは、サイバーセキュリティの実践と対策が開発プロセスと車両ライフサイクルの各段階にわたって適切に適用されることを保証するために、組織のプロセス、責任、ガバナンスを定義する体系的なアプローチです。特定のセキュリティツールや１つの対策に焦点を当てることが多い従来の対策とは異なり、CSMSは組織のサイバーセキュリティリスクを管理するための包括的なアプローチとなります。CSMS の詳細な仕様は、UNR 155 の文書に記載されています。

CSMSの核となる構成要素には以下のものがあります。

• ポリシーと手順 – 脅威に積極的に向き合い、機密情報を保護するためのベストプラクティス、ポリシー、コントロールを策定。組織の業務全体を通じてサイバーリスクを特定、評価、対処するための構造的なアプローチ。
• リスク管理 -組織が製品やサービスのライフサイクル全体を通じて、サイバーリスクをタイムリーに特定、評価、軽減するシステムを構築。
• インシデント対応 – サイバーインシデント対応計画（CIRP）と呼ばれるサイバーセキュリティインシデントへの対応および管理プロトコルの策定。

現在、UNECE加盟国のOEMは、新車の型式認証を受けるためにCSMS適合証明書（CoC）を取得しなければなりません。CoCは、認定型式認証機関による厳格な審査プロセスを経て付与されます。

CSMSの導入方法

CSMSを確立し、規制コンプライアンスを達成することは、自動車サイバーセキュリティの知識、熟練したリソース、専用ツールを必要とする複雑な取り組みです。幸いなことに、ISO/SAE 21434は国際的に認知されたCSMSの実施ガイドラインを提供しており、多くのOEMやTier1サプライヤが参考にしています。

組織レベルでは、OEMは、ISO/SAE 21434の品質管理要件に沿った手順、方針、戦略など、組織レベルで開発および生産を監視するためのプロセスを整備する必要があります。これには、企業文化、トレーニング、意識などの分野があります。

脅威分析とリスク評価（TARA）は、製品レベル（ECUなど）でのCSMS実装の最初のステップです。TARAは、車両アーキテクチャを分解し、重要なソフトウェア・コンポーネントを特定し、潜在的なサイバー脅威を評価し、これらの脅威の影響と実現可能性を分析します。このステップでは、リスクやギャップを明らかにするために、ペネトレーションテストやファジングテストが行われることが多くあります。OEMはTARAの結果を受け、（リスクの重大性に応じて）リスクと脆弱性を軽減するために必要な修正（すなわち、ソフトウェアへの変更）を実施します。このプロセスの最後のステップは検証と妥当性確認であり、システム全体が安全であり、すべての脆弱性にパッチが適用されていることを確認するための最終テストを含んでいます。このサイクル全体は、ISO/SAE 21434に明記されています。

CSMS導入の課題

自動車業界には複雑で特殊な課題があるため、ISO/SAE 21434に基づくCSMSを導入する際、OEMやTier1は重要な課題に直面します。

• 他の規格とのシームレスな統合： サイバーセキュリティは、OEMが準拠しなければならない多くの規格（ISO9001、ISO26262、ASPICEなど）の一つに過ぎません。CSMS は、他のすべての品質および安全規格と組織レベルでシームレスに連携している必要があります。
• 開発サイクルに影響を与えるサイバーセキュリティ： サイバーセキュリティは製品開発サイクルにも影響します。なぜなら、全体的な開発フローの中でセキュリティを実装する必要があるからです。ISO/SAE 21434では、サイバーセキュリティサイクルは継続的であるべきであり、生産段階とその後の段階をカバーすべきであると述べています。
• 自動車のサイバーセキュリティ専用ツールの必要性： OEMの企業ネットワークの保護に使用されている従来からあるITツールは、コネクテッドカー特有の課題に対応する機能を備えていません。自動車のサイバーセキュリティは開発段階もカバーする必要があるため、IT環境で使用される多くの一般的な標準（ISO27001など）、手順、ツールだけでは対応できません。
• サプライチェーンの統合： サプライヤは、自社のサプライチェーン全体でサイバーセキュリティの実践を確実に行う必要があります。これは、自動車のサイバーセキュリティ標準に精通していない可能性のあるサブサプライヤと取引する場合、問題となることもあります。
• 継続的な脆弱性管理： この規格では、自動車のライフ（10～15年）を通じて、継続的に脆弱性を監視、評価、緩和することを求めています。このようなプロセスを確立し、維持することは、複雑でリソースを多く必要とします。
• 文書化とトレーサビリティ： ISO/SAE 21434 は、サイバーセキュリティに関連する活動、決定、その理由について詳細な記録を求めています。このレベルの文書を維持し、トレーサビリティを確保することは、多くのサプライヤにとって大きな課題となります。
• リソースの制限： CSMSの導入には、多大な時間、人材、資金が必要です。多くのサプライヤ、特に小規模のサプライヤでは、規格のすべての要求事項を満たすために十分なリソースを割り当てることが困難であると感じるかもしれません。
• スキル不足：すべての製造業者が CSMS 導入に必要な社内リソースやサイバーセキュリ ティ分野の専門知識を持っているわけではありません。多くの OEM は、CSMS コンプライアンスを専門とする外部のコンサルタントやサービスプロバイダにプロジェクトを依頼しています。
• 認証プロセス： 認証監査の準備と実施は複雑で時間のかかるプロセスであり、コンプライアンス達成のために十分な準備と複数回の修正が必要になることもあります。

PlaxidityX（旧アルガス）が支援します

自動車のサイバーセキュリティ規制が複雑化する中、コンプライアンス達成には、自動車のプロセスに対する深く包括的な理解、自動車サイバーセキュリティのノウハウ、実績のあるコンプライアンス経験が必要です。

PlaxidityXのサイバーセキュリティ専門家は、車両レベルおよびECUレベルのCSMSおよび型式認証要件によって義務付けられたプロセスを確立するために、OEMおよびTier 1と多くのコンプライアンスプロジェクトを実施してきました。 ギャップ分析、プロセス定義、デプロイ、継続的なサポートなど、CSMS導入のための実証済みの手法により、自動車メーカーはサイバーリスクを最小限に抑えつつ、自動車セキュリティコンプライアンスを達成することができます。

自動車ペネトレーションテスト、 TARAとサイバーセキュリティアーキテクチャ設計、 UNR 155とISO 21434サイバーセキュリティコンプライアンスを含む包括的な自動車サイバーセキュリティサービスは 、自動車メーカーが製品開発と生産の各段階を通じてサイバーセキュリティプロセスを統合する支援をしています。

The post 自動車サイバーセキュリティ：急速に変化する規制状況への対応ガイド appeared first on PlaxidityX.

これに心当たりがありますか？これはあなただけではありません。こうした高度なサイバー技術を用いた車両盗難は今やパンデミックのように広がっており、その影響は業界全体、つまり車の所有者、自動車メーカー（OEM）、フリート運用者、保険会社に至るまで、誰もがその被害を受けているのです。

従来手口のホットワイヤリングから高度なハッキングへ

これまで車両盗難に必要な道具といえば、窓を割るための大きな石とイグニッションをバイパスするためのホットワイヤーが定番でした。それさえあれば、車を簡単に持ち去ることができたのです。そして約20年前、イモビライザーが登場し、盗難防止の「大定番」となりました。しかし、言うまでもなく、現在のハイテクな車両盗難手口にはイモビライザーはもはや対抗できません。私たちはこの現実を近所の道路でも日々目の当たりにしているのです。

セキュリティの観点から見ると、今日のソフトウェア・デファインド・ビークル（SDV）の高度な技術は諸刃の剣です。キーを使わずにすむ技術や、その他のスマートなコネクテッドカーのシステムは、ドライバーにとって安全性と利便性を高めてくれる一方で、同時に新たなアタックベクトルにもなっています。車両の盗難ではこれらの技術を悪用し、わずか30秒足らずで車のロックを解除し、エンジンをかけて盗み出すことができるのです。

車両盗難の増加はもはやエピデミックレベル

車の盗難は、多くの国で深刻な問題に発展しています。たとえばカナダだけでも、2023年だけで自動車盗難による保険金請求が15億カナダドルを超えました。アメリカでも同様に、同年に盗難された車両の数は100万台を超えています。「Crime trends report（犯罪動向レポート）」によると、自動車盗難は2023年前半では39％、後半には21％増加しています（グラフ参照）。

ソース：Council on Criminal Justice、「Crime Trends in U.S. Cities, Mid-Year 2023 Update Report 」

自動車エコシステムに及ぼす深刻な影響

車両の盗難は、車の所有者だけみても毎年80億ドル以上の損失をもたらす数十億ドル規模の犯罪です。サイバー盗難は、車の所有者に精神的な苦痛をもたらすだけでなく、自動車エコシステム全体に影響を及ぼします。

• OEM（自動車メーカー） – 一部の市場や国では、特定の自動車ブランドやモデルが盗まれやすい車として知られており、このような「レッテル」は、メーカーのブランドイメージや販売に悪影響を与えます。
• 保険会社 – 車の盗難率が高いということは、保険会社への請求が増えることを意味し、その結果として消費者やフリート運用者に課される保険料が引き上げられます。こうしたトラブルやコストを避けようと、盗難されやすい車種に対する保険の引き受けを渋る保険会社が増えてきています。
• フリート運用者 – 保険会社が損失回避のために引き受けを控える中、多くのフリート運用者は車両を自社で保険管理（自家保険）し、盗難による損失を自己負担でまかなうようになっています。

自動車盗難の増加が消費者に与えている影響は、最近発表された「Deloitte 2025 Global Automotive Consumer Study（デロイト 2025年 グローバル自動車消費者調査）」にも表れています。ヨーロッパ、アジア、アメリカの消費者に対し、コネクテッドサービスのうち追加料金を支払ってもよいサービスは何かを尋ねたところ、「盗難防止機能」は最も多く挙げられたサービスの一つでした。回答者の49％〜88％が、自身の車両を盗難から守るためであれば「ある程度支払ってもよい」または「ぜひ支払う」と答えています。

サイバー車両盗難手口

車両盗難は、自動車の発明とともに始まったと言っても過言ではありません。変わったのは盗む手口だけです。車両技術が進化し続けるのと同様に、車両盗難に用いられる手口もますます高度化していくと考えて間違いないでしょう。

現在よく使われている代表的な手口には、以下のようなものがあります。

1. CANインジェクション攻撃：この手法は、車両のCANバスの脆弱性を悪用し、物理的な破壊なしにわずか30秒以内で車を盗むことを可能にします。ダークネット上で購入可能な既製のハッキングデバイスを使って、攻撃者はイモビライザーを無効化し、ドアのロックを解除、エンジンを始動させてそのまま車を持ち去ることができます。
2. キーフォブ・クローン：この手法は、車の所有者が紛失したキーを再プログラムする際にに自動車メーカーが使用するタブレット端末を利用します。こうした端末はブラックマーケットで簡単に入手可能で、攻撃者はそれを使ってダッシュボードのポートやヘッドライト経由で車のネットワークに接続します。一度デバイスが車載ネットワークに接続されると、攻撃者は不正なキーを正規のものとして登録するコマンドを実施し、車の制御が可能になります。

3. リレーアタック：通常は2人1組で行われ、それぞれが小型の携帯デバイスを持っています。1人はキーフォブの近く（例：車の所有者の家の前など）、もう1人は車の近くで準備します。最初のデバイスがキーフォブの信号をキャッチし、それを2人目のデバイスに中継します。2人目のデバイスがその信号を車に送ることで、車はキーが近くにあると誤認し、攻撃者はエンジンを始動させることができるのです。こうして、実際にキーがなくても車を持ち去ることが可能になるのです。

サイバー車両盗難がこれほどまでに蔓延している理由のひとつは、これらの手口のいずれも特別な技術的知識やサイバーセキュリティの専門知識を必要としないことです。犯人たちは、専用のデバイスをインターネット上で購入し、その接続方法さえ覚えれば、あとはそのデバイスが自動的に盗難を実行してくれるのです。

問題への対策

車両盗難が深刻な問題となっている国々では、盗まれた車両の追跡・回収に多大な労力が費やされています。多くの場合、保険会社に義務付けられていることもあり、車の所有者やフリート運用者は盗難車両追跡サービスを利用しています。しかし、本当に必要なのはそもそも車を盗まれにくくすることです。

消費者が盗難防止にお金を払う意思があることはわかっています。市場のニーズに応えるために、以下の3つの柱に基づいてソリューションが設計されるべきです。

1. 検知 – 不正な車載ネットワークへのアクセスや、不正なキーフォブの登録といった盗難の試みを検知します。
2. 防止 – 攻撃によって一時的に無効化されたイモビライザーの再有効化や、CANネットワーク上を流れる偽のメッセージのブロックなど、リアルタイムで盗難を防止するアクションを実行します。効果的な防止には、「正当な操作」と「不正な操作」（例：新しいキーの再登録）を正確に見分け、不正なものだけを阻止する能力が求められます。
3. 将来への備え – 今後登場する新たな車両盗難手口にも対応できるよう、継続的なソフトウェアアップデートを可能にします。現在、主なアタックベクトルは3つですが、明日にはまったく新しい手口が登場するかもしれません。今日生産された車両は、平均して10〜15年間道路を走り続けることになります。盗難防止ソリューションは、車両のライフサイクル全体を通じてOTA（無線）によるセキュリティアップデートを可能にするインフラとツールを備えていなければなりません。

路上を走る車の保護：アフターマーケットでの防御の必要性

UNR 155 や ISO21434 などの新たなサイバーセキュリティ規制・標準への対応のため、自動車メーカーは新型車両の開発においてサイバーセキュリティを考慮するようになっています。これには、セキュアコーディング、車載ネットワークにおける侵入検知・防御機能、そしてフリート保護のための VSOC（Vehicle Security Operations Center：車両セキュリティオペレーションセンター）機能などが含まれます。

しかし、盗難防止対策に関して言えば、業界はいまだに後手に回っているのが現状です。OEMとしては、盗難防止機能（あるいはサービス）を車両に追加したいと考えているものの、それを後付けで行うことはできません。仮にOEMが今日、車両盗難の急増に対応するために新たなセキュリティ対策の設計を始めたとしてもそれらが市場に出回るまでには数年かかります。では、すでに道路を走っている何百万台もの車両をどうやって守ることができるのでしょうか？

車両に既知の脆弱性が発見された場合、OEMは該当する車両に対してソフトウェアアップデートを提供することができます。しかし実際には、すべての車両のすべての脆弱性に対応することは不可能です。もしそれが可能であれば、サイバー手口を用いた車両盗難はほとんど存在しないはずです。さらに、何百万台もの車がすでに走行している現状では、そのモデルの全ての車両がアップデートを完了するまでに時間がかかります。その間、何が起きるのでしょうか？

まさにこの“隙間”こそが、先に述べた三本柱（検知・防止・将来への備え）に基づいた新しいアフターマーケット向けの盗難防止サービスの必要性を生み出しています。車両盗難という大きな社会問題と盗難防止にお金を払ってもよいという消費者の意識の高まりが、サイバー攻撃に特化した新しいタイプの保護サービスというビジネスの可能性となっているのです。

私たちがお手伝いします

PlaxidityX vDome はAIを活用した盗難防止ソリューションで、悪意ある盗難の試みを200マイクロ秒以内に検知し、無力化することができます。 vDome はドアのロック解除やエンジン始動など、車両を盗もうとする電子的な操作を含む不正な車両ネットワーク上の挙動を検知し、リアルタイムで盗難防止アクションを実行します。

この vDome ソフトウェアはすでに Vodafone Automotive の盗難防止ソリューションにも統合されています。

vDomeが最新のサイバー盗難手口から車両を守る方法に関する詳細を知りたい場合はお問い合わせください。

The post 車両盗難への備え：新たなサイバー攻撃に必要な車両盗難防止対策の進化 appeared first on PlaxidityX.

こうした措置を取る背景には、国家安全保障があります。データへのアクセスや接続技術（例：IoT）を制御することは、敵対勢力にとってサイバースパイ活動を行ったり、重要なインフラを攻撃したりするための手段となり得ます。近年、輸入されたハードウェアやソフトウェアに隠された「バックドア」が発見されるケースが相次いでおり、ハッカーがこれを利用して米国内のさまざまな活動を密かに監視し、データを収集していることが明らかになっています。

この地政学的な技術戦における最新の動きとして、ICTの規制が自動車業界にも拡大されました。2025年1月14日、米国商務省は、中国およびロシアを原産とするコネクテッドカーのハードウェアおよびソフトウェアの販売・輸入を禁止する最終規則を発表しました。この規則は、2027年モデルの車両から適用されます。

では、この課題は米国市場で車両を販売するOEMにとってどういう意味があるのでしょうか？ 現時点では不明なことが多くありますが、明確なことが１点あります。それはOEM各社が、この連邦政府の規則にどのように対応するのか、今すぐに検討を始める必要があるということです。

コネクテッドカーをリスクと考える理由

規制当局によると、車両のコネクティビティ技術や自動運転システムに統合されたソフトウェアは、外部からの信号に対して脆弱であるとされています。これらの技術が「中国またはロシアによって設計、開発、製造、または供給された場合、非常に深刻で、容認できない国家安全保障上のリスク」をもたらすと指摘しています。

例えば、現在、多くの車両には複数のカメラが搭載されています。運転中、車両は周囲の映像を記録し、言い換えればリアルタイムで都市の地図を作成しているのと同じ状態になります。この情報が中国のクラウドに転送されると、中国政府はそのデータすべてにアクセスできるようになり、事実上あなたの車が偵察ツールへと変わってしまう恐れがあります。さらにソフトウェア・デファインド・ビークルは、ドライバーや所有者の個人情報を含む機密データを収集しており、これらの情報が外国の敵対勢力によって悪用されるリスクも懸念されています。

これらのリスクに加えて、現在の自動運転システムやADAS（先進運転支援システム）は、ハッカーが遠隔操作で車両を操ることを可能にするサイバー攻撃に対して脆弱である恐れがあります。外国の敵対勢力が悪意を持って大規模な車両フリートを乗っ取った場合、どのような深刻な事態が引き起こされるか想像してみてください。

規則はどうなっているのか

詳細を見ていきましょう。今回の新たな規則は、乗用車の車両コネクティビティシステム（VCS）および自動運転システム（ADS）に重点が置かれています。この規則により、中国やロシアに関連する企業が提供するハードウェアやソフトウェアを搭載したコネクテッドカー、またはそのようなコンポーネントを組み込んだ車両の販売や輸入が禁止されます。

ソフトウェアに関しては、この規則はオペレーティングシステム、ミドルウェア、アプリケーションソフトウェア、バックエンドシステムまで幅広く対象としています。ただし、ファームウェアやオープンソースソフトウェアは適用除外となります。ソフトウェア関連の禁止措置は2027年モデルの車両から適用され、ハードウェア関連の禁止措置は2030年モデルの車両から施行されることになります。

OEMは、本規則への適合を証明する「適合宣言（Declarations of Conformity）」を毎年提出することが義務付けられます。この宣言には、VCSのハードウェアおよび対象となるソフトウェアに関する詳細情報が必要で、さらに適正評価手続き文書も求められます。

自動車サプライチェーン全体に及ぶOEMへの巨大な影響

この措置によって影響を受けるのはどこでしょうか？

この規則の対象となるのは、米国市民または永住権を持たない中国またはロシアの市民や居住者です。つまり、キプロス在住のロシア人フリーランスのソフトウェアエンジニアが、サードパーティの車両サプライヤー向けにソフトウェアを開発する場合も、問題になる恐れがあるということになります。

企業レベルでは、さらに複雑な問題が生じます。 所有権、法的管轄、株主構成、または取締役会の構成を通じて、中国またはロシアから直接または間接的な影響を受ける可能性のある企業は、この規則の適用対象となります。例えば、ボルボ・カーは中国の持株会社によって所有されています。2027年にこの規則に適合するため、ボルボは所有構造や市場戦略の見直しが必要になるのではないでしょうか。

現在、多くのOEMが100社以上のベンダーからソフトウェアコンポーネントを調達・統合しているという事実を踏まえると、これらの規則がOEMおよびそのサプライヤーに及ぼす商業的影響は非常に大きなものとなります。

やってみないとわからないことだらけ

ここで問題の核心に迫ります。前述のとおり、すべてのコネクテッドカーは、中国またはロシア由来のコンポーネントを含まないとする適合宣言（Declaration of Conformity）を提出する必要があります。さらにOEMはこの宣言を裏付ける証拠を提出しなければなりません。では、どのようにして適合性を証明すればよいのでしょうか？

難しいのは、車両アーキテクチャ内の該当コンポーネントを特定することです。一般的な車両には50以上のECUが搭載されており、各ECUには、多くのサプライヤーから提供された数十ものソフトウェアライブラリが組み込まれています。さらに自動車のサプライチェーンは非常に複雑であり、OEMやTier 1サプライヤーであっても、下流のサプライヤーから受け取るコンポーネントに含まれるソフトウェアの詳細な構成を完全に把握していないケースが多いのが現状です。

多くの場合、問題の原因となるコンポーネントはサプライチェーンの奥深くに埋もれている可能性があります。UNR 155で義務化されているソフトウェアの脆弱性スキャンと同様に、OEMは外国の敵対勢力によって開発されたソフトウェアを特定するための高度なツールを導入する必要があるでしょう。問題となるコンポーネントが特定され、報告されれば、OEMはサプライヤーに対して問題のあるソフトウェアを含まない更新版の提供、または別の代替品の提供を求めることが可能になります。

この問題の複雑さを説明するために次の例を考えてみましょう。あるソフトウェア企業が中国の下請け業者と協力して開発したソフトウェアが、ミドルウェアスタックに統合されているケースを想定してください。この場合、車両メーカーはどのようにしてミドルウェア層まで深堀りし、車両アーキテクチャの一部となっているハードウェアやソフトウェアを特定し、リスクを軽減できるのでしょうか？

OEMが直面するコンプライアンスの課題

すでに作業部会が結成され、この規則が自動車のサプライチェーン全体に及ぼす技術的な課題について議論・分析が進められています。この初期段階では、OEMやサプライヤーは以下のようなハイレベルな課題に取り組んでいます。

• 非常に広範な適用範囲 – OEMは、政府の具体的な要求事項をまだ詳細には把握できていません。大枠の目標は示されたものの、常に細部にこそ課題が潜んでいます。北米の主要な自動車サプライヤー団体であるMEMA（Motor & Equipment Manufacturers Association）は、すでにこの規則の広範な適用範囲に懸念を表明しており、特に先進運転支援システム（ADAS）やバッテリーマネジメントシステム（BMS）について言及しています。

バックエンドシステムや通信サービスにおいて、具体的に何が禁止されるのかについては、さらなる明確化が求められています。おそらく最も重要な点として、対象となるハードウェアおよびソフトウェアコンポーネントを特定するための基準について明確な指針が示されていません。

• コンプライアンスのタイムライン – 既述のとおり、ソフトウェアの禁止措置は2027年モデルから適用され、ハードウェアの禁止措置は2030年モデルから施行される予定です。しかし、自動車の開発・生産サイクルの特性を考えると、この時間軸は大きな懸念事項となります。OEMやそのパートナー企業は、すでに次世代車両の設計・開発に着手しており、ハードウェアやソフトウェアの調達プロセスも進行中です。この段階で契約済みのサプライチェーンを変更しなければならない場合、多大な損失が発生する恐れがあります。
  これらの課題を踏まえ、MEMAはすでにサプライヤーが新たな規則に適合するための期間を、2年間延長するよう要請しています。その理由として、サプライチェーンの複雑性や、徹底した適正評価手続きの必要性を挙げています。
• 知的財産（IP） – もう一つの課題は、独自開発のソフトウェアに関連する知的財産の保護です。企業がソフトウェア部品表（SBOM）やハードウェア部品表（HBOM）を規制当局に提出する義務を負う場合、自社の知的財産が確実に保護され、競合他社に漏洩しないことを保証する必要があります。ここでの課題は、規制に準拠しながら、車両に中国やロシア関連のコンポーネントが含まれていないことを証明しつつ、機密情報や独自技術を守る方法を見つけることです。

お手伝いできることはありますか？

最近のサイバーセキュリティ規制への対応と同様に、OEMは禁止されたコンポーネントを特定し、報告するためのツール、プロセス、専門知識が必要になります。これには、例えばソフトウェアやハードウェアの資産に、中国またはロシア由来のコンポーネントがないかスキャンし、疑わしいコンポーネントを特定・報告するツールの導入が含まれる可能性があります。

UNR 155やISO 21434などのサイバーセキュリティ規制に対応するため、多くのOEMやサプライヤーはすでに資産の脆弱性スキャンを実施しています。しかし今回の新規則に対応するためには、新たなリスク管理プロセスやツールを導入し、中国やロシア由来の禁止コンポーネントを特定・検査し、必要に応じて交換する仕組みを整える必要があります。PlaxidityXはすでに、Software Supply Chain Security製品を強化し、SBOMをスキャンして禁止コンポーネントを特定し、レポートを生成するなど、OEMが新規則に準拠するための支援の準備を整えています。

さらにOEMは、ハードウェアとソフトウェアの調達段階で潜在的な問題を特定することを目的としたプロセスを設定し、内部監査と外部の第三者機関による評価を実施する必要があります。このような適正評価手続きを実施することで、開発プロセスの後半で予期せぬ問題が発覚するリスクを回避することが可能になります。

新規則への適合戦略の構築にお困りですか？PlaxidityX（旧アルガス）のサービスチーム にお問い合わせください。サプライチェーンに関する支援プロセスやツールに関して最適なアプローチをご提案いたします。

The post 自動車業界の技術戦：米国の対中・対露禁輸措置が引き起こす大混乱 appeared first on PlaxidityX.

動的SBOM（DSBOM）は、従来の静的SBOMに比べてソフトウェアセキュリティ評価を進化させたものです。静的SBOM分析では、ライブラリや依存関係を含むシステムコンポーネントの包括的な概要を提供しますが、動的SBOMはコードの実行中にサードパーティライブラリへの呼び出しを能動的に監視することで、リアルタイムのインサイトを追加します。

動的SBOMの際立った特徴は、アプリケーション内で実際に使用されているライブラリを正確に特定し、追跡できる能力です。このリアルタイムの監視により、ソフトウェアのエコシステムや潜在的な脆弱性をより正確に把握できるため、セキュリティ対策の優先順位を効果的に決定することが可能になります。

DSBOMの利点

動的SBOMは、セキュリティ対策の優先順位付けをより簡単かつ効果的に行います。以下の例を見てみましょう。静的SBOMでは、CVE-2023-31484がlibperl 5.36.0に関連していると報告されています。しかし、動的スキャンではこのアプリケーションのライブラリで使用されていないことが確認されました。一方で、動的SBOMによってアプリケーションがlibcurlをロードしていることが判明しました。これを静的SBOMと照合すると、libcurlのバージョンが7.86.0であり、これにはCVE-2023-27534が存在することが確認できます。

これで優先順位の判断が容易になりました。仮にこのアプリケーションのセキュリティ評価を行う必要がある場合、libperlに関連するCVE-2023-31484への対処は後回しにできます。一方で、libcurlに関するCVE-2023-27534は実際に使用されているライブラリに関連しているため、より緊急性が高く、優先的に対処する必要があります。

DSBOMの仕組み

初めに、「PlaxidityX DSBOM」は、動的ライブラリへのすべての呼び出しをトラップ割り込み、つまり「ブレークポイント」（x64およびARCH64で動作）に置き換えます。これは、メモリのアセンブリコードを置き換えることで実現されます。

そしてコードが実行されます。

動的SBOMを使用する際の検討事項

動的SBOMを活用する際には、以下の点を考慮することが重要です。

ItraceではなくDSBOMを使用する理由

ltraceは、printfのように繰り返し呼び出されるものを含め、外部ライブラリへのすべての呼び出しを記録するため、パフォーマンスが低下します。一方、DSBOMは各呼び出しを一度だけ記録することで、スピードと効率を最適化します。さらに、ltraceはアプリケーションからの直接的な呼び出ししか追跡できず、他のライブラリからの内部関数や推移的な呼び出しを把握することができません。これに対して、DSBOMはコード内の重要なパスを特定できます。例えば、特定の関数に脆弱性が存在する場合、DSBOMはその呼び出しがサードパーティライブラリ経由で行われた場合でもアラートを発することが可能です。

静的解析の補完にDSBOMを使用

動的SBOMは静的分析を補完するものですが、いくつかの理由から完全に置き換えることはできません。

1. 不完全なカバレッジ: 動的分析では、コードカバレッジが不十分な場合にアプリケーションのすべての機能を網羅できない可能性があります。そのため、潜在的な脆弱性を特定するためには、静的分析の併用が必要となります。
2. 依存関係の影響:特定のライブラリがメインアプリケーションで直接使用されていなくても、別のコンポーネントやサブシステムが依存している可能性があります。このような場合、脆弱性修正の優先順位に影響を与えることになります。
3. 未使用ライブラリの識別: 動的SBOMの結果を基に未使用のライブラリを特定し、システムから削除することで、攻撃対象領域を減らし、システムのセキュリティを強化できます。

カバレッジと効果

動的SBOMの結果は、モニタリング中に達成されたカバレッジに直接影響を受けます。ユニットテストなどの包括的なテスト手法や、「PlaxidityX Security AutoTester」のような自動車向けファジングテスト製品を活用して高いカバレッジを達成すれば、システムの安全性とセキュリティを向上させるための、より信頼性が高く実用的な結果が得られます。

行カバレッジは、テスト中に実行されたコード行の割合を測定する指標であり、DSBOM分析において使用される重要なメトリクスです。以下のグラフでは、行カバレッジがライブラリの発見に与える影響を示しています。なお、この例では小規模かつ目的特化型のコードを用いており、大規模なプロジェクトでは結果が異なる可能性があります。

静的SBOMの出力結果は、次のような形式になります。

この表は、システム内に存在するアプリケーションやライブラリについて、実際に使用されているかどうかに関わらずユーザーに情報を提供します。図6に示されているように、メインアプリケーションで使用されていないアプリケーションやライブラリがシステム内に含まれている場合があります。

この例は、カバレッジを増やすことで検出精度が向上することを明確に示しています。しかし、依然として静的SBOMと重ならない未検出のライブラリが存在します。複数の実行結果を比較した詳細は、図4をご参照ください。

DSBOMがカバレッジに依存しているという事実は、たとえカバレッジ率が高くても、ライブラリが呼び出される箇所を網羅していなければ、結果の精度が低下することを意味します。したがって、重要なのはカバレッジの「量」だけでなく「質」であるという点です。

もう1つ重要なポイントは、DSBOMは呼び出されなかったライブラリ（関数が一度も呼び出されていないライブラリ）についても報告することです。これは、システム要件を理解する上で有益な情報となります。以下の表では、無作為に選んだサンプルの中で、実際に使用されたライブラリは1つだけであり、他のライブラリはすべて「必要」として報告されていることがわかります。全体として、カバレッジが高い領域で呼び出されたライブラリは読み込まれたライブラリ全体のわずか11%でした。この結果が示す可能性として、以下の3つが考えられます。

1. デッドコード: 必要のないサードパーティコードが使用されている可能性があります。
2. 低カバレッジ:
   該当するコードがテストされていない可能性があります。
3. 推移的依存関係:
   ライブラリの機能の一部のみが使用されるのは一般的であるため、特に対応する必要はありません。

この表は、プロセスメモリにロードされたライブラリの数と、実行時に実際に呼び出されたライブラリの数を比較したものです。表示されているデータは、全体の表から無作為に選んだ小規模なサンプルであり、完全なデータは非常に膨大であるため、ここでは一部のみを示しています。

図8は、システム内に存在するアプリケーションおよびライブラリの数と、メインアプリケーションで実際に使用されているライブラリの数を比較したものです。DSBOM分析の結果、1,000個のライブラリのうち、実際にアクティブに使用されているのはわずか14個であることがわかりました。この洞察は、脆弱性対策の優先順位を決定する上で非常に重要です。このようにライブラリを絞り込むことで、プログラマーやプロダクトマネージャーは言うに及ばず、CISO（Chief Information Security Officer、最高情報セキュリティ責任者）にとっても負担が軽減されます。特に、より重大な脆弱性が存在する領域を強調することで、意思決定が容易になり、アナリストのアラート疲れを回避する助けにもなります。

結論

動的SBOMは、コード実行中にライブラリの使用状況をリアルタイムで把握することで、ソフトウェアセキュリティ評価を強化する重要なツールとして登場しました。静的分析を完全に置き換えることはできないものの、それを効果的に補完する能力により、静的分析だけでは見逃したり、優先順位を誤って判断する恐れのある脆弱性を明らかにします。ライブラリの使用状況を正確に特定し追跡することで、動的SBOMはセキュリティ対策の優先順位付けを効率的に支援し、より堅牢なソフトウェアセキュリティの実現に貢献します。

しかし、動的SBOMのカバレッジと有効性は、モニタリングのカバレッジに直接影響を受けるため、包括的なテスト手法の導入が重要であることも忘れてはなりません。また、ライブラリが使用されたかどうかにかかわらず、必要なライブラリをすべて報告する機能は、デッドコードやテストカバレッジの不足など、システム要件や潜在的な問題を示す有用な指標となります。静的分析と慎重に組み合わせて活用することで、動的SBOMは潜在的な脅威に対するソフトウェアエコシステムの強化に大きく貢献することができます。

The post 動的SBOM：ソフトウェアセキュリティをリアルタイムで可視化 appeared first on PlaxidityX.

最近、PlaxidityX（旧アルガス）の研究チームは、興味深いデバイスをみつけました。それは、PSPのようにスタイリッシュで持ち運べる程度のサイズの端末で、7つのボタンが便利に配置され、洗練されたデザインと謎めいた名前がついています。このデバイスのパンフレットには、OEMの承認なしに、多くの車両に対してリモートエントリーやパッシブキーエントリー用の新しいキーを登録できる機能を備えていると記載されていました。

このデバイスの本来の目的は、無認可の自動車修理店が正規のサービスステーションよりも安価にサービスを提供できるようにすることです。しかし、言うまでもなく、この説明通りのことが可能であれば、このデバイスは悪意のある者によって車両を盗むために悪用される可能性があります（コンピュータゲームのグランドセフトオート、GTAのように）。その方法は非常に単純です。

1. 車両に対して物理的に侵入する
2. デバイスをOBDポートに接続する

3. 自分のキーを登録する

4. イグニッションをオンにし、誰にも気づかれないうちに走り去る
5. 盗難車を入手

当然のことですが、このデバイスを起動すると、法的責任は使用者に転嫁するという免責事項が表示されます。自動車セキュリティリサーチャーとして、このデバイスは興味深く、プロフェッショナルな理由から調査する必要がありました。

お気づきの通り、意図的にこのデバイスの名前は伏せています。というのも、このデバイスには少々後ろめたいところがあるものの、いわゆる“闇ルートを経由した”ものではなく、完全に合法的な手段で入手できたからです。実際、これはeBayで購入しました。ただし、このブログ記事の主旨が『この魔法のデバイスを使えば車の盗難が簡単にできる』という印象を与えたくないので、この情報は今後も公開しない方針です（しかも、筆者は車の盗難は簡単ではないと考えています）。オンライン上で自動車サイバーセキュリティに関するブログ記事を誰が読んでいるか分からない以上、慎重なアプローチが必要だからです。

とはいうものの、簡単な検索で同様の機能を持つ多くのデバイスが見つかります。その中には、手頃な価格で月次アップデートやカスタマーサポートを提供しているものもあります。しかし、ご心配なく。このデバイスが引き起こしそうな問題は、以下に説明する方法で容易に無効化できます。

このツールを試す

デバイスがラボに届いた際、チームは大いに盛り上がり、すぐに作業に取り掛かりました。まず初めに、そのユーザーインターフェース（UI）を詳しく調べました。予想通り、多くのOEMから提供されている多種多様な車両モデルが対応可能であることが確認できました。中にはパンフレットに記載されていなかった最新モデルも含まれており、同年に市場に投入された車両もありました（さらに多くのモデルを追加するアップデートも入手可能です）。さらに、このデバイスはキーの登録や登録解除以上の機能を備えています。一部のモデルでは、「イグニッションをオンにする」という機能まで備わっています。これらは必ずしも安価なモデルだけではありません。明らかに、イグニッションをオンにできれば、キー登録の手順を省略でき、車両の盗難がさらに容易になります。

PlaxidityXの業務が忙しいため、このデバイスを分解してファームウェアを抽出し、リバースエンジニアリングを行う（ECUに対して行うような）手間を省き、完全なブラックボックスアプローチを採用することにしました。このデバイスは車両のOBDポートに接続することを前提としているため、それをシミュレートし、デバイスと通信を試みました。リストにあるいくつかの車両モデルを適当に選び、キーの登録や登録解除、イグニッションのオン、その他の機能も含め、試してみました。

この作業を行うためには、デバイスが送信するさまざまなCANメッセージに対して、車両の応答を真似する必要がありました。多くの場合、この作業は比較的簡単でした。というのも、大半のケースで使用されていたプロトコルがUDSであり、メッセージのやり取りが各アクションにつき2～3回程度と短かったからです。ほとんどの場合、正しい応答が予測できるか、ブルートフォースの方法が通用し、目的を達成しました。（つまり、「キーが正常に登録されました」というメッセージがデバイスの画面に表示されました）。ただし、実際の車両でこのデバイスをテストしたわけではないため、これがすべて見せかけだけの動作である可能性もあります（とはいえ、このデバイスが実際に機能することを示すYouTube動画もいくつか確認しましたが）。

課題と発見

このデバイスには多くの機密情報、しかも、デバイス開発者自身のものではない機密情報が含まれています。この種のデバイスは、疑わしい動作を検出するとロックされる保護メカニズムを備えている場合が多いです。しかし、私たちはリスクを承知の上で作業を進めることにしました。そして、デバイスのメッセージに対する正しい応答を見つけるためにスキャンを実行していた際に問題が発生しました。そのスキャンでは、デバイスの「キーを登録する」ボタンを何度も押す必要がありましたが、結果としてデバイスがロックされてしまいました。新しい画面が表示され、パスワードの入力を要求されました。エスケープもできず、リセット操作を試みても解除できませんでした。

さて、次はどうするべきでしょうか？ デバイスをリバースエンジニアリングして解決策を見つけることもできますが、もっと簡単な方法を試してみるのはどうでしょうか？ つまり、販売者にサポートを求めてみることです。正直なところ、この方法には懐疑的でした。というのも、これは合法スレスレのデバイスであり、我々が聞いたことのないよく知らない会社によって製造されているものだからです。しかし、数時間後に販売者から返信がありました。「なぜロックされたのですか？ ソフトウェアを開発していますか？」と尋ねられました。「いいえ」と私たちは答えました（ただのリサーチです）。すると、「それならOKです。こちらが解除用のパスワードです。ご不便をおかけして申し訳ありません」と販売者は答え、パスワードを教えてくれました。カスタマーサポートの対応には感心しました。星5つです。

リサーチに戻りましょう。多くの場合、キー登録プロセスは以下の2段階で構成されていました。

1. 「PINコードの読み取り」機能を使用してPINコードを抽出します。この段階では通常、UDSセキュリティアクセスをパスする必要がありますが、デバイスはこれをクリアすることができました。どうやら、このデバイスは車両のセキュリティアクセス機構が提示するランダムシードに対応する正しい応答をすべて把握しているようです。
2. 「キーの登録」機能を使用して新しいキーを登録します。通常、この段階では、手動でPINコードを入力するよう求められました（何らかの理由で、ユーザーの利便性を考慮して2つの段階を統合していませんでした）。さらに、車両によっては、「ドアを開ける」「キーをイグニッションボタンに置く」などの指示がデバイスから提示されました。

では、この謎のデバイスの開発者は、どのようにしてセキュリティアクセスやキー登録プロセスを突破する方法を知ったのでしょうか？ 正確な方法は分かりませんが、以下のように推測されます（繰り返しますが、これは車両盗難デバイスの開発方法を指南するものではありません）。私たちの仮説では、開発者は認可されたサービスステーションから正規のOEMテスターを入手し、合法的なキー登録プロセスを記録してそれをコピーした可能性があります。これにより、一般的なプロセスについての知識を得たと考えられます。しかし、それだけではセキュリティアクセスを突破する方法についての説明がつきません。

確かに、一部のケースではセキュリティアクセスが非常に単純で、わずかなケースからそのアルゴリズム全体を推測することができました。しかし、他のケースではより複雑なものも見られました。一つの可能性として、開発者がすべての可能なシードをテスターに送り、その応答を記録したという方法が考えられます（シードの長さが十分に短ければこれは可能であり、実際多くの場合あてはまりました）。しかし、この方法では大量のストレージスペースが必要となり、実現可能性は低くなります。より現実的な説明としては、一部の車両モデルにおいて、開発者がOEMテスターまたはキー登録に関係するECUを調査した可能性があります。この方法は手間がかかるものの、セキュリティアクセスキーの計算アルゴリズムを抽出するだけで十分である点を考えると、十分に実行可能です。例えば、毎月異なる車両をレンタルし、関連するECUを取り外し、そのファームウェアを抽出、コードを少し調査してキー登録のPoCを開発した後、すべてを元通りに戻し、車両を返却する（もちろん燃料満タンで）というシナリオが容易に想像できます。多くの車両モデルが同じシステムを使用していることを考慮すると、1つのモデルを調査するだけで、多くの車両を開錠するための知識を得ることができます。

結論と安全対策

では、このデバイスを使って実際に車を盗むことは可能なのでしょうか？ 一部のケースでは不可能でした。新しいキーを登録するには、事前にPINコードまたはその他の情報を知っている必要があったからです。しかし、多くのケースでは、実行可能であるように思われます。ただし、実際の車両でこのデバイスを使用していないため、100%確実とは言い切れません。しかし、顧客のレビューや多数のYouTube動画を見る限り、このデバイスが確かに宣伝どおりに機能するようです。OEMがこの事実を認識し、FOTAアップデートを通じて脆弱な車両モデルを修正していることを願っています。しかし、一部の車両はアップデートされないまま残り、依然としてこの方法による盗難のリスクがあります。

では、OEMはどのようにしてこのような盗難の可能性を回避できるのでしょうか？ 以下は、OEMがこのデバイスを無効化するために採用できる比較的簡単な方法です。

1. UDSセキュリティアクセスプロセスでより長いシードを使用し、正規のOEMテスターの通信記録からシードキーのディクショナリを作成することを不可能にします。もちろん、シードはランダムである必要があり、シードの重複が発生しないようにする必要があります。
2. セキュリティアクセスアルゴリズムにHSM（ハードウェアセキュリティモジュール）に保存された秘密要素を含めることで、デバイスがセキュリティアクセスを突破することを防ぎます。一方で、正規のOEMテスターは、OEMのサーバーにアクセスしてこの情報を取得することが可能となります。当然ながら、アルゴリズムは十分に複雑である必要があり、少数のサンプルから推測されることがないようにする必要があります。
3. 現在では、このような目的でセキュリティアクセスサービスを使用する必要はありません。より安全な暗号化方式（対称鍵および非対称鍵の両方）に基づいた、UDSサービス0x29やSecOCのようなより優れた方法が存在します。
4. キーを登録するために必要な唯一の秘密情報として4桁のPINコードを使用するのは避けるべきです（それ自体が脆弱な仕組みです）。もしPINコードを使用する必要がある場合は、そのコードが車両から抽出されないようにしてください。正規のサービスステーションのみが、OEMのバックエンドからPINコードに安全な方法でアクセスできるようにするべきです。
5. JTAGのような物理インターフェースを保護し、ファームウェアを外部フラッシュに保存しないことで、ファームウェアの抽出やリバースエンジニアリングを困難にすることができます。同じ理由から、アップデートパッケージは常に暗号化する必要があります。

これらのシンプルな対策により、無許可のデバイスによる車両盗難のリスクを軽減することが可能です。

PlaxidityXリサーチグループについて

PlaxidityXリサーチグループは、数十年にわたるサイバーセキュリティと自動車分野の専門知識を活用し、OEMやTier 1サプライヤーの数多くのペネトレーションテストや研究プロジェクトを行ってきました。その結果、OEMやTier 1サプライヤーらのサイバーセキュリティ体制を検証・強化し、UNR 155、UNR 156、ISO 21434標準への準拠をサポートしています。自動車のアーキテクチャ、プロトコル、規格に関して深い理解があり、PlaxidityXリサーチグループは、包括的な自動車サイバーセキュリティサービスを提供しています。これには、自動車向けペネトレーションテスト、TARA（脅威分析とリスク評価）、サイバーセキュリティアーキテクチャデザイン、そしてUNR 155およびISO 21434標準へのサイバーセキュリティ準拠支援が含まれます。

The post 市販の自動車ハッキングキットを解剖する appeared first on PlaxidityX.

以前から、特定のサイバーセキュリティの課題に対処するために、ベストオブブリードのツールが利用されてきました。これらのツールはそれぞれの得意分野で優れた性能を発揮しますが、ますます複雑になる自動車サイバーセキュリティを管理するために必要な統合性、可視性、および柔軟性が不足しています。この記事では、プラットフォームを中心においた戦略がこの業界独自のニーズに対応するために最適である理由について説明しています。

１．セキュリティ管理をシンプルにするための包括的な視野

自動車業界のメーカーは、サプライチェーン、開発環境、生産ライン、車載ソフトウェア、および顧客向けサービスなどの広範囲にまたがり相互接続しているシステムのネットワーク内で稼働しています。この広範なエコシステムを、複数のベストオブブリードツールのパッチワークで管理することは、多くの場合、非効率性、重複作業、そして盲点を生じさせることにつながります。

プラットフォームアプローチは、多様なセキュリティ機能を単一の統合システムにまとめることで管理を簡素化します。この集中化により、運用上の負担が軽減され、サイバーセキュリティチームからコンプライアンス担当者に至るまで、すべての関係者がシームレスに連携できるようになります。さらに、プラットフォームはエコシステム全体からデータを集約し、全体的なセキュリティ状況をわかりやすく一元的な現象にまとめ、包括的なビューを示します。

エンドツーエンドの可視性があるため、メーカーは脆弱性を特定し、脅威を検出し、より効果的にインシデントに対応することができます。例えば、重要なサプライヤのソフトウェアに脆弱性が発見された場合、プラットフォームは求められるレベルの可視性を提供できます。そして、その脆弱性のもたらす潜在的な影響をサプライチェーン全体および車両システム全体にわたってマッピングすることができます。この包括的な監視は、事業および顧客の両方を保護するために不可欠です。

２．スマートで迅速な意思決定のためのコンテキストに基づく洞察

車両の製造プロセスでは、サプライチェーンのメトリクスから車載テレメトリまで、膨大なデータが生成されます。ベストオブブリードのセキュリティツールの場合、こうしたデータの取得は可能ですが、有意義な分析に必要なコンテキストを提供できないことが多くあります。コンテキストがなければ、脅威を効果的に優先順位付けしたり、タイムリーな意思決定を行ったりすることはほぼ不可能です。

プラットフォームアプローチは、生データを実用的なインテリジェンスに変換する点で優れています。TARA管理システム、脆弱性管理ツール、コードセキュリティ製品などの複数のソースから得られたデータを関連付けることで、プラットフォームは脅威を特定するだけでなく、それを超えた洞察を提供します。これにより、問題の深刻度、緊急性、潜在的な影響を評価するために必要なコンテキストが提供されます。

例えば、ソフトウェアパッケージに見つかったある脆弱性に対して、プラットフォームは脅威分析とリスク評価（TARA）を容易に行うことができます。クリティカルなブレーキシステムに高い優先度の脆弱性が見つかれば、重大な問題と認識されるでしょう。しかし、TARAプロセスにおいて、システムの多層フェールセーフによりその脆弱性の影響が軽減されることをプラットフォームが示すこともあります。その逆に、例えばフロントガラスのワイパーなど重要度の低いシステムに同じ脆弱性が見つかった場合、優先度が下がる可能性があります。この機能により、サイバーセキュリティチームは最も重要な脅威への対応に集中し、正確な意思決定とリソース配分を可能にします。

安全が最優先の業界では、このように優先順位をつけて迅速に行動する能力は、リスクを軽減し、信頼性を維持するために非常に重要です。

３．進化する業界に対応できるシームレスな統合とスケーラビリティ

プラットフォームは、業界の断片化した性質に対応できるよう自動車のバリューチェーン全体にシームレスに統合できるよう設計されています。自動車の技術市場は、多くの場合、AUTOSARによる標準化された車両ソフトウェアアーキテクチャ、データ保護に焦点を当てたITセキュリティ、部品のトレーサビリティを確保するサプライチェーン技術、車載機能を支える組み込みシステムといったように分断されています。これらの異なる要素を統合することで、プラットフォームは開発プロセスを合理化し、サプライチェーンのレジリエンスを強化し、車載システムのセキュリティを向上させます。この統合アプローチにより、エコシステム全体で一貫性のある包括的なサイバーセキュリティ対策が可能になります。

さらに、これらのプラットフォームは、自動車業界の急速な進化に対応するために必要なスケーラビリティを提供します。メーカーが自動運転、電気自動車、V2X通信といった革新的な技術を採用する中で、プラットフォームベースのアプローチは、既存のセキュリティワークフローを用いながら、こうしたイノベーションをシームレスに統合することを可能にします。この適応性のおかげで、技術の進歩に伴ってサイバーセキュリティ戦略を進化させ、変化し続ける自動車業界において堅牢で将来性のある基盤を構築できます。

４．セキュリティを損なわずに市場投入までの時間を短縮

イノベーションは自動車産業の生命線ですが、新しい機能を迅速に提供しようと焦るあまり、厳格なサイバーセキュリティの要件と衝突することがあります。ベストオブブリードのアプローチでは、多くの場合、ツールの統合やプロセスのマニュアル管理に時間を費やすため、遅延が発生します。

プラットフォームは、主要なセキュリティ機能を自動化し、事前に統合されたソリューションを提供することで、こうしたボトルネックを解消します。脆弱性スキャン、コンプライアンスチェック、リアルタイムの脅威検出がプラットフォーム内でシームレスに実行され、メーカーは開発スケジュールを遅らせることなく強固なセキュリティ体制を維持できます。

この市場投入までの時間短縮は、電気自動車や自動運転などの分野でリードしようと競争する自動車メーカーにとって特に重要です。プラットフォームアプローチは、スピードとセキュリティを確実に両立しながら、妥協せずにイノベーションを行うことを可能にします。

５．セキュリティを業界基準とビジネス目標に合わせる

規制への準拠は、自動車サイバーセキュリティの基盤となるものです。UNECE WP.29 や ISO/SAE 21434 などの標準は、設計から廃車まで、車両のライフサイクル全体を通じて強固なセキュリティ対策を義務付けています。断片化されたベストオブブリードツールを使用してコンプライアンス管理を行うと、リソースを多く消費し、エラーが発生しやすいプロセスになりかねません。

プラットフォームは、リスク評価、レポート、監査のための組み込みツールを備えた、コンプライアンスを確保するための集中管理フレームワークを提供します。これは規制遵守を簡素化するだけでなく、顧客の信頼を高め、ブランドの評判を保護するなどの、より広範なビジネス目標とサイバーセキュリティの取り組みを一致させることにつながります。

プラットフォームは包括的かつ統合的なアプローチを提供できるため、メーカーは規制要件を満たすと同時に、イノベーションを安全に行うリーダーとしての地位を確立できます。

６．より低いトータルコストとシンプルな保守による運用の最適化

複数のベストオブブリードツールを統合するコストと複雑性は、トータルコストを大幅に増加させる可能性があります。ポイントごとのソリューションでは、多くの場合、統合、テスト、トラブルシューティングのために専用のリソースを必要とするため、コストを増加させ、運用効率を妨げます。それに対して、単一のベンダーによる事前統合プラットフォームを採用すれば、これらの課題が解消され、コストの削減およびプロセスの簡素化を図ることができます。

さらに、断片化されたツール群を維持するには、それぞれのソリューションごとのアップグレードとアップデートを調整する必要があります。このアプローチは時間とリソースを消費するだけでなく、新たな更新のたびに統合が失われるリスクも伴います。

例えば、脆弱性管理ツールがアップグレードされると、脅威検出システムとのワークフローが中断され、コストのかかる修正が即座に必要な場合があります。統一されたプラットフォームの場合、ベンダーが管理するシームレスなプロセスにアップデートを統合することで、このような問題を回避でき、メーカーは関連するリスクとコストから解放されます。

結論

車両がよりスマートに、よりコネクテッドになり、ソフトウェアへの依存が高まるにつれて、それらが直面するリスクは増大する一方です。サイバーセキュリティに対するプラットフォームアプローチを採用することで、自動車業界の企業がこれらの課題に正面から取り組み、自社の製品、顧客、そして評判を保護できるようになります。

自動車サイバーセキュリティの未来は断片化されているのではなく、統一されています。プラットフォーム戦略を採用することで、メーカーは複雑性を簡素化し、市場投入までの時間を短縮し、そして最も重要なこととして、より安全でセキュアな未来に向けて自信を持って進むことが可能になります。

The post 自動車業界を脅かすサイバーリスク：なぜ断片的サイバーセキュリティ対策は危険なのか？
 appeared first on PlaxidityX.

はじめに

コンピュータの画面でこの文章を読んでいる今、このやりとりを可能にしているデバイスには間違いなくメモリ管理ユニット（MMU）が搭載されています。普段はあまり意識されないものの、MMUは現代のコンピューティングにおいて欠かせない存在であり、日々私たちが使用しているソフトウェアをスムーズに動作させるために、背後でメモリリソースを管理しています。スマートフォンからインターネットを支える強力なサーバーに至るまで、MMUはメモリの割り当てを調整し、パフォーマンスを最適化し、セキュリティ脅威から保護する中心的な役割を担っています。ここまで説明しましたが、今回のブログ記事ではMMUについて取り上げるわけではありません。なぜなら、自動車の電子制御ユニット（ECU）の大部分を支えるマイクロコントローラユニット（MCU）には、通常MMUが実装されていないためです。

代わりに今回のブログでは、MMUの「弟分」とも言えるメモリ保護ユニット（MPU）についてご紹介します。MMUは、中央処理装置（CPU）のメモリ管理において中心的な役割を果たすため注目を集めがちですが、MPUはメモリ保護を強化し、不正アクセスを防ぎ、セキュリティ脅威から保護するという重要な役割を果たしています。それにもかかわらず、MPUは目立たない存在になりがちです。

今回のブログでは以下の内容について説明します。

• 現代のMPUの機能：
  最新のメモリ保護ユニット（MPU）の機能と、自動車分野におけるセキュリティ確保における特別な役割について解説します。
• 現代のMCUで使用されるMPUの種類：
  最新のマイクロコントローラユニット（MCU）で使用されるさまざまなMPUの種類について議論します。
• 発見された脆弱性：
  発見された脆弱性（CVE-2023-48010およびCVE-2024-33882）の詳細について説明します。
• 責任ある開示プロセス：
  チップベンダーとの責任ある脆弱性開示プロセスの概要を紹介します。
• 推奨される緩和策：
  発見された脆弱性に対処するための緩和策を提案します。

背景

MMUからMPUへ

現代の中央処理装置（CPU）では、MMUは通常、仮想アドレス空間を管理するハードウェアデバイスとして使用され、仮想アドレスを物理アドレスにマッピングします。さらに、MMUはメモリに関連するタスクも実行します。MMUのメモリ保護機能は、プログラムが事前に要求していないメモリにアクセスしようとする試みをブロックするよう設計されており、これにより、誤動作するプログラムがメモリを使い果たしたり、悪意のあるコードが他のプログラムのデータを読み書きすることを防ぎます。

初期のマイクロプロセッサ設計では、1965年のIBM System 360や1986年のApple Macintoshなど、仮想メモリマッピングやメモリアクセス権限を処理するためにMMUが含まれていました。

一方、小型のマイクロコントローラは、MMUによる仮想メモリマッピングの負担を必要としませんでした。しかし、マイクロコントローラのアーキテクチャにおける弱点には、オペレーティングシステム、ユーザーソフトウェア、変数が共通のメモリを使用していたことがあげられます。この問題は、市場に複数コアのマイクロコントローラが登場し始め、異なるセキュリティおよび安全レベルの複数のアプリケーションが同じ共通メモリを使用するようになるとさらに複雑になりました。

より高いレベルのセキュリティを必要とするアプリケーション、例えば自動車産業では、メモリアクセス権限のみを管理するMMUの縮小版を実装しました。これがメモリ保護ユニット（MPU）の始まりです。

MPU：現代のサイバーセンティネル（見張り番）

メモリ保護ユニット（MPU）は、メモリの「門番」として機能するプログラム可能なハードウェアユニットです。これにより、メモリを異なる領域に分割し、それぞれの領域に対してメモリアクセス権限（特権アクセスのみや完全アクセスなど）やメモリ属性（読み取り/書き込み/実行など）を設定することが可能になります。

非常に基本的な説明をすると、MPUはメモリリソースへのアクセス制御を監視します。「アクセス制御」とは、「コンピューティング環境において、誰が、または何が、リソースを閲覧または使用できるかを規制するセキュリティ技術」¹ と定義されます。これはセキュリティの基本的な概念であり、組織にとってのリスクを最小限に抑えるものです。

より広い意味では、『Computer Security: Principles and Practice』において次のように述べられています。

「…すべてのコンピュータセキュリティはアクセス制御に関するものである。アクセス制御は、特定のシステムリソースに誰がまたは何がアクセスできるか、また各事例で許可されるアクセスの種類を指定するセキュリティポリシーを実施するものである。」²

この意味では、MPUは一般的なセキュリティ、特に組み込みシステム（自動車を含む）のセキュリティにおける主要な防御策の1つです。ある研究『From MMU to MPU: adaptation of the Pip kernel to constrained devices（MMUからMPUへ:拘束デバイスへのPipカーネルの適応）』³ では、マイクロコントローラでMPUを有効化すると、性能とエネルギー消費の両面で16%のオーバーヘッドが発生するものの、アクセス可能なアプリケーションメモリのアタックサーフェスが100%からわずか2%！に削減できることが示されています⁴。

許可されていないメモリへのアクセスを試みると、ハードウェアフォルトが発生し、潜在的な攻撃を実質的に停止し、不正なアクセスを、例えば、システムをリセットして攻撃者を「振り払う」ような形で対応します。

MPUを有効化すると、ランダムアクセスメモリ（RAM）上での実行アクセスを制限することが可能です。そのため、たとえ攻撃の第一段階として、ターゲットのECUスタックメモリにスタックバッファオーバーフローの脆弱性を利用して悪意あるコードを書き込むことに成功しても、MPUの保護によりそのコードをスタックメモリ領域で実行することはできなくなります。

自動車の保護ユニット

メモリ保護ユニット（MPU）は、自動車業界において、車両内の組み込みシステムのセキュリティ、信頼性、安全性を向上させる重要な役割を果たしています。以下にその役割の概要を示します。

• セキュリティ強化
  MPUはメモリ保護メカニズムを実装・適用することで、自動車システムのセキュリティを向上させます。これにより、不正アクセスやデータの破損、意図しないコードの実行を防ぎ、外部からの脅威から重要な情報や機能を保護します。
• アクセス制御の厳格な適用
  MPUは異なる特権レベルを区別し、事前に設定されたアクセス制御ポリシーを厳格に適用ができます。
  自動車アプリケーションでは、ハードウェアセキュリティモジュール（HSM）、ブートローダーアプリケーション、セキュアブートプロセス、サードパーティアプリケーションなど、異なる特権レベルを持つコンポーネントが頻繁に使用されます。例えば、HSMメモリへの不正なアプリケーションからのアクセスをブロックする機能は、自動車システム設計者にとって重要なセキュリティツールです。
• 安全性の向上
  MPUはメモリ保護ポリシーを適用し、重要なソフトウェアコンポーネントを分離することで、安全性が求められるシステムの構築を支援します。これにより、エラーや悪意のある干渉が車両の安全を損なうリスクを低減します。
• アプリケーションの分離
  MPUは、車両内の組み込みシステムにおける異なるアプリケーションの分離を可能にします。それぞれのアプリケーションやソフトウェアモジュールに専用の保護されたメモリ領域を割り当てることで、アプリケーション間での干渉やデータ破損を防ぎます。この分離は、重要な機能の完全性を維持し、1つのアプリケーションへの攻撃が同一システム内の他のアプリケーションに影響を与えないようにするために不可欠です。
• MPUは、コア、DMA（Direct Memory Access）コントローラ、CAN、USB、GPUなどのコア－外部のペリフェラルコントローラなど、システム内のバス・マスタの相互作用を管理し、安全を確保する上で極めて重要な役割を果たします。バス・マスタにおいてMPUは、データ転送の完全性とセキュリティを保証する重要なコンポーネントとして機能します。メモリ保護メカニズムを提供することで、MPUは異なるバス・マスタの分離を可能にし、共有メモリへのアクセスにおける意図しない干渉や潜在的な競合を防ぎます。この機能は、さまざまなコアがメモリ資源に同時にアクセスする可能性のあるマルチコアシステムにおいて特に重要です。MPUは、安全かつ明確に定義された境界の確立に貢献し、各バス・マスタが割り当てられたメモリ空間内で動作することを可能にします。MPUは、不正または悪意のある行為から保護するためにアクセス制御を実施し、高速なコア外転送中のデータの機密性と完全性を保証します。

MPUの種類

すべてのメモリ保護ユニット（MPU）が同じ設計で作られているわけではなく、アーキテクチャによってさまざまな種類が存在します。しかし、以下の例のブロック図に示されるように、一般的に次の3つの主要なタイプに分類することができます。

コアMPU（CMPU）

CMPU（Core MPUまたはCPU MPUとも呼ばれる）は、マイクロコントローラの各コアに直接統合されたメモリ保護ユニットです。コアレベルで動作し、細かいメモリ保護およびアクセス制御メカニズムを提供します。CMPUは、コア自身が実行するコードおよびデータアクセスに対して、メモリ保護ポリシーを適用することを可能にします。通常、複数のメモリ領域ごとにアクセス権限（読み取り、書き込み、実行）や特権レベルを設定することができます。CMPUは、マイクロコントローラの各コアで実行される個々のソフトウェアプロセスのメモリアクセスを保護するために不可欠な役割を果たします。

システムMPU（SMPU）

SMPU（System MPUとも呼ばれる）は、システム全体のメモリ空間を保護するために設計されたメモリ保護ユニットです。コアの視点で保護を提供するCMPUとは異なり、SMPUはシステムレベルで動作し、システム内のバストランザクション⁵を対象としたメモリ保護を提供します。CMPUがコアで実行されるソフトウェアコードから発生するバストランザクションを監視・制御するのに対し、SMPUはダイレクトメモリアクセス（DMA）やHSMなどのハードウェア関連のメカニズムを含むシステム全体のバストランザクションを制御します。SMPUのアドレス領域は通常、バストランザクションの発信元によって定義されます。例えば、SMPUはHSMに共有メモリ内の特定のアドレス範囲へのアクセスを許可するように設定される一方、他の発信元からのすべてのバストランザクションをブロックするように構成することができます。

周辺機能保護ユニット（PPU）

PPU（Peripheral MPUとも呼ばれる）は、組み込みシステム内のメモリマップドレジスタを保護するために特化されたメモリ保護ユニットです。PPUは、通信インターフェース、タイマー、I/Oポートなどの周辺機器に特化したアクセス制御およびセキュリティ機能を提供します。これにより、プロセッサコアや外部バスマスターによって開始される周辺機器へのアクセスに対し、アクセス権限や制限を適用することが可能です。PPUは重要なシステム周辺機器への不正または悪意のあるアクセスを防ぎ、周辺機器とのやり取りのセキュリティと信頼性を向上させます。

CVE-2023-48010とCVE-2024-33882

注意深く設定されたメモリー保護ユニットは、攻撃者にとって強力な対抗手段となります。しかし、「鎖はその最も弱い部分と同じ強さしかない」という決まり文句があります。もし攻撃者が完璧に設定されたMPUを無効化することができれば、当然ながらMPUの保護機能が失われてしまいます。

これら2つの脆弱性、CVE-2023-48010とCVE-2024-33882は、いずれもPowerPCマイクロコントローラの特定の設計に関連する、我々が発見したハードウェア脆弱性です。これらの脆弱性は、特権を持つ攻撃者がSMPU（システム・メモリ保護ユニット）全体を停止させることを可能にし、その結果、保護されたメモリ領域への読み書きを可能にします。PowerPCマイクロコントローラのデータシートによれば、あるハードウェア機能により、攻撃者がSMPUを無効化しようとしても、初期設定後もSMPUが有効な状態に保たれるはずですが、実際にはこの機能はシリコンに実装されておらず、SMPUはこのような攻撃に対して脆弱なままであることが明らかになっています。

その結果、ソフトウェアの設計者は、データシートに詳述されている対策を講じることで、保護されているかのような印象を抱いたまま、実際には保護されておらず、システムにリスクがあることにまったく気づかない可能性があります。

背景：PowerPCアーキテクチャ

最初のPowerPCマイクロコントローラは、1990年代半ばにモトローラ（後のFreescale Semiconductor）によって製造されました。これらのマイクロコントローラはMPC5xxシリーズとして知られ、PowerPCアーキテクチャが、自動車アプリケーションを含む組み込みシステム市場に進出した最初の例となりました。MPC5xxファミリーの起源は、1990年代初頭にIBM、Apple、モトローラが共同で進めた取り組みにまでさかのぼります。

RISCベースの設計により、高い性能と効率を兼ね備えたPowerPCプロセッサは、1990年代後半には自動車システムに採用されるようになりました。当初はエンジン制御やトランスミッション制御といったタスクに使用されていましたが、リアルタイム処理能力と過酷な環境下での耐久性により、インフォテインメントシステムや先進運転支援システム（ADAS）など、幅広い用途にとって欠かせない存在となりました。

2000年代半ばには、STMicroelectronicsとFreescale Semiconductor（現在のNXP Semiconductors）が共同開発したPowerPCアーキテクチャに基づくMPC56xx/SPC56xファミリーが登場しました。これらは特に自動車アプリケーション⁶
向けに設計されており、両メーカー間でピン互換性があり、マイクロコントローラはほぼ同一の仕様を持っています。

脆弱性

(1) CVE-2023-48010

PlaxidityX（旧アルガス）では、ペネトレーションテストやセキュリティ研究に加えて、自動車システム向けのセキュリティ製品およびソリューションの設計と開発も行っています。今回のケースでは、将来の製品に向けた概念実証（PoC）を開発しました。どのシステムを採用するかを決定する前に行う評価の一環として、このPoCはSTMicroelectronicsのPowerPC SPC58Nファミリーのマイクロプロセッサを基に構築しました。上述の通り、これらのマイクロコントローラは特に自動車用途向けに設計され、広く使用されているためです。

SPC58Nは、自動車のASIL-D⁷, 規格やセキュリティアプリケーション向けに設計された、トリプルコアの32ビット「Powerアーキテクチャ」⁸ マイクロコントローラです。

以下は、このチップのデータシートから引用したブロック図です。

図の下部には、チップのメモリがあります。フラッシュメモリとEEPROMはグレーで、スタティックRAMは青で示されています。これらのメモリは定義上、すべてのコアおよび周辺機器から共通してアクセス可能です。
図の上部には各コアが配置されており、それぞれに独自のコアメモリ保護ユニット（CMPU – 赤い長方形で示されています）と、コア間に配置された64のDMAチャネル（緑で示されています）があります。

コア、DMAチャネル、およびメモリの間には、黄色の長方形で示されたシステムメモリ保護ユニット（SMPU）が配置されています。

各コアで多様なアプリケーションが動作し、それぞれが異なる安全性およびセキュリティレベルを持つことが事前に分かっていたため、私たちはCMPUとSMPUの設定を慎重に定義することに取り組みました。

CMPUと制限

各コアメモリ保護ユニット（CMPU）は、各コアから発生するすべての命令フェッチとデータメモリアクセスを監視します。CMPUは、システムソフトウェアがメモリ領域とその関連するアクセス権限を定義するために使用するハードウェア機能です。CMPUは、ソフトウェアが権限を違反してメモリ領域にアクセスしようとすると例外を発生させ、システム設計者が介入して適切に例外を処理できるようにします。

セキュリティの観点から、CMPUは以下の2つの主な理由により、全体的なセキュリティ体制の非常に重要な部分となっています。

1. CMPUは、スタックバッファオーバーフローを検出できるマイクロプロセッサアーキテクチャ内で唯一のエンティティです。スタックバッファオーバーフローは、プログラムがスタック上のバッファに収まる以上のデータを書き込むことで発生し、隣接するメモリアドレスをオーバーフローさせます。この問題は、入力データが適切に検証または制限されていない場合に発生し、攻撃者が関数の戻りアドレスやスタック上の他の重要なデータを上書きできるようになります。その結果、攻撃者がスタック上で悪意のあるコードを実行し、プログラムの正常な動作を妨害することで、任意のコードを実行する可能性が生じます。
   マイクロコントローラ上で動作するすべてのアプリケーションのスタック領域を慎重に定義することで、設計者はCMPUを構成し、そのスタック領域での実行をブロックするように設定できます。これにより、攻撃対象領域を大幅に制限できます。
2. CMPUは、アプリケーションの読み取り/書き込み操作を効果的に制限します。これにより、攻撃者が任意のコア上でコードの実行を得た場合（例えば、悪意のあるサードパーティコードを実行することで）、適切に構成されたCMPUが悪意のあるメモリアクセスを検出し、攻撃者の行動を妨害することを保証します。
   しかし、本当にそうでしょうか？

上記のブロック図を振り返ると、各コアに適切に構成されたCMPUがあることで、コア自身からのメモリアクセスを防ぐのには役立つものの、Direct Memory Access（DMA）、Ethernet、HSMなどの特別な周辺機器を悪用して攻撃者がメモリにアクセスすることを防ぐことはできません。

このような攻撃を効果的に防御するために、SMPU（システムメモリ保護ユニット）が必要となります。

システムMPU（SMPU）

一見すると、SMPUはCMPUと非常に似ています。SMPUもシステムソフトウェアがメモリ領域とその関連するアクセス権限を定義するために使用するハードウェア機能であり、権限違反が発生した場合には、システム設計者が介入して例外を処理できるようにします。

しかし、SMPUにはCMPUにはない特別な機能があります。それは、SMPUが各バスマスターごとのメモリアクセスを同時に監視および評価することです。

以下は、SPC58Nで利用可能なバスマスターの一覧です。

各バスマスターには、それぞれ指定されたメモリ領域へのアクセスを管理するための読み取り/書き込み/アクセス禁止のフラグが設定されています。たとえば、SMPUを特定のメモリ領域をHSMのみがアクセス可能とし、他のすべてのマスターを拒否するように設定することができます。この場合、CMPUがHSMの特定アドレスへのアクセスをブロックしないとしても、HSMメモリを読み書きしようとする試みはすべてSMPUによって効果的にブロックされます。

もう一つの例はDMAによるアクセスです。Core1上で動作するアプリケーションがCore1のCMPUによって特定のメモリ領域へのアクセスをブロックされている場合でも、攻撃者がDMAハードウェアを利用してその禁止されたメモリ領域に読み取り/書き込みアクセスを取得し、CMPUの制限を回避する可能性があります。

このことから、SMPUの重要な機能の1つは、アクセスを試みた発信元のバスマスターによるメモリアクセスをブロックできることに加え、他のマスターがそのメモリにアクセスすることもブロックできる点にあります。

まとめると：マイクロコントローラアーキテクチャにおいて、コアMPU（CMPU）は各コアからのメモリアクセスを監視し規制する上で重要な役割を果たします。CMPUはメモリ領域とその権限を適用し、違反が発生した場合に例外を発生させます。この機能は、スタックバッファオーバーフローのような一般的な攻撃ベクトルが任意のコード実行につながるのを防ぐなど、セキュリティ上極めて重要です。

一方、CMPUはコアに基づくメモリアクセスには対処できますが、DMAのような特殊な周辺機器を悪用した攻撃には対応できません。このギャップを埋めるのがシステムメモリ保護ユニット（SMPU）です。SMPUは各バスマスターごとにメモリアクセスを同時に監視・評価し、メモリ権限に対するきめ細かな制御を可能にします。本質的に、SMPUの発信元のマスターによるアクセスを規制する独自の能力は、周辺ハードウェアを利用した潜在的な攻撃を阻止し、全体的なシステムセキュリティを強化します。

SMPUの設定

前の段落では、CMPUとSMPUを適切に設定する重要性について説明しました。CMPUはコアで動作するアプリケーションコードがセキュリティや安全性の理由で禁止されたメモリ領域に直接アクセスするのを防ぎ、SMPUは間接的なメモリアクセスを防ぐ役割を果たします。

私たちが使用していたSPC58Nチップには、16のバスマスターごとに読み取り/書き込みアクセス制御権限を設定できる24のリージョンレジスタが搭載されていました。

各SMPUリージョンは、32ビットの開始アドレスと終了アドレス、および保護されたアドレス領域とリージョンフォーマットレジスタで構成されています。これにより、16のバスマスターごとに許可されるアクセス権限（読み取り、読み取り/書き込み、またはアクセス禁止）が定義されます。

各リージョンには、それぞれ有効ビット（Valid Bit）と読み取り専用ビット（Read Only Bit）が設定されています。しかし、次のセクションで読み取り専用ビットについて詳しく説明する前に、もう1つ重要なSMPUレジスタであるCESR0レジスタについて触れておきましょう。

すべてが適切に設定されたら、制御/エラーステータスレジスタ0（CESR0）のGlobal Valid（GVLD）ビットを設定する必要があります。これにより、SMPUが有効化され、潜在的な攻撃に対抗する準備が整います。以下のように設定されます

リージョン読み取り専用ビット

では読み取り専用ビットに話を戻しましょう。データシートを確認します。

読み取り専用（RO）ビットは、リージョンディスクリプタの意図しない変更を防ぐ役割を果たします。ROビットが設定されると、リージョンレジスタ内の任意の場所への書き込みが無視されます。これは非常に理にかなっており重要です。一度設定されたリージョンが、偶発的または悪意のある書き込みから保護されることが望ましいからです。しかし、ROビットの説明には以下のような注意書きもあります。

 Source:  RM0452 SPC58H, p. 536

上記の注意書きには、ROビットが設定されると、リージョン全体がロックされ、システムリセットまで変更できなくなると記載されています。この間、リージョンの有効ビット（Valid Bit）およびグローバル有効ビット（GVLD）には影響がなく、これらもシステムリセットまで変更することができません。

これは非常にスマートな防御策です。一度SMPUのリージョン情報が設定され、ROビットが有効化されると、グローバル有効ビット（GVLD）を操作することができなくなり、攻撃者がSMPUを無効化することができなくなります。SMPUを無効化する唯一の方法は次回のシステムリセット後となるため、攻撃者はデバイスへの支配を失うことになります。

SMPUの脆弱性

SMPUの設定を終えた後、システム全体のテストを開始しました。この製品では、1つのコアが安全性（ASIL-D）のアプリケーションを実行し、もう1つのコアがサードパーティのアプリケーションを実行するように構成されていました。当然ながら、2つのコアはメモリを共有していました。

SMPUは、安全性アプリケーションのメモリ領域（フラッシュ、EEPROM、SRAM）をアプリケーションコアからの読み取りおよび書き込みから保護するように設定されました。さらに、すべてのROビットが設定されていたため、システムリセットが行われるまでSMPUの保護を変更することはできないようになっていました。

ペネトレーションテスト中に、アプリケーションコア上で攻撃者をシミュレーションしました。

SPC58のデータシートには、ROビットを設定した後はGVLDビットがSMPUに影響を与えないと明記されていたにもかかわらず、このハードウェアメカニズムがシリコンには実装されていないことが判明しました。そのため、アプリケーションコア上の攻撃者がGVLDビットに0を書き込むことでSMPUを無効化し、セーフティコアのメモリに対して読み取りおよび書き込み操作を行うことが可能になりました。

たとえCMPUが正しく構成されていたとしても、SMPUが無効化されると、DMAやEthernetといったシステム周辺機器を通じて主要なメモリが攻撃にさらされる結果となっていました。

STMicroelectronicsへの開示

SPC58チップでこの挙動を確認した直後、私たちはSTMicroelectronicsのPSIRT（製品セキュリティインシデント対応チーム）に、この脆弱性に関するすべての関連情報を提供しました。

数回のやり取りの後、STMicroelectronicsからこの問題に関するエラッタ（訂正情報）を公開するとの回答があり、以下がその問題に対する回答の全文です。

「検出されたSMPUの挙動の逸脱は、非セキュアデバイスドメインに影響を及ぼす可能性があります。ただし、このドメインはセキュリティ情報を保存するために使用されるべきではありません。

秘密情報やセキュリティクリティカルなデータは、HSMサブシステムのメモリ内に保存する必要があります。それが外部に保存される場合は、暗号化が必要です。

SMPUはセキュリティ保護メカニズムではありません。例えば、SMPUは干渉を防ぐための補助機能として設計されています。」

STMicroelectronicsへの責任ある開示の時系列

影響のあるSTMicroelectronicsのパーツ⁹

• SPC58デバイス全て
• SR5E1
• SPC574K (K2)
• SPC572L (Lavaredo)
• SPC574Sx (Sphaero)

(2) CVE-2024-33882

そこで、NXPのMPC5748を選択しました。このチップは「自動車および産業用で制御およびゲートウェイ向けの非常に高い信頼性を持つMCU」¹⁰と説明されています。このNXP PowerPCがSTMicroelectronicsのPowerPCチップよりも優れたセキュリティ体制を持っているかどうかを確認する目的です。

以下は、NXP MPC5748 PowerPCマイクロコントローラのブロック図¹¹です。

上記のブロック図を見ただけで、疑問を抱かずにはいられませんでした。コアメモリ保護ユニット（CMPU）はどこにあるのでしょうか？

黄色で示した部分は3つのMCUコアを表していますが、どれもCMPUによって保護されていないようです。このシステムオンチップ（SoC）には、赤で示したシステムメモリ保護ユニット（SMPU）しか存在しないようです。緑で示した部分はチップのメモリです。

さらに調査を進めたところ、MPC5748のSMPUはCMPUの機能も兼ね備えていることが判明しました。これはつまり、STのSPC58で見つかったのと同じ脆弱性がMPC5748にも存在する場合、攻撃者はコア保護とシステム保護を含むメモリ保護システム全体を完全に無効化できることを意味します！

NXPのレジスタ名は、STMicroelectronicsのチップと非常に似ています。「Global Valid」GVLDビットは、SMPUx_CES0レジスタのビット31に位置しています。

出典：MPC5748Gリファレンスマニュアル, Rev. 7.1, p. 493-494

メモリ領域は、レジスタSMPUx_RGDn_WRD5で定義されています

Source: MPC5748G Reference Manual, Rev. 7.1, p. 505

STMicroelectronicsのSPC58と非常によく似ており、リージョン・ディスクリプタ・ロック（LCK）またはSPC58での読み取り専用ビット（RO）は、メモリ保護領域を設定後にロックするために使用されます（上記の黄色で示されています）。赤い部分の注意書きもSPC58のものと似ているようです。

ここでもSPC58マイクロコントローラの場合と同様に、記述はほぼ同一です。リージョンをロックすると、SMPUのグローバル有効ビット（Global Valid）が無効になり、SMPUを無効化できなくなるとされています。

しかし、簡単なテストで判明したのは、SMPUが有効化され、すべてのLCKビットがロックされている状態でも、特権を持つ攻撃者がGlobal Validを0に設定することで、SMPUを完全に無効化できるということです。別にCMPUが存在しないため、SMPUを無効化することで攻撃者はメモリ空間全体に対して制限なしの読み取り/書き込み/実行アクセスを得ることができます。

NXPへの開示

MPC5748チップでこの挙動を確認した直後、私たちはNXPのPSIRT（製品セキュリティインシデント対応チーム）に、この脆弱性に関するすべての関連情報を提供しました。

何度かのやり取りの後、NXPはドキュメントの記述が不明確であることを認め、この夏（具体的な日付は未定）に誤解を防ぐためのドキュメントのエラッタを公開すると述べました。しかし、NXPはSMPUがセキュリティ機能ではないと明言しました。

以下にNXPの回答全文を示します¹²。

「本製品のリファレンスマニュアルは、SMPUがセキュリティ機能ではないことを明確に記載しています。SMPUは『セキュリティ概要』の章や『セキュリティモジュール』のセクションではなく、『システムモジュール』のセクションに記載されています。また、SMPUは『機能一覧』表の『セキュリティ』の項目には含まれておらず、SMPUを説明する章でも『セキュリティ』という用語は使用されていません。」

しかし、MPC5748チップのリファレンスマニュアルを読み進めても、SMPUがセキュリティ機能ではないという明確な記述は見つかりませんでした。それどころか、リファレンスマニュアルの第21章第2節のSMPUに関するパラグラフには、次のように記載されています。

「システムメモリ保護ユニット（SMPU）は、システムバスメモリ参照のためのハードウェアアクセス制御を提供します。SMPUは、システムバストランザクションを同時に監視し、メモリ空間とそのアクセス権を定義する事前プログラム済みのリージョン・ディスクリプタを使用して、それらの適切性を評価します。十分なアクセス制御権限を持つメモリ参照は処理が許可されますが、どのリージョン・ディスクリプタにもマッピングされていない、または権限が不十分な参照は、アクセスエラー応答となります」¹³

リファレンスマニュアルでは、SMPUについて直接的または間接的にも言及していません。ただし、SMPUについて書かれた章では、SMPUがMCUのメモリ空間へのアクセス権限を制御する役割を担っていると記載されています。これはコンピュータセキュリティの基本とも言える概念です。

NXPへの責任ある開示の時系列

軽減策

• 重要なセキュリティメカニズム、例えばMPUなどに関するデータシートの記載を信頼する前に、自身でテストを行うか、外部のペネトレーションテストベンダーを利用するなどして、必ずその主張を検証してください。
• また、MCUのエラッタ（訂正情報）を必ず確認してください。これには、チップのセキュリティ状況に関する重要な情報が含まれている場合があります。
• CVE-2023-48010に関連して: ハードウェアのメカニズムをセキュリティ目的で信頼できない場合（上述のSMPUの例のように）、そのメカニズムに依存しないでください！同等のセキュリティレベルを達成するための他の方法を探すか、安全で確実な方法で利用できるようにしてください。たとえば、STMicroelectronics MCUにあるCMPUのような他のメモリ保護ユニットを利用することを検討してください。

結論

本論文を通じて示してきたように、メモリ保護ユニット（MPU）はすべてのマイクロコントローラの防御戦略において重要な役割を果たしています。MPUは、自動車アプリケーションのコンテクストにおいて不可欠であり、車両内のECUや組み込みシステムのセキュリティ、信頼性、安全性を向上させます。そのため、共有リソースに対するアクセス制御を実行するために設計されたハードウェアメカニズムがセキュリティ機能ではない、というNXPやSTMicroelectronicsの主張を受け入れるのは極めて困難なように思います。

両社とも、特定の操作手順に従えばSMPUを無効化できなくなると明確に述べていますが、私たちが示したように、グローバル有効ビット（Global Valid Bit）をロックするはずだったハードウェア部分が実装されておらず、その結果、特権を持つ攻撃者がSMPUを無効化し、通常アクセス不可能な機密メモリ領域にアクセスできることが判明しました。

1. 出典: https://www.techtarget.com/searchsecurity/definition/access-control#:~:text=Access%20control%20is%20a%20security,access%20control%3A%20physical%20and%20logical. ︎
2. W. Stallings, L. Brown, Computer Security: Principles and Practice, 3^rd Edition, p. 114 ︎
3. Nicolas Dejon, Chrystel Gaber, Gilles Grimaud. From MMU to MPU: adaptation of the Pip kernel to constrained devices. 3rd International Conference on Internet of Things & Embedded Systems (IoTE 2022), Dec 2022, Sydney, Australia. ffhal-03705114v2f ︎
4. https://hal.science/hal-03705114v2/file/FromMMUToMPUAdaptationOfThePipKernelToConstrainedDevices-IoTE2022-Final.pdf p. 2 ︎
5. バストランザクションとは、コンピュータ化されたシステム内で、バスによって接続された2つのデバイス間でデータや制御情報を交換することを指します。バスは、コンピュータシステム内の複数のデバイスが互いに通信できるようにする通信経路です。 ︎
6. https://en.wikipedia.org/wiki/PowerPC_e200 ︎
7. ASIL D（Automotive Safety Integrity Level D）は、ISO 26262規格内で定義されている初期ハザード（傷害リスク）の最も高い分類を指します。このレベルは、合理的ではない残余リスクを回避するために適用される最も厳格な安全対策の水準を示しています。 ︎
8. これは、STMicroelectronicsがPowerPCマイクロコントローララインに付けた商標名です。 ︎
9. この影響を受けるMCUのリストは、2024年3月13日にSTMicroelectronicsからメールで送信されました。 ︎
10. https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/mpc5xxx-microcontrollers/ultra-reliable-mpc57xx-mcus:MPC57XX ︎
11. https://www.nxp.com/docs/en/data-sheet/MPC5748G.pdf, p. 4 ︎
12. この返信は、2024年4月4日に送信されたメールからのものです。 ︎
13. MPC5748G Reference Manual, Rev. 7.1, 01/2019, p. 479 ︎

The post 自動車用メモリ保護ユニットに隠れた脆弱性を解明 appeared first on PlaxidityX.

この記事では、自動車サイバーセキュリティにおけるAIの重要な役割を検証し、異常検知によって車両データから脅威を発見する方法、生成AIと大規模言語モデル（LLM）が脅威調査にどのような革命をもたらしているか、AIを活用したサイバー攻撃のリスクの高まり、拡張検知・応答（XDR）プラットフォームが包括的な保護を提供するためにAIをどのように活用しているかを探ります。これらのイノベーションの技術的側面を掘り下げるとともに、その効果を示す例を紹介します。

自動車サイバーセキュリティにおけるAIの価値

車両システムのコネクティビティおよび複雑化が急速に進行する中、潜在的な攻撃ベクターの数が指数関数的に増加しています。コネクテッドカーが生成するデータ量が膨大になるに従い、リアルタイムでスケーラブルな脅威検知・対応ソリューションが求められるようになります。AIはこのようなニーズに対して極めて重要な役割を果たし、従来のシステムにはない精度とスピードで対応します。

AIのリアルタイムのデータ処理と分析能力があれば、車両から送られる膨大な量のテレマティクス、IDPSセンサー、ネットワークデータを扱うことができ、人間のアナリストが長い時間をかけて検出するよりも早く脅威を発見することができます。例えば、コネクテッドカーは、ブレーキやアクセルの入力、周囲の環境に関する情報など、センサーに関連するデータを生成します。AIモデルはこのデータをリアルタイムで分析し、故障やサイバー攻撃を示すパターンを特定します。

さらに、パターンや傾向を認識するAIの能力は、予測型セキュリティにとって極めて重要です。AIは、膨大なデータセットの中から差し迫った脅威の微妙な兆候を特定する能力に優れており、セキュリティチームが一歩先んじて対応できるようにします。例えば、車両制御通信のわずかな逸脱を検出して、車両のシステムに悪意のあるコマンドを注入しようとする中間者攻撃の可能性を示すことができます。

また、AIは脅威検知の精度を高め、データのノイズと実際のセキュリティイベントを区別します。その結果、誤検知が減り、セキュリティチームの負担が軽減されます。さらに、AIはアラート分析やネットワークトラフィックの監視などのルーチンタスクを自動化して行えるため、チームは時間を節約し、より優先順位の高い問題に集中することができます。最後に、AIのスケーラビリティは、コネクテッドカーの大規模なフリートを管理する上で非常に重要であり、あまり人手に頼らずに包括的なセキュリティカバレッジを確保することができます。

AIを活用して車両データの異常を検知

異常検知は、自動車のサイバーセキュリティにおける重要なAI活用アプリケーションです。AIは、車両にとって「正常な」動作は何かということを継続的に学習することで、潜在的なサイバー脅威を示す逸脱を検出することができます。この機能は、最新の車両が生成するデータの複雑さと可変性を考慮すると、特に価値が高いといえます。

AIモデルはまず、ECU、センサー、CAN（Controller Area Network）バスのような車載ネットワークなどの車両データソースから、通常の動作パターンを学習します。時間の経過とともに、AIはブレーキ、加速、車両通信プロトコルの予想パターンなど、通常動作のベースラインを確立します。例えば、典型的なシナリオでは、CANバスは速度、スロットル開度、ブレーキ状態に関するメッセージを頻繁にやり取りします。AIシステムは、このような情報の流れを予測することを学習します。

AIは、CANバスの予期せぬコマンドやセンサーの異常な値など、これらのベースラインから著しく逸脱したアクティビティを検出すると、それを異常としてフラグ付けします。これらの異常は、システムの誤動作からサイバー侵入の試みまで、さまざまな問題を知らせるシグナルになる可能性があります。例えば、攻撃者が車両のブレーキシステムを制御するためにCANバスに不正なメッセージを注入した場合、AIを使用した異常検知はこのパターン外の通信を認識し、アラートを生成します。

異常検知の応用範囲は広く、不正なECUコマンドやネットワークトラフィックの急増など、AIはマルウェアを示す異常な挙動を特定することができます。別のシナリオでは、GPS信号を偽装して車両を誘導しようとする場合など、正規の車両信号になりすますハッカーの試みをAIが検出できるかもしれません。さらに、AI搭載システムはネットワークトラフィックを監視して、ECUと外部ネットワーク間の不正アクセスの試みまたは疑わしいデータフローを検出することができます。

生成AIとLLM： 脅威調査における革命

生成AIとは、文章、画像、コードの生成など、大規模なデータセットから得たパターンに基づいて新しいコンテンツを作成できる高度な人工知能システムのことです。大規模言語モデル（LLM）は、人間の言語を理解し、出力するように設計された生成AIです。LLMは、膨大な量のテキストデータを学習してパターンを認識し、文脈を理解し、非常に正確で関連性の高い情報を回答します。生成AIとLLMは共に、複雑なタスクを自動化し、自然言語を用いて深い洞察を提供することで、業界を変革しています。

自動車のサイバーセキュリティでは、生成AIとLLMは、セキュリティアナリストが自動車に関するサイバーインシデントを調査し、対応する方法に変化を起こしています。これらのテクノロジーは、複雑な車両システムをより深く文脈的に理解し、脅威をより迅速かつ正確に検知することを可能にします。生成AIとLLMは、膨大な量の車両データを分析し、ECU間の通信やセンサーの値の異常を特定し、可能性のある攻撃シナリオをシミュレートすることができます。このため、アナリストは、CANバスやテレマティクスシステムにおける異常な挙動などの脆弱性を迅速に特定し、攻撃がどのように進行するかを予測することができ、最終的には高度化するサイバー脅威に対して車両の保護を強化することができます。

生成AIは、潜在的な解決策や攻撃シミュレーションを自動化して、セキュリティチームを支援します。異常が検出されると、生成AIはその異常に関する詳細な文脈情報を出力し、それが既知の脆弱性や攻撃パターンとどのように関連する可能性があるかを示すことができます。例えば、車両通信の異常を検出すると、生成AIはそれがECUのファームウェアの既知の脆弱性と一致することを示し、アナリストに調査の出発点を明示するかもしれません。

さらに、生成AIは検出された異常に基づいてさまざまな攻撃経路をシミュレートできるため、アナリストは攻撃の結果を予測することができます。このため、脅威による被害が広まる前に、その脅威がもたらす影響について調べることができます。例えば、異常なCANバスのトラフィックを検出した後、生成AIは、関連する攻撃がブレーキやステアリングのような重要な車両システムの不正制御につながる可能性をシミュレートするかもしれません。

LLMは、膨大なデータセットとの自然言語による対話を促進することで、調査プロセスを強化します。LLMは、膨大な量の車両データ、脅威インテリジェンスレポート、過去の攻撃パターンを効率的に分析し、実用的な洞察を導きます。例えば、LLMは新たに検出された異常を、他の車両モデルにおける同様の攻撃ベクターと関連付けることができ、この脅威が大規模なキャンペーンの一部であるのかをアナリストが判断する助けになります。さらにLLMは、アナリストが自然言語を使用してデータの問い合わせを行うことを可能にし、複雑なログをナビゲートすることなく、重要な情報を簡単に抽出できるようにします。これにより、アナリストは過去の攻撃の兆候について照会し、即座に文脈に即した回答を得ることができます。

AIの暗黒面：巧妙化するサイバー攻撃

AIは防御側に大きなメリットをもたらす一方で、高度な攻撃を仕掛けるための洗練されたツールをサイバー犯罪者に提供することにもなります。攻撃者は、自動化された脆弱性スキャン、適応型マルウェア、標的型フィッシングキャンペーンにAIを利用するようになっており、サイバーセキュリティチームに新たな課題をもたらしています。例えば、AIを利用した攻撃者は、自動スキャンによって、パッチが適用されていないファームウェアや時代遅れのセキュリティプロトコルなど、車両システムの脆弱性を迅速に発見することができます。弱点を迅速に特定することで、より効率的に攻撃できるようになり、従来の手法よりも素早く、既知のセキュリティ欠陥をターゲットにした、車両のECUファームウェアへの迅速な攻撃が可能になります。

適応型マルウェアもまた、広がりつつある脅威のひとつです。AIは、マルウェアが動作する環境に応じて、その挙動を動的に調整することを可能にします。例えば、自動車のインフォテインメントシステムを標的とするAIを搭載したマルウェアは、当初は異常な挙動を見せず、車両全体のネットワークとの統合を検出すると、悪意のあるペイロードを実行することがあります。

さらに、AIは高度に的を絞ったフィッシング攻撃を仕掛けるために使用されることもあります。生成AIモデルは、自動車メーカーの従業員を欺くためにフィッシングメールをパーソナライズすることができ、受信者が正当なメッセージと攻撃を区別することを難しくします。例えば、AIは信頼できるパートナーや同僚から送られたように見せかけたフィッシングメールを生成し、認証情報の詐取の成功率を高めます。

AIを搭載したXDR: フリートを狙うサイバー脅威への対策

XDR（Extended Detection and Response）は、特に自動車業界において複雑化するサイバー脅威に対応するために設計されています。XDRプラットフォームは、AIを使用して、車両エコシステム全体からのデータを統合し、知能的な脅威の検出、対応、緩和を実現する統合されたエンドツーエンドのセキュリティソリューションです。

XDRプラットフォームの主な強みの1つは、AIを活用した検知機能です。XDRプラットフォームには、自動車の環境に合わせたAI検知ルールがあらかじめ組み込まれており、既知の脅威や新たな脅威を迅速に特定することができます。例えば、XDRプラットフォームには、CANバス上の不審なアクティビティを検出したり、車両センサーへの不正アクセスにフラグを立てたりするためのルールがすぐに使える状態で含まれている場合があります。

統合データプラットフォームは、XDRシステムのもう一つの重要な特徴です。ECU通信、CANバストラフィック、外部ネットワークアクティビティなど、さまざまなソースからのデータを統合することで、XDRは車両のセキュリティ状況を包括的に把握することができます。例えば、XDRプラットフォームは、CANバスメッセージで検出された異常と外部ネットワークの異常なトラフィックパターンを関連付け、連携した攻撃を検出することができます。

AIはまた、XDRシステム内でよりスマートな緩和策を実行します。脅威が検出されると、AIはそのコンテキストを分析し、特定の攻撃に合わせた緩和策を推奨します。場合によっては、パッチの適用、侵害されたシステムの隔離、被害の拡大を防ぐためのファイアウォールルールの調整といった対応をAIが自動化することもできます。例えば、車両通信でスプーフィングを検出した後、XDRプラットフォームのAIは、影響を受けたECUを自動的に隔離して、さらなる改ざんを防ぐことができます。

リアルタイムの脅威検知、インテリジェントな対応メカニズム、包括的なデータ分析を統合することで、XDRプラットフォームは、コネクテッドカーを標的とする高度化するサイバー脅威に対して強固な防御になります。

時間との戦い：自動車のサイバーセキュリティは進化しなければ取り残される

サイバー犯罪者がAIを活用して車両やフリートに対して巧妙化する攻撃を行うケースが増えており、自動車業界はAIを活用した強固なサイバーセキュリティ対策を導入する必要ががますます高まっています。このような新たな脅威に効果的に対処するためには、OEMは積極的なアプローチを採用し、インシデントが発生する前に対策を実施する必要があります。攻撃者が絶えず戦術を洗練させている環境では、一歩先を行くことが不可欠です。AIを搭載したXDRプラットフォームは、このような課題に対処するために必要な知能的で統合された対応を提供します。高度な検出機能、リアルタイムの洞察、よりスマートな緩和戦略により、XDRは貴重なツールとしてだけでなく、進化するサイバー環境におけるコネクテッドモビリティの未来を確保するための重要なコンポーネントとしても機能します。

The post ギアを加速：自動車サイバーセキュリティの変革とAIの果たす役割 appeared first on PlaxidityX.

DevSecOpsとは？

DevSecOpsは、ソフトウェア開発ライフサイクルを通じてセキュリティをシームレスに統合し、工程の早い段階で潜在的な脆弱性を特定し、必要に応じて対処するアプローチのことです。このアプローチは、ハードウェア生産の重視からソフトウェア開発の優先に移行しようとする自動車メーカーやサプライヤーにとって極めて重要であるといえます。

本レポートのために、PlaxidityXは北米、ヨーロッパ、アジアの主要な自動車メーカーやサプライヤーの開発、エンジニアリング、セキュリティ、DevOps、QAの各分野の専門家数百人を対象に調査を実施しました。そのデータに基づき、企業がどのようにDevSecOpsを導入しているか、直面している主な課題、そしてどのようなメリットがあるかについて明らかにしています。

レポートの要点

1. 複雑なセキュリティ対策の負担： 回答者の63％が少なくとも勤務時間の20％をセキュリティタスクに費やしており、製品セキュリティの管理が開発チームにとって複雑で、大きな負担になっていることが明らかになりました。この課題は、複数のセキュリティツールを使用する必要性によってより深刻化しており、55％の人が7～10種類のツールを使用していると答えています。
2. ツールの有効性に関する課題： セキュリティチームが自社で使用しているツールに満足している一方で、研究開発チームとエンジニアリングチームのうち、ツールが有効であると評価しているのはわずか20％でした。この回答の差は、セキュリティと、イノベーションそしてスピードのバランスをとることの難しさを浮き彫りにしています。
3. 自動車メーカーとサプライヤーの比較： 自動車メーカーはDevSecOpsを製品品質を向上させる方法として主に捉えているのに対し、サプライヤーは顧客の信頼を高めることを主眼に置いています。数あるメリットの中でもコスト削減は下位にランクされており、DevSecOpsが単なる効率向上策ではなく、製品の成功と信頼に不可欠なものであるという業界の理解の変化を示しています。

SDV開発におけるDevSecOpsの重要性

「当社の調査レポートは、自動車業界で起きている変革を浮き彫りにしています。企業は、DevSecOpsが単なるコスト削減ではなく、顧客からの信頼につながるような高品質でセキュアな製品を提供することだと認識しています。」

DevSecOpsの導入を加速

このレポートは、多くの自動車メーカーがDevSecOps導入を進めている一方で、まだ道のりが長いことを示しています。自動車メーカーとサプライヤーはそのメリットを実感することが増えているようですが、リソースの不足、ツールの複雑さ、効果的な統合の欠如が依然として大きな課題となっています。

DevSecOpsのプラクティスを採用することで、自動車業界の各社は、ソフトウェア優先の業界で競争力を保ちながら、製品の安全性を高め、開発サイクルを短縮し、全体的なリスクを低減することができます。

The post DevSecOpsを加速する： 2024年調査レポート　車載ソフトウェア開発者のための洞察 appeared first on PlaxidityX.

自動化テストをCI/CDパイプラインに組み込むと非常に大きな利点が得られます。ただし、真に効果的であるためには、テスト時間が標準的な開発サイクルと合致して、可能な限り迅速にフィードバックが提供されなければなりません。実装を完了させた後に、パイプラインに定義されたリグレッションテストやDevSecOpsテストにコードが合格したかどうかを確認するまで長い時間待たされることほど、開発者がフラストレーションを感じることはありません。

プラクシディティ エックス（旧アルガス）は、社内の製品開発部門とお客様の双方のために開発サイクルの最適化に取り組んでいます。

これから、当社の主要な製品開発チームが、夜間のテスト実行時間を2時間44分からわずか21分に短縮した方法についてご紹介します。

ステップ1 – 現状分析

テスト実行の改善に向けた最初のステップは、現状を理解し、テストにかかる時間の裏に潜む根本原因を明らかにすることでした。

チームはウィザードとして構築されたWebベースのアプリケーションのテストを担当しています。ウィザードでは、一連のステップを通じてシステムに様々なパラメータや機能を設定でき、最終的にはユーザーが使用できるダウンロード可能な出力が提供されます。

安全性が保証された範囲を確保するために、テストは主に次の2つのカテゴリーに分かれていました。

1. 機能テスト – アプリケーションの様々な機能、ロジック、要素をテストする
2. エンドツーエンド（E2E）テスト – システムの様々なフローを実行し、出力をダウンロードし、出力に期待通りの結果が含まれているか検証する

Allureレポートとコードを詳しく調べたところ、実行時間に関する興味深い知見を得ることができました。

1. テストは順番に実行されている。つまり、総実行時間は個々のテストにかかった時間の合計である
2. 何かが原因で単純な機能の検証に時間がかかっている
3. 他より大幅に時間のかかる機能がある
4. テストケースとそれらのステップ、再実行方法に冗長性が見つかった

ステップに長い時間がかかっている原因を分析したところ、次のようないくつかの要因が重なっていることがわかりました。

1. アプリケーションを実行するマシンリソースが不足していたために、アプリケーションの動作が遅くなっていた
2. テスト効率が最適ではなかった。UIで操作し、より効率のよいRESTful APIを使用していなかった（UI要素がテスト対象でない場合）

次に、一部のステップに他のステップより大幅に時間がかかっていた原因の解明に取り組みました。例えば「ページに移動」のステップは効率よくコード化されていなかった、ということがわかりました。該当ページに移動するのに、自動化インフラストラクチャとして目的画面にただ「ジャンプ」すれば済むところを、ユーザーとして目的のページまで各画面への移動を繰り返していました。

テストケースにおけるログインメカニズムの問題解決にも取り組みました。通常、各テストケースでは設定フェーズ時にブラウザを開き、URLに移動してログインを実行します。一部のテストケースでログインメカニズムを検証すれば、他のすべてのテストケースでこのプロセスを踏む必要はありません。代わりに、一度ログインしてセッションを維持し、残りのテストケースを実行することで、ログインフェーズをスキップすることができます。

注：不安定なテスト（一貫性のない結果を出すテスト）は、テストケースを再実行して貴重な時間を浪費することになりがちな重大な課題です。次のブログでは、不安定なテストを管理・軽減するための戦略を掘り下げます。どうぞお楽しみに。

ステップ2 – 必要な改善の導入

最初のステップで集めた知見と情報に基づき、私たちは次のアクションアイテムを定めました。

1. テストケースの並列実行を実装する
2. テスト対象システム（SUT）を実行するマシンリソースを拡充する
3. テストインフラストラクチャにRESTful APIハンドラーを実装する
4. 「ページに移動」などの機能の実装を最適化する
5. ログインフェーズを最適化する
6. テストケースを確認し、冗長なケースを取り除く
7. テストケースを確認し、冗長なステップを取り除く

上記のアクションアイテムは１人以上の分量だったため、複数のチームメンバーが関与しました。これらのアクションアイテムを割り当てた後、「クイックウィン（即効性のある小さな成功）」を達成することを優先して、早い段階で目に見える改善を実現し、フィードバック時間を10～15分に短縮するという目標に向けてチームの士気を上げました。

並行テストの実行

並行テストの実行は有益であると広く認められていますが、次のような課題が存在します。

1. テストランナーが並行実行をサポートしなければならない
2. テスト用システムで複数の同時操作をサポートするか、複数のテスト環境を設定する必要がある
3. 各テストは独立して実行できる必要がある。テストの設定で必要な状態を作り、テスト後にクリーンアップしなければならない
4. テストケースは他のテストケースで使用している共有リソースを上書きしたり、共有リソースへのアクセスに関して競合したりしてはならない

私たちは次のような方法でこれらの課題に対処しました。

1. テストランナーにpytestを使用する。これには「pytest-xdist」という並行実行向けのすぐれたプラグインが用意されている
2. テスト用システム自体が複数の操作をサポートしている。そのため、システムの動作が大幅に遅くなっていた。システムリソースを最適化するためにDevOpsチームと協力した
3. テストの独立性はすでに実装されていた（テスト自動化のための一般的なベストプラクティス）
4. 出力ファイルの管理は重要な課題だった。テストを並行実行すると、相互のファイルが上書きされていた。各テスト出力に一意のパスを割り当て、テスト名と正確な実行時間をそれに組み入れることで、この課題を解決した。UUIDもこの目的に役立ったと考えられる

注意すべき重要なことの一つは、起動できるワーカー（独立したプロセス）の数を、実行するマシンに含まれるCPUの数と等しくすることです。CPUの数が増えれば増えるほど、並行で実行できるテストの数が増え、実行時間が短くなります。

2営業日後、私たちは8つのCPUを備えたマシンを使用して並行実行を組み込むことに成功ました。これにより、夜間の実行が2時間45分から48分にまで短縮できました。

今後、各マシンのCPUの数を増やして、さらに改善を進めようと計画しています。

テストインフラストラクチャにRESTful APIハンドラーを実装する

テストは通常、前処理、実行、後処理の3つのフェーズで構成されます。

前処理と後処理のフェーズで実行する操作は主要機能をテストしないため、必要な機能を使用できる限り、柔軟に実装することができます。したがって、より軽くて速いRESTful API呼び出しで同じ結果を効率良く達成することができるのであれば、重くて遅いUI操作に頼る必要はなくなります。

テストケースでRESTful API呼び出しを使用するために、次のことを実行しました。

1. 統合レイヤーの開発 – RESTful APIとのすべてのインタラクションを処理するテストフレームワーク内のレイヤー。このレイヤーにはリクエストの送信、応答の処理、認証トークンの管理を行う機能が含まれます。
2. RESTful APIベースの機能の実装 –テストの一環として使用する機能（「create_new_project」など）について、RESTful APIハンドラーを使用した実装を追加できました。そのため、設定に応じてRESTful APIまたはUI操作のいずれかを使用して操作できるようになりました。
3. テストケースの前処理と後処理を変換してRESTful API機能のみを使用するようにしました。

この移行には開発チームとの幅広い連携が欠かせませんでした。結果的にテストケースの実行時間が大幅に短縮（各テスト約2分からわずか30秒に短縮）され、夜間の実行時間が全体で23分にまで短くなりました。

その他の改善点

上記に加え、アクションアイテムリストの他のアクティビティも実装して、テストインフラストラクチャの効率を向上させ、自信を持ってCI/CDプロセスを行えるようになりました。最も重要なことは、これらのすべての改善を、テスト品質を損なうことなく達成できたことです。つまり、同じ機能やセキュリティをより短い時間で網羅できるようになったのです（グラフを参照）。

現在、テスト実行時間は21分にまで短縮され、目標の10～15分も視野に入ってきました。目標達成まであと少しです！

覚えておきたい重要点

ここまでお読みいただいた方はおそらく、自社のテスト自動化を改善する方法にご興味をお持ちなのではないでしょうか。 

次に、私たちが経験から得た学びをご紹介しますので、ぜひご検討ください。

技術的なヒントとリソース

1. テストインフラストラクチャ用の並列テスト実行プラグインをご検討ください。
   1. Python – pytest – pytest-xdist
   2. Python – unittest – nose2
   3. Java – JUnit 5 – junit-platform-parallel
   4. Java – TestNG – ビルトインサポート
   5. JavaScript – Jest – ビルトインサポート
   6. JavaScript – Mocha – ParallelBufferedRunner
   7. JavaScript – Cypress – ビルトインサポート
2. 自動化にRESTful APIをまだ利用していない場合は、RESTful APIテスト戦略の計画を開始し、関連する開発マネージャーに必要なプラットフォームの提供を依頼してください。
3. Playwrightを使用していて、ワンタイムログインのメカニズムを導入したいとお考えの場合は、このブログをご確認ください。他のフレームワークでも、同じ結果を達成するための独自の方法があるはずです。

まとめ

この投稿はCI実行時間の短縮に焦点を当てていますが、このアプローチは一連のパフォーマンステストの実施、新たなDevSecOPSツールのパイプラインへの組み込み、自動テストケース生成へのAIの統合など、プロジェクトの内容に関わりなくあらゆる自動化改善プロジェクトに適用できます。

QA自動化改善プロジェクトを成功させるための当社の基本計画は次の通りです。

1. 現在の稼働状況とその要因を分析する
2. アクションアイテムを管理可能な小さなステップに分割する
3. タイムラインに沿ってアクションアイテムの実施を計画し、関係リソースを割り当てる
4. 各アクティビティを継続的にモニタリングする

最後に、クイックウィンの重要性を過小評価しないでください。簡単に完了できて目に見える効果を発揮するステップがどれかを見つけ出してください。クイックウィンによってチームの自信が高まるだけでなく、取り組みの正当性を組織内の他のステークホルダーに説明しやすくなります。

さらに詳しい内容にご興味をお持ちでしょうか？

The post CI/CDパイプライン：品質を維持し、追加コストをかけずに、自動化ソフトウェアのテスト時間を85％短縮する方法 appeared first on PlaxidityX.

EVは、充電ステーション、スマートグリッド、その他の車両を含む、より大きな相互接続されたエコシステムの一部です。これらのコンポーネントのひとつにセキュリティ上の欠陥があれば、他のコンポーネントも危険にさらされる可能性があります。例えば、EVと充電ステーション間の通信は、充電ステーションを改ざんする悪意ある行為者によって侵害され、車両を危険にさらす可能性があります。

このような脅威を踏まえ、プラクシディティ エックス（旧アルガス）のリサーチグループは、EVの充電プロトコルとEVと充電ステーション間の通信について徹底的な研究を行ってきました。私たちの目標は、EVや充電ステーションが充電インターフェースを介して攻撃される可能性がある既知の方法と、これまで公表されていなかった方法を探り、理解することでした。

この記事は、当社のリサーチャーが発見した、攻撃者が充電ステーションを侵害して、コントロールする恐れのあるオープンソース・フレームワークの重大な脆弱性についてまとめたものです。この脆弱性については、すでにプロジェクトの保守担当者に「責任ある開示」がされており、問題は修正されています。

新たに発見された脆弱性はEVメーカーにも関係するものです。なぜなら、これらのプロトコルは双方向通信に使用されるため、EVにも実装する必要があるためです。したがって、仮説ではありますが、この脆弱性を利用して、EV充電に関する車載ECUを侵害することができると考えることができます。

脆弱性の概要 (CVE-2024-37310)

この重大な脆弱性は、EV充電のためのフルスタック環境を構築するためのオープンソースのモジュールフレームワークであるEVerestプロジェクトで発見されました。モビリティ分野の電動化を支援するためにPIONIX GmbHによって開始されたEVerestプロジェクトは、Linux Foundation Energy（LFE）の公式プロジェクトです。この大規模なオープンソース·プロジェクトは、最終的には公共充電ステーションの標準通信スタックになることを目指しています。

私たちは、EVerest フレームワークの EvseV2G モジュールの V2G トランスポートプロトコル (V2GTP) の実装に、整数オーバーフローを発見しました。この脆弱性はヒープオーバーフローを引き起こし、攻撃者がLinuxプロセス上で任意のコードを実行することを可能にします。これにより、充電のための支払いゲートをバイパスしたり、充電ステーション（電気自動車給電装置、Electric Vehicle Supply EquipmentまたはEVSE）に保存されている秘密鍵を侵害したり、侵害されたが信頼できる充電ステーションになりすましてOCPP（Open Charge Point Protocol、充電インフラ通信プロトコル）を使用してベンダーのバックエンドと通信したりすることができます。

この脆弱性は、PlaxidityX Security AutoTesterを使ってEVerestの実装をテストしているときに発見されました。これは、V2Gを含む自動車プロトコルのセキュリティ問題や脆弱性をファジングテストで検出するために設計されたツールです。

プラクシディティ エックスはこの脆弱性をEVerest プロジェクトの保守担当者に慎重に開示し、問題はは迅速に修正され、パッチが適用されたバージョンがリリースされました。  

この脆弱性の特徴について

これまで、EVのサイバーセキュリティに関するセキュリティ研究のほとんどは、充電ステーションにアクセスするために使用される外部通信プロトコル [1]（WiFi、Bluetooth、NFCなど）に注目していました。今回のケースでは、よくある通信インターフェースではなく、充電インターフェースに脆弱性があります。この脆弱性に関する私たちの研究は、EVと充電ステーション間のダイレクトな通信を分析するもので、セキュリティ·コミュニティではまだあまり注目されていない分野です。私たちが特に注目したのは、EVが充電ステーションを攻撃するためにどのように使われる可能性があるのか、またその逆もあり得るのかということです。

攻撃シナリオの例

この脆弱性を悪用するには、攻撃者は公共の充電ステーションにアクセスする必要があります。充電ステーションのソフトウェアにアクセスする最も一般的な方法は、物理的な接続です。攻撃者は、通常の充電ケーブルの一端を充電ステーションに差し込み、もう一端を（簡単な修正を加えた上で）ノートパソコンに接続されたPLCモデムに差し込み、脆弱性を悪用すれば充電ステーションを制御することが可能になります。

EVとEVSEの間のハイレベルな通信は、通常、公共の充電ステーションで行われていることに注意が必要です。このような充電ステーションは都心から離れていたり、無人であったり、十分な物理的セキュリティがないことも多いです。このようなシナリオでは、準備されたツールを持った攻撃者は、気づかれることなく充電ステーションを侵害することができるのです。

EVもこの脆弱性の危険にさらされる理由

前述の通り、今回発見された脆弱性は、充電ステーションの通信プロトコルの実装におけるエラーに関連しています。ISO 15118-2とDINSPEC-7012規格は、EVと充電ステーション間の通信を定義していますが、この規格の実装は複雑でエラーが発生しやすいのです。結局のところ、これらのエラーはバグにつながり、ひいてはセキュリティの脆弱性につながる可能性があります。

ここで重要なのは、この同じ規格が車両の電気自動車通信コントローラ（EVCC）ECUにも実装されていることです。EVでは、EVCCが充電ステーションとの通信を担当します。したがって、充電ステーションのソフトウェアで私たちが発見したのと同じ脆弱性が、実装の欠陥によりEVCC自体でも見つかる可能性があると考えるのが妥当です。

このようなシナリオでは、攻撃者がEVCC ECUのこの脆弱性を悪用してECUを侵害し、車両ネットワーク内部の足掛かりを得る可能性があります。極端な場合、攻撃者がCANバスに内部アクセスできるようになり、セーフティクリティカルな車両コンポーネントのセキュリティが脅かされる可能性があります。

EVメーカーにとって重要なこと

私たちの調査によると、他の多くの通信プロトコルと同様に、ISO 15118-2規格の実装にはプログラミングエラーやバグが発生しやすいのです。様々な特殊ケースを検討することは、各EVメーカーの責任です。一律に対応できる解決策はなく、実装を正しく行うには多くの労力が必要です。

我々が発見した脆弱性は、正しく実装することの難しさを物語っています。EVerestは、多くの開発者が関わっている巨大なオープンソース·プロジェクトですが、私たちは実装の欠陥による重大な脆弱性を特定しました。このエラーが多数の開発者の目を逃れることができたとすれば、EVメーカーが自社開発した独自の実装でも同じことが起きると考えるのが妥当でしょう。

要するに、EVメーカーは（オープンソースであろうとなかろうと）充電通信プロトコルを車両に実装する際には、その複雑さと潜在的なセキュリティリスクに留意しなければならないということです。ここでは、実装の誤りがどのような事態を招くかをみてきました。

EVセキュリティのための事前対策

プラクシディティ エックスは、大手グローバルOEMおよびTier1サプライヤーと何十もの量産プロジェクトで協力し、製品のセキュリティ体制を強化し、新しい自動車サイバーセキュリティ規制への準拠を支援した豊富な経験があります。当社のコンサルティング　リサーチグループは、自動車およびECUメーカーに、自動車ペネトレーションテスト、TARAとサイバーセキュリティ·アーキテクチャデザイン、UNR 155およびISO 21434サイバーセキュリティ·コンプライアンスなどの包括的な自動車サイバーセキュリティサービスを提供しています。

EVのサイバーセキュリティについて疑問は、自動車サイバーセキュリティの専門家にご相談ください。

The post EVのサイバーセキュリティ：PlaxidityXがEVerestオープンソースEV充電ファームウェアに重大な脆弱性を発見（CVE-2024-37310） appeared first on PlaxidityX.

現在では、ソフトウェア・デファインド・ビークル（SDV）という言葉を聞いたことがないという人はいないでしょう。 具体的にそれが何を意味するかはそれぞれの観点によって変わってきます。しかし、その意味するところとして、現代の自動車のコンポーネントに使用される組込みソフトウェアのコードの量が増えており、かつては機械的または電気的な手段で制御されていた多くの機能が、現在ではソフトウェア・コードによって制御されているということは広く認識されています。このこと以上に、SDVはハードウェアとソフトウェアを分離することを可能にしました。言い換えれば、自動車メーカーはすでに道路を走っている車両に対しても、車両機能を更新したり、新しい機能を導入したりすることができるのです。

SDVのコンセプトを採用する車両が増え、この進化（なかには「革命」と表現する人もいます）の意味合いが具体化し始めると、ユーザー・デファインド・ビークル（UDV）の話題が出てきます。これは一体どういうことを意味するのでしょうか？携帯電話を例にとって比較してみましょう。

スマートフォンが登場する前の時代に使っていた携帯電話は、どのようなものであったか、思い出すのは難しいでしょう。当時の携帯電話の機能や性能は、購入から何年経ってもその端末の寿命までまったく変化しませんでした。携帯電話に新しい事をさせたかったら、店舗で新規モデルを買う必要がありました。

現代のスマートフォンは、2つの重要な点ですべてを変えました。第一に、携帯電話のオペレーティング・システム（OS）をハードウェアから切り離したことで、携帯電話メーカーはOTA（オーバー・ジ・エア：無線通信によるアップデート）によって定期的にシステムを更新できるようになりました。多くの携帯電話メーカーは、少なくとも年に1回はOSをアップデートし、新しい機能や性能を追加しています。第二に、携帯電話の所有者は自分の興味のあるアプリをインストールすることができるようになりました。2008年にApple社がiPhoneにApp Storeを導入したことで普及したスマートフォンのエコシステムは、今日、オンラインアプリストアで数百万ものアプリを提供しています。ユーザーは皆、自分の好みに合わせてアプリを選ぶので、同じ電話は二つとありません。文字通り、ユーザー自身が自分の経験を定義しているといえます。

アプリは王者、今度は自動車にも

スマートフォンと同様に、UDVは車の所有者がユーザー体験をカスタマイズできるようにするものです。AppleやAndroidのユーザーは、以前からApple CarPlayやAndroid Autoを使用して、これらのプラットフォームと互換性があれば、スマートフォン上のアプリを車のインフォテインメント・システムにミラーリングしています。しかし、Android Automotiveなどの新しい車両ネイティブ・プラットフォームは、さらに直感的なユーザー体験を提供し、ユーザーはスマートフォンなどのデバイスからミラーリングする必要なく、車両インフォテインメント・システムに好みのアプリを直接インストールすることができるようになっています。

車載コネクテッドサービス

SDVのコンセプトは、コネクティビティというもうひとつの自動車トレンドに乗っかっています。この2つの組み合わせは、自動車メーカーにとってコネクテッド・サービスの販売という新たなビジネスモデルを可能にしています。調査によると、自動車会社はコネクテッド・カー・サービスを販売することで、1台あたり1,600ドルを生み出すことができると予測しています。車の所有者は、ありとあらゆる機能を購入する必要はありません。その代わり、欲しいものを選んで購入することができます。マッキンゼーの調査によると、コネクティビティの好みは地域や顧客セグメントによって大きく異なります。例えば、中国の消費者は高度な運転支援機能などの先進技術を好み、米国やドイツの消費者はシートヒーターや空調制御などの快適性や利便性を好む傾向にあります。また、消費者は柔軟な支払いオプションを望んでおり、機能に対して1回払いを好む人もいれば、サービスベースのサブスクリプション・モデルを望む人もいます。

ソフトウェア・アップデートによりクルマが新しい技を学習する

多くの自動車メーカーは、顧客が購入したりサービスに加入する前から、将来のサービス購入を可能にするハードウェア、センサー、テクノロジーを車の設計に追加しています。これは、アフターマーケットでの機能追加はさておき、車のハードウェアは通常、車の寿命が尽きるまで変わらないため、変化を続け、新規のサービスを提供することを可能にするために必要だからです。自動車の平均的な寿命は12年以上であり、多くの自動車はこれよりもはるかに長持ちです。しかし、コネクテッドSDVが、OTAでソフトウェアアップデートをできるようになれば、新たな次元で機能強化を行う機会となります。2012年にモデルSを発表してSDVのパイオニアとなったテスラは、およそ数カ月ごとに車載ソフトウェアを更新しており、これよりも早いタイミングで更新を行うこともあります。テスラだけではありません。一部から「中国のテスラ」とも言われているNioは、独自のUDVを提供しています。Nioは自らを自動車メーカーではなく「ユーザー・エクスペリエンス」と捉え、顧客を「ユーザー」と考えています。彼らは少なくとも年に4〜5回、完全なソフトウェア・アップデートを行っており、これはユーザーからのフィードバックをもとに機能とソフトウェア開発プロセスを行うものです。フィードバックは通常、車内の音声アシスタントシステムを通じて収集される以外にも、ユーザー向けワークショップやユーザーのスマートフォンからも収集されます。そして、それは直接Nioのユーザー・アドバイザリー・ボードに届けられます。Nioのエクスペリエンス・マネージャーがフィードバックを分析し、複数のユーザーから出たコメントは数ヶ月以内にOTAアップデートによって車両の改善に反映されます。2023年、Nioは768件のエクスペリエンス向上を含む10回のOTAソフトウェア・アップデートを行いました。

ユーザー・デファインド・ビークルにおけるサイバーセキュリティの観点

SDVからUDVへの進化は、スマートフォンの歴史を参考に、これまでにないまったく新しいカー・デジタル体験を切り開くものです。同時に、業界が考慮しなければならない自動車サイバーセキュリティの問題も提起しています。車の所有者がデジタルアプリをダウンロードおよびインストールできるようにすることは、悪質な行為者にとって新たな潜在的攻撃ベクトルを生み出すことになります。アプリの中には、正規のものであっても、サイバー態勢が十分でないものもあり、ソフトウェアの脆弱性や車両へのハッキングに悪用可能な弱点を含んでいる可能性があります。また、不正アプリがApp Storeに潜んでいて、車の所有者が意図せず悪意のあるコードを車に注入してしまう可能性も考慮する必要があります。

デジタルアプリ以外に、道路を走る車のソフトウェアアップデートは、ソフトウェア脆弱性のもう一つのチャンネルになります。SDV 車のメーカーは、年に何度も主要なソフトウェアアップデートをプッシュしています。このようなソフトウェアスタックにはそれぞれ新しいコードが含まれ、オープンソースまたは商用ソフトウェアの新規または更新されたソフトウェアライブラリが導入される可能性があります。車両ソフトウェアのサイバー態勢を維持することは、変化し続ける目標というだけではなく、終わりのないタスクになりつつあります。ある意味、UDVのソフトウェア開発プロセスに終わりはありません。伝統的に、車両とそのコンポーネントの設計と開発は生産開始前に行われますが、UDVのソフトウェアはその後何年にもわたって進化し、強化され続けるようになるでしょう。

ユーザー・デファインド・ビークルのサイバーセキュリティリスクを軽減する方法

1. 車載ソフトウェア開発にDevSecOpsアプローチを適用すること。この方法論は、セキュリティをシフトレフトすることを可能にし、設計と開発プロセスの各段階でセキュリティテストと対策の適用が可能になります。
2. 各車両コンポーネントのソフトウェアコードに脆弱性がないかスキャンすること。ソフトウェア更新のたびに脆弱性が含まれている可能性があるため、ソフトウェアをデプロイする前に発見し、対処する必要があります。
3. ソフトウェアバイナリしか入手できない場合（例えば、コードがサプライヤによって開発されている場合）、サプライチェーンのサイバーセキュリティ態勢を高く維持するために、すべてのバイナリのソフトウェア部品表（SBOM）をスキャンして脆弱性を検出すること。
4. ゼロデイ脆弱性を発見し、ソフトウェアが安全であることを確認するために、ファジングテストとペネトレーションテストを実施すること。
5. スイッチ、ゲートウェイ、重要なECUなどの車両アーキテクチャの戦略的領域に侵入検知・防御システムを組み込むこと。CAN IDPS、Ethernet IDPS、Host IDPSは、悪質な行為者が侵入に使用できるような脆弱性を見つけた場合に、車両を保護することができます。
6. 車両フリートを定期的に監視すること。車両セキュリティ・オペレーション・センター（VSOC）で拡張検知·対応プラットフォームを採用すれば、リスクやサイバー攻撃をリアルタイムで特定できるため、迅速な対処が可能になります。

The post ユーザー・デファインド・ビークルの登場：テクノロジー、パーソナライゼーション、サイバーセキュリティの融合 appeared first on PlaxidityX.

Linux上で動作するECU（Android上で動作するものもあります）には、SELinux（Security-Enhanced Linux）として知られるオープンソースの保護レイヤーが付属しています。SELinuxはソフトウェア開発者にとっては効果的な汎用ツールですが、自動車のサイバーセキュリティの観点からは、すべての要件を満たしているとは言えません。そのため、多くのOEMは、車載ネットワークやコンポーネントを保護し、新たな自動車サイバーセキュリティ規制や標準（ISO 21434、UNR 155、中国のGB/Tなど）に準拠するために、侵入検知・防御システム（IDPS）を導入しています。

この記事では、複雑なサイバー脅威からコネクテッドECUを保護するために、OEMやティア1サプライヤーがSELinuxに加えてセキュリティを必要とする理由について説明します。

車載用途におけるSELinux： 強みと課題

SELinuxはLinuxカーネル・セキュリティ・モジュールであり、システム管理者がユーザー、プログラム、サービスに対して設定したアクセス制御セキュリティ・ポリシーを管理・実行するためのメカニズムを提供します。そのため、SELinuxが有効な環境内のアプリケーションは、指定された境界を超えてシステムリソースにアクセスしようとする試みから保護されます。このセーフガードは、アプリケーションの一貫した安全な動作を保証します。

SELinuxは、Linux上で動作する自動車用ECUの管理とセキュリティにおいて極めて重要な役割を果たしています。システムプロセスをきめ細かく制御し、ミッションクリティカルな車両システムのセキュリティを強化します。この機能は、高度化するサイバー脅威から車載ECUを保護しようとするOEMとTier 1サプライヤーの双方にとって極めて重要です。

こうした強みがあるにもかかわらず、自動車業界におけるSELinuxの実装に関して、いくつかの業界特有の課題があります：

• 機能を損なうことなくセキュリティを最大化すること – サイバーセキュリティを実装する際には、攻撃対象領域を最小化すること（つまり、システムを制限すること）と、通常のシステム機能に必要な機能を許可することの間で、常にバランスを取る必要があります。言い換えれば、異常な動作に対してシステムを強化したいにもかかわらず、日常的な運用を可能にするためにシステムを十分にオープンにしておく必要があるということです。そのためには、あるプロセスに対しては機能を制限し、別のプロセスに対しては同じ機能を許可するという柔軟性が必要ということになります。これをSELInuxで実現するのは難しいことです。
• リアルタイムレスポンス機能の必要性 – SELinuxのようなハードニング保護レイヤーは優れていますが、静的なものであり、急速に進化する攻撃手法に対応するようには構築されていません。対照的に、不可知論的で柔軟なソリューション（例えば、SELinuxをEDR（Endpoint Detection and Response）や自動車向けIDPSと組み合わせる）は、定期的なメンテナンスを必要とすることなく、動的な方法で包括的で詳細な保護を提供することができます。
• セキュリティ・イベントのログ – これはSELinuxの標準機能です。ここで難しいのは、ログが作成された後のハンドリングです。イベントの収集と保存、フィルタリング、分析のためのバックエンド管理システムへの送信などがこれに当たります。この作業はITの観点からは簡単なように聞こえるかもしれませんが、実際のところ、ほとんどのOEMはこの機能をサポートすることができていません。さらに、ログを取ることは、UNR155とGB/Tに準拠するために必要な要件です。
• オープンソース – オープンソースソフトウェアは開発者にとっては素晴らしいものですが、セキュリティの観点からは諸刃の剣となりえます。コードは容易に入手可能であり、それがどのように実装されているか見えるので、熱心なハッカーは最終的にバイパスする方法を見つけます。SELinuxは様々な目的に使用でき、すべてのアプリケーションに必要なわけではないため、設計上取り外し可能であり、巧妙なマルウェアによって無効化される恐れがあります。
• 保守性 – オープンソースのもう一つの欠点は、長期にわたって保守する必要があることです。アプリケーションをアップグレードするたびに、SELinuxとの互換性をチェックする必要があります。例えば、SELinuxのバグフィックスとアップグレードを認識し、そして、それらのアップデートをサポートするために自分のコードを適応させ、アップデートする必要があります。プロプライエタリなソフトウェアとは対照的に、オープンソースはサポートやアップグレードを提供しません。もし、規制に新しい要件が追加された場合、自動車業界にサービスを提供するソフトウェアベンダーはすぐにそれに対応します。オープンソースを使用する場合、インターネット上のフォーラムに支援を求めるか、独自のリソースを使用して要件を満たす必要があります。

1層のセキュリティでは不十分

例えて言うなら、有名な美術館を警備する場合、正門に鍵をかけるだけで十分とは思わないのではないでしょうか。カメラやモーションセンサーなど、不正侵入を防ぐための装置も設置することでしょう。セキュリティのレイヤーを1つに絞るのは危険すぎるということです。美術館にとっても、自動車にとっても、セキュリティを一か所に頼ることは受け入れられません。

サイバーセキュリティの基本的な考え方のひとつは、単一の保護レイヤーでは、関連する攻撃ベクトル、エクスプロイト、シナリオのすべてに対処するには不十分だということです。特にSELinuxは、当社のリサーチチームが何度も実証しているように、簡単にバイパスまたは無効にすることができます。これが、SELinuxだけを保護レイヤーとして頼るべきでないもう一つの重要な理由です。 

自動車のサイバーセキュリティ要件への対応

多層防御は、複数のベンダーのソフトウェアや様々なコンポーネントで構成されている今日のECUにおいて特に必要です。このように多様で階層化されたエコシステムは、統合の問題や予期せぬセキュリティ脆弱性を引き起こす可能性があります。したがってOEMは、試行錯誤的に特定のハードニングを行うのではなく、包括的なセキュリティイメージを提供する全体的なセキュリティソリューションを必要としています。

SELinuxのポリシーは、主に標準的なLinuxの使用パラダイムを中心に設計されており、自動車固有のニーズとは必ずしも一致していません。試行錯誤のアプローチに基づくことが多く、自動車アプリケーションに特化した機能やショートカットが欠けているため、自動車のセキュリティ確保に必要なシナリオやユースケース（カーネルパラメータの保護など）を定義することが困難です。

HostProtection（IDPS）： ECUサイバーセキュリティのギャップを埋める

この多層防御アプローチを反映して、多くのOEMがSELinuxの上にECUセキュリティの追加レイヤーとしてHost IDPS Protectionソリューションを導入することを選択しています。Host Protectionは、既存のSELinux機能を補完し、自動車セキュリティ特有のニーズに対応するように設計されています。シンプルで簡単に設定が可能なルールに基づき、Host Protectionは、厳格な実行制御など、SELinuxが対処できない、あるいは制御が困難な特定のセキュリティギャップを埋めます。

Host Protectionは、SELinuxと併せて、以下のセキュリティレイヤーを追加で提供することで、OEMに安全な自動車グレードのシステム・ソリューションを提供します：

1. 保護 – Host IDPS Protectionは、すべての実行ファイルと特殊ファイルの完全性と真正性を確保することで、ECUの保護を強化します。システムで実行される各実行ファイルは、OEMによって署名された証明書と同一である必要があります。ファイルへの変更や修正が検出されると、そのファイルはブロックされます。さらに、Host Protectionでは、様々な自動車特有のシナリオをカバーするルールを作成し、その悪用を防止することができます。
2. 検知 – 先ほどの例に戻ると、保護レイヤーはゲートのロック、検出レイヤーは美術館の周囲や内部のカメラやセンサーとなります。Host Protectionシステムは通常、システムの異常動作を感知することができるECU上のセンサーのバンドルを含みます。これは、SELinux自体が削除されたり改ざんされていないことを確認するために監視する専用センサーや、さらなる調査を行うためにシステムの測定値やCPU使用率などを監視する専用センサーも含まれます。
3. ロギング – このレイヤーは、システム内のすべてのSELinuxログと他のすべてのセキュリティイベントを収集・管理し、SEvs（セキュリティイベント）としてIdsM（侵入検知システムマネージャー）または収集とフィルタリングのために設定されたシンクに送信します。 UNR 155とGB/Tによって義務付けられているこれらの運用機能は、SELinuxの基本的なログ機能を補完します。

前述したように、これらの各レイヤーは、車両やECUをサイバー攻撃から保護するとともに、型式認証のためのサイバーセキュリティ要件への準拠を促進しようとするOEMにとって不可欠なものになります。

結論

SELinuxは開発者にとって優れた価値を提供しますが、LinuxベースのECUを保護し、規制要件を満たすためには、自動車グレードのセキュリティのレイヤーを追加して補完する必要があります。

SELinuxとHost IDPS Protectionの組み合わせは、自動車サイバーセキュリティにおける強力な相乗効果が得られます。SELinuxは堅牢な基盤を提供し、Host Protectionは自動車業界特有の課題に対処するために必要なアジリティと特異性を提供します。この二重のアプローチにより、自動車は現在のサイバーセキュリティの脅威に対応できるだけでなく、将来の進化する課題にも備えることができます。

The post 車載ECUのサイバーセキュリティ： SELinuxとHost Protectionのパワフルな組合せ appeared first on PlaxidityX.

自動車業界においては、路上で自動車を運転することで発生するリスクを考慮しなければならないことは明らかです。この業界では、安全リスクマネジメント、サプライチェーンリスクマネジメント、品質リスクマネジメント、オペレーショナルリスクマネジメントなど、さまざまなリスクマネジメントプロセスが存在します。近年では、サイバーセキュリティリスクマネジメントという新しいリスクマネジメントが必要になってきています。

自動車のサイバーセキュリティに対する懸念の高まりを受けて、規制団体や業界団体は規格やガイドラインの策定に着手しました。ISO/SAE 21434国際規格「Road vehicles – Cybersecurity engineering (路上走行車両－サイバーセキュリティエンジニアリング）」は2021年に発行されており、自動車のライフサイクルを通じてサイバーセキュリティを確保するための枠組みを示しています。さらに、2021年1月22日に発効した「サイバーセキュリティおよびサイバーセキュリティ管理システムに関する国連規則第155号（UNR155）」があります。この国連規則は、国連欧州経済委員会（UNECE）が自動車規制調和世界フォーラム（WP.29）の一環として策定したものです。UNR 155は、自動車メーカーが自動車のライフサイクルを通じて効果的なサイバーセキュリティ対策を実施することを目的としています。同規制は、サイバーセキュリティ管理システム（自動車向け CSMS）を構築し、サイバーセキュリティリスクを評価・軽減してサイバー脅威から自動車を保護することをメーカーに求めています。EUと、日本や韓国などのアジア諸国がこの規制を採用しています。これらの地域では、すべての新型車両がUNR155に準拠する必要があります。2024年7月からは、新たに生産されるすべての車両がUNR155に準拠しなければならないとされています。

2つの重要な概念を理解することが重要です： 「脅威」と「リスク」です。脅威とは価値あるものを侵害する可能性のあるものであり、リスクとは可能性と確率を伴う脅威です。脅威分析とリスク評価（TARAとも呼ばれます）とは、実際のリスクとして顕在化する可能性のある脅威を特定し、それらのリスクについて意思決定を行うプロセスです。リスクは、受容することも、緩和策を実施して低減することも、根本原因に対処して回避することも、リスクが属する別の当事者に移転することもできます。米国国立標準技術研究所が発表した世界的なNISTサイバーセキュリティフレームワークは、組織内のサイバーセキュリティリスクを管理するための共通言語とベストプラクティスを5つのゾーンに分けて提供しています。それは、 特定（Identify）、防御（Protect）、検知（Detect）、対応（Respond）、回復（Recover）です。

自動車のサイバーセキュリティリスクマネジメントに話を戻すと、脅威分析とリスク評価（TARA）の実施は、サイバーセキュリティ規制UNECE W.29 UNR 155のさまざまな要件で言及されています。TARAの実施フレームワークは、ISO/SAE 21434:2021規格に概説されています。しかし、これらの文書では、脅威分析の特定の手法を規定していないため、TARA を実施する組織が、そのスキルと能力に基づいて手法を選択できる柔軟性がでてきます。ISO/SAE 21434:2021規格は、使用可能な手法の例として、EVITA、PASTA、STRIDEを含むさまざまな脅威モデリングアプローチについて言及しています。 自動車のサイバーセキュリティの懸念と交差する組織は、ISO/SAE 21434規格とNISTサイバーセキュリティフレームワークの両方に従うことを選択することができます。

プラクシディティ エックス（旧アルガス）の脅威分析のベストプラクティスは、マイクロソフトのエンジニアが最初に開発したSTRIDEと呼ばれる脅威分析モデルに基づいており、これはサイバーセキュリティの脅威モデリングに活用されています。これは、脅威を6つのカテゴリーに分類します： Spoofing（なりすまし）、Tampering(改ざん)、Repudiation（否認）、Information Disclosure（情報漏洩）、Denial of service （サービス拒否）、Elevation of privilege（権限昇格）です。

STRIDEを使う理由

複数のサイバーセキュリティアーキテクトを一つの部屋に集め、ターゲットシステムに対する脅威を分析するよう依頼した場合、それぞれが異なる脅威を分析する可能性が高く、中には特定の脅威を見逃す可能性さえあります。組織として、脅威分析プロセスの共通基盤を確立し、包括的で正確なカバレッジを確保することを目指しています。STRIDEを使用することで、完全性と予測可能性を提供することでこれらのニーズに対応し、それが現場で広く採用されている理由です。同様に、STRIDE は、予算やリソースが限られている小規模な組織であろうとも、あらゆる規模の組織に適しています。STRIDEはシンプルなフレームワークであり、専門家を訓練してこれを導入することも可能です。 

TARAを自動化する理由

一方では、TARAはサイバーセキュリティのプロセスであり、特にリスク処理の決定やセキュリティ管理策の導入の提案に関しては、機械ではマネできない人間の判断や創造性が必要な場合があります。その上、自動化されたシステムの定期的なメンテナンス作業も忘れてはいけません。 一方、自動車業界では、TARAは製品開発のライフサイクルの中で、変更要求や新たなサイバーセキュリティの脆弱性やインシデントの発見などをきっかけに、ある程度の期間がたてば変更されることがあります。そのため、プロセス全体を自動化することで、専門知識を活用し、TARAを実行する体系的な方法を知りたいと考えています。特に、このプロセスについて多くの知識を持つ経験豊富な企業であれば、自動化によって質の高い結果を得ることができます。

自動化TARAがSTRIDEを採用する理由

上述したように、STRIDEのようなシンプルな脅威モデリングアプローチと組み合わせた自動化プロセスを使用することは、限られた時間で質の高い結果を得るための確実な方法です。また、人為的なミスや質の低い脅威の特定を減らすことで、一貫性と正確性が得られます。さらに、このようなツールの結果は非常に明確であるため、リスクを処理し、開発や対策のためのセキュリティ要件を検討するプロセスが容易になります。

PlaxidityX TARA自動化ツール

PlaxidityX TARA自動化ツールであるSecurity AutoDesigner（PlaxidityX DevSecOps Platformの一部）は、STRIDE脅威モデリングに基づき、車両アーキテクチャ、システム、コンポーネントのセキュリティソリューションをゼロから提供します。このソリューションはISO/SAE 21434:2021に準拠しています。このツールは、さまざまなトリガーに基づいて簡単に修正できるように設計されており、特定の組織スキルに合わせて調整できます。さらに、Security AutoDesignerは、脅威分析プロセスにおいてUNECE W.29 R155の付属書5（脅威カタログ）を考慮するように設計されています。

このツールは、AI機能を使ってすべての分析データを自動的に生成し、1つのレポートに統合します。このデータは、プラクシディティ エックスの専門家によって構築されたプラクシディティ エックスの脅威カタログデータベースから来ています。これは、OEMやTier-1 / Tier-2サプライヤーにTARAプロジェクトを提供してきた長年の豊富な経験に基づいています。

Vモデルに基づいた包括的なプラクシディティ エックス製品

結論として、自動車のような産業において、リスク管理、特にサイバーセキュリティは極めて重要です。ISO/SAE 21434やUNR 155のような新しく作られた標準に則ったアプローチがある一方で、STRIDEのような方法論は、PlaxidityXのTARA自動化ツールに代表されるように、自動車サイバーセキュリティのための包括的な脅威分析とリスク評価を確実にする体系的な方法を提供しています。

Security AutoDesignerについてはこちらから詳細をご覧ください。

The post 自動車サイバーセキュリティリスク管理とそれを自動化する理由 appeared first on PlaxidityX.

自動車OEMが自動車の生産に革命を起こす一方で、このソフトウェアによる変革は新たなリスクと課題ももたらしています。自動車がテクノロジーを重視するにつれ、ソフトウェアの脆弱性やサイバーセキュリティの脅威にさらされる機会も増えています。機能面では、OEMは複数のソフトウェアベンダーのコンポーネントを統合し、安全で高品質なコードを確実に開発し、継続的なソフトウェア更新（OTA）をサポートする必要があります。同時に自動車OEMは、自社の車両が複雑で厳しい標準や規制（UNR 155/156、ISO 21434、ASPICEなど）に準拠していることを確認しなければいけません。

こうした課題を克服するため、自動車OEMは車載ソフトウェアの迅速な開発、開発サイクル内でのサイバーセキュリティの統合、市場投入までの時間短縮を可能にするツールを求めています。

自動車のためのDevSecOpsを用いてセキュリティ・バイ・デザインを実現

サイバーセキュリティが自動車の機能性と安全性に不可欠な時代では、開発プロセスの早い段階でセキュリティ対策を統合することが不可欠です。開発中に発見された問題や脆弱性は、自動車が量産開始された後に発見されたものよりもはるかに修正が容易であり、リコールにかかるコストや評判へのダメージは言うまでもありません。

DevSecOpsは、DevOpsの原則を拡張し、ソフトウェア開発ライフサイクル全体にサイバーセキュリティをシームレスに組み込みます。DevSecOpsは、初期設計から統合、テスト、デリバリー、デプロイメントに至るまで、ソフトウェア開発ライフサイクルのあらゆる段階でサイバーセキュリティ対策を自動化して統合します。このアプローチにより、サイバーセキュリティは後付けではなく、製品設計の不可欠な一部となります。

PlaxidityX DevSecOpsプラットフォームのご紹介

自動車業界向けに特別に設計された最先端のツールと手法を使用して、プラクシディティ エックス（旧アルガス）は包括的なDevSecOpsプラットフォームを構築しました。プラクシディティ エックスの実績あるサイバーセキュリティとテスト能力を活用したこの世界初のプラットフォームは、設計から運用までのDevSecOpsプロセス全体を自動化します。

シフト・レフトとセキュリティー・バイ・デザインのコンセプトを採用することで、開発とテストのスピードを加速することができます。これにより、開発チームは更新までの時間を短縮し、コストを削減し、機能的な柔軟性を求める市場の要求に応えることができます。

PlaxidityX DevSecOpsプラットフォームのモジュール：

• Security AutoDesigner：自動化された脅威分析とリスク評価（TARA）を実行し、アーキテクチャ設計段階（実際の開発前）において潜在的な脅威と脆弱性を前倒しで特定します。
• Security AutoTester：自動車ソフトウェア開発者に、包括的なカバレッジのための約200のパッケージ化されたテストケースを含む、ファジングテストや侵入テストなどのエンタープライズグレードの自動セキュリティテストを提供します。自動化により時間に対する価値が上がり、検出された脆弱性の迅速な修正とテストの再実行が可能になります。

• Code Security Manager：脆弱性を特定するための高度な静的（ホワイトボックス）テスト機能と動的テスト機能を提供します。高度なソフトウェア構成分析（SCA）モジュールは、ソフトウェア部品表（SBOM）を抽出し、セキュリティとアプリケーションのインテリジェンスを使用してコードに脆弱性がないかどうかを調べます。自動化されたコンプライアンス検証により、自動車OEM は既存の CI/CD パイプラインを拡張して継続的コンプライアンス（CC）を含めることができ、セキュアなソフトウェア開発ライフサイクル（SSLDC）の基盤を構築できます。

• SW Supply Chain Security：AUTOSAR、Linux、AndroidなどのバイナリからSBOMを自動的に抽出し、プロジェクトまたは車両モデルごとにECU、ハードウェアコンポーネント、ソフトウェアライブラリのアセットを管理します。

自動車サイバーセキュリティの専門知識を活用した包括的な一貫性のあるプラットフォーム

DevSecOpsプラットフォームは、プラクシディティ エックスの自動車アーキテクチャー、プロトコル、ネットワークに対する深い理解と、サイバー技術や研究における豊富な経験を活用しています。

プラクシディティ エックスは10年以上にわたり、OEMやティア1に対し、製品ライフサイクルの全段階における自動車サイバーセキュリティのコンプライアンス、エンジニアリング、テスト、運用サービスを提供してきました。コードレビュー、ペネトレーションテスト、TARAなどといったサービスは、メーカーのサイバーセキュリティレベルを強化し、コンプライアンスを促進するために、車両が業界標準や規制に従って設計通りに保護されていることを保証します。

この数ヶ月の間に、プラクシディティ エックスはこれらのライフサイクル・サイバーセキュリティ機能とツールを、設計・構築からテスト・運用まで、DevSecOpsプロセス全体を自動化する一貫性のある1つのプラットフォームに製品化しました。これまで、ポイントソリューションはさまざまなベンダーから提供されてきましたが、それらを1つの自動化プロセスに統合することは、ほとんどのOEMにとって大仕事です。プラクシディティ エックスのプラットフォームは、そのような問題を解決します。

結論： すばやい開発、セキュアなコード、迅速な市場投入

未来のソフトウェア・デファインド・ビークルと自動運転車の安全性とセキュリティは、自動車OEMとそのサプライヤがソフトウェア開発プロセスを安全に行えるかどうかにかかっています。SDV 開発にサイバーセキュリティ・バイ・デザイン・アプローチを採用することで、自動車OEM は生産スケジュールを短縮し、ビジネスの機敏性を高め、将来的な競争力を獲得することができます。

PlaxidityX DevSecOps プラットフォームは、現在利用可能な最も先進的な機能の包括的なセットを使用して、自動車OEM とそのサプライヤのツールチェーンの近代化を支援します。シフトレフトのアプローチに基づくこの画期的なプラットフォームは、SDV 開発を合理化し、サイバーセキュリティ、コード品質、コンプライアンスの面で製品品質を向上させます。

The post 自動車のためのDevSecOps： ソフトウェア・デファインド・ビークルの開発を加速し、サイバーセキュリティを強化 appeared first on PlaxidityX.

この決定は、二輪車業界に対するウェークアップコールです。これまで、二輪車メーカーがサイバーセキュリティに対応する必要はありませんでした。

しかし、状況が変わりました。二輪車メーカーはこれに対応する必要があります。

この決定の背景にあるものはなんでしょうか。二輪車にとってサイバーセキュリティが不可欠になる理由、また、どのようなリスクがあるのでしょうか。そして、二輪車メーカーがUNR155に準拠することは、ビジネス上どのような影響があるのでしょうか。

この記事では、基本的な自動車サイバーセキュリティおよびUNR155コンプライアンスに関する我々の洞察と、四輪車メーカーのコンプライアンス準拠における道のりをナビゲートするなかで学んだ貴重な教訓を共有します。

自動車にサイバーセキュリティが必要な理由

自動車業界におけるサイバーセキュリティの導入はここ2、3年のことですが、現在ではほぼすべての自動車メーカーやティア1サプライヤーにとって、サイバーセキュリティは一般的な用語となっています。

その理由は、現在路上を走行している何千万台もの自動車が、クラウド接続を備えたソフトウェア・デファインド・ビークル（SDV）であるためです。他の接続デバイスと同様に、SDVにはソフトウェアが持つ脆弱性があり、ハッキングの対象であり、サイバーセキュリティリスクにさらされています。最近開催されたハッキングコンテストでもこれは明確に示されており、大手自動車サプライヤーの車両充電システム、車載エンターテインメント技術、モデムサブシステムで数十ものソフトウェア脆弱性が発見されました。

ITネットワークへのサイバー攻撃とは異なり、自動車へのサイバー攻撃は生命を脅かす結果をもたらす可能性があります。特定の脆弱性を悪用することで、悪質な行為者はセーフティ・クリティカルなシステム（ブレーキなど）を侵害したり、遠隔地から自動車を始動させて制御したりすることさえ可能です。

安全性への懸念に加え、車両のサイバー攻撃は個人情報を危険にさらす可能性もあります。SDVが生成・収集するデータは、自動車メーカーが車両運用を改善し、ドライバーの運転体験をパーソナライズするのに役立つ一方で、データプライバシーに関する深刻な懸念ももたらします。 Mozillaの調査によると、現代の自動車は、OEMによるデータ保護が不十分であるため、「私たちがこれまでレビューした中で、プライバシーに関して最悪の製品カテゴリー」であると述べています。

テレマティクス、アダプティブ・クルーズ・コントロール、高度なコネクティビティが二輪車に導入されたことで、二輪車の潜在的なサイバーリスクに対する懸念も高まっています。

規制の現状を理解する

コネクテッドカーに対するサイバー攻撃リスクの高まりに対応するため、近年、新たな自動車サイバーセキュリティ規制や標準が登場しました。UNR 155やISO/SAE 21434のようなグローバルな指令は、すでにOEMとそのサプライヤーの製品開発・管理方法に大きな影響を与えています。

ISO 21434は、路上を走行する車両のエンジニアリングにおけるサイバーセキュリティ観点からの国際規格です。この規格は、コンセプト、設計、生産、運用、保守、廃棄に至るまで、車両のライフサイクル全体にわたってサイバーセキュリティのリスクを管理するためのガイドラインを提供しています。

UNR155は、車両のライフサイクル全体を通じてサイバー脅威を検知・防御するためのリスクベースの管理フレームワーク（別名サイバーセキュリティマネジメントシステム、CSMS）の導入をすべてのOEMに義務付けています。EU諸国、日本、韓国などを含むUNECE加盟国の乗用車、トラック、バスに義務付けられているUNR155は、サイバーセキュリティに関して路上を走行する車両の型式認証のための国際的枠組みとなっています。

UNR155を構成する主な2つの柱：

• CSMS – CSMSは、サイバー脅威を緩和し、サイバー攻撃から車両を保護するために必要な組織的プロセス、責任、ガバナンスを定義する体系的なリスクベースのアプローチです。CSMSの仕様はUNR155の文書に詳述されています。UNR 155は、開発、製造、製造後の各段階で実施すべきプロセスを規定していますが、そのようなプロセスを実行するために使用される特定のツールや製品については規定していません。
• 型式認証 – UNR155は、自動車メーカーが型式認証を取得するために満たすべき組織的・技術的要件について、新たな状況をもたらしたといえます。同規則は、型式認証に2つのマイルストーンを設定しました。2022年7月、すべての新車は型式認証を取得するためにCSMS適合証明書（CoC）の取得が義務付けられました。2024年7月に設定された2つ目のマイルストーンでは、この要件がUNECE加盟国のすべての新型車（承認済みの型式と新型の両方）に拡大されます。CoCは、型式承認機関による厳格な審査プロセスを経て付与されます。

UNR155により、自動車のバリューチェーン全体が対象となり、早急な対応を求められています。OEM は現在、型式認証取得に向けてコンプライアンスを実証する必要があるため、サプライヤーに対しても、製品の設計、開発、運用、保守のプロセスにサイバー耐性を組み込むことを要求しています。

二輪車メーカーにとっての規制遵守の意味合い

コンプライアンス・プロジェクトを実施した四輪車メーカーから学んだことを生かして、二輪車メーカーは、新規制が自社のビジネスと製品開発に及ぼす潜在的な影響を理解することが求められています。

CSMSを確立し、二輪車の型式認証のためのコンプライアンスを達成するためには複雑な取り組みを進める必要があり、自動車サイバーセキュリティの知識、熟練したリソース、専用ツールが必要になります。それだけでなく、既存のモデルにサイバーセキュリティを後付けするために必要な工程を検討することも重要です。

サイバーセキュリティ規制の影響を示す最近の例として、ポルシェは、ベストセラーのICEエンジン搭載SUV車「マカン」について、2024年春に欧州販売を終了すると発表していますが、これはサイバーセキュリティ規制に関連するものです。ポルシェは、新規制に準拠するために必要なアップデートが非常に複雑でコストがかかると判断したと説明しています。VWやアウディを含む他の車種に関しても同様の発表がありましたが、その最新版と言えるでしょう。

まとめ

UNR155の二輪車（車両カテゴリーL）への拡大は、2024年6月に正式採用される予定です。

UNECE加盟国で販売されるモーターサイクルやスクーターを製造する二輪車メーカーは、サイバーセキュリティについて考え始め、来るべき規制要件準拠のための周到な計画を準備すべき時がやってきました。

二輪車向けのサイバーセキュリティが必要になった今、業界の対応が早いに越したことはありません。

サイバーセキュリティ・コンプライアンス準拠に向けたナビゲートが必要ですか？ギャップ分析、CSMS、二輪車の型式認証については、プラクシディティ エックス（旧アルガス）のサービスチームまでお問い合わせください。

The post 二輪車向けサイバーセキュリティ規制の導入 appeared first on PlaxidityX.

ソフトウェアの脆弱性を悪用すれば、セーフティ・クリティカルなシステム（ブレーキなど）を侵害したり、個人情報にアクセスしたり、あるいは遠隔から車を始動させることもできます。これは、19歳のIT専門家がサードパーティ製アプリの脆弱性を悪用し、複数の車両機能を遠隔操作したテスラ・ハックの例で実証されています。最近よく聞かれる自動車盗難の手法である「CANインジェクション」と呼ばれるハッキング技術では、窃盗犯はキーを使用せずに、2分以内に車のロックを解除し、始動させ、盗むことができます。

データプライバシー規制がOEMに与える影響

データプライバシーは、自動車のコネクティビティの重要な要素の１つです。自動車から収集されるデータはOEMが顧客理解を深めるのに役立ちますが、同時に倫理的・法的な課題ももたらします。OEMはGDPRやCCPAといったデータ保護法を遵守する必要があり、自動車から収集される個人データを扱う際には、同意、セキュリティ、透明性が求められます。

データプライバシー規制を遵守することで、OEMはリスクを回避し、顧客との信頼を築くことができます。また、自社の製品やサービスを革新し、差別化するためにデータプライバシーを活用することもできます。プライバシー・バイ・デザインの原則と信頼性の高いセキュリティ・ソリューションを適用することで、OEMは顧客の期待に応えることができて、よりユーザー中心の安全なソリューションを構築することができます。

OEMに車両セキュリティ・オペレーション・センター（VSOC）が必要な理由

自動車に対するサイバー攻撃は、費用のかかるリコールや規制上の問題から賠償責任や評判の低下まで、OEMに大きな財務的インパクトを与えます。サイバーによって発生した自動車盗難は、保険会社への請求が増えることを意味し、ひいては所有者や車両運行会社の保険料が上がる可能性があります。

こうした現実の脅威を反映し、UNR155のような新しい自動車サイバーセキュリティ規制は、サイバー攻撃を検知、監視、調査、対応するシステムの導入をOEMに義務付けています。2024年7月には、すべての新型車または継続生産車が、サイバーセキュリティに関するUNR 155型式認証の対象になります。

その結果、OEM各社はサイバーセキュリティ能力を強化し、新たな自動車サイバーセキュリティ規制や基準に準拠できるようシステムを導入しています。

ここ数年の間に、従来のIT SOCで自動車サイバーセキュリティの規模、複雑さ、課題に対応するためには最適化が必要なことにOEMが気づき始めています。つまり、何百万ものエンドポイントを保護する必要性、12～15年の車両寿命、非常に複雑なサプライチェーン、厳格なコンプライアンス要件、コストのかかる緩和プロセスなどが含まれるためです。

最も重要なことは、ネットワークやデータを標的とするITサイバー攻撃とは異なり、自動車サイバー攻撃の影響は人命にかかわる可能性があるということです。悪意のあるハッカーが自動車のブレーキシステムを侵害するシナリオを想像してみてください。

人命が危険にさらされる可能性があり、何百万台ものコネクテッドカーがすでに運用されているため、OEMは車両をリアルタイムで監視し、車両に影響が及ぶ前に潜在的な脅威を検知するMDR（Managed Detection and Response）ソリューションを必要としています。従って、OEMはサイバー攻撃をリアルタイムで監視、調査、対応する専用の車両SOC（VSOC）を構築しているのです。

ソリューション：自動車のサイバーセキュリティに合わせた最適なMDRサービス

最高の防御を実現するための専門知識の統合： Evidenとプラクシディティ エックスは、自動車サイバーセキュリティのために特別に設計されたクラス最高のエンドツーエンドMDRサービスを提供するために提携しました。この包括的なソリューションは、自動車の脆弱性と技術に関するプラクシディティ エックスの深い理解と、Evidenの実績あるMDRの専門知識をシームレスに統合しています。

可視性と脅威検知を強化： このサービスは、自動車に特化した豊富なユースケース、プレイブック、100以上のAIモデルとともにプラクシディティ エックスのVehicle SIEMをEvidenのMDRプラットフォームAIsaac Cyber Meshと活用することで、車両フリート全体の脅威検知と可視性を最大化します。プラクシディティ エックスのvSIEMはAIsaacと統合されており、数百万ものセンサーやコンポーネントから膨大な量のデータを取り込み、高度な機械学習とビッグデータアルゴリズムを活用してサイバーインシデントの可能性を分析します。この詳細な分析は、攻撃ソース、侵害場所、潜在的な影響などをピンポイントで特定し、重要なコンテキストを提供します。

プロアクティブな脅威ハンティングと迅速なレスポンス： EvidenのMDRサービスは、ユーザー、ネットワーク、クラウド、データセンターを含む複数のベクトルを用いて常に脅威ハンティングを行っており、受動的な検知のレベルを超えています。Amazon BedrockのジェネレーティブAIエンジンと組み合わされた100を超えるAIモデルを武器として、調査とレスポンスを加速します。さらに、プラクシディティ エックスとの共同ソリューションを用いることで、脅威を迅速に封じ込め、潜在的な被害を最小限に抑えることを可能にします。

無敵の防御のための専門家のコラボレーション： MDRサービスは、脅威ハンター、フォレンジック調査官、倫理的ハッカー、インシデント対応者を含むEvidenのエリートセキュリティ専門家チームと、プラクシディティ エックスの自動車サイバーセキュリティ・リサーチャーがシームレスに連携します。これらの専門知識により、あらゆる規模のOEMに対して包括的な脅威の検知と対応を保証します。

グローバルサポートとスケーラビリティ： 世界中に戦略的に配置された16の次世代SOCを特徴とするEvidenの堅牢な運用インフラは、規模や場所に関係なく、どのようなOEMに対しても確実なサポートを保証します。

つまり、Evidenとプラクシディティ エックスは、自動車サイバーセキュリティ特有の要求に合わせた最高のMDRソリューションを提供します。この提携により、より優れた可視性、積極的な脅威ハンティング、迅速な対応、および専門家によるガイダンスを提供し、変化し続けるサイバー脅威の状況に対し、OEMが自信を持って対処できるよう支援します。

秘訣：自動車に関するノウハウ

最高クラスの技術、プロセス、スキルを持ったリソースも重要ですが、真に効果的なVSOCサービスの秘訣は、自動車に関するノウハウです。

サイバーリスクに関連する実用的な洞察を導き出すために、どのようなデータを評価すべきかを知るためには、サイバー技術や研究の経験とともに、自動車のアーキテクチャ、プロトコル、ネットワークに対する深い理解が不可欠です。

この提携により提供できるようになったオートモーティブMDRは、600人年以上の自動車サイバーセキュリティ技術と研究を通じて得た自動車に関する深いノウハウを反映しています。この専門知識とエビデンのSOCにおける深い業界知識により、誤検知を最小限に抑えつつ高い検知率を実現しています。

Evidenとプラクシディティ エックス（旧アルガス）：よいパートナーシップ

Evidenとプラクシディティ エックスは、脅威ハンティング、インシデント管理、SOCオペレーションを含む包括的なVSOC/MDRサービスをOEMに提供します。EvidenのサイバーセキュリティとSOCの専門知識とプラクシディティ エックスの自動車サイバーセキュリティの深い知識を組み合わせることで、このパートナーシップは自動車業界の変化を続けるサイバーセキュリティのニーズを満たす最善のソリューションを作り出します。

提携して提供するソリューションは、自動車メーカーに対して、増え続けるサイバー脅威をプロアクティブに検知・対応し、リスクを低減するとともに、新たな自動車サイバーセキュリティ規制への準拠を支援することができます。

PlaxidityX VSOCの詳細はこちら

The post レーンを守る： EvidenとPlaxidityXが自動車のサイバーセキュリティ強化のために提携 appeared first on PlaxidityX.

技術オタクではなく、新技術のアーリーアダプターでもない私たちのために、順を追って考えてみましょう。

スマートホームとは？

家庭にあるデジタル機器、家電製品、コントローラー、スイッチなどを思い浮かべてください。近年、これらの機器はますますスマートホームのエコシステムの一部となっていることに気づくでしょう。テレビ、スピーカー、玄関チャイム、エアコンのコントローラー、冷蔵庫など、数え上げればきりがありません。まず、これらのデバイスはインターネットに接続できるようになりました。しかし、単に接続性だけでなく、「スマート」なところは、センサーを活用してローカルデータをリアルタイムで収集し、インターネットからの無限のデータと組み合わせて賢く行動するということです。その結果、彼らはイケてるもの、便利なもの、単に奇妙なだけのものなど、多くの新しい技を習得します。例えば自宅の洗濯機は、投入された洗濯物の種類と量がわかるとその情報を乾燥機に伝え、この洗濯物を乾燥させるのに最適なプログラムを自動で設定します。照明のスイッチは私の照明の好みを知っていて、毎晩、日没の直前に完璧な組み合わせの照明がつきます。離れていてもスマホのアプリからドアの開錠ができます。嵐が来るのを事前に予測し、自動で窓のシャッターが下ります。これらのスマートデバイスやスイッチはすべてワイヤレスでインターネットに接続され、最終的にはスマートフォンで簡単にアクセスできるアプリに接続されています。

テクノロジー愛好家向けのニッチな市場のように聞こえるかもしれませんが、決してそうではありません。例えばグーグル、アマゾン、アップル、サムスンなど、ハイテク業界の大企業がスマートホームやスマートデバイスに多大な投資を行っています。以前は、スマートホーム技術は高価で導入するには複雑なものでしたが、現在では主流になりつつあります。

スマートカーとは？

ソフトウェア・デファインド・ビークルという単語を耳にしたことがあるでしょうか。ModelSの登場で、2012年にTeslaがこのコンセプトを普及させたといっていいでしょう。簡単に言えば、車のハードウェアとソフトウェアを切り離すことで、自動車メーカーは車のライフを通じて定期的にソフトウェアを更新し続けることができるということです。問題の修正だけでなく、性能の向上、新機能の追加、新機能の導入も可能です。最近では、スマートフォンだけでなくインターネットにも接続された車が主流になってきています。ドライバーはストリーミング音楽、ポッドキャスト、オンラインラジオを聴くことができ、同乗者はビデオをストリーミング再生したり、オンラインビデオゲームで遊ぶことができます。そして、「リコール」の概念は完全に変わりました。かつては、安全上の問題を解決するためのリコールといえば、サービスセンターまで車を走らせ、ドライバーにとってはあまり楽しい経験ではないですが、整備士が部品を交換するまで数時間待つものでした。何百万ドルあるいはそれ以上ものコストがOEMに発生することは言うまでもありませんが、今日のリコールは、スマートフォンの定期的な更新のように、オーバージエア（OTA）アップデートで行われています。

さて、スマートホームとスマート／コネクテッドカーという2つの分野を理解したところで、最新の状況に話を戻しましょう。この２つの分野が出合い、少なくとも、交流が始まっているといえます。サムスンと現代自動車が先行者になっていますが、この流れは他のプレーヤーも必ず取り入れることでしょう。具体的には、サムスンと現代自動車は、新しい消費者向けサービスを提供するために、スマートホームとコネクテッドカー間の双方向通信を発表しました。

ホーム・トゥ・カーサービス

車のオーナーは、スマートホームのアプリを使って、車のエンジンをかけたり、車内温度の管理、窓の開閉、充電状況の確認など、自宅から車をコントロールできるようになります。これはコネクテッドカーのOEMアプリでも可能ですが、2つのエコシステムを組み合わせた新しいユースケースについて考えてみましょう。寒い日にスマートホームアプリでホームステータスを「留守」に設定すれば、車は自動的にドライブの準備と暖房の開始を指示されたと理解します。

カー・トゥ・ホームサービス

裏を返せば、車が家の中の機能をコントロールすることもできます。車載インフォテインメント・ディスプレイは、家の照明や温度をコントロールできるようになります。また別の、スマートなシナリオもあります。例えば、予期せぬ渋滞で帰宅が45分遅れるような場合、車が家の空調スケジュールを自動的に調整してエネルギーを節約することができます。また、EVのバッテリー残量や走行可能距離をテレビや家にあるスマート・ディスプレイに表示するなど、車両情報を共有して家にあるデバイスに表示することもできます。

では、なぜ心配するのでしょう？

一言で言えば、サイバーセキュリティです。コネクテッドカーはサイバー攻撃の標的になりつつあります。自動車がより多くのソフトウェアを搭載し、携帯電話、無線LAN、ブルートゥースなど複数の接続チャンネルを提供するようになるにつれ、意図せず新たな攻撃ベクトルが生まれています。自動車のサイバーセキュリティが業界で最初に注目されたのは、2015年に起こった有名なジープ・チェロキーのリサーチャーによるハッキングでした。

自動車へのサイバー攻撃、公表されたリスクや脆弱性は増加の一途をたどり、ついに自動車サイバーセキュリティ規制につながり、特に有名なものにUNECE R155規制、国際標準ISO/SAE 21434があります。

技術的に言えば、スマートホームのエコシステムを車に接続することは、まったく新しい攻撃ベクトルを導入することになります。大きいというよりも非常に巨大なものです。厳しい規制があり、品質と安全性の高い基準が設定されている自動車業界とは異なり、スマートホームデバイスはまだそこに至っていません。スマートデバイスのサイバーセキュリティへの対応は始まったばかりであり、無数のベンダーが製造したスマートデバイスが安価に普及するにつれ、スマートホームのエコシステムのサイバー態勢を評価することはかなり不可能になっています。脆弱性に関するニュースの報道から判断すると、素晴らしいとは言い難いのです。よく知られているRingセキュリティカメラは2019年にハッキングされ、顧客を危険にさらしました。より最近のカメラのセキュリティ報道は、Wyzeウェブカメラに関わるもので、自分のものではない知らないカメラからの映像フィードを短期間見ることができたと報告した所有者がいたため、ニューヨークタイムズのWirecutterは6年間のレビューの後、Wyzeセキュリティカメラの推奨を取り下げました。しかし、スマートホームのセキュリティに関する懸念はウェブカメラだけではありません。リサーチャーたちは、スマート電球でさえハッキングされる可能性があり、ハッカーはそこから自宅のWi-Fiネットワークに侵入し、個人情報を盗むことができることがわかりました。

最近の調査で、Z世代とミレニアル世代がスマートホームデバイスがハッキングされることを非常に心配していることが示されたのは驚くべきことではありません。正直なところ、15ドルのスマートカメラに、どれだけのセキュリティ上の対策やサイバー保護が施されていると思いますか？そして、ホームネットワーク全体をハッキングするのは、たった1つの弱いリンク、保護が不十分なスマートデバイスが１つあれば十分なのです。

無数のベンダーが製造し、サイバーセキュリティに関する規制がまだない、オンライン・スマートホームデバイス、家電製品、スイッチといった新しいエコシステムを、あなた自身とあなたの親しい人を乗せておよそ時速120㎞で移動する車に接続した場合の結果を想像してみてください。何か問題となりそうなことはあるでしょうか？

一例として、脆弱性を利用してコネクテッドホームのスマート電球をハッキングし、そこから車にアクセスしてコックピットのスマート・アシスタントに車の機能を操作するよう指示することで、コネクテッドカーを遠隔操作することです。あるいは、車で向かった詳細な行先、そこで何分過ごしたかといった個人情報にアクセスして盗むこともできます。これがホーム・トゥ・カーのベクトルです。では、カー・トゥ・ホームのベクトルも考えてみましょう。ハッカーがコネクテッドカーを侵害できれば、車両レベルでの被害だけでなく、ハッカーの潜在的な攻撃範囲は家にまで広がることになります。ハッカーは、自宅のカメラにアクセスしたり、スマートロック搭載のドアを解錠したり、エアコンを操作したり、その他のスマートデバイスを操作したりする可能性があります。

どんな対策が可能？

自動車を家やデジタルライフの続きとするジャーニーは少し前から始まっており、スマートホームのエコシステムとコネクテッドカーの連携は必須になるでしょう。なぜなら新しいライフスタイルを形成し、車のユーザー体験を革新する可能性を秘めているからです。しかし同時に、この進化を誰にとっても安全なものにするために対処しなければならない、重大なサイバーセキュリティ・リスクがあります。このことは、自動車のサイバーセキュリティの重要性をさらに強調するものです。イーサネット向け侵入検知やCANバス向け侵入検知による車載ネットワークの保護から、インフォテインメント・システムやテレマティック・ユニットなどのホストECUのハードニングと保護、脆弱性の継続的なスキャン、攻撃を検知してリスクや脅威に対応するためのフリート・サイバー・モニタリングまで必要です。

まとめ

コネクテッドカー、スマートホーム、そしてスマートフォンがバーに入っていく…このジョークがサイバーによる悲惨な結末を迎えることを望まないのであれば、自分の乗る車が適切なサイバー保護対策を備えていることを確認したほうがいいでしょう。

The post 車と家の関係の始まり appeared first on PlaxidityX.

UNECEのWP.29とISO 21434による今後の規制強化は、自動車産業におけるセキュリティ・ライフサイクルの安全確保に関するコンプライアンス要件を推進するものです。このコンプライアンスを実現するためには、自動車産業特有の複雑性から、設計・開発、製造、路上での運用という自動車ライフサイクルの3段階すべてを網羅し、最終的には各車両の15～20年のセキュリティ・ライフサイクル全体を管理する、未来の自動車の安全性を確保するための包括的なアプローチが必要となります。

このような独特な課題に対処するため、PlaxidityX（旧アルガス）、CyberArk、Device Authority、マイクロソフトの革新的な協業により、自動車およびモビリティ・セキュリティのための次世代ソリューションが誕生しました。この包括的なプラットフォームベースのアプローチは、マイクロソフトの最新のAzure OpenAI Security Co-pilotテクノロジーを活用することで、コネクテッドカーの安全確保、データ主権・管理およびコンプライアンスの確保、クラウドとエンタープライズ環境の保護といった複雑な課題に対処します。

この協業は、自動車とモビリティのセキュリティにおける大きな飛躍を意味し、各社の強みを組み合わせて堅牢なエンドツーエンドのソリューションを構築します。コネクテッドカーがもたらす独特な課題に取り組むことで、このパートナーシップは、急速に進化する自動車業界において、セキュリティ・データ管理とコンプライアンスの新たなベンチマークとなるでしょう。

コラボレーションとイノベーションの主要分野：

包括的でセキュアなソフトウェア開発環境

GitHub Copilotと開発環境を活用することで、ソフトウェア開発を加速し、開発者が問題解決とコラボレーションにより多くのエネルギーを集中させ、ありふれた定型的な作業に労力を費やさないようにします。バイナリコード分解ツールを使用して、大規模な自動車ソフトウェアの脅威サーフェスのセキュリティ態勢を確立します。

エンド・ツー・エンドのセキュリティ

サイバーセキュリティ・ソリューションのシームレスな統合により、Vehicle Security Operation Center (VSOC)やVehicle to Cloud (V2C)通信を含むコネクテッドカーやクラウド環境のエンドツーエンドのセキュリティを確保します。

包括的な脅威検出

Azure OpenAI Copilotテクノロジーを活用することで、対応時間と手作業を削減し、より高い精度でより多くの脅威を検出するための実用的な洞察とインシデント対応自動化が含まれます。

包括的な可視性

データコネクターを活用して、コネクテッドカー、クラウド、VSOC、車両エコシステム全体にわたるセキュリティの全体像を提供します。

包括的かつライフを通じた運用中の車両状況管理

SBOM分析ツール、IDPSシステム、Security Copilot、最新の脅威インテリジェンスを活用し、路上の自動車のセキュリティとコンプライアンスのライフサイクルを管理します。

コネクテッドカー・ソリューションの革新

PlaxidityX、CyberArk、Device Authority、マイクロソフトの専門知識を結集し、自動車セキュリティ、データ主権・管理およびコンプライアンスにおけるイノベーションを推進し、業界に新たな基準を打ち立てます。

ソリューションの主な構成内容

PlaxidityX

自動車メーカー向けに車載およびクラウドベースのサイバーセキュリティ技術を提供

• 侵入検知・防御システムといった車載製品およびライフサイクルを通じて車両をモニタできる脆弱性管理およびセキュリティ・オペレーション・センター・サービスといった非車載ソリューションの両分野において製品を提供。
• 車両コンポーネント、ネットワーク、フリートに対するサイバー攻撃を監視、検出、防御。

プラクシディティ エックスについて

プラクシディティ エックスは、自動車サイバーセキュリティのグローバルリーダーとして、自動車メーカーやサプライヤーに車載およびクラウドベースのサイバーセキュリティ技術を提供し、自動車のコンポーネント、ネットワーク、フリートがそのライフサイクル全体を通じて安全で規制に適合できるよう支援しています。
プラクシディティ エックスのイノベーションとソリューションは、数十年にわたるサイバーセキュリティと自動車に関する研究に基づいています。当社は、取得済みと申請中を合わせて100件以上の特許を所有しています。
2014年に設立され、プラクシディティ エックスは本社をイスラエルに構え、米国、ドイツ、フランス、日本、韓国にオフィスを展開しています。

CyberArk

• あらゆる業界のクラウドおよびエンタープライズ環境のアイデンティティセキュリティに特化。
• 管理者、ユーザー、アプリケーション、コネクテッドカーやデータとやり取りするマシンの認証情報と秘密を保護。

CyberArkについて

CyberArkはアイデンティティセキュリティのグローバルリーダーです。CyberArkは、インテリジェントな特権管理を中心に、ビジネスアプリケーション、分散型ワークフォース、ハイブリッドクラウドのワークロード、DevOpsライフサイクル全体における、あらゆるID（人間またはマシン）に対して最も包括的なセキュリティを提供します。世界の一流企業が、最も重要な資産のセキュリティ確保にCyberArkを活用しています。

Device Authority KeyScaler

自動車のIoTデバイス向けに、マシンのIDライフサイクルと鍵管理の自動化を提供し、車両からクラウドへのセキュアな通信を自動化。

• デバイス証明書および鍵のプロビジョニング、ローテーション、失効を自動化
• OEMからTier1までの鍵管理、工場での鍵注入
• IT/OTの可視性と制御を強化するスマート・コネクテッド・ファクトリー・セキュリティ
• デバイスのデータと通信に対して、ポリシー駆動型の暗号化と認証を実施

Device Authorityについて

Device Authorityは、ゼロトラスト・セキュリティを大規模に自動化することでコネクテッドの未来を保護し、エンタープライズIoTエコシステム向けのアイデンティティおよびアクセス管理（IAM）のグローバルリーダーとして認められています。Device AuthorityのKeyScaler、IDセキュリティ・プラットフォームとKeyScaler-as-a-Service（KSaaS）により、企業は人的ミスを減らし、インシデント対応を迅速化し、リスクを最小限に抑え、デバイスとデータの完全な信頼性を確保し、あらゆる接続環境で信頼できるAIを実現できます。

Microsoft Manufacturing and Mobility Industry Team

マイクロソフトでは、パートナーとともに、開発、生産、ポストプロダクションの3つのライフサイクルフェーズと、それに関連するすべてのホモロゲーションプロセスにおいて、自動車および製造業を包括的にサポートするためのプラットフォームベースの製品とサービスの幅広いポートフォリオを用意しています。今回の協業では、設計・開発段階でGitHub Copilotが活用される予定です。マイクロソフトのPurviewプラットフォームは、Azure OpenAIツールとCopilotで利用可能であり、リスクを低減し、コンプライアンス要件を満たしながら、さまざまなデータ資産に対してデータセキュリティとガバナンスを提供します。Microsoft Sentinelは、セキュリティイベントを収集、分析、対応するためのクラウドネイティブなSIEMおよびSOARプラットフォームであり、Azure OpenAI Copilotで有効化されたDefender Threat Intelligenceとともに、包括的なVSOCオペレーションを提供します。VSOCプラットフォームは、CyberArk、Device Authority、PlaxidityX Security、およびマイクロソフトの65兆の脅威インテリジェンスを含むその他のソースからデータを取り込み、Security Copilotを活用して、重要な脅威をマシンスピードでプロアクティブに特定、優先順位付け、緩和します。

次のステップ

自動車業界は複雑であり、未来の自動車を保護するための総合的なプラットフォーム・ベースのアプローチが必要であり、パートナーのエコシステムを用いて、最先端の製品、ノウハウ、革新的なアプローチを組み合わせ、最先端の生成AIを活用したセキュリティ技術を活用することで、自動車業界特有の課題に対処することができます。近い将来、この協業プラットフォームが提供できる具体的な内容についてご期待ください。

The post 業界リーダーが協力し、次世代の自動車およびモビリティ・セキュリティ・ソリューションのパイオニアに appeared first on PlaxidityX.

注：MITM攻撃には、2者間の通信を合意なしに傍受し、操作することが含まれます。

効率のよい高帯域幅の車載ネットワーク接続を容易にするため、車載イーサネットリンクは車載E/Eアーキテクチャとして一般的になりつつあります。

自動車業界でイーサネットを使用するために、DoIP (Diagnostics over IP：診断通信プロトコル) やSOME/IPといった専用のアプリケーションレイヤープロトコルが開発されました。これに加え、一般的な車載イーサネットスタックとして、ICMP、ARP、DHCP といったIT業界の一般的なイーサネットプロトコルも挙げることができます。

車載ネットワークセキュリティの一般的な分析では、まず、影響の大きい以下の攻撃パターンについて調べます。

1. サービス拒否攻撃（DoS）
2. ECU挙動の改ざん
3. 車両挙動に対する悪意あるトリガー
4. ドライバー情報の改ざん
5. ユーザー情報の漏洩
6. 知的財産の侵害

上記のうち、サービス拒否、車両挙動に対する悪意あるトリガー、ドライバー情報の改ざん、ユーザー情報の漏洩の4つは、このMITM攻撃によって引き起こされる可能性があります。

SOME/IPとサービスディスカバリについて

SOME/IP （Scalable service-Oriented MiddlewarE over IP：サービス指向通信）は、車載用ミドルウェアプロトコルであり、高速データ転送、低いオーバーヘッド、短い起動時間など、車載通信のニーズに対応するよう設計されています。

これは、クライアント・サーバー間の通信用に設計されており、サーバーは通常クライアントにサービスを提供します。サービスによって、車内イベントに関する通知が提供されるほか、クライアントによるサーバー機能の呼び出しおよび情報のリクエストが可能になるRPC（Remote Procedure Call：遠隔手続き呼び出し）が提供されます。

SOME/IPにはサービスディスカバリ機能（SOME/IP-SD）が備わっており、サービスへの動的なサブスクリプションが可能です。通常、サーバーはネットワーク上の接続先すべてにオファーメッセージを送り、サーバーが提供するサービスについて通信します。次に、クライアントがサブスクライブメッセージを送信して、関連するサービスをサブスクライブします。サブスクリプションが完了すると、サーバーはクライアントにサービスの提供を開始します。つまり、サーバーは通知を送信し、リクエストに応答します。このサブスクリプションプロセスは定期的なもので、通常は2秒に1回行われます。

リファレンス攻撃設定

今回の攻撃設定は、自動車業界における一般的なユースケースを代表するもので、AとBの2つのECUはスイッチを介して接続し、SOME/IPで通信します。ECU Aはサーバーで、クライアントであるECU BにサービスS1を提供します。このスイッチには別のECUであるECU Cも接続されています。

この攻撃シナリオの前提条件は、ECU Cがすでに侵入されて、ネットワークに偽のメッセージを送信することができるというものです。

攻撃の流れ

この攻撃では、攻撃者はECU A とECU Bの間のサービス通信を乗っ取り、強制的にECU Cを通して通信が行われるようにします。通常ECU Aは、サービスディスカバリオファーメッセージを送信してS1サービスを提供します。これらのメッセージは複数の場所に送信されるため、ECU Cもこのメッセージを受信します。ECU Cは攻撃を実行するため、受信したオファーS1メッセージに対してサブスクライブS1メッセージをECU Aに送信してサービスをサブスクライブし、スプーフィング（なりすまし）されたオファーS1メッセージをECU Bに送信する、という2つのことを行います。

ECU BはオリジナルのオファーS1とスプーフィングされたオファーの両方を受信しますが、2つ目のオファーが1つ目のオファーの直後に届くため、2つ目だけをサブスクライブします。このようにして、ECU A （サーバー） からECU C （クライアント）へ、そしてECU C （サーバー） から ECU B （クライアント）へ、という2つの接続が開始されます。

その後、ECU CはECU AとB間でメッセージをリレーします。例えば、ECU AがそのクライアントであるECU Cに通知を送信した場合、ECU Cはその内容を直ちにECU Bへ転送します。サービスサブスクリプションプロセスおよびメッセージのリレーは攻撃の間ずっと繰り返されます。

攻撃者はこの攻撃を実行することで2つのことができるようになります。1つ目はECU AとECU Bの間の通信を傍受することです。この通信では、スイッチがそれぞれのスイッチポートに関係するパケットしか転送しないため、攻撃がなければ本来ECU C（攻撃者）からは見ることができません。2つ目は、ECUの間の通信をコントロールしてスプーフィングすることです。

攻撃者はこの攻撃を実行することにより、偽の通知をクライアントに送信する、サーバー上でリモート機能を呼び出す、メッセージデータを改ざんする、重要なメッセージを削除する、といったことができるようになります。サーバー側またはクライアント側で検出できるような通信エラーが発生することはありません。

私たちは、車載イーサネットスイッチを介して接続した2つのECUのシミュレーションと攻撃スクリプトを使用して、この攻撃を実行することができました。

攻撃の緩和策

このような攻撃を緩和する方法はいくつかありますが、どの方法を選ぶべきかは、主にネットワークプロパティによって決まります。

スイッチの機能（TCMAルールなど）を使って基本的なファイアウォールを適用すれば防げる場合もありますが、それだけでは不十分な場合もあります。

通常のネットワーク・パラメータ（MAC アドレス、IP アドレス、UDP/TCP ポート）だけでなく、SOME/IP サービス ID や SOME/IP-SD メッセージ・タイプなどの自動車固有のネットワーク・パラメータに基づいてトラフィックをフィルタリングする、例えばAUTOSAR ファイアウォール規格にあるような侵入検知・防御システム（IDPS）や高度なファイアウォールなどの高度なセキュリティ・メカニズムを使用することを強く推奨します。

認証あるいは暗号化手法を使用しても、この攻撃の防止には限定的な効果しかありません。SOME/IP-SDトラフィックは複数の宛先に送信されるため、標準プロトコルでは認証や暗号化はできません。SOME/IPトラフィックは認証や暗号化が可能ですが、攻撃側のECUが正当な形でサービスをサブスクライブした後、攻撃者の代わりにSOME/IPメッセージを送信しているため、この攻撃を防止することはできません。

結論

E/EアーキテクチャーにおけるSOME/IPの役割は拡大し続けており、サイバー脅威の影響を受けやすいことは、SOME/IPプロトコルを悪用したMITM攻撃で説明されています。このシナリオでは、敵が2つのECU上の2つのアプリケーション間の接続をハイジャックし、攻撃するECUがECU間の通信を盗聴して送信データを操作することを可能にします。

この懸念すべき問題は、堅固な自動車サイバーセキュリティ対策を取る必要性を強く示しています。どのような緩和手段が使えるかはネットワークの特性によって異なりますが、今回のような攻撃を防ぐには、自動車に特化した高度なセキュリティ・メカニズムの使用が強く推奨されます。

このような脆弱性を軽減するためには、潜在的な攻撃に対応できる、自動車専用の高度なセキュリティ・メカニズムを導入する必要があります。さらに、SOME/IPに関連する潜在的なリスクに対し、規制対応が進められています。例えば、日本のJASPARでは、この脆弱性を正しく認識し、指摘しており、自動車通信規格における厳格なセキュリティ・プロトコルの必要性を示しています。SOME/IP を利用したシステムにおける悪用からの保護は、依然として極めて重要な関心事であり、進化するサイバー脅威に対応する積極的な対策が必要です。

The post 中間者攻撃によるSOME/IPプロトコルの乗っ取りについて appeared first on PlaxidityX.

自動車業界はデジタル革命の真っ只中にあり、この変革はソフトウェアによって推進されています。OEMやティア1サプライヤーがソフトウェア開発に膨大なリソースを投資しており、ソフトウェア・デファインド・ビークル（SDV）は今後の業界の方向性を示しています。

最先端技術を活用し、高度なソフトウェアとコネクティビティ機能を備えたSDVは、安全性、効率性、利便性の高い未来を提供します。しかし、このような新しいテクノロジーにはリスクがつきものです。ソフトウェアが重視される世界で、リスクを最小限に抑えながら自動車のイノベーションを実現するためには、サイバーセキュリティとデータプライバシーが極めて重要です。

このブログでは、SDVにおけるサイバーセキュリティの複雑さを検証し、SDVをサイバー脅威から保護する方法について、自動車メーカーが直面している課題および検討事項について調査した内容をまとめています。

ソフトウェア・デファインド・ビークル（SDV）とは？

SDVは、自動車分野におけるパラダイムシフトを象徴するものであり、従来の機械部品をソフトウェアを用いたシステムが補強したり、あるいは置き換えているものです。この変化は、自動運転、コネクティビティの強化、運転体験を再定義する無数の革新的な機能など、新たな可能性を切り開くものです。

アーキテクチャの観点からは、SDVは1台以上の高性能コンピュータ（HPC）と複数のゾーンコントローラで構成されます。アプリケーションレイヤーは、車両オペレーティングシステム（AUTOSAR、Linuxなど）によってハードウェアレイヤーから分離されているため、ソフトウェアを柔軟に拡張・適応させることができます。SDVの大きな利点は、ソフトウェア・アップデートを無線（OTA）で継続的に受信できるため、車両の機能と性能を常にアップデートおよび改善できることです。

自動運転車とコネクテッドカーの普及： 脅威と課題

SDVが普及するにつれ、堅牢な自動車サイバーセキュリティ対策の必要性が大きくなります。SDVの各コード行、自動走行機能、ソフトウェアベースのサービス、OTAアップデートには、適切なサイバーセキュリティ対策が必要です。このような理由から、多くのOEMにとってサイバーセキュリティは機能安全や品質と同じくらい重要になってきています。

特に自動運転車は、環境を理解するために複雑なソフトウェア・アルゴリズムとセンサーに大きく依存しているため、その機能を損なうサイバー脅威の影響を受けやすくなっています。同様に、交通の流れや安全性を向上させるために他の車両やインフラと通信するコネクテッドカーも、悪意のある目的でこれらの通信を操作するサイバー攻撃に対して脆弱であるといえます。

SDVのサイバー脅威：その詳細

SDVは、以下のようなタイプのサイバー脅威に狙われる可能性があります。

マルウェアおよびランサムウェア攻撃：悪意のあるソフトウェアがSDVのシステムに侵入し、機能を低下させたり、重要なコンポーネントの制御を奪う可能性があります。ランサムウェア攻撃は、車両をロックダウンしたり、車両全体を人質にして、車両のロックを解除するために巨額の身代金の支払いを要求したりする恐れがあります。2022年には企業や組織のITネットワークに対するランサムウェア攻撃が4億9,300万件を超える（出典：Statista）ことから、このようなシナリオの可能性はますます高まっているといえます。

リモートアクセスの脆弱性：SDVのコネクティビティが向上するほど、SDVはより大きなサイバーセキュリティリスクにさらされるようになります。新しい脆弱性は定期的に公表され、事実上すべてのブランドの何百万台という車両に影響を及ぼしています。特定の脆弱性を悪用し、悪意ある者はセーフティクリティカルなシステム（ブレーキなど）にアクセスしたり、個人データにアクセスしたり、あるいは遠隔地から自動車を始動させたりします。これは、19歳のITスペシャリストがサードパーティ製アプリの脆弱性を悪用し、複数の車両機能を遠隔操作したテスラのハッキング事件で実証されています。

センサーのなりすまし：自動運転車は、環境を認識するためにセンサーに大きく依存しています。サイバー攻撃者は、偽の信号を送信することでこれらのセンサーを欺き、車両に誤った判断をさせようとする恐れがあります。

サービス拒否（DoS）攻撃：DoS攻撃は、大量の偽のリクエストで通信ネットワークを圧倒することで、SDVの正常な機能を妨害します。その結果、接続が失われ、車両が情報に基づいた意思決定を行うことができなくなります。

SDVのサイバーセキュリティに関する主な検討事項

SDVのサイバーセキュリティ戦略を策定する際、OEMは以下の重要な要素を考慮する必要があります。

データセキュリティとプライバシー：SDVは膨大な量のデータを生成・収集します。このようなデータは、自動車メーカーが車両の運用を改善し、ドライバーの体験をパーソナライズするのに役立つ一方で、データプライバシーに関する重大な懸念ももたらします。運転の癖や好みの移動ルート、音楽の好みなどを知るだけでなく、車内で交わされる会話や車内カメラの映像など、極めて個人的なデータを収集する車両もあります。さらに悪いことに、Mozillaの報告によると、ほとんどの自動車ブランド（84％）はデータを共有または売却するとしており、大多数（92％）は個人情報をほとんど管理していないとしています。

ネットワークセキュリティ：SDVは通信とアップデートのために広範なネットワークに依存しているため、これらのネットワークのセキュリティ確保は必須です。強固な暗号化プロトコルと認証メカニズムを導入することで、重要なシステムへの不正アクセスや不正操作を防ぐことができます。

リアルタイムの脅威検出：サイバー脅威の動的な性質を考慮すると、SDVサイバーセキュリティシステムは、ファイアウォールや侵入検知システム（IDS）などのリアルタイムの脅威検知機能を備えている必要があります。これには、サイバー攻撃の可能性を示す異常がないか、車両のソフトウェアとネットワークを継続的に監視することが含まれます。

安全なソフトウェア開発：安全なソフトウェアを構築することは、SDVのサイバーセキュリティの基本です。コードレビュー、ペネトレーションテスト、定期的なソフトウェア更新など、安全なソフトウェア開発のベストプラクティスを採用することで、脆弱性を最小限に抑えることができます。実際、多くの OEM やティア 1 サプライヤは、脆弱性管理プロセスをソフトウェア開発（CI/CD）プロセスの初期段階に移行しています。

多層的なセキュリティアプローチ：OEM は、サイバー脅威に対する強固な防御を構築するために、さまざまなセキュリティ対策を組み合わせ、多層的なセキュリティアプローチを SDV に導入することを検討すべきです。これには、車載ネットワークトラフィックの監視ツール（ファイアウォール、IDS など）、潜在的なサイバーリスクの特定と対応、脆弱性の緩和、走行中のフリートの保護（VSOC など）が含まれます。

継続的な監視とアップデート：OEMやサプライヤーにとって、サイバーセキュリティ対策の継続的な監視とアップデートは不可欠です。サイバー脅威の動的な性質にはリアルタイムの対応が必要であり、SDVシステムには新たなリスクに迅速に対応する能力が求められます。継続的な脅威評価に基づく定期的なソフトウェアアップデートは、脆弱性に対処し、SDVの全体的なセキュリティ体制を強化するためのプロアクティブな対策として機能します。

SDV のサイバーセキュリティ向上にはエコシステムの協力が不可欠

SDV が自動車業界に革命をもたらす中、サイバー脅威の高度化に伴い、メーカー、サイバーセキュリティの専門家、規制機関、さらには消費者を含む関係者間の協力が必要となっています。自動車業界は、新たな脅威に先んじるために、コラボレーションと情報共有を促進する必要があります。サイバー脅威と脆弱性に関する洞察を共有することは、エコシステム全体で効果的な対策を開発することにつながります。

この状況において、規制の枠組みが SDV のサイバーセキュリティに対して極めて重要な役割を果たします。各国政府は、ベースラインとなるセキュリティ対策の基準を策定し、実施するために、業界と積極的に協力していく必要があります。これらの基準は、技術の進歩に連動して進化し、SDV の持続的な安全性とセキュリティを確保するため柔軟かつ強固な枠組みを構築する必要があります。

SDVサイバーセキュリティで自動車のイノベーションを実現

今後、SDVのサイバーセキュリティにおいて重要なのは、イノベーションと保護の間の複雑なバランスを取ることです。メーカーは、技術の可能性を広げつつ、一方で、悪意ある者に対抗するために製品を強化するということのバランスに取り組まなければなりません。これを実現するためには、コンセプトの段階から車両のライフサイクルの終わりまで、サイバーセキュリティをSDVの開発に統合するアプローチが必要です。

結論として、ソフトウェア・デファインド・ビークルのセキュリティを確保するには、包括的かつ協力的な取り組みが必要です。SDVのサイバーセキュリティのニュアンスを理解し、プロアクティブな考え方を取り入れ、強固なセキュリティ対策を実施すれば、OEMとティア1サプライヤは、次世代の自動車の安全性とセキュリティを確保しつつ、自動車イノベーションの可能性を最大限に引き出せるでしょう。

The post SDVサイバーセキュリティ入門： 自動車の安全な未来のために appeared first on PlaxidityX.

自動車をサイバー攻撃から保護する一般的な手法は、セキュリティ・イベントを検知するためのセンサーを含めた IDPS（侵入検知・防御システム）をECUに組み込むことです。このようなイベントは大量に発生する可能性があり、車載ECUの限られたローカルメモリーに影響を及ぼすだけでなく、詳しい調査のためそれらのイベントをクラウドに送信するためのネットワーク帯域幅にも影響が及ぶ恐れがあります。もう一つの課題は、ECUがOS（AUTOSAR、Linuxなど）によって異なるフォーマットでセキュリティ・イベントを生成することです。セキュリティ・イベントに関する共通基準がないために、集中管理している車両SOC (VSOC)から侵入の可能性を効果的にモニタリングし、特定することが難しくなっています。

この記事では、侵入検知システム管理のためのクロスプラットフォーム基準の必要性の説明、および、AUTOSARとLinuxベースのECU間におけるセキュリティ・イベントの追跡と管理を統合し、合理化するための新たなアプローチを提示します。

車載セキュリティイベントの追跡を義務付ける規制

新たな規制により、自動車OEMは、自動車のライフサイクルを通じて、車両の脆弱性およびサイバーリスクを追跡することが義務付けられています。UNR 155の規制は新しい車種に適用されており、自動車OEMがサイバーセキュリティ・マネジメントシステム（CSMS）を導入し、「車両データおよび車両ログからサイバー脅威、脆弱性およびサイバー攻撃を分析および検出する機能を含めること」（UNR 155、セクション7.2.2.4）が求められています。

従って、（UNR 155に規定されているように）サイバー攻撃の試みや実際の攻撃を検知し、調査するには、自動車OEMは車両コンポーネントから生成される大量のセキュリティ・イベント・データにアクセスする必要があります。

車両セキュリティ・イベント管理における課題

自動車OEMは有害なセキュリティ・イベントが発生してないか、数百万台もの自動車を監視する必要があり、このセキュリティ要件を満たすことは簡単ではありません。各車両は定期的に大量のローカルイベントを生成しますが、その多くは日常的なものや重要ではないものであって、セキュリティ・イベントではありません。しかし、なぜデータ量が問題になるのでしょう？ECUのローカルストレージにすべてのイベントを保存し、自動車OEMのクラウドに定期的にアップロードすることは、どのくらい困難なことなのでしょう？

このアプローチにはストレージとコストという2つの大きな制約があります。通常、ECUのストレージ容量は限られており、日常的に収集される大量のセキュリティイベントを保存するようにはできていません。また、クラウドにイベントを送信すると、無線データ通信の帯域幅の費用とクラウドストレージ費用（データ量に直接関係する）が発生します。

既述の通り、多くのイベントにはセキュリティ上の価値はほとんどなく、セキュリティ上の意味があるイベントは、大量のデータの中に埋もれています。適切でないセキュリティ・イベントを分析するのは効率が悪く、また時間の浪費になります。そのため自動車OEMは、調査のためバックエンドシステムにイベントを送信する前に、そのイベントにセキュリティ上の価値があるかを判断する手段が必要と考えています。

侵入検知システムマネージャー(IdsM)とは？

AUTOSARは2020年、上記の課題に対処するためにIdsMのコンセプトを含むIDSアーキテクチャを導入しました。IdsMはAUTOSAR ECU向けに統一されたイベントフォーマットを作成し、車両セキュリティ・イベント（SEv）を収集し、指定された基準を用いてフィルタリングを行います。IdsMの主な目標は、複数のセキュリティ・イベントの集中管理とコントロールを実施し、車両内でローカルに発生する多くの無関係なイベント（メンテナンス関連など）をフィルタリングすることです。

IdsMは、現代のコネクテッドカーを効果的にモニタリングするのに不可欠なコンポーネントになっています。自動車OEMはIdsMによって、適切なセキュリティ・イベントだけに集中し、フリートのサイバーセキュリティ状況を追跡し、サイバーリスクを検知することができます。このように、IdsMを用いることで、OTA帯域幅やクラウドストレージコストを削減しながら、VSOCの統合作業を支援できます。

IDSアーキテクチャはAUTOSARおよびLinuxベースECUを横断する必要がある

IdsMは大きな前進ではあるものの、これで解決できるのは問題の一部に過ぎません。なぜなら、今日のIdsMに対する業界基準が、AUTOSAR ECU（AUTOSAR ClassicとAUTOSAR Adaptiveの両方）だけに焦点を当てているからです。それでは、他のタイプのECUはどうなるのでしょうか？現在、ほとんどの車両ネットワークには、AUTOSAR ECUとLinuxベースのECUが組み合わされて用いられています。インフォテインメント（IVI）システムやテレメトリECU（TCU）といったデータ量の多いアプリケーションのスループットニーズに対応するため、この組み合わせはますます普及しています。

プラットフォーム間でIdsMが標準化されていないため、Linux ECUのメーカーは独自にセキュリティ・イベント管理システムを構築しなくてはなりません。AUTOSARとLinuxベースのECUでは、異なるフォーマットでセキュリティ・イベントが生成されるため、AUTOSARとLinuxベースのECUから収集されたイベントを統合するには、バックエンド（自動車OEMのVSOC内）で大規模な統合作業が必要になります。ビジネスの観点から言えば、これらの作業によって自動車を市場に投入するまでの期間が長くなってしまいます。

PlaxidityX IdsM for Linuxを使う理由

インフォテインメントシステムやテレマティックECUなどの車載ECUには、Automotive Grade Linux（AGL）といったPosixベースのOSプラットフォームの普及が進んでおり、標準的なIdsMの必要性が高まっています。このギャップに対応するため、業界は多様なECUが生成するイベントの集約・分析を支援するクロスプラットフォーム（AUTOSAR、Linux、Androidなど）標準が必要です。

プラクシディティ エックス（旧アルガス）はこの必要性を認識し、IdsM AUTOSAR標準をLinuxベースのECUに対して拡張・適用できる画期的なソリューションを開発しました。プラクシディティ エックスの受賞歴を持つLinux向けIdsMソリューションは、LinuxプラットフォームのECUに搭載された複数の侵入検知システム（IDS）センサーからのセキュリティイベントを管理・調整します。これにより、効率的にセキュリティイベント（SEv）を収集し、事前定義されたルールとロジックを用いて適格なセキュリティイベント（QSEv）を特定します。その後QSEvは、ECUメモリーにローカルに保存するか、侵入検知システムレポーター（IdsR）モジュールを介してクラウドVSOCに送信することができます。

AUTOSARの仕様と機能を拡張しLinuxベースのデバイスをもカバーすることにより、PlaxidityX IdsMは車載ネットワークのトラフィックや潜在的なセキュリティ侵害を合理的かつ効率のよい形でモニタリングできます。

自動車OEMやティア1サプライヤーにとってのメリット

プラクシディティ エックスのLinux向けIdsMソリューションは画期的なソリューションで、AUTOSARおよびLinuxベースのECUからセキュリティ・イベントをシームレスに統合することが可能になり、自動車OEMやティア1サプライヤーに、次のようなメリットを提供します。

• UNR 155の規制要件を満たす – 車載セキュリティイベントを記録し、クラウドへ効率よく送信
• VSOC統合を簡素化・合理化する – ECUプラットフォーム間で標準化されたセキュリティ・イベント・フォーマットを使用
• Linuxベースの車載ソフトウェアの開発コストを削減する – IdsM for Linuxは、あらゆるLinuxベースECUをシームレスに統合可能なレディメードモジュール
• 新規SDV車種の市場投入期間の短縮 – このソリューションはClassic AUTOSARおよびAdaptive AUTOSARの両方に互換性があり、類似したAPIを公開し、この分野で認められた基準に従って認定メカニズムを実行可能

PlaxidityX IdsM for Linuxソリューションの詳細については、Host IDPS製品ページをご覧ください。

The post 自動車セキュリティを合理化する：AUTOSARおよびLinuxベースECU向け侵入検知システムマネジャー（IdsM） appeared first on PlaxidityX.

同時に、多くの自動車メーカーが重要なコンポーネントのOTAアップデートや頻繁なソフトウェアリリースを含むCI/CD（継続的インテグレーション/継続的デリバリー）技術を採用するようになる中、製品開発の早い段階で車両脆弱性管理（VVM）を統合する傾向が顕著になっています。

この「シフトレフト」アプローチのメリットおよび、一般的に使用されているCI/CDツールとVVMとの統合の例を見ていきましょう。

自動車に特化した脆弱性管理が重要な理由

自動車専用のVVMソリューションは、最新のクルマが抱える安全面での固有の課題や複雑性に対処するよう設計されています。これらのツールは、ソフトウェアの脆弱性を特定する以外に、アセット管理、AUTOSAR との互換性、さらには電子制御ユニット（ECU）のハードウェアの脆弱性への対処、といった機能も併せ持っています。

例えば、車両アセットの中の脆弱性をピンポイントで特定するためには、脆弱性管理ツールは、自動車ECUの複雑な階層を自由に行き来できなければなりません。しかし自動車ECUには、多くの場合、複数のサプライヤーが提供するコンポーネントが組み込まれています。自動車専用ソリューションは従来のITツールと異なり、これらの階層に的を絞った可視性を提供することでこの問題に対処し、より効果的で正確な緩和戦略を実現します。

脆弱性管理のもう一つの課題は、自動車ECUには事前定義されたSBOMが搭載されていないことが多い、ということです。自動車専用VVMツールはこの情報を自動車用AUTOSAR ECUなどのバイナリーファイルから自動的に抽出するよう設計されているため、自動車メーカーは汎用ツールでは提供できない詳細なレベルで脆弱性を管理することが可能になります。

脆弱性の早期検出が迅速な問題解決につながる

すでに述べたように、多くのティア１サプライヤーはコーディングやテストプロセスにかかる時間を短縮するために既にCI/CD技術を導入しています。ECUや他のコンポーネントのソフトウェアコードをゼロから開発するサプライヤーもいれば、複数のサブレベルのソフトウェアサプライヤーと連携するサプライヤーもいます。

自動車サプライチェーンは複雑であるため、ティア１はサプライヤーから受け取ったECUコンポーネントのソフトウェア構成を必ずしも認識しているとは限りません。ティア１は、OEMへ出荷する前に脆弱性の検査のためコードをスキャンしますが（これは事実上の要件になりつつあります）、そのためには開発プロセスにおいてコードを完全に可視化する必要があります。

ティア１は、脆弱性管理ツールをCI/CDパイプラインの他のツールと統合することにより、開発の初期段階で自動的に脆弱性を検出することができます。このアプローチにより、早め早めに先手を打ってプロアクティブに脆弱性に対処することができ、エンジニアはより迅速にコスト効率よく問題を解決することができます。

VVMをCI/CDパイプラインに統合する方法

では、ソフトウェア開発者の視点からはVVMをCI/CDに統合することはどういうことなのでしょうか。VVMをJenkinsと統合してソフトウェアのビルドとテストを自動化し、Jiraと統合して脆弱性のソリューションを記録し管理するシナリオを例にしましょう。

この統合により、開発者はJenkins内でテストフェーズの一環としてコードをスキャンして脆弱性を確認することができます。ここでのメリットは、JenkinsとVVM間で手作業によってファイルをダウンロード/アップロードする必要がなく、またビルドのセキュリティステータスに関するフィードバックをすぐに得られる点です。例えば、発見された脆弱性の数や重大度に基づいてビルドの成功と失敗を決定するルールをJenkins内で作成することができます。

例えば、あるECUに重大な脆弱性があるとVVMが検出したと仮定しましょう。VVMツールをJiraなどのプロジェクト管理ツールと統合すれば、分析および対策のタスクが社内のプロジェクトチームや開発チームの担当者に割り当てられます。担当するサイバーアナリストは、脆弱性を分析するうえで必要なすべての情報（「ユーザーストーリー」）をJiraから受け取り、その解決方法を見出し、対策を実施します。

社内で製品開発やテスト用に様々なCI/CDツール、あるいはレガシーシステムを使用している場合、自社で使用しているVVMソリューションが、CI/CDパイプライン内でシームレスに統合するために必要なAPIに対応しているかを確認する必要があります。ベンダーはスムーズな統合を実現するために様々なレベルのAPIドキュメントやサポートオプションを提供しています。

先見の明をもって車両脆弱性管理を行う

自動車ソフトウェアやハードウェアの設計に脆弱性はつきものです。これを踏まえ、ティア１は脆弱性が重大なリスクになる前に優先的に脆弱性を特定して対処する必要があります。

先見性のある脆弱性管理ソリューションは、サイバーセキュリティ責任者がCI/CDパイプラインの不可欠な部分として脆弱性を検出し解決するのに役立ちます。脆弱性の検出を開発プロセスの初期段階に（テストとQAとともに）移行させることで、ティア１は市場投入までの時間を短縮できるだけでなく、時間、労力、コストを削減することができます。

車両脆弱性管理をCI/CDパイプライン内に統合するメリットについて詳しく知りたい方は、以下のリンクからホワイトペーパーをダウンロードできます

The post 自動車サイバーセキュリティのシフトレフト：車両脆弱性管理におけるROI重視のアプローチ appeared first on PlaxidityX.

自動車ソフトウェアとシステムエンジニアリングにおけるコンプライアンスと継続的改善のためのベースラインを確立する際の主要な標準として、 Automotive SPICE® (Software Process Improvement and Capability Determination)があります。

ASPICE の最新バージョン（4.0）はドラフト版であり、2023 年 9 月にリリースされ、トレーニングと移行は 2025 年に行われる予定です。この記事では、ASPICE 4.0 について、サイバーセキュリティ・プロセスとどのように関連するのか、また、新バージョンが今後 OEM、サプライヤ、ASPICE アセッサーに及ぼす影響について、ASPICE レベル2準拠のサイバーセキュリティソフトウェア企業の立場から、独自の見解を共有したいと思います。

Automotive SPICEとは？

ドイツの VDA によって発行されている Automotive SPICE（別名 ASPICE）は、自動車用ソフトウ ェアサプライヤの開発プロセスの品質をガイド、測定、評価するためのプロセス、プラクティス、およ び評価手法を定めています。現在、ASPICE 評価は、システム要求分析、システムアーキテクチャ設計、ソフトウェア要求分析、プロジェクト管理、およびその他のトピックをカバーする、メーカーとサプライヤ間の共同プロジェクト作業に広く利用されています。ASPICE プロセス評価モデルは、プロセスの成熟度に応じて 6 つの能力レベルで構成されています。

ASPICE 4.0の変更点

ASPICE 3.1（現行バージョン）に対する ASPICE 4.0 の主な変更点は、VDA スコープの縮小です。VDAとは、ソフトウェア開発プロセスが満たすべき、完全な ASPICE標準の必須要件を指します。この変更の背景には、迅速な開発プロセスを可能にするために、作業成果物の数を減らすという動機があります。

さらに、評価の複雑さを軽減し、透明性が高く、測定可能で客観的な方法で、プロジェクトあるいは企業の評価結果の比較が容易になります。

VDAのスコープ

スコープの変更は、以下のプロセスに関するものです：

• 基本領域ー品質、プロジェクト管理、コンフィグレーションマネジメント、問題解決、変更要求
• 専門領域ーシステムエンジニアリングプロセス、ソフトウェアエンジニアリングプロセス、ハードウェアエンジニアリングプロセス、機械学習プロセス
• フレキシブル領域ーリスク管理、計測、リユース製品の管理、プロセス改善、製品リリース、ステークホルダー要求事項の抽出、バリデーション、サプライヤーモニタリング

ASPICE 4.0では、必須となる VDA 評価のスコープが縮小され、基本領域と少なくとも 1 つの専門領域が 含まれるようになります。また、OEM によっては、特定のビジネスニーズに応じて、フレキシブル領域の追加を求める場合もあります。

戦略

各プロセスの戦略（すなわち、会社の仕組み、プロセスの目標、オーナー、使用ツールなど）を文書化しなければなりません。これには時間がかかり、通常、数十ものドキュメントにもなります。ASPICE 4.0 では、戦略がレベル 1 から外され、レベル 2 になりました。これらの文書を作成することは、多くの企業にとって障壁となっているため、この変更により、レベル1の認証取得が容易になると思われます。この変更は、要求事項そのものではなく、アセッサーが証拠を求めるレベルにおける変更となります。

ベース・プラクティス

ベースプラクティスの数は削減されましたが、必要な作業成果物の 量には影響しないと私たちは考えています。これは、多くの場合、新バージョンでは 2 つのベースプラクティスが 1 つに統合されているためです。例えば、ASPICE3.1 では、トレーサビリティに関するベースプラクティスと一貫性に関するベースプラクティスが１つずつありました。4.0 では、トレーサビリティと一貫性を記録することが１つのベースプラクティスとなります。このため、プラクティスの数は減りますが、実際に作業が減るわけではありません。

アセッサーの専門性

ASPICE 4.0では、アセッサーの認定方法が変更され、また、新しいプロセス領域が追加されました。このため、アセッサーにはより専門的な知識と技術が要求され、追加のトレーニングや試験が必要になります。必要な専門知識を提供するために、評価チームをおそらく拡大する必要があるでしょう。 

一言で言えば、ASPICE4.0の主な変更は、企業がどのようにソフトウェアを開発するかではなく、ア セッサーがどのように機能するかということです。ティア 1 サプライヤーやその他のソフトウェア企業にとって、これらのアセスメントにかかるコストは増加する可能性が高いと思われます。

ASPICE for Cybersecurity

2022年2月、VDAは、サイバーセキュリティ・エンジニアリングのためのプロセス参照および評価モデル（Cybersecurity PAM）に定められたサイバーセキュリティ・エクステンションにより、ASPICEのスコープを正式に拡大しました。このエクステンションは、OEM およびそのサプライヤのためのベースラインとして機能し、要求事項の抽出、サイバーセキュリティの実装、リスク処置の検証、およびリスク処置の妥当性確認を含むサイバーセキュリティ評価のための新たな領域を定義しています。

サイバーセキュリティ戦略を策定する OEM にとって、ASPICE のサイバーセキュリティ・エクステンション、CSMS、および ISO 21434 の違いを理解することは重要です。規制要件に基づけば、会社レベルで CSMS 監査を実施することが「必須」であることは明らかです。しかし、製品ごとに CSMS 監査を実施することや、開発プロセスの中で ASPICE サイバーセキュリティ・エクステンションを実装することは、現在のところ必須ではなく、各顧客固有の要件によって決定されます。

2022年6月、プラクシディティ エックス（旧アルガス）は他社に先駆けてASPICE for Cybersecurityのアセスメントを受けました。このアセスメントは、PlaxidityX Ethernet IDPS製品ラインに対して行いました。 私たち自身のASPICE導入経験により、お客様やパートナーに付加価値を提供することができます。

効率的な ASPICE 評価には、サイバーセキュリティ・バイ・デザインが必要

2024年7月には、すべての新車種または既存車種が、サイバーセキュリティに関するUNR155型式承認の対象となります。これらの型式承認要件を満たすため、メーカーは車両の設計、開発、運用、保守の各プロセスにサイバーレジリエンスを組み込んでいます。

自動車のコネクテッド化がすすみ、ソフトウェアが重視されるようになると、OEMは、機能安全性に劣らず、サイバーセキュリティも重要であることを認識するようになりました。品質の観点からは、経験上、私たちはサイバーセキュリティは機能の「上に」搭載されるべきではないと考えています。むしろ、Vモデルに従って、他の機能と同様に、ソフトウェアの設計プロセスの一部として扱われるべきです。プラクシディティ エックスでの取り組みを紹介すると、一例として、私たちの製品を設計する際、潜在的なサイバーセキュリティの脅威をそれぞれ個別の機能要件として扱います。これが、ASPICEレベル2で運用する企業がサイバーセキュリティの管理と実装を容易にする理由です。

サイバーセキュリティを別個の作業パッケージではなく、システム機能の一部として扱うことで、企業は CSMS 監査の実施に必要な複雑さと時間を大幅に削減することができます。このように、サイバーセキュリティは、各プロセスの ASPICE 戦略の中に含めるべきです。例えば、コンフィグレーションマネジメントの戦略文書がある場合、既存のプロセスの一部として、サイバーセキュリ ティについても言及すべきです。

最終的に、すべての戦略文書をアセッサーがレビューしなければなりません。プロセスと戦略の重複を排除することで、アセッサーは戦略のレビューをより効率的に管理および実施することができます。このため、ほとんどのアセッサーは、会社が ASPICE とサイバーセキュリティ（CSMS）プロセスを整合させ、所定の プロセスに関連するすべての機能を組み込むことを望んでいます。

プラクシディティ エックスがASPICEとサイバーセキュリティの専門知識を融合

ソフトウェア・デファインド・ビークルの時代においては、品質とサイバーセキュリティは切り離せないものだとOEMとティア1サプライヤーは理解しています。また、ソフトウェア設計とサイバーセキュリティを、自動車エコシステム全体の「Vモデル」の一部として組み込む本質的な必要性も理解しています。したがって、多くのOEMは、ASPICEとサイバーセキュリティの両方を理解する企業とパートナーを組みたいと考えています。

OEMとそのサプライヤーのCSMS実装を支援してきた豊富な経験に基づき、プラクシディティ エックスは、自動車メーカーがASPICEとサイバーセキュリティイニシアチブを整合し、合理化することを支援できるユニークな立場にあります。当社の比類なき自動車サイバーセキュリティの専門知識と充実した製品・サービスは、世界中の90社以上のメーカーから信頼を得ています。 

The post ASPICEとサイバーセキュリティを連携させ品質管理を効率化させる方法 appeared first on PlaxidityX.

キーレス・エントリーの普及と利便性は誰もが認めるところです。しかし、他の多くの技術進歩と同様に、RKE/PKEシステムはハッカーから、そして特にこの技術は自動車窃盗犯からの攻撃を受けやすいということが挙げられます。 

このようなサイバーを悪用した自動車盗難の可能性を考慮し、自動車メーカー（OEM）と自動車サイバーセキュリティの専門家は、この脅威の軽減策を模索しています。この記事では、RKE/PKE攻撃の性質と進化、この技術がハッカーからの攻撃に対して潜在的に脆弱である理由、およびRF攻撃を軽減し、車両フリート全体のセキュリティを強化するためにOEMが取り得る対策について考察していきます。

リモートキーレスエントリー（RKE）システム

リモート・キーレス・エントリーとは、物理的なキーを使わずに（例えば、ドアキーパッドやリモコンを使って）車に乗り込むことを指します。最初のRKEキーは、コード化されたパルス信号発生器とバッテリー駆動の赤外線放射器を使用していました。キーは特定の信号を送信するように設定され、車はその信号に反応するようにプログラムされていました。 

リプレイ攻撃

この保護されていない信号を悪用して、ハッカーたちは「古典的な」リプレイ攻撃を考案しました。この攻撃では、キーと同じIR周波数を記録し、任意のタイミングで送信する装置を使用します。ドライバーが解錠ボタンを押すと、ハッカーはこの信号を記録し、後でそれを再生してドアを解錠することができます。ただし、この方法は、キーから送信される解錠の信号が常に同じ場合にのみ機能します。

このような攻撃を防ぐため、キーから車に送信されるメッセージにローリング・コード・フィールドが導入され、同じ解錠信号が繰り返し使用されないようにしました。車とキーは、解錠用と施錠用の2つのコードシーケンスを共有します。例えば、Xnは解錠用のn番目のローリングコードであり、Ynは施錠用のn番目のローリングコードとします。すべてのシーケンスは、暗号論的擬似乱数生成器（CSPRNG）を使用して定義されます。解錠ボタンをn回目に押すと、キーはコードXnを送信します。車は受信したローリングコードと想定されるローリングコードとを比べ、それに応じて車の解錠または施錠が実行されます。

RKE攻撃に続く攻撃： ロールジャム攻撃

前項で紹介したセキュリティー改善策は、ローリング・コードをバイパスするように設計された「ロール・ジャム」攻撃に進化しました。ロール・ジャム攻撃は、ローリング・コードを記録し、キーからのRF信号を妨害して車がこれを受信することを妨害します。この攻撃シナリオは、以下のステップで構成されます。

1. ドライバーは解錠ボタンを押し、車のロックを解除する最初のコードであるX1を送信します。攻撃者は信号を妨害し、X1の値を入手します。妨害されたため、車は信号を受信できず、施錠されたままです。
2. ドライバーは再び解錠ボタンを押し、X2を送信します。攻撃者は信号を妨害し、X2の値を手に入れます。ステップ1と同様、車は施錠されたままです。
3. 攻撃者はX1を送信し、ドライバーのために車を解錠します。
4. 運転から戻ったドライバーは駐車し、施錠用のローリングコードであるY1を送信して車を施錠します。
5. その夜に、攻撃者は車の解錠コードX2を送信し、車を解錠することができます。

セキュリティの観点から見ると、上記の実装の主な弱点は、解錠と施錠のローリングコードが互いに独立していることです。しかし、ローリングコードを共有するだけでは、ロールジャム攻撃の新たなバリエーションに対応できません。攻撃者は、連続して送信を妨害し、解錠コマンドのローリングコードを入手し、有効な施錠コマンドを作成することができます（または、施錠コマンドを妨害して、解錠コマンドを作成する逆のシナリオも成立します）。したがって、ローリングコードを共有することに加えて、攻撃者が送信を妨害して入手したローリングコードに基づいてコマンドを作成できないように、メッセージに署名する、または暗号化することが重要です。これは、AES-CMACやHMACのような、暗号学的に安全なメッセージ認証コード（MAC）と、長い共有秘密鍵を使うことで実現できます。

パッシブ・キーレス・エントリー（PKE）システム

パッシブ・キーレス・エントリー（PKE）は、ドライバーがポケットからキーを取り出すことなく車に乗り込みエンジンを始動できるようにしたことで、利便性をより高いレベルに引き上げました。RKEから学んだ教訓に基づき、基本的なPKE通信は、キーの身元を認証するために車から送信されるチャレンジと、キーから送信される暗号計算されたレスポンスで構成されています。

ほとんどのPKEでは、キーと車は、レスポンスの生成と検証に使用される長いランダムな秘密鍵を共有しています。キーはチャレンジに対して暗号関数を実行し、レスポンスを生成します。

リレー攻撃

PKEはキーと車の近接性に基づいているため、送信機の電波が到達できる距離に固有の制約があります。この距離の制約を回避する方法として考案されたのが、悪名高い「リレー攻撃」です。これは2人組の攻撃者が協力して実行します。一人の攻撃者は車の近くにいて、もう一人はキーの近くにいます。それぞれの攻撃者は、長距離（例えば4GやWiFiを使用して）対応のトランシーバーを使い、車とキーから送信されたメッセージを転送します。

下図のように、攻撃者Aはチャレンジを送信させ、それを攻撃者Bに転送します。攻撃者Bはこれをキーに送信し、キーはチャレンジに対しレスポンスを送ります。攻撃者Bはそれを攻撃者Aに転送し、攻撃者Aはそれを車に再送信します。

リレー攻撃を軽減するためのベストプラクティス

緩和策1：応答時間の上限を設定する

リレー攻撃を軽減する方法の１つは、応答時間に上限を設けることです。波動は光速で伝搬するため、車のチャレンジ送信からレスポンス受信までの往復時間を測定することで、距離の上限を推定することが可能です。UWB技術を使えば、精度の高い測定が可能になります。

緩和策2：RSSIを使用してキーの位置を推定する

もう１つの緩和策は、信号強度によってキーと車の距離を特定するRSSI（受信信号強度インジケーター）を使ってキーの位置を推定することです。車は複数のアンテナからチャレンジを送信します。キーは各アンテナのRSSI値で応答し、車はそれらの値を使って位置を推定できます。

しかし、ハッカーが位置推定アルゴリズムを「出し抜く」方法があります。RSSIはキー側で測定されるため、2人組の攻撃者は、キーの近くで増幅したチャレンジ信号を送信してRSSI値を増大し、キーが実際よりも近くにあると車を「騙す」可能性があります。

この緩和策のもう１つの問題は、その値が署名または暗号化されていないことです。つまり、デジタル攻撃者は復調器を使って送信されたデータを抽出し、RSSI値を変更した後、再び信号を変調することができます。ローカライズにRSSIを使用する場合は、これらの値に署名または暗号化することをお勧めします。

緩和策その3：モーションセンサーの統合

リレー攻撃を防ぐため、キーによっては、アイドル期間を検出するモーションセンサーを組み込んでいます。設定された秒/分後に動きが検出されなければ、キーはチャレンジに応答しなくなります。言い換えれば、キーが一晩中キッチンテーブルの上にあれば、攻撃者はあなたの車に対してリレー攻撃を行うことはできません。

既知のチャレンジ・リレー攻撃

もう1つの理論的なハッキングシナリオは、チャレンジが予測可能であることを悪用する既知のチャレンジリレー攻撃です。例えば、次のチャレンジは前のチャレンジに1を足したものです。例：0, 1, 2, …, 0xFFFFFFFF。またはチャレンジがLCG、LFSRなどの暗号学的にセキュアでない乱数生成関数を使用して生成される場合、PRNG関数を知っているか、それを正しく推測した攻撃者は、完全なチャレンジシーケンスを作成することができます。

古典的なリレー攻撃（前述）と同様、このシナリオでもキーと車は離れていますが、今回は攻撃者は1人だけです。彼は車からのチャレンジを送信させ、次に車が送信するチャレンジを予測します。その後、攻撃者はキーに近づき、予測したチャレンジを送信します。キーはそれにレスポンスを送信します。その後、攻撃者は車に戻り、別のチャレンジを送信させます。そのチャレンジが攻撃者の予測したものであった場合、攻撃者はキーから記録したレスポンスを送信することでそのチャレンジに対応し、車を解錠して発進させることができます。

このシナリオを防ぐために検討すべき1つの方法は、高いエントロピーのシードを持つCSPRNGを使用することで、確実にチャレンジが予測不可能なものにすることです。もう一つの提案は、車に全てのチャレンジに署名させることです。こうすることで、たとえ攻撃者がチャレンジを予測できたとしても、レスポンスを得るためにキーに送信できなくなります。

セキュアな実装が勝負

自動車の盗難は、自動車が発明されて以来、ずっと問題となっています。今日に至るまで、使用するツールが進化しているものの、セキュリティの専門家と窃盗犯のいたちごっこが続いています。

RKEとPKEは、OEMにとって多くのセキュリティの課題を生み出しています。安全でないRKEの実装により、最近のロールバック攻撃はじめ、さまざまなバリエーションのリプレイ攻撃やロールジャム攻撃にさらされることが分かっています。攻撃者がキーから入手したメッセージを変更できないように、メッセージは署名または暗号化されるべきです。 

PKEの実装に関しては、ランダム化のために高エントロピーのシードを使用し、チャレンジを暗号化するためにCSPRNGを適用することによって、確実にチャレンジを予測不可能なものにすることが重要です。RSSIを使用して位置を推定する場合、これらの値も改ざんを防ぐために署名または暗号化する必要があります。

さらに、欠陥のある実装の中には、セキュリティ対策をアップグレードすることで軽減できるものもあります。多くの場合、既知の脆弱性を修正するには、BCMおよび/またはキーのいずれかのソフトウェア更新で十分な場合があります。このため、オーバー・ジ・エア（OTA）アップデート機能を提供するOEMは、必然的に発生する次世代の攻撃に効率的に対応するための最良の体制を整えていると言えます。

自動車盗難を防ぐ万能策はありませんが、上記の軽減策と対策を適切に実施すれば、キーレス・エントリーのハッキングの大半を回避するための強力なベースラインになると思われます。

The post リモート／パッシブ・キーレス・エントリー・システムにおける脆弱性の軽減 appeared first on PlaxidityX.

ここ数週間、MarketWatch、MSN、The Telegraphなどの自動車関連ウェブサイトや世界的なメディアは、自動車盗難の最新トレンドである「CANインジェクション」、より詳しい専門用語では「ヘッドライトCANインジェクション」と呼ばれるハッキングの手法に関するニュースでもちきりです。 自動車泥棒が、駐車中の車のエンジンを不正にかけて持ち去ることが簡単にできてしまったことで、車の所有者と自動車メーカーの双方に大きな不安をもたらしています。

このブログでCANインジェクションの仕組みと自動車メーカーに何ができるか、検証してみましょう。

自動車盗難と自動車の歴史はほぼ一緒

1919年、アメリカのダイアー法（National Motor Vehicle Theft Act）は、盗難車の州間輸送を連邦犯罪としました。最初の車両盗難防止装置である取り外し可能なステアリングホイールは、1920年代に市場に登場しました。これは、ドアロックが発明される前のことです。1950年代には自動車用アラームが普及し、その後、エンジンをかけるためにスマートキーフォブを所持する必要があるイモビライザーが登場しました。しかし、車上荒らしはすぐにこれらの技術に適応しました。車の持ち主の家に侵入してキーを盗むのではなく、無線でキーをコピーして車を乗っ取る方法を開発したのです。これに対抗するため、キーの無線信号を遮断する金属製のキープロテクターが開発されました。このように、自動車泥棒とセキュリティ専門家のいたちごっこが続いています。

最新の印象的な方法

このビデオを見てください。泥棒は車を壊さず、2分以内に2021年型トヨタRAV4の盗難に成功しています。彼らはスマートキーにアクセスすることはせず、代わりにヘッドライトに注目しました。より詳しく説明すると、バンパーを外し、ヘッドライトのプラグを抜いて配線にアクセスしたのです。最新鋭のセキュリティシステムを搭載したクルマに対して、どのようにヘッドライトの配線から侵入して盗むことができたと思いますか？CANネットワークのセキュリティ専門家であるケン・ティンデル博士は、自身のブログでその謎を説明しています。泥棒は「CANインジェクション」と呼ばれる手法を使って、車のロックを解除し、イモビライザーをバイパスしてエンジンを始動させたのです‐しかも、鍵を使わずに、2分以内にすべての作業を終わらせています。

CANとは、どのようなもので、どのように侵入されるのか？

コントローラエリアネットワークは、CANバスとも呼ばれ、何十年も前からある一般的な車両ネットワークプロトコルです。複雑な専用配線を必要とせず、電子制御ユニット（ECU）同士の通信を可能にします。最新の自動車には、ブレーキ、エアバッグ、インフォテイメント、ドアロック、エンジン、そしてご想像の通り、ヘッドライトなど、あらゆる電子部品を制御するECUが100個以上搭載されていることがあります。自動車に使用されるECUは複数のネットワークに接続されており、通常、ゲートウェイとして機能する特殊なECUで互いに接続されています。では、ハッカーはどのようにしてこのネットワークに侵入するのでしょうか。コネクテッドカーでは、技術のあるハッカーはECUのソフトウェアコードの脆弱性を突いて、リモートで車に侵入しようとすることがあります。しかし、今回の 「ヘッドライト泥棒」は、リモート接続を使用していません。その代わりに、ヘッドライトという物理的な侵入口を選び、バンパーを引き抜いてヘッドライトに接続するワイヤーを露出させ、配線にアクセスしました。そして、ハッカーはシンプルな電子機器（ダークウェブでプロの窃盗団が購入可能）をその配線に接続して、ネットワークに侵入しました。

「CANインジェクション」でスマートキーになりすます

自動車盗難の次のステップは、スマートキーになりすますことです。スマートキーは、自動車に鍵が本物であることを証明するために、暗号化されたメッセージを交換するように設計されています。暗号を解読するのは大変な作業であるため、泥棒は脆弱性のある経路を攻撃します。CANバスに侵入し、鍵の有効性が確認されたので、イモビライザーを無効にするように、という偽メッセージを送信するのです。そして仕上げに、次の偽メッセージをドアロックECUに送信して、車のロックを解除させ、車に乗り込んで走り去ったのです。

CANインジェクションの引き起こす問題

CANインジェクションを使った盗難は、盗難車のオーナーに苦痛をもたらしますが、OEMにとっても大きな問題です。車が盗まれやすいという評判を得たOEMが受ける金銭的ダメージは大きく、特定のメーカーやモデルの販売に影響を及ぼす可能性があります。この問題に対処するために物理的なリコールが必要な場合、OEMのコストは大きく膨らみます。盗難の増加は、保険金を支払わなければならない保険会社にとっても大きな問題になります。最終的には、保険会社が保険料の値上げを余儀なくされ、最悪の場合、盗難の多い地域では特定の車の保険加入を拒否されるなど、最終的に消費者にしわ寄せがいくことになります。

OEMの反撃方法

非常に効果的で簡単に実施できる対策として、車両のCANネットワークに侵入検知・防止システム（IDPS）を導入することができます。IDPSソフトウェアはコンピュータネットワークを監視し、悪意のある車載通信を検出します。

IDPSは、通信の不規則性や想定された順番から逸脱した場合、これを認識します。これは、次のようないくつかの場合で検知できます：

• メッセージの内容 – 各メッセージには、あらかじめ定義された構造と許容値のセットがあります。IDPSは、この構造および値に違反した場合に、それを検出することができます
• メッセージ送信タイミング – CANバス上の各メッセージには、それぞれ送信方法と想定される間隔があります。例えば、周期的なメッセージは、サイクルタイムごとに1回だけバス上に表示されることが期待されます。このタイミングから逸脱した場合、たとえメッセージがうまく構成されていたとしても、IDPSによって検出されます（下図参照）。
• パターン認識 – 特定のプロセスや特定の攻撃を想定すると、メッセージの既知のパターン（またはその欠如）を確認することが期待されます。IDPSは、このようなパターンを検知し、必要に応じて警告するように設定することができます。

ソフトウェアソリューションであるIDPSは、ハードウェアの追加や物理的な変更を必要とせず、ソフトウェアアップデートによりデプロイすることが可能です。さらに重要なことは、すでに路上を走っている車両にもOEMがこの保護機能を導入できることです。

車両のアーキテクチャに応じて、IDPSをゲートウェイECUに実装し、重要なECUへ攻撃が広がるのを阻止するか、または、重要なECU自体に実装することが可能です。
下図は、IDPSをゲートウェイに配置した場合の攻撃防止を示したものです。送信された偽メッセージはゲートウェイに到達し、エンジン制御ECUなどの重要なコンポーネントに到達する前にブロックされます。

また、IDPSがエンジン制御ECUに実装されている場合、不正なメッセージはゲートウェイを通過することになります。しかし、エンジン制御ECUのIDPSは偽メッセージを検知してブロックするため、例えば、イモビライザーが車の始動をすることはありません。

どちらの場合も、重要なECUは悪意のあるメッセージの影響を受けないため、泥棒は実際には何もできません。

追加で検討すべき防御層

車載IDPSは、悪意のあるメッセージを検出し、重要な車両部品に影響を与えるのを防ぐ、最初の防御ラインです。さらに、OEMが導入できる追加の防御層があります：

• 車両脆弱性管理 – このツールは、車両のソフトウェア部品表（SBOM）を継続的に分析し、公開または非公開の脆弱性を検出します。自動車のサイバー攻撃は通常、1つまたは複数のソフトウェアの脆弱性を悪用して、自動車内のコンポーネントに侵入し、侵害することで発生します。新たに発見された脆弱性に対し、定期的に対処することで、ハッカーの侵入はより困難になります。
• 車両セキュリティ・オペレーション・センター（VSOC）による車両監視 – OEMはVSOCを使用して数百万台ものコネクテッドカーを監視し、機械学習アルゴリズムを活用して異常を検知し、サイバーセキュリティ関連のインシデントを発見します。

自社に最適なソリューションがわからない場合、プラクシディティ エックス（旧アルガス）の自動車サイバーセキュリティの専門家が、特定の車両アーキテクチャを分析し、最適な提案をいたします。

The post 「CANインジェクション」による自動車盗難を防ぐためにOEMができること appeared first on PlaxidityX.

2024年7月には、すべての新規または既存の「車種」が、サイバーセキュリティに関するUNR155の型式承認の対象となります。これは、業界にとって、そして世界中のドライバーと乗客の安全にとって、大きなマイルストーンになります。

間もなく施行されるこの規制により、規模を問わず、自動車メーカーは無数の課題に対応することを求められます。こうした課題は、年間生産台数が1万台以下のような少量生産を行う自動車メーカーにとって、特に深刻なものとなる恐れがあります。 技術に精通したEVのスタートアップであれ、歴史のある商用車メーカーであれ、小量生産を行うOEMは、新しいサイバーセキュリティ要件を満たすために、いくつか独自のハードルを越えなければなりません。

少量生産を行うOEMがこの新しい世界を切り開くために、サイバーセキュリティの主要な課題を取り上げ、サイバーセキュリティ設計に優れた車両と管理システムへの移行を行いやすくするためのベストプラクティスについて以下にまとめました。小量生産OEM向けのcompliance starter kitの詳細は、リンクからご覧いただけます。

少量生産OEMは一様ではありません

サイバーセキュリティに対する意識と準備の観点から、ほとんどの少量生産を行うOEMは、一般的に2つのカテゴリーに分類することができます： 1）ニッチ市場を主なターゲットとする歴史のある少量生産OEM（例えば、ハイエンドの高級車メーカー、セメントミキサーなどの特殊用途車メーカー、バスなどの商用車メーカー）、2）生産プロセスにアジャイル開発とソフトウェア中心主義を取り入れている過去10年間に創業した電気自動車（EV）スタートアップ企業

当然ながら、歴史のあるOEMとEV新興企業はそれぞれ異なる能力と文化を持っており、サイバーセキュリティに対する準備や、自動車の開発、製造、管理/保守におけるサイバーセキュリティのコントロールとプロセスを適用する能力に違いがあります。EVのOEMは、サイバーセキュリティの課題の理解という点では従来のOEMより先行している傾向がありますが、自動車規制の要件を満たすために必要とされる体系的で、反復可能な、認可され得るプロセスという点では経験が浅いようです。

しかし、こうした違いにかかわらず、あらゆるタイプの少量生産OEMに共通するサイバーセキュリティ・コンプライアンスの課題は数多く存在します。

複数の攻撃対象領域における課題をプロファイルする

少量生産メーカーの現状と関係なく、自動車のサイバーセキュリティ・コンプライアンスは非常に負担が大きいものです。サイバーセキュリティに関する検討をせずに新車の開発を始めたケース、あるいは、認可された既存の車両を継続して販売するつもりのOEMのケースを考えてみてください。こうしたケースでは、予期せぬ新たな出費と遅延を伴う変更要求が発生する可能性があります。

組織的・技術的なサイバーセキュリティの要件は、車両型式承認や販売の前提条件となっています。UNR155は、車両のプログラムや管理システムにおいて、サイバーセキュリティを「あると便利」から「なくてはならない」ものへと変化させています。それに伴い、少量生産OEMは、サイバーセキュリティに関するエンジニアリング、運用、管理のすべてのタスクについて、自分たちが利用可能な能力を評価し、成長させています。 

少量生産OEMのタイプにより、課題は少しずつ異なります。技術に精通したEVのOEMは、ソフトウェア指向が強く、設計段階からサイバーセキュリティの必要性を認識しているかもしれませんが、歴史のある少量生産OEMに比べ、車両認証や自動車の市場投入に関する経験が少ない可能性があります。

いずれにせよ、歴史のあるOEMもEV新興企業も、サイバーセキュリティのノウハウやスキルセットを組織全体および車両プログラムに組み込んでいく必要があります。これらの要件を満たすために、OEMは能力を強化し、必要な作業や規模を評価し、コンプライアンスに向けた道筋を調整・計画する必要があります。

このような状況で、少量生産OEMは、人材と予算の二重の課題と向き合っています。自動車業界では、長い歴史を持つ企業であっても、利益の圧迫という課題に面していることは広く知られています。まだ第一世代、第二世代の自動車の販売規模を拡大していない新興OEMにとって、投資家の期待とサイバーセキュリティに関する追加の開発作業の必要性を整合させることは難しいかもしれません。

要件と投資額および能力の間にギャップがあるため、少量生産OEMは、サイバーセキュリティ担当ではないスタッフにサイバーコンプライアンスプロジェクトを任せています。多くの場合、機能安全や品質保証のマネージャーの責任範囲が増えることになります。

このアプローチは、一定のコスト感覚を保ちながら、新しい要件を満たそうとする努力を示しています。とはいえ、サイバー専門家ではない人に、サイバー関連の課題を克服するためのスキルやノウハウがすべて備わっているとは言えません。そのため、多くの少量生産OEMは、自動車サイバーセキュリティベンダーに目を向け、自社のニーズに合うような機能および製品を見つけて活用しています。

これらのベンダーと提携することで、少量生産を行うOEMは、プロセス導入や技術的対策の実施に関する経験を活用することができます。多くの場合、ベンダーは少量生産OEMが必要とするものを提供できます。例えば、要件を分析するための適切な知識ベース、サイバーセキュリティの実装作業（プロセスまたは製品）の経験、コンプライアンスの適用範囲および適切なリスク管理に必要なさまざまなサイバーセキュリティ対策（脅威監視、脆弱性スキャン、アクティブ検知、防御など）を提供できます。

少量生産を行うOEMにとってのベストプラクティス

上記の課題に効率的に取り組むために、少量生産OEMは、セキュアな自動車と製造組織を支援する以下の戦略を採用することができます。

1. 新しい規制要件並びに、業界の最先端基準を満たすために、「サイバーセキュリティマネジメントシステム」におけるサイバーセキュリティの方針、プロセス、および手順を実装しましょう。UNR 155は要件をまとめているかもしれませんが、ISO/SAE 21434とASPICEは、安全とサイバーセキュリティ開発のための追跡可能で再現性のあるフレームワークを示しています。

2. 車両、そのシステム、サプライチェーンに対する潜在的なサイバー脅威を理解するために、徹底したリスク評価を行いましょう。このような評価に基づき、適切なセキュリティ概念と要件を開発することができます。こうした活動に関するガイダンスは、ISO/SAE 21434サイバーセキュリティガイドに記載されています。

3. セキュアコーディング、ペネトレーションテスト、ファジングテスト、脆弱性管理、侵入検知・解析、VSOCなど、分野横断的にサイバーセキュリティの意識とベストプラクティスの採用を高めるため、従業員に研修・教育を提供しましょう。

4. サイバーセキュリティプロセスの確立、監視・分析目的のサイバーセキュリティコントロールの実装など、対象となる活動を加速させるために、ベンダーとの連携を検討しましょう。複数の自動車サイバーセキュリティ領域をカバーするような機能を提供するベンダーは、少量生産メーカーの担当者の時間とリソースを節約することができるかもしれません。

5. UNECEが認定した技術サービスや試験・検査・認証機関と連携しましょう。完成車であろうとコンポーネントシステムの開発であろうと、結果として最終製品におけるコンプライアンス勧告や決定を行うような組織から継続的にフィードバックを受けることは、非常に有益です。

6. すべてのソフトウェア材料、バージョン、アセットなどを含むデータベース、すなわちソフトウェア部品表（SBOM）を体系的に維持管理することにより、新規あるいは既存の脅威や脆弱性に対するリスクの程度を決定しましょう。メーカーは、最新のリスク分析を求められており、常に現場において、車両及び車両部品に対する既知の脆弱性を把握できるようにする必要があります。

7. サイバーセキュリティシステム、プロトコル、対策計画を定期的に見直し、更新し、継続的なコンプライアンスと進化するサイバー脅威に対する防御を確実なものにしましょう。新しいリスク、脆弱性、技術を想定した定期的なリスクアセスメントは、UNR155で要求されており、ライフサイクルを通して適切なリスク管理を行うためにも必要です。さらに、UNR155に準拠するために、OEMのCSMSプロセスは3年ごとに再認証が必要になっています。これは、新しい脅威や進化する脅威とともに、新しく得た知見が関連するリスク管理プロセスに組み込まれていることを確認するためです。

8. 新型車にセキュリティセンサーを搭載し、これらのセンサーとサービスレイヤインフラ（車両通信とコネクテッドサービス）から収集したデータを分析するために、クラウドベースのサイバーセキュリティを実装しましょう。これらの対策は、基本的なインシデント管理と報告、サイバー脅威の調査、攻撃の緩和のために重要です。
9. サイバー脅威、脆弱性、攻撃の特定と、セキュリティ関連の設定やコンポーネントをOTA（Over-the-Air）アップデートで更新する機能を両立させましょう。インシデントの影響を最小限に抑えるため、リンプホームモードや機能の無効化など、フリート全体の対応も検討しましょう。

10. セキュリティ関連データ（リスクアセスメント結果、テスト結果、要件文書など）の管理及び利用を支援するセキュリティ帳簿ツールを使用しましょう。一部のツールでは、リスク識別、影響分析、トレーサビリティなどの活動を自動化でき、効率性、知識の再利用、コンプライアンスの向上に役立てることができます。

11. アフターマーケットのハードウェア/ソフトウェアを通じて車両にもたらされるリスクに対処するため、アフターマーケット製品と互換性のある車両領域からの通信を検査しましょう。物理的な分離方法に加え、OS/ハードウェア/認証メカニズムなど、他の分離技術も確立しましょう。少量生産OEMの場合、この種のリスクは、車両の使用目的に応じた脅威分析の範囲で対処することが特に重要なことがあります。

まとめ

少量生産を行うOEMは、UNR155の規制を遵守し、堅牢なサイバーセキュリティシステムを開発する上で大きな課題に直面しています。これらの課題を軽減するために、ソフトウェア・デファインドなコネクテッドカーを提供するOEMがコンプライアンスを確保し、サイバー脅威のリスクを軽減し、事業継続を確保するために参考にできるベストプラクティスとガイドラインがあります。外部の専門家、サプライヤー、ベンダーと緊密に連携することで、つまりバリューチェーンの中にある利用可能なサイバーセキュリティのノウハウを活用することで、少量生産を行うOEMはサイバー脅威がもたらす課題を克服し、可能性のある新しいビジネスモデルの価値を最大化することができます。

The post 少量生産を行うOEM向けの自動車サイバーセキュリティのベストプラクティス appeared first on PlaxidityX.

バーチャル・アシスタントは、機械学習と自然言語処理を統合し、音声コマンドを受け付け、希望する動作（例：曲を再生する、アプリを開く、目覚まし時計を設定する）を実行します。スマートフォンに初めて搭載された最新のデジタル・バーチャル・アシスタントはSiri（2010年）で、すぐにAmazonのAlexa、MicrosoftのCortanaなどが続きました。その後、この技術はスマートホームにも導入され、スマートフォンのアプリからサーモスタットや照明などのIoT対応家電を遠隔操作するために、バーチャル・アシスタントが利用されるようになっています。 

こうしたAIを利用した技術が進化を続ける中（ChatGPTは最新の技術躍進を示しています）、分野を超えた革新的なソリューションに新たな可能性が広がっています。

Amazon Alexaが音声AIを自動車に導入

バーチャル・アシスタントが自動車に搭載されることは されることは、消費者にとって特別興味を引くことです。自動車が家庭やオフィスの延長となり、毎日何時間も運転席に座っているようなドライバーにとって、より生産的に過ごせるようになることが期待できます。

ドライバーが車と家の差を縮められるように、自動車メーカー（OEM）は、Siri（Apple CarPlay）やAlexaなどの音声起動型パーソナル・アシスタントを統合し、車両システムに接続するようになってきています。これにより、ドライバーは、家を出る前に遠隔でドアの施錠や開錠、エンジンの始動、車内温度の調整などを行うことができるようになります。また、慌てて家を出ることになった場合、Alexaが車のフロントシートから玄関の施錠、ポーチライトの点灯、警報システムの起動を行ってくれます。

運転中は、Alexaがルートを提案し、EVドライバーの最大の悩みである最寄りの充電ステーション探しをサポートします。Alexaは、充電ステーションまで案内してくれるだけでなく、簡単な音声コマンドでサービスの支払いも行います。

増加する自動車サイバー攻撃のリスク

ソフトウエア・デファインド・ビークルはもはや未来のものではなく、すでに製造されており、今後数年間の自動車産業に影響するでしょう。自動車1台あたりの平均ソフトウェアコード行数は、2015年の1億行から2020年には2億行と倍増しています（出典：ゴールドマン・サックス）。そして、電動化や自動運転車の普及により、この増加傾向は今後さらに加速するものと予想されます。

ソフトウェアが多用され、コネクテッドカーが増加すると、サイバーリスクにさらされる機会は増えます。車載ソフトウェアの脆弱性がサイバー攻撃につながり、自動車の重要な機能や機能安全（エアバッグ、ブレーキシステムなど）が損なわれ、人命が危険にさらされたり、リコールを余儀なくされる恐れがあるのです。

この1ヶ月の間に、複数の著名なグローバル自動車メーカーにおいて、基幹システムの遠隔操作やSSO認証の不適切な設定など、重大な脆弱性が発見されました。また、リサーチャーは、メーカー16社から販売されている数百万台もの自動車に影響を及ぼす、少なくとも20件のAPIの脆弱性を発見し、ハッカーが自動車の遠隔操作、追跡、移動、エンジンの始動・停止、個人情報の漏洩を行う可能性があることを明らかにしました。

現在の状況は、UN R155やその他の自動車サイバーセキュリティ規制で義務付けられているソフトウェアの脆弱性を検出・軽減する必要性とともに、サイバーセキュリティが重要になっていることを示しています。コードの各行、コネクティビティ、ソフトウェアを使用するサービス、OTAのアップデートには、OEMが適切なサイバーセキュリティ対策を講じることが必要です。

車両統合前のバーチャル・アシスタントのセキュリティ

Alexaやその他のバーチャル・アシスタントを自動車に統合することで、自動車の攻撃対象領域はさらに拡大します。これらのテクノロジ Alexaやその他のバーチャル・アシスタントを自動車に統合することで、自動車の攻撃対象領域はさらに拡大します。これらのテクノロジーは、多数の車両機能だけでなく、外部の接続デバイス（EV充電器、スマートホームなど）ともつながるため、車両に統合されたバーチャル・アシスタントには、サイバーセキュリティ対策が必要です。

Amazonは、この重要なセキュリティ原則をいち早く認識し、OEMがAlexaをIVIシステムに統合する前に従わなければならない厳格なセキュリティ要件を導入しています。

こうしたセキュリティ対策は、OEMが現在行っているUN R155の要件にシステムを適合させる取り組みと密接に関連しています。これには、サードパーティのソフトウェアに脆弱性がなく、車両の安全性やデータプライバシーにリスクが及ばないことを確認するためのセキュリティテスト・プロセスの実施が含まれます。

Alexa Auto統合のための最初のAmazon公認セキュリティラボ

Amazonのセキュリティ基準に準拠していることを証明するために、OEMはAmazonが認定するサードパーティラボの1つでセキュリティ評価を受け、合格することが義務付けられています。アクセス制御、ソフトウェア更新メカニズム、脆弱性管理などにわたる包括的なセキュリティ要件に対するOEMの能力が評価されます。

プラクシディティ エックス（旧アルガス）は、自動車に特化したセキュリティベンダーとして初めて、Alexa を自動車に統合するための公認セキュリティラボとしてアマゾンから認定されたことを誇りに思います。この認定により、車両システム内にAlexaを統合しようとしているOEMに対して、自動車に特化したセキュリティ・テスト・サービスを直接提供することが可能になりました。広範なドメイン知識、サイバーセキュリティのノウハウ、そしてペンテストの経験を活用し、プラクシディティ エックスのサービスチームは独立したセキュリティ評価を実施し、OEMがAlexa Auto統合に向けたセキュリティ要件を満たせるよう支援します。

The post Alexa（アレクサ）、サイバー攻撃から保護されていますか？ appeared first on PlaxidityX.

執筆：製品担当VP Michal Frenkel、VVM製品マネージャー Jonathan Legkov

OEMやティア1メーカーが、サイバーリスクにさらされる危険性を低減し、新たな規制や基準に準拠していくためには、自社のアセットにソフトウェアの脆弱性がないかを確認する必要があります。

これは簡単なことではありません。なぜなら、多くの場合、メーカーがサプライヤーから仕入れるAUTOSAR ECUコンポーネントのソフトウェア構成に通じていないためです。車には一台につき、複数のサプライヤーが供給するECUが100以上も組み込まれているため、こうした可視性の欠如は重大なサイバーリスクとなります。

メーカーはこの問題を克服するため、AUTOSAR ECUの内部の「隠れた」ソフトウェアモジュールを可視化し、関連するコードをスキャンし、脆弱性を検出する方法を模索しています。

AUTOSARはセキュリティ上の盲点となっています

2003年に発足したAUTOSARは、業界全体におけるECU開発の事実上の基準となっています。AUTOSARによりOEMおよびティア１サプライヤーの共通ソフトウェアアーキテクチャが確立され、ECUソフトウェアの品質が向上し、開発にかかる時間やコストが削減されています。

今日に至るまで、ほとんどのメーカーはAUTOSAR ECUを「ブラックボックス」とみなし、その内部のソフトウェア構成についての知識を持つことなく、自社のニーズに合わせてECUのプログラミングを行ってきました。一般的なECUには複数のティア１およびティア２サプライヤーからの数十におよぶソフトウェアライブラリが含まれています。その全てにメーカーにとって「目に見えない」脆弱性が潜んでいる可能性があるのです。

セキュリティの観点から見ると、自動車業界は、伝統的にAUTOSARの閉じられたシステムデザインコンセプトに依存し、ECUの安全性を保持してきました。インフラストラクチャのコンポーネントを曖昧にすることによって、これらのコンポーネントへの攻撃から守られると想定されていました。

しかし、ECUがインターネットにつながり、車両におけるソフトウェアの重要性が増している現在、これらのAUTOSAR ECUはサイバーセキュリティの盲点となっています。攻撃者がコネクティビティを利用し、「隠された」ECUライブラリ内の脆弱性を発見して侵入し、車両ネットワーク内の ECU 間を横方向に移動するのは簡単なことです。

AUTOSAR の脆弱性をスキャンする必要性

サプライヤーから提供されるソフトウェアの脆弱性を確認しないことによる潜在的コストと安全上のリスクは甚大です。ソフトウェアの脆弱性は、重要な車両機能や機能安全性（エアバッグ、ブレーキシステムなど）に影響をおよぼす可能性があり、人命を損なう危険性や、費用のかさむリコールにつながることがあります。

さらに、UN R155やISO 21434といった新たなサイバーセキュリティ法規に準拠するには、自動車メーカーは、ティア1およびティア2サプライヤーから提供されるコードを含め、車両ソフトウェアの脆弱性を特定し、軽減する必要があります。そのためには、OEMおよびティア１はサプライヤーから受け取ったコードを理解し、コードに脆弱性がないか確認する必要があります。すでに述べた理由から、AUTOSAR ECUに関しては、これが非常に難しくなっています。

業界が脆弱性管理の要件を満たすための措置を講じているため、OEMおよびティア１は、ブラックボックスの蓋を開け、AUTOSAR ECUのソフトウェアモジュールを正確にマッピングし、それらのモジュールに既知の脆弱性がないかをスキャンすることが可能な、新たなツールを開発プロセスに取り入れようとしています。

プラクシディティ エックスのAUTOSAR SBOM Extraction ソリューションの導入

プラクシディティ エックスの新たなAUTOSAR SBOM Extraction機能は、シームレスにPlaxidityX Vehicle Vulnerability Management （VVM）に統合されており、ECUコードの限られた可視性に対応するように設計されています。

PlaxidityX VVMは現在独自の技術を用い、詳細なバージョンやベンダー情報を含め、AUTOSAR ECUからすべてのSBOMを抽出することが可能です。SBOMが抽出されると、脆弱性が自動的に検出されて優先順位が付けられ、ECUに影響をおよぼす脆弱性に迅速に効率よく対応することが可能です。以下は一般的なワークフローの例となります。

1. SBOM Extractionプロセスにより、ECUのすべてのSBOMのリストが自動的に作成されます。

   

2. 公開済みの脆弱性および非公開の脆弱性について、VVMが各ライブラリのスキャンを行い、深刻度に応じてそれらの脆弱性に順位付けがなされます。
   

   

3. VVMを用いて、各脆弱性をECUおよびアセットと関連付けを行い、緩和対策をサポートします。

   

4. ティア1およびOEMが、緩和対策の一部として当該の脆弱性にパッチを当てる方法や時期を決定します。

SBOM Extraction以外のソリューション

プラクシディティ エックスは、SBOM 抽出、バイナリ分析、脆弱性スキャン、アラートの優先順位付け、アセット管理などを含む包括的なVVMソリューションを提供することにより、ティア1およびOEMの車両脆弱性管理におけるあらゆる課題に対応できるようサポートします。

ユーザーはPlaxidityX VVMを使用することにより、どの車両の、どのECUの、どのソフトウェアパッケージが脆弱性の影響を受けているか、各脆弱性の正確なインパクト分析と合わせ、即座にインサイトを得ることが可能です。

AUTOSAR ECUやその他の車両ソフトウェアに脆弱性管理のための高度な自動ツールを導入することで、ティア1サプライヤーおよびOEMは、サイバーセキュリティ対応を向上させ、型式認証の規制要件に準拠することができます。

お客様の脆弱性管理の課題に対するプラクシディティ エックスのサポートについての詳細は、 PlaxidityX Vehicle Vulnerability Management をご覧ください。

The post PlaxidityX VVMにAUTOSAR Automatic SBOM Extraction機能を追加 appeared first on PlaxidityX.

By Ronen Smoly, CEO, PlaxidityX（旧アルガス）

２０２２年９月 Automotive World, に掲載

ピカピカの新型テスラで出勤し、朝のコーヒーを味わっていると、突然、エンターテインメントシステムがフルボリュームで音楽を流し始め、ヘッドライトが点滅し始めます。あなたはラジオを消しましたが、まるで自分の意思を持っているかのように、再びラジオがつきますます。スピードを落としてドアを開けようとしても、またロックがかかってしまいます。

サイエンスフィクション？そうではありません。

2022年1月、19歳のITスペシャリストによって25台のテスラが同時にハッキングされ、一部のテスラオーナーが使用しているサードパーティアプリの脆弱性が突かれました。この脆弱性を利用し、ハッカーはサードパーティーのサーバーから上記のような悪戯を行い、世界中にある車両の位置を追跡することができたのです。

しかし、このハッキングは氷山の一角に過ぎません。サードパーティのアプリを通じて25台の車両を危険にさらすことが可能だとしたら、サイバー犯罪者が車両全体を遠隔操作し、車両のロックを解除するために巨額の身代金の支払いを要求した場合の結末を想像してみてください。ランサムウェアの攻撃は猛威を振るい続けており（2021年には世界で3億件）、そのようなシナリオの可能性はますます高まっています。

テスラがハッキングされた事実を軽んじるべきではありません。この先進的な企業は、モビリティ市場の未来を象徴し、自動車技術に関して言えば「最先端」を象徴しています。特にサイバー攻撃に関しては、テスラに発生した出来事は、同じように技術のアップグレードを目指す「従来型」自動車メーカーにとっても劇的な影響を与えます。

コネクティビティ＋ソフトウェア＝リスク

では、なぜ私たちの大切な車がサイバー攻撃の標的になったのでしょうか。

過去10年間で、モビリティ市場は大規模なデジタル変革を遂げました。現在では、ほぼすべての自動車に、情報を受発信するためのコネクティビティ・オプションが組み込まれています。

しかし、ソフトウェア・ドリブンのコネクテッドカーの便利さを、コストなしで得ることはできません。30年前にコンピュータの世界で起きたことを思い出してみてください。コンピュータがネットワークにつながるようになると同時に、新しい脅威に対して脆弱になりました（現在では、どの企業もネットワークを保護しています）。同じことが、今日のモビリティ市場にも当てはまります。

自動運転車、クラウドベースの機能、シェアモビリティなど、自動車産業における現在のメガトレンドは、自動車をより大きなサイバーリスクにさらしています。自動車はすでに世界で8番目にサイバー攻撃者から狙われている分野であり、コネクテッドカーはメーカーのITシステムや設備に侵入するための新たな攻撃対象になる可能性があります。

電気自動車や自動運転車の新技術をサポートするために、自動車業界はソフトウェア開発に膨大なリソースを投入しています。自動車メーカーは、これらのソフトウェア・コンポーネントを完全に制御することを望んでおり、拡大する高度な攻撃対象から車両を保護するための複雑さは増しています。さらに、現在のビジネス・アーキテクチャへの統合、より大きな攻撃対象領域、膨大なデータ量（25GB/1時間/１台当たり）により、今後数年間でサイバーリスクがさらに高まると予想されます。

自動車の将来は、技術中心、ソフトウェア中心のアプローチになり、新機能や機能アップグレードはソフトウェアアップデートによって提供されるようになります。自動車が工場から出荷された後、サイバーセキュリティの更新を含む継続的な機能拡張を提供できることが、自動車メーカーにとって今後の重要な競争要件になるでしょう。

機能安全とサイバーセキュリティの連携

自動車業界は、シートベルト、エアバッグ、事故防止用レーダーなど、常に安全を第一に考えてきました。しかし、自動車がコネクテッド化、自律化、ソフトウェア主導化するにつれ、安全とセキュリティは相互に依存するようになってきています。つまり、システムが機能的に安全であるためには、セキュアであることも必要なのです。

ネットワークやデータの保護に重点を置くITセキュリティとは異なり、自動車のサイバーセキュリティは運転手や乗客の安全に直接影響します。自動車ソフトウェアの脆弱性は、その発生源（サプライチェーン、OTAアップデート）に関係なく、サイバー攻撃によって自動車のブレーキシステムやエアバッグシステムが危険にさらされ、生命を脅かす結果になる恐れがあります。

変化する世界のためのサイバーセキュリティ

今日の自動車は、サイバー攻撃から十分に保護されているとは言えません。この業界は非常に動きが大きく、新しいソフトウェアベースの機能やアプリが常に開発されており、また充電ステーションなどの新しいインターフェースも開発されているため、高度な攻撃ベクトルへの新たな入り口が開かれることになります。

自動車の安全性を確保し、UNR155やGB/Tなどの自動車業界の新しいセキュリティ規制に準拠するため、自動車メーカーやティア1サプライヤーは、高度なサイバー脅威から身を守るための高度なサイバーセキュリティ・ソリューションに投資しています。

最初のステップとして、自動車メーカーとそのサイバーセキュリティパートナーは、エンドツーエンドの車両アーキテクチャ全体の徹底的な脅威分析に基づいて、車載セキュリティ制御の要件を特定し、指定する必要があります。車載制御（ネットワーク監視など）は、セキュリティ・インシデントを監視し対応するためのバックエンド技術（車両セキュリティ・オペレーション・センターなど）によってサポートされるべきです。現在、自動車メーカーが導入している最も一般的な機能には、ネットワークトラフィックの監視とフィルタリング（CANやイーサネット侵入検知システムなど）、アプリケーションのハード化と監視、機能の分離・分別の厳格化などがあります。

さらに高度な技術やツールとしては、車両レベルでの異常検知とレポート、車両ソフトウェアの反復的な脆弱性スキャン、バックエンド分析、安全なソフトウェア更新メカニズムなどが検討されるべきでしょう。

サイバー脅威を新たなビジネスチャンスに変える

自動車は、様々な意味で、家庭やオフィスの延長線上にあるような存在になっています。人々は毎日何時間もかけて通勤し、車からスマートフォンを使って私生活を管理しています。スマートフォンを使用する際にプライバシーを犠牲にするのと同様に、今日のコネクテッドカーは、私たちの位置を把握し、何をしているか情報を聞いて収集し、車内に配備されたカメラ、センサー、マイクはもちろんのこと、最もプライベートなデータにもアクセスすることができるのです。

こうしたセキュリティやプライバシーのリスクが高まるにつれ、消費者が自動車のサイバーセキュリティ機能を、バッテリーサイズや動作範囲、充電時間と同じくらい気にするようになる日もそう遠くはないでしょう。このことは、自動車メーカーがサイバーセキュリティを収益化する新たな機会をもたらす可能性があります。例えば、何千万もの侵入検知装置を自動車に内蔵したり、ドライバーや車両が生成するデータのリアルタイム分析に基づく付加価値の高いデータサービスを提供したりすることが考えられます。

今後、自動車のサイバーセキュリティは、自動車だけでなく、モビリティのエコシステム全体を包含する必要があります。技術の進歩に伴い、充電ステーション、盗難防止ソリューション、セキュアな接続、車両とクラウドの間、スマートシティの設備との間、その他のインターフェースの間のデータ保護など、新しいサイバーセキュリティ・ソリューションとサービスが必要になるでしょう。

テクノロジーは時として諸刃の剣です。10代のハッカーに聞いてみてください。

The post 未来のコネクテッドカー技術：諸刃の剣 appeared first on PlaxidityX.

従来のペンテストが手作業によるプロセスである一方、ファジングは自動化されたプロセスです。ファジングテストでは、ターゲットを混乱させることを目的に、スクリプトを用いてさまざまな加工データを大量にインプットします。

ファザーはターゲットとなるさまざまなコンポーネント（コード、バイナリライブラリ、インターフェイス）を分析し、カスタマイズされたインプットを作成し、最適なテストカバレッジを得ることができます。優れたファジングツールを利用すると、ペンテスターには再現できない大量のインプットでシステムを過負荷の状態にし、リサーチャーが１度のリサーチでは発見できない脆弱性を発見することができます。しかし、ファジングには限界があります。ファジングテストではシステム（ECUなど）を過負荷状態にし、その反応を見ますが、ペンテストはインプットによる過負荷ではなく、既知の脆弱性またはゼロデイ脆弱性を利用して攻撃対象領域への侵入を試みます。

自動車業界の開発パイプラインは、通常、要件の収集から実装、発売まで、下記の図1のようになっています。ご覧のように、図中のテストステージには、手作業によるペンテストに加え、下記の2つのファジングテストが含まれています。

• コードファジング
• インターフェイスファジング

図1 – 自動車業界の開発パイプライン

この記事では、自動車メーカーが規制を遵守し、最適な車両サイバーセキュリティ基準を達成するために、ファジングを導入してペンテストを補完する理由について説明します。

コードファジング

コードファジングは、多くのさまざまなインプットにより特定の機能を実行するテクニックです。ファザーはサニタイザーを使用して、バッファオーバーフロー、メモリリーク、およびその他の潜在的な問題を検出します。コードファザーは、ソフトウェアのコードブロックすべてに（パフォーマンス測定のための）インストルメンテーションを配置して、ファジングにより得られたカバレッジを確認したり、さまざまなソフトウェアフローがカバーされるようインプットを変化させたりします。

オープンソースファザーには、一般的なAFL、libfuzzer、SymCC、Qsymなどがあります。自分のプロジェクトとソースコードファザーを統合する手法は、開発者がモジュールを開発または変更する際にファジングラッパーを維持しなければならないという点で、ユニットテストの実施と非常に似ています。プロジェクトの初期からファジングを実施することで、その後のメンテナンスを容易かつ円滑に行えるようになります。

インターフェイスファジング

その名が示すように、インターフェイスファジングでは、システムの特定のインターフェイスをテストします。ツールはプロトコルアウェアで（さまざまなプロトコルの、さまざまなレベルにおいて）、関連するカスタマイズされたインプットを用いてそれぞれのコンポーネントインターフェイスをテストすることが可能です。インターフェイスファジングが、ECUのコンパイル可能な環境と統合されると、ファジングによって得られたカバレッジを追跡することができます。

ステートフルプロトコルのインターフェイスファジング

ステートフルプロトコルはTCP、HTTPといったセッション情報を保持するプロトコルであり、IPはステートレスプロトコルです。それぞれのリクエストメッセージは個別に理解されます。ステートフルプロトコルはファザーの効率性に影響をおよぼします。ハンドシェイクで始まる標準的なプロトコル（TCPなど）を思い描いてみてください。最初のハンドシェイクを成功させることができないファザーは、多くのコードフローの可能性を見逃してしまうことになります。

インターフェイスファザーはブラックボックス手法であり、高い効率性やカバレッジを得るには、開発者やリサーチャーによる設定や指示が必要です。

プラクシディティ エックス（旧アルガス）のインターフェイスファジングは、さまざまなネットワークスキーム（ARXML, DBC）を分析し、そのスキームに基づいたさまざまな攻撃をシミュレートすることが可能です。また、当社のツールは以下のインターフェイスやプロトコルに対応しています

• イーサネット標準プロトコル、SOME/IP, DoIP, HSFZ, AVB
• CAN ISO-TP, CAN-FD, UDS (LINおよびFlexRay上でも対応)

コードファジングおよびインターフェイスファジングは、次のテスト段階であるペンテストとは異なり、CI環境に統合することができます。

侵入テスト（ペンテスト）

自動化テストやファジングは、バグや脆弱性の検出を効率良く行うことのできる革新的な手法ですが、こうした自動化テストは、システムが悪用されないことを確認するための手作業によるペンテストに置き換えられるものではありません。自動的にECU攻撃対象領域をマッピングし、すべてのサーフェースコードのフローをリバースエンジニアリングし、プリミティブを見つけてそれらを統合し、サイバー攻撃のリサーチオペレーション全体を管理できる方法は未だにありません。

システムの持つセキュリティ手法（セキュアブートやソフトウェアハードニングなど）の完全性を検証するには、経験豊富なリサーチャーによる作業が必要です。このため、開発サイクルの最後の方で、ECUに対してサイバーセキュリティリサーチャーの手作業によるペンテストを実施する必要があるのです。当社では、UNR 155 （WP.29）を遵守し車両サイバーセキュリティを最適化するために、ファジングとペンテストの両方を実施することを推奨しています。

Ohad Peled
PlaxidityX、エンベデッドセキュリティリサーチ・チームリーダー

ブログ編集者より：ファジングまたはペンテストに関するリクエスト、お問合せは、ページ上の「お問合せ」リンクよりご連絡お願いします。

The post 最適な車両サイバーセキュリティのため、ファジングを用いて侵入テストを補完する方法 appeared first on PlaxidityX.

自動車がますますインターネットとつながり、ソフトウェアが多用されるようになる中、UNECE R155もきっかけとなって、自動車にペンテストを実施することは、サイバーリスクを低減したいOEMやティア1にとって不可欠な作業となりました。当社ではOEMやティア1から依頼を受け、何十ものペンテストプロジェクトを実施し、100％の成功率で侵入を達成してきました。これを受け、読者の方が今後ペンテストを最大限有効なものにできるよう、以下の自動車ペンテストの必須事項をまとめました。

自動車ペンテストの必須事項1：時間を賢く使ってペンテストを行うこと
ペンテストとは自動車への侵入が目的なのであり、むやみに何かを探ることではない

OEMやティア1は、ペンテストを実施するチームにテスト対象についての情報をほとんど提供せず、テストを難しくすればするほど、最大の効果を得られるという誤解をしがちです。ブラックボックスプロジェクトとして一般に知られていますが、これはテストの際、リサーチャーに対象となるコンポーネントの情報をまったく与えないで行われるプロジェクトのことです。

しかし、ハッカーは意志が強く、最終的にシステムをハッキングしてしまうので、ハッキングは時間の問題です。重要なのは、コードにどのような脆弱性が存在しているか、またハッカーがその他のセキュリティの欠陥を発見するかです。これを見つけることがペンテストの真の目的です。

一例ですが、当社のペンテストチームがテレマティクスユニットのテストを依頼されました。チームはコードをテストするために、何週間もかかってユニットのファームウェアを抽出し、そのソフトウェアをリバースエンジニアリングし、逆コンパイラを構築しました。リサーチャーたちはこの課題を楽しんでいたものの、脆弱性ではなく、テレマティクスユニットのコードを入手するのに貴重な2週間を費やすことになりました。最終的に、チームは複数の脆弱性を発見しましたが、もっと時間を有効に使えば、1か月かけてより多くのセキュリティの欠陥を見つけ出し、そのユニットのサイバーセーフティを高めることに貢献できたはずでした。

自動車ペンテストの必須事項2：重要な情報をペンテスターと共有する
何を保護すべきかの情報がなければ、テスターは何をテストするか推量しなければならない

脅威分析およびリスク評価（TARA）のプロジェクトにおいては、車両のアーキテクチャ、システム、そして様々なECUについて、サイバー脅威に対する評価を行います。脅威分析では脅威を特定してモデル化し、リスク評価ではそれぞれの脅威に関連する影響やそれが実際に起きる可能性を分類します。これにより、OEMは車両設計および開発プロセスのごく早い段階で車両のセキュリティ状況について理解することができます。

OEMおよびティア1は、当該の情報が無関係である、あるいは機密であると思い込み、ペンテスターにその脅威評価を伝えないことがあります。

しかし、情報共有を徹底することは最善の結果につながります。前回の脅威評価に基づいてペンテストを実施した場合、テストチームは優先順位の高い脅威に集中して取り組むことができます。脅威評価レポートを共有しないことによって、ペンテストチームはテスト項目の決定とそれに対する評価を行い、これに対して支払いが発生します。

自動車ペンテストの必須事項3：他のプロジェクトと同様に取り扱う
準備に失敗するということは、失敗する準備をしているようなものである

テストを実施する企業も、プロジェクトを主導するOEMも、ペンテストを他のプロジェクト同様に管理する必要があります。

プロジェクトは、例えば、要件分析、テスト範囲の決定、テストストラテジー、必要なツールの決定、見積もり、プロジェクト計画など、複数の段階からなっています。これらはすべてペンテストプロジェクトを成功させるのに不可欠なステップです。当社のペンテストチームは記憶に残るあるペンテストプロジェクトから、事前の準備の大切さを学びました。チームはセルラーネットワークにつながっておらず、コネクテッド機能がすべて無効になった状態のユニットのペンテストを依頼されました。この見落としによって2か月の遅延が生じましたが、これは回避することができたはずでした。

車両ペンテストはプロジェクトであり、どのような複雑なプロジェクトにも適切な計画が必要と言えます。

自動車ペンテストの必須事項4：やめ時を知る
どこまでもやらなければならない、ということではない

通常のペンテストプロジェクトでは、発見された脆弱性をすべてマッピングした後、OEMまたはティア1の要件に基づき、ペンテスターがそれらを用いて侵入を試みることがあります。脆弱性を利用するには、多くの時間や資源がかかります。さまざまな攻撃を実証するにはペンテスターは自らの経験や直感を駆使する必要があるからです。

前述したように、ハッカーは発見した脆弱性の悪用に最終的には成功するものなので、ペンテスターとしては、付加価値が得られることが明らかな場合にのみ、脆弱性を活用するべきです。例えば、ほとんどのケースで既によく知られている攻撃の影響を経営陣に証明する必要がある場合などです。

ペンテストの目標を事前に決めておき、それを達成したところで終わりにすべきです。

自動車ペンテストの必須事項5：想定外！に備える
最善を期待し、最悪の事態を予測し、想定外に備える

自動車のペンテストプロジェクトでは、既に販売されている車両の脆弱性をリサーチャーが発見する可能性があるため、OEMやティア1にとって深刻な事態となる場合があります。OTAによるセキュリティアップデート機能がない場合、自動車メーカーはサイバーリコールをしなければならず、そうなれば重大な財政的損失やブランドイメージの低下につながりかねません。自動車メーカーがペンテストプロジェクトを実施する際には、常に最悪の事態に備え、インシデント対応計画を定めておく必要があります。

自動車ペンテストの必須事項6：組織内での期待値のズレをなくす
共有は、思いやりである

OEMやティア1は多くの大企業が直面しているのと同じ、「効果的な知識の伝達」という課題を抱えています。ある部署がペンテストプロジェクトを実施しても、その結果が社内で共有されないことも少なくありません。

当社のリサーチチームは、ある地域のティア1から、あるユニットのペンテストを依頼されました。後になってわかったのですが、このテスト結果は、このユニットに関わっている別の地域のチームにはまったく伝えられていませんでした。社内で知識の伝達が行われないのは非効率なことであり、テストの対象となったユニットのセキュリティ状況を改善するという目標に近づくことができません。

プラクシディティ エックス（旧アルガス）のリサーチチーム一同、上記のアドバイスがお客様のペンテストプロジェクトのお役に立つことを願っています。今後のペンテストプロジェクトについてのご相談や、関連するご質問があれば、お問合せフォームからご連絡ください。すぐに当社から折り返しご連絡いたします。

The post 自動車の侵入テストにおける6つの必須事項 appeared first on PlaxidityX.

自分たちのネットワークにマルウェアが存在しているか、わからない。ハッカーたちがこちらでは把握していない脆弱性を発見しているかどうか、わからない。次に対応することになるセキュリティの問題がわからない。平均的な金融企業や商社では1か月に複数回の攻撃を受けていますが、そうした企業がデータ侵害を検知するまでに6か月以上かかるのが実情です。

そう聞くと、CISOの仕事は特別ストレスフルでもないと思われる方もいるかもしれません。しかし、こと自動車業界のCISOについて言えば、現在新たな、そして自動車業界に特有の数多くの困難な課題に直面しているのです。

言い換えると、昨日の自動車業界CISOの責務が会社のITシステムの保全だったとして（これはこれで大変な仕事ですが）、今日の彼らは、昨日までの責務と同等のレベルでコネクテッドカーや車両データサービスに対する責任を負っています。そしてこれは、乗員の安全や人命の保護に関わる問題と言えます。

では、これらの課題は正確にはどういうものなのでしょう？そして、それらは従来のIT業界の課題とどう違うのでしょうか？

自動車業界に特有の10の課題

新たなエコシステム

1. 複雑な製品＆サプライチェーン

自動車は非常に複雑な製品です。ECU数の急激な増加を受け、今日の車両ソフトウェアは1億行ものコードを実行していますが、コーディング規約が不十分になりがちで、脆弱性が発生しやすくなっています。さらに、さまざまなサードパーティーサプライヤーが3万にものぼる部品を製造しており、このことが、保護しなければならないエンドポイントに大きな影響を及ぼしています。このサプライチェーンの状況により、数多くのサイバーセキュリティリスクが生じ、それらを管理する必要があります。例えば、1つのECUに脆弱性が発見された場合、フリート全体に影響が及ぶ可能性があるのです。

2. 自動車技術

自動車業界には、従来のITシステムが対応していない特有の技術があります。例えば、自動車はVINによって識別されるのに対し、サーバーはホスト名で識別されます。また別の例としては、ITではTCP/IPが使用されていますが、自動車のネットワークにはCAN-BUSが使用されています。

3. 新たな規制

自動車業界は多くの規制が設けられている業界であり、自動車メーカーは新規の規制、ガイドライン、義務要件に対して綿密な注意を払うことが求められます。例えば、国連欧州経済委員会 （UNECE）は、自動車サイバーセキュリティとソフトウェアの更新に関する「WP.29」を、米国では国家道路交通安全局 (NHTSA) が自動車サイバーセキュリティに関するガイドラインを発表しています。

4. 自動車の製品寿命の長さ

自動車は実際に販売されるまで、約2 ～5年かけて設計されています。つまり、工場から出荷される頃には、その車両に搭載されたサイバーセキュリティソリューションが時代遅れになっている可能性があります。さらに、製品寿命が長くても6年ほどのITデバイスと異なり、自動車の製品寿命は最大15年ほどにおよびます。そのため、自動車は量産の段階において、より長期にわたるサイバーセキュリティ保護が必要となります。これは、CISOが対応しなければならないもう1つの重要な課題です。

5. スケーラビリティに関する懸念

以前にも述べたように、平均的なOEMのフリートは2000万台におよびます。これは何百万ものエンドポイントを保護しなければならず、何千ものアラートに対応しなければならないということを意味します。現状では、IT SOCチームはこれほど大容量のデータとセキュリティイベントに対応できない恐れがあります。

セキュリティ業界でよく知られたもう1つの問題は、機械学習に関するものです。汎用型機械学習アルゴリズムは膨大な数の異常や誤検知をしてしまい、その結果SOCチームに非常に多くの的はずれなアラートが押し寄せることになります。一方、自動車に特有の異常を検知するよう設計された機械学習アルゴリズムでは誤検知の数が減り、その結果アラート数も減少します。

6. 位置情報データ

自動車は、車輪のついたデータセンターと言えます。そしてそこで収集されるデータの1つが位置情報です。これはサーバーが移動しないIT業界ではまったく馴染みのない性質のデータです。
例えば、自動車がある位置でデータの送受信ができなくなることがあり、その場合、自動車からSOCチームへのデータ送信に遅延が生じる可能性があります。位置情報に関するもう1つの一般的な問題は、攻撃者が自動車の近くにいる場合、自動車のBluetooth接続をハッキングしやすいことです。

SOCの能力

7. 専門知識の欠如

自動車を保護するためには、SOCチームは自動車サイバーセキュリティを深く理解するだけでなく、自動車に関連する分類体系、業界の変化、規制、テクノロジーについての知識も最新の状態に保つ必要があります。現在、IT SOCを運用しているチームにはこの分野での専門知識が欠如しており、そのため調査プロセスに多くの時間がかかったり、OEMが長時間にわたって攻撃のリスクにさらされたりする可能性があります。

8. 定められたプロセスとツールの欠如

IT SOCが直面する別の課題は、自動車のセキュリティ状態を監視するためにデザインされた専用のプロセスとツールの欠如です。現在、脅威が特定された場合、OEMは顧客に新しい部品を取り付けてもらうか、自動車を修理ショップに持っていってもらわなくてはいけないという大きな課題を抱えています。また既存の技術に関して言えば、従来のIT SOCツールはこれほど大容量のデータを持つ何百万というエンドポイントを管理できるようには設計されていない、という問題があります。

攻撃の影響

9. ダメージレベルの大きさ

現在、大企業では1社で何十万台ものコンピューターを所有しているわけですが、OEMフリートは1社で、路上を走行する2000万台以上の自動車を抱えており、自動車には保護しなければならないドライバーや同乗者が乗っています。車載ECUの一般的な脆弱性を標的にしたサイバー攻撃があった場合、人命、資産、ブランドイメージの毀損コストを考えると、想定される影響は破滅的と言える程大きなものになります。

10. 緩和にかかる時間＆複雑性

IT SOCが脅威を検知した場合、エンジニアは直ちに脅威を緩和するため必要なものすべてにアクセスすることができます。しかし自動車セキュリティの場合、ECUに脆弱性が検知された際には、緩和は複雑でより時間がかかり、ティア1のサポートと無線経由（OTA）でのアップデートが必要になります（下記の図を参照）。

フローチャート: 自動車におけるソフトウェア更新プロセス

課題解決に向けた取り組み

ハッカーの手法がより洗練されたものになっている昨今、これらの様々な課題に取り組むために、OEMには経験豊富な人材や、専用のプロセスおよびツールが特に必要です。

残念ながら、従来のIT SOCには、ツールキット、ノウハウ、車両やフリートに対する効果的でスケーラブルな保護を提供するのに必要なフレームワークが欠如しています。これに対応するため、自動車業界のCISOは業界のニーズにあった新たな解決策を検討しています。そうした解決策の中には、「車両SOC（VSOC）」を含む形でのセキュリティオペレーションの拡大が挙げられます。今後のVSOCに関するブログ記事も参照ください。

著者：Sapir Segal
PlaxidityX（旧アルガス）、プロダクトマーケティングマネージャー

The post 自動車サイバーセキュリティを担う自動車CISOが直面する最も重大な10の課題 appeared first on PlaxidityX.