JP6762347B2 - 交通手段に対するコンピュータ攻撃を阻止するためのシステムおよび方法 - Google Patents

Description

本開示は、コンピュータセキュリティの分野、より具体的には、車両の電子システムのコンピュータセキュリティに関する。

現在では、自動車、車両、および交通手段全般へのコンピュータ攻撃の可能性が絶えず増大しており、車両のコンピュータシステムや電子システムに対する依存が高まるにつれ、そのような攻撃の数も増加している。そのため、コンピュータ攻撃を成功裏に検出して対応できるシステムを構築することが緊急課題である。

コンピュータ攻撃が自動車の内部装置（主として、電子制御ユニット（Electronic Control Unit：ＥＣＵ））に対して行われた場合、攻撃の検出に成功したとしても、その影響を無効にすることのできる適切な処置を講じることは極めて困難である。

そこで、セキュリティの専門家であるチャーリー・ミラー（Charlie Miller）とクリス・ヴァラセク（Chris Valasek）は、自動車のセキュリティをテーマにした数々の著作を発表した。”Adventures in Automotive Networks and Control Units”と題する白書の中で、このセキュリティの専門家たちは、ノート型パーソナルコンピュータとニンテンドー（Nintendo）（登録商標）ゲームパッドを使って、コントローラエリアネットワーク（Controller Area Network：ＣＡＮ）バス上のパケット送信を伴う、ＥＣＵに対するコンピュータ攻撃を行って、2010年式トヨタ・プリウス（Toyota Prius）（登録商標）と2010年式フォード・エスケープ（Ford Escape）（登録商標）をコントロールする方法を説明している。また、2015年8月10日発表の”Remote Exploitation of an Unaltered Passenger Vehicle”と題する別の論文に説明されているように、ミラーとヴァラセクは、自動車の車載マルチメディアシステムの脆弱性を利用して、Wi-Fiで自動車のネットワークに侵入し、2014年式ジープ・チェロキー車（Jeep Cherokee）（登録商標）のハッキングに成功した。携帯電話事業者、スプリント（Sprint）（登録商標）の通信ポートにおける脆弱性がもう１つのエントリポイントとなった。自動車の電子システムをコントロールするために、調査員たちは、特殊なプログラムコードを導入することでＣＡＮバスのコントローラのファームウェアを改変して、ＣＡＮバスに対するコンピュータ攻撃を行った。調査員たちは、このコンピュータ攻撃によって、自動車のステアリングホイール、ブレーキシステム、およびその他の電子システムの動作を遠隔制御することができた。この調査の結果、現実に、フィアットクライスラーアメリカグループによる140万台の2014年式ジープ・チェロキー車のリコールに至った。

しかし、自動車産業における更新サイクルは長期間を要するため、自動車の電子システムの脆弱性が発見された場合、更新版をリリースして自動車の電子システムに搭載するには比較的長い期間を要する可能性があり、自動車をリコールすることも必要になる可能性がある。一方では、旧モデルの自動車はまったく更新されないこともあるため、脆弱性にさらされる可能性がある。したがって、自動車メーカーが自動車の電子システムを更新することによって脆弱性を取り除くよりも前に、そのようなコンピュータ攻撃を検出して阻止できる解決策を開発することが必要となる。

既存の侵入検知システム（Intrusion Detection System：ＩＤＳ）は、自動車のバス上に伝送されるデータの異常を発見することができる。しかし、ＩＤＳの動作は大規模な統計的データベースの集合体を必要とするので、そのようなシステムは、例えば上記のような複雑な標的型攻撃を効率的に検出することはできない。しかし、まさにこれらの種類のコンピュータ攻撃が最大の危険をもたらすものである。また、既存の侵入検知システムを車両のネットワークアーキテクチャに容易に適応させることはできない。例えば、ＣＡＮプロトコルのブロードキャスト的性質のために、送られたメッセージを受信するＥＣＵは、それが攻撃者からのものか、予想したＥＣＵからのものかを知ることができない可能性がある。

注目すべきことは、コンピュータ攻撃が成功して、道路交通事故（Road Traffic Accident：ＲＴＡ）などの、重大な結果になったときは、たとえその攻撃を事前に検出して防止できなかったとしても、その（例えば、ＲＴＡなどの）インシデントの原因に関する情報が極めて重要であるということである。この情報は、将来、そのようなインシデントを防止する手段の開発を可能にするので、自動車メーカーにとっても、そのインシデントの調査を行う当局にとっても、非常に貴重である。留意しなければならないことは、インシデントの発生後の調査段階で、それがコンピュータ攻撃によるものであっても、そのことを示す証拠がすべてシステムから削除されているか消滅している可能性があるということである。そうすると、そのインシデントが、例えば、人為的ミスによるものではなく、明確にコンピュータ攻撃によるものであるということを知ることは不可能になる。

本開示の１つの態様によれば、車両の電子システムに対する攻撃を検出するためのコンピュータ上で実現される方法が提供される。本方法は、車両の複数の電子制御ユニット（ＥＣＵ）間の第１通信バス上に伝送される複数のメッセージを傍受すること、および、どのＥＣＵが第１通信バスと通信可能に接続されているかに基づいて、傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定することを含む。傍受されたメッセージ、および、判定された少なくとも１つの受信側ＥＣＵを示す情報はログに保存される。本方法は、ログに保存されているメッセージと情報がルールの少なくとも１つの条件を満たすか否かに基づいて、車両へのコンピュータ攻撃を検出すること、および、ルールに応じた処置を実行することによって、車両に対するコンピュータ攻撃を阻止することをさらに含む。ルールは、コンピュータ攻撃において使用された悪意あるメッセージ、および、悪意あるメッセージの受信側である少なくとも１つのＥＣＵに関する情報から成る１つ以上の侵害指標に依存してもよい。

態様のその他の例においては、車両の電子システムに対する攻撃を検出するためのコンピュータシステムが提供される。コンピュータシステムは、複数の電子制御ユニット（ＥＣＵ）、複数のＥＣＵを通信可能に接続するように構成された第１通信バス、およびハードウェアプロセッサを含む。ハードウェアプロセッサは、複数のＥＣＵ間の第１通信バス上に伝送される複数のメッセージを傍受し、どのＥＣＵが第１通信バスと通信可能に接続されているかに基づいて、傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定するように構成されている。ハードウェアプロセッサは、さらに、傍受されたメッセージ、および、判定された少なくとも１つの受信側ＥＣＵを示す情報を、ログに保存するように構成されている。プロセッサは、ログに保存されているメッセージと情報がルールの少なくとも１つの条件を満たすか否かに基づいて、車両へのコンピュータ攻撃を検出し、ルールに応じた処置を実行することによって、車両に対するコンピュータ攻撃を阻止するように構成されている。ルールは、コンピュータ攻撃において使用された悪意あるメッセージ、および、悪意あるメッセージの受信側である少なくとも１つのＥＣＵに関する情報から成る１つ以上の侵害指標に依存してもよい。

態様のその他の例によれば、本明細書に開示された方法のいずれかを実行するためのコンピュータ実行可能命令から成る命令を含むコンピュータ読み取り可能媒体が提供される。

上記の、態様例の簡単な概要は、本開示の基本的な理解を提供するものである。この概要は、想定されるすべての態様の広範な概説ではなく、すべての態様の鍵となる要素や重要な要素を特定したり、本開示の一部またはすべての態様の範囲を規定したりすることを意図するものではない。その唯一の目的は、１つ以上の態様を、後述する本開示のより詳細な説明への前置きとして、簡易な形で提示することである。上述のことを達成するために、本開示の１つ以上の態様は、特許請求の範囲で説明され、かつ例示的に示される特徴を含んでいる。

本明細書に組み込まれ、その一部を構成する添付図面は、本開示の１つ以上の態様例を図示し、それらの原理および実施例を説明するために、詳細説明と共に供される。

図１Ａおよび図１Ｂは、自動車の例を用いて、交通手段のネットワークアーキテクチャの例を示す、ブロック図である。 図１Ａおよび図１Ｂは、自動車の例を用いて、交通手段のネットワークアーキテクチャの例を示す、ブロック図である。

図２Ａから図２Ｃは、交通手段のネットワークにおける保護モジュールの配置の例を示す図である。 図２Ａから図２Ｃは、交通手段のネットワークにおける保護モジュールの配置の例を示す図である。 図２Ａから図２Ｃは、交通手段のネットワークにおける保護モジュールの配置の例を示す図である。

図３は、ルール作成システムの例を示す図である。

図４は、交通手段に対するコンピュータ攻撃を阻止するためのシステムを示す図である。

図５Ａおよび図５Ｂは、本開示の各態様、特に、図３および図４のシステムを実現する方法を図示するフローチャートである。 図５Ａおよび図５Ｂは、本開示の各態様、特に、図３および図４のシステムを実現する方法を図示するフローチャートである。

図６は、ＣＡＮプロトコルのフレームのフォーマットを示す図である。

図７は、開示されたシステムおよび方法を態様例に従って実現可能なコンピュータシステムのブロック図である。

車両の電子システムに対する攻撃を検出するためのシステム、方法、およびコンピュータプログラム製品に関する態様例について以下に説明する。以下の説明は、単に例示の目的のためであって、いかなる制限を加えることも意図されていないことは、当業者には理解されるであろう。その他の態様は、本開示から利益を得る当業者には、容易に想起できるであろう。添付図面に示すように、態様例の実施態様が詳細に参照される。同一あるいは類似する項目には、図面および以下の説明を通して、可能な範囲で、同一の参照符号を用いる。

用語解説：本開示の異なる態様を説明するために用いるいくつかの用語について以下に定義する。

交通手段（以下、ＭＴ）とは、人や、貨物や、その交通手段に装備された機器を、道路上で運搬するように構成された装置である。例えば、当該装置は、自動車のような車両であってもよい。本開示においては、交通手段を自動車または車両と称することもある。

交通手段は、車両の１つ以上の電気システムやその他のサブシステムを制御するように構成された１つ以上の内蔵システムを含む電子システムを有している。自動車の電子システムは、例えば、以下のものを含んでいてもよい。

１．運転状態（例えば、エンジン回転数）およびセットポイント値（例えば、スイッチ位置）を検出するように構成されたセンサおよびセットポイントジェネレータ。センサおよびセットポイントジェネレータは、さらに、物理的変数を電気信号に変換するように構成されている。

２．センサおよびセットポイントジェネレータからの情報を、数学的計算プロセス（開回路および閉回路制御アルゴリズム）で処理するように構成された電子制御ユニット（ＥＣＵ）。ＥＣＵは電気的出力信号を用いてアクチュエータを制御する。さらに、ＥＣＵは他システムおよび車両診断システムに対するインターフェースとして機能する。

３．ＥＣＵからの電気的出力信号を機械的変数（例えば、ソレノイド弁のニードルのリフト）に変換するように構成されているアクチュエータ。

電子制御ユニット（ＥＣＵ）とは、所定の形式の電気信号で構成される情報を処理するための任意の複雑度を持った電子回路を含む、構造的には別々の、機能的には完結した電子装置部分である。

バスとは、すべてのノードを受動的通信回線によって接続して双方向のデータ通信を可能にしている、データ通信ネットワークのトポロジーである。

フレーム（メッセージとも称する）とは、通信チャネル上の伝送シーケンスにおけるビットまたはビットフィールドの順序と値を定義する、通信チャネルプロトコルのデータブロックである。

先進運転支援システム（advanced driver-assistance systems）とは、ＭＴの制御処理などによって、ＭＴの監視、ＭＴの運転者への警告、ＭＴの制動において運転者を支援するためのシステムである。

テレマティックデータ（テレマティクスとも称する）とは、ナビゲーショナルデータであり、路上走行車の車載ナビゲーション通信装置が移動通信チャネルを介して配送センターへ送信することができる、動作要素の現在状態に関するデータである。

情報セキュリティインシデントとは、かなり高い確率で、事業活動の侵害や情報セキュリティへの脅威の発生をもたらす、１件以上の望ましくないかもしくは予想外の情報セキュリティイベントである。

本出願において、「交通手段に関わるインシデント」（以下、インシデントと称する）とは、道路交通事故（Road Traffic Accident：ＲＴＡ）などの、予想したＭＴの挙動に変化をもたらす、１件以上の望ましくない、もしくは予想外の事象を意味する。本開示の各態様は、まさに、情報セキュリティインシデントの結果として交通手段に関わるインシデントが引き起こされた場合に、前述の技術的問題の解決に寄与するものである。

侵害指標（Indicator of Compromise：ＩＯＣ、また、感染指標（indicator of infection）とも称する）とは、コンピュータ上またはネットワーク上で観察できる情報システムへのアーティファクト、すなわち、侵入の残留痕跡である。代表的な侵害指標として、ウィルス対策レコード、ＩＰアドレス、ファイルのチェックサム、ＵＲＬアドレス、ボットネットのコマンドセンターのドメイン名などがある。侵害指標には、特に、OpenIOC、STIX（Structured Threat Information eXpression）、CybOX（Cyber Observable eXpression）（商標）などのような規格が複数存在する。

コンピュータ攻撃（サイバー攻撃または悪意ある攻撃とも称する）とは、情報システムおよび情報通信ネットワークの情報セキュリティを侵害するために、当該システムおよびネットワークに対して行われる、ハードウェアおよびソフトウェアによる標的型行動である。

標的型攻撃（Targeted Attack：ＴＡ）とは、特定の組織や特定の個人に向けられたコンピュータ攻撃の特定の例である。

注目すべきことは、本開示は、エンジン（内燃機関、水素エンジン、電気エンジン）を使用し、少なくとも１つのＥＣＵを含む、あらゆる種類の交通手段に適用できるということである。

図１Ａは、自動車の例を用いて、交通手段のネットワークアーキテクチャ１００の例を示す図である。まず、注目すべきことは、最新のＭＴ、特に、自動車では、現行規格に従って、以下のバスが使用されるということである。例えば、ネットワークアーキテクチャ１００は、車両のマイクロコントローラや装置の相互通信を（例えば、ホストコンピュータなしに）可能にするように設定された、交通手段のネットワークに関する（ISO 11898-1にも規定されている）通信規格である、コントローラエリアネットワーク（ＣＡＮ）を実現するように構成されてもよい。ＣＡＮバスは、データ送信速度が125 kbit/sと1 Mbit/sの間である高速バスＣＡＮ−Ｃ（ISO 11898-2）と、データ送信速度が5 kbit/sと125 kbit/sの間である低速バスＣＡＮ−Ｂ（ISO 11898-3）とに分けられる。ネットワークアーキテクチャは、さらに、可変データレート対応のＣＡＮ（ＣＡＮ ＦＤ）と称するＣＡＮの拡張版を実現するように構成されてもよい。

他の一例においては、ネットワークアーキテクチャ１００は、ＣＡＮに対する高速で高信頼性の代替として開発されたISO 17458-1-17458-5規格である、フレックスレイ（FlexRay）を実現するように構成されてもよい。ネットワークアーキテクチャ１００は、免責の低い自動車システムの制御を指向した、産業ネットワークに関するISO 17987規格である、ローカル相互接続ネットワーク（Local Interconnect Network：ＬＩＮ）を実現するように構成されてもよい。他の一例においては、ネットワークアーキテクチャ１００は、自動車産業におけるマルチメディアとコンピュータエンターテインメントネットワークに関する事実上の規格である、メディア指向システムトランスポート（Media Oriented Systems Transport：ＭＯＳＴ）を実現するように構成されてもよい。他の一例においては、ネットワークアーキテクチャ１００は、802.3グループのＩＥＥＥ規格に説明されている、コンピュータ用の装置と産業ネットワークの間のパケットデータ送信のための技術である、イーサネット（Ethernet）（登録商標）を使用するように構成されてもよい。注目すべきことは、上記規格は継続的に改善されており、交通手段において使用される新しい規格や技術もまた出現しているということである。したがって、本開示の範囲は上記規格に限らず、交通手段において使用され得るいかなる技術にも適用可能である。

車両のネットワーク１００は、例えばＣＡＮバスのようなマルチマスターシリアルバスを用いたＥＣＵ間（すなわち、ノード間）のメッセージ交換を可能にするように構成されてもよい。最新のＭＴのネットワーク１００は、セントラルゲートウェイ１０１と、車両のシャーシ１６１に付随し、第１バス１５１（例えば、フレックスレイバス）によってシャーシ１６１と通信可能に接続された複数のＥＣＵ１１１から１１３（ＥＣＵ１、ＥＣＵ２、…、ＥＣＵｎと名付ける）と、車両のマルチメディアサブシステム１６２（車内エンターテインメント（In-Car Entertainment：ＩＣＥ）または車載インフォテインメント（In-Vehicle Infotainment：ＩＶＩ）とも称する）に付随し、第２バス１５２（例えば、ＣＡＮ−Ｂバス）によってマルチメディアサブシステム１６２と通信可能に接続された複数のＥＣＵ１２１から１２３と、車両のトランスミッションシステム１６３に付随し、第３バス１５３（例えば、ＣＡＮ−Ｃバス）によってトランスミッションシステム１６３と通信可能に接続された他の複数のＥＣＵ１３１から１３３と、車両のテレマティクス１６４に付随し、第４バス１５４（例えば、ＭＯＳＴバス）によってテレマティクス１６４と通信可能に接続されたもう一群のＥＣＵ１４１から１４３とを含んでいる。セントラルゲートウェイ１０１は、診断バス１５５、ローカル相互接続ネットワーク（ＬＩＮ）１５６、およびイーサネット（登録商標）１５７へも出力する。本例において、ＭＴのネットワークアーキテクチャは、ＭＴのすべてのサブシステムをバス１５１から１５７によって接続する単一のセントラルゲートウェイ１０１を収容している。本明細書で使用されている、他のモジュール、すなわちサブシステムと「接続」されているモジュール、すなわちサブシステムは、任意の数の介在要素によって、直接または間接的に、そのモジュール、すなわちサブシステムと通信可能に接続されている。

いくつかの態様においては、バスは、アドレッシングをサポートしない限定的な通信中継手段であってもよい。１つの態様においては、メッセージはバス上のすべてのノードにブロードキャストされ、各ノードは、メッセージが自ノード宛か否かを判断する。例えば、ＥＣＵは、ＣＡＮバスを使ってメッセージをブロードキャストし、特定のメッセージに（すなわち、ＣＡＮ識別子によって）関心がある他のＥＣＵは、それらのメッセージを受信しようとし、その他のメッセージを無視するものとする。言い換えれば、ＣＡＮメッセージには送信元識別子も認証も組み込まれていない。これらの制限によって、既存のコンピュータセキュリティ技術を車両の電子システムに適合させる際に問題が生じる。例えば、これらの制限によって、悪意ある要素は、ＣＡＮネットワーク上のトラフィックの傍受および他のＥＣＵへのなりすまし（すなわち、データインジェクション）の両方を行うことができる。また、これらの制限のために、どのＥＣＵが特定のＣＡＮメッセージを送信もしくは受信しているのかを知る方法がないため、コンピュータセキュリティ解析のためにトラフィックにリバースエンジニアリングを適用することは困難である。

各ＥＣＵは、ＣＡＮバス上のメッセージを受信および送信するように構成されたＣＡＮコントローラを（ＥＣＵのマイクロコントローラの個別構成部品または不可欠な部分として）含んでもよい。ＣＡＮコントローラは、メッセージを受信するため、バスから受信したシリアルビットを、メッセージ全体が得られるまで蓄積するように構成されてもよい。メッセージは、その後、ホストプロセッサに（例えば、割込みをトリガするＣＡＮコントローラに）フェッチされる。ＣＡＮコントローラは、メッセージを（例えば、他のＥＣＵに）送信するため、バスがフリーのときにビットをバス上でシリアル伝送することによって（マイクロコントローラによって提供された）メッセージを中継するように構成されてもよい。

いくつかの態様においては、ＥＣＵは、バス上のデータストリームをＣＡＮバスのレベルからＣＡＮコントローラが使用するレベルに変換することによりメッセージの受信を促進し、かつ、データストリームをＣＡＮコントローラのレベルからＣＡＮバスのレベルに変換することによりメッセージの送信を促進するように構成されたトランシーバをさらに含んでもよい。１つの態様においては、ＥＣＵが、ＣＡＮトランシーバを使用して、非ゼロ復帰（Non-Return-to-Zero：ＮＲＺ）形式を用いてメッセージをバス上でシリアル伝送し、その後、バス上のすべてのＥＣＵがメッセージを受信するように構成されてもよい。

メッセージ（すなわち、フレーム）は、識別子（identifier：ＩＤ）とデータペイロード（例えば、1フレームにつき8または64データバイト）を含んでもよい。メッセージは、冗長コード（巡回冗長検査（Cyclic Redundancy Check：ＣＲＣ））と、確認スロットと、その他のフィールドをさらに含んでもよい。いくつかの態様においては、メッセージの識別子フィールドはメッセージの優先度（例えば、値が低いほど、優先度が高い）を示す。また、受信側の各ＥＣＵが、識別子フィールドを使って、バス信号を処理してメッセージを受け取るべきかを判断してもよい。

図１Ｂは、交通手段のネットワークアーキテクチャ１００Ｂの他の一例を示す図である。ＭＴのネットワーク１００Ｂは、それぞれ特定のサブネットワークを分担する相互接続されたゲートウェイ２０１から２０４を収容している。ゲートウェイ１（２０１）は、ＭＴのシャーシを分担するＥＣＵ１１１から１１３に、フレックスレイバス１５１によって接続されている。ゲートウェイ２（２０２）は、ＭＴのマルチメディアサブシステムを分担するＥＣＵ１２１から１２３に、ＣＡＮ−Ｂバス１５２によって接続されている。ゲートウェイ３（２０３）は、トランスミッションを分担するＥＣＵ１３１から１３３に、ＣＡＮ−Ｃバス１５３によって接続されている。そして、ゲートウェイ４（２０４）は、テレマティクスを分担するＥＣＵ１４１から１４３に、ＭＯＳＴバス１５４によって接続されている。

図２Ａは、交通手段のネットワークにおける保護モジュール１０２の配置の例を示す図である。この例では、図１Ａに示すネットワークアーキテクチャ１００が使用される。保護モジュール１０２は、主として、ＭＴに対するコンピュータ攻撃を阻止する役割を果たす。ＭＴに対するコンピュータ攻撃とは、主として、ＭＴのネットワークおよびＭＴの電子システム、特に、ＥＣＵおよびネットワークゲートウェイに対するコンピュータ攻撃を意味する。保護モジュール１０２の機能性について、以下にさらに詳細に説明する。図２Ａに挙げられている例において、保護モジュール１０２はセントラルゲートウェイ１０１のソフトウェアコンポーネントであり、ネットワークの全ノードの保護を提供する。

他の一例においては、図２Ｂに示すシステムは、２つの保護モジュール１０２ａおよび１０２ｂを収容し、そのうち１つ目はフレックスレイバス１５１と、２つ目はＭＯＳＴバス１５４と接続され、それによって、保護モジュール１０２ａおよび１０２ｂのそれぞれは、そのアクセス先のネットワーク／サブネットワークに保護を提供するものとする。保護モジュールのネットワークとの接続の、これ以外の例も可能であることは言うまでもない。

図２Ｃは、図１Ｂに示すアーキテクチャを用いた、交通手段のネットワークにおける保護モジュール１０２の配置のさらに他の例を示す図である。ネットワークは４つの保護モジュール１０２ａから１０２ｄを収容している。保護モジュール１０２ａはフレックスレイバス１５１と接続され、保護モジュール１０２ｂはＣＡＮ−Ｂバス１５２と接続され、保護モジュール１０２ｃおよび１０２ｄは、それぞれ、ゲートウェイ２０３および２０４のソフトウェアコンポーネントである。保護モジュール１０２ａから１０２ｄのそれぞれは、そのアクセス先のネットワーク／サブネットワークに保護を提供するものとする。保護モジュールのネットワークとの接続の、これ以外の例も可能であることは言うまでもない。一般例においては、ＭＴのネットワークに対する総合的保護を確保するために、保護モジュールを任意のサブネットワーク（すなわち、バス）および任意のゲートウェイと接続してもよい。

１つの態様においては、ＥＣＵは、ＭＴの主電子システムおよびＭＴの補助電子システムのカテゴリーのうち一方に所属してもよい。ＭＴの主および補助システムのＥＣＵのリストを、例えば、１つ以上の保護モジュール１０２ａから１０２ｄのメモリまたはゲートウェイのメモリに収容してもよい。主電子システムは、ＭＴの制御、ＭＴの安全、およびその周囲の人にとって重要なＥＣＵを含んでいる。補助電子システムが含むＥＣＵは、運転者に付加的な利便性を提供し、ＭＴのエンターテインメントオプションやその他の付加的機能を利用可能にするものであって、切断されてもＭＴやその安全性を制御する能力に影響を与えない。

１つの態様例においては、ＭＴの補助電子システムのＥＣＵは、運転支援システム、マルチメディアシステム（車内エンターテインメント（ＩＣＥ）または車載インフォテインメント（ＩＶＩ）とも称する）、およびテレマティクスを含んでもよい。運転支援システムは、特に、駐車センサ（パークトロニクスまたは駐車支援システムとも称する）、カメラモニタシステム、ブロックヒーター、およびアンチロックブレーキシステム（Anti-lock Braking System：ＡＢＳ）の各ＥＣＵを含んでもよい。マルチメディアシステムは、特に、ナビゲーションシステム、車内インターネット、ステアリングホイールのオーディオコントロール、およびハンズフリーボイスコントロールを含んでもよい。テレマティクスは、特に、テレマティックコントロールユニット（Telematic Control Unit：ＴＣＵ）、グローバルポジショニングシステム（Global Positioning System：ＧＰＳ）ユニット、外部移動体通信インターフェース（ＧＳＭ（登録商標）、ＧＰＲＳ、３Ｇ、４Ｇ、（ＬＴＥ）Wi-Fi、WiMAX、またはBluetooth（登録商標））、加速度、衝撃、および空間方位センサを含む１個以上のセンサなどを含んでもよい。さらに他の特定の態様においては、ＭＴの補助電子システムのＥＣＵのリストは、信頼できない無線接続チャネルおよび自律走行システム（最終レベルの制御まで）をさらに収容している。

他の態様においては、ＭＴの主電子システムのＥＣＵのリストは、特に、ギアボックスに付随するコントロールユニットおよびシャーシに付随するコントロールユニットを含む。ギアボックスに付随するコントロールユニットは、特に、トランスミッションコントロールユニット、トラクションコントロールシステム（Traction Control System：ＴＣＳ）などを含む。車両のシャーシに付随するコントロールユニットは、特に、クルーズコントロールシステム、車線維持システムなどを含む。

注目すべきことは、１つの態様においては、補助電子システムのリストにある、例えば、ＡＢＳシステムなどの、いくつかのＥＣＵは主電子システムのリストに移動させてもよいということである。他の態様においては、その逆のことができる。さらに注目すべきことは、１つの態様においては、主および補助電子システムのリストは、ＭＴの製造者、モデルおよびタイプに応じて異なってもよく、適宜変更してもよいということである。

図３は、ルール作成システム３００の例を示す図である。ネットワークアーキテクチャは既に示したもののうちどれでもよいが、ここで考察される例においては、ＭＴのネットワークアーキテクチャは、図２Ａに既に示した外観を有している。システムは少なくとも１つの交通手段３０１を含み、交通手段３０１は乗員保護システム（Occupant Protection System：ＯＰＳ）３３１および保護モジュール１０２を含む。ＯＰＳ３３１はＭＴのバスと（本例では、ＣＡＮ−Ｃバス１５３と）接続され、ＭＴに関わるインシデント（例えば、ＲＴＡ）が発生した時点を確認するように構成されている。

保護モジュール１０２も、ＭＴのバスと接続され（本例では、保護モジュール１０２はセントラルゲートウェイ１０１のモジュールである）、ＭＴのバス上を流れるメッセージ（すなわち、フレーム）を傍受するように構成されている。このため、傍受されたメッセージは、傍受する過程でログ３０４に保存される。保護モジュール１０２は、さらに、メッセージの受信側であるＭＴの少なくとも１つのＥＣＵに関する受信側情報を、傍受されたメッセージごとに保存するように構成されてもよい。また、保護モジュール１０２は、ログ３０４のうちの、メッセージと、ＭＴに関わるインシデントの発生時刻前後の特定期間中（すなわち、期間（t_o - Δt, t₀ + Δt）の間、ただし、t₀はＭＴに関わるインシデントの発生時刻であり、ΔtはＭＴに関わるインシデントの発生時刻前後の特定期間、例えば、10秒）にＭＴのバス上の保護モジュール１０２によって傍受された前記メッセージのうち少なくとも１つの受信側である少なくとも１つのＥＣＵに関する情報とを含む部分を、サーバ３０３に送信する役割も果たす。

ＥＣＵに関する情報はＥＣＵを一意的に識別するために用いられ、特に、ＥＣＵの一意的識別子、すなわち表示記号を含む。

保護モジュール１０２は、ネットワーク３０２（すなわち、Wi-Fiネットワーク、ＬＴＥなどの無線通信ネットワーク）によってサーバ３０３と通信することができる。サーバ３０３は、保護モジュール１０２からログ３０４を受信し、受信したログ３０４を解析することによってコンピュータ攻撃を検出するように構成されている。コンピュータ攻撃が行われる可能性は、ＭＴの電子システム、特にＥＣＵの脆弱性次第である。さらに、サーバ３０３は、コンピュータ攻撃を検出する際に、特に以下の侵害指標を判定するように構成されている。すなわち、コンピュータ攻撃の中で用いられているメッセージ、および、それらのメッセージのうち少なくとも１つのメッセージの受信側であるＭＴの少なくとも１つのＥＣＵに関するメッセージごとの情報である。また、サーバ３０３は、侵害指標に基づいて、保護モジュール１０２に対するルールを作成するようにも構成されており、１つのルールは、ＭＴに対するコンピュータ攻撃を検出するためのルールを適用する少なくとも１つの条件、および、ＭＴに対するコンピュータ攻撃を阻止する、ルール適用時の少なくとも１つの処置を含む。このように、ルール適用の条件は、特に、侵害指標への依存性を構成し、それによって、ＭＴに対するコンピュータ攻撃の検出を可能にする。例えば、ルール適用の条件は、判定された侵害指標すべてがログ３０４の中で発見されることであってもよい。

ルール適用時の処置も侵害指標に依存する。例えば、ある侵害指標が、ＣＡＮバス上の定義されたメッセージと、このメッセージの受信側に関する情報を含む場合、ルール適用時の処置として、ＣＡＮバス上の受信側に送信されているメッセージをすべて阻止してもよい。侵害指標に基づく、保護モジュールに対するルールの作成について、その他の可能な例を以下に示す。

１つの特定の態様においては、侵害指標はメッセージを傍受した時刻をさらに含み、加えて、メッセージを傍受する過程で、それらのメッセージに対応し、それらのメッセージを傍受した時刻を示すタイムスタンプもログに保存される。他の態様においては、侵害指標は、それらのメッセージのうちの少なくとも１つの受信側である少なくとも１つのＥＣＵに関する情報をさらに含み、加えて、受信されたログ３０４は、上記ＥＣＵのうち少なくとも１つをさらに含む。

１つの特定の態様においては、ルール適用の条件は、保護モジュールによって傍受されたＭＴのバス上のトラフィックが、（例えば、定義された侵害指標に含まれるメッセージのうちの）定義された一群のメッセージを含む、という条件を含む。

上述のように、2014年式ジープ・チェロキー車に対するコンピュータ攻撃の例を示した。以下の考察において、コンピュータ攻撃がどのように行われたかを、さらに詳細に検討する。サイバー攻撃は、車両の駐車支援システムの脆弱性の悪用を含むものであった。自動車が診断セッションに切り替えられた瞬間にブレーキを阻止させる機能がジープに内蔵されている。このためには、診断用ＣＡＮメッセージが受信されている必要がある。原則として、自動車の速度が7 km/hから15 km/hを超えると、大半のＥＣＵはそのようなメッセージを無視するので、そのようなコンピュータ攻撃は自動車が低速走行中に可能である。ここで考察する例において、自動車が診断状態に切り替えられるとブレーキが機能を停止し、このとき自動車が低速走行中であっても、安全上重大な問題となる。この機能上の不備をハッカーが利用して、ＥＣＵのＡＢＳに関する診断セッションを開始する以下のコマンドであるメッセージをＣＡＮバス上で送信する恐れがある。
EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00

次に、ハッカーは最大限にブレーキ圧をかける。このコマンドは、数件のメッセージをＣＡＮバス上で送信することによって実行される。
EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00

このように、示されたＣＡＮメッセージを侵害指標として定義することが可能であり、上記脆弱性の場合、態様例においては、侵害指標に基づくルール適用の条件は、自動車の走行中において上記の一群のメッセージが存在することであると定義することが可能である。
EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00
EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00

このように、自動車の走行中にこれらのメッセージが受信されると、ルール適用時の処置が実行され、コンピュータ攻撃は阻止されることになり、上述のシナリオは実現しないことになる。

他の態様においては、ルール適用の条件は、上記の一群のメッセージのうちのメッセージの受信側または送信側は特定のＥＣＵであるという事実に関する情報をさらに含む。このように、ジープに関する考察の例において、ルール適用の条件は、メッセージの受信側であるＥＣＵのＡＢＳに関する情報も含むことになる。例えば、ルールの条件として、（ａ）以下の一群のメッセージが受信されたということ、
EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00
EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00
および、（ｂ）一群のメッセージの受信側は
ＥＣＵのＡＢＳ
であるということを指定してもよい。

さらに他の特定の態様においては、ルール適用の条件は、定義された一群のメッセージのうちのメッセージは特定の順番で配列され、特定の時間間隔の間に保護モジュールによって傍受されたという情報も含むものとする。ジープの例という状況の中で、ルール適用の条件として、（ａ）一群のメッセージが以下の順番で受信されたということ、
1. EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00
2. EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
3. EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
4. EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00
および、（ｂ）一群のメッセージの受信側は「ＥＣＵのＡＢＳ」であり、そして、（ｃ）メッセージの受信の時差は、
1.から2.までは1分以下
2.から3.までと3.から4.までは100ミリ秒以下
であるということを指定してもよい。

このように、示されたルールに対して、１番目と２番目のメッセージの間には1分以下の時間間隔を置き、２番目と３番目、および３番目と４番目のメッセージの間には100ミリ秒以下の時間間隔を置くべきであるという条件が追加された。実際には、１番目のメッセージは診断モードに切り替えるコマンドを含み、その後に、ブレーキングコマンドを含む３つのメッセージが届くので、メッセージは近接して続くことになる。

さらに他の特定の態様においては、ルール適用の条件は、ＥＣＵの状態に依存するものとする。他の態様においては、ルール適用の条件は、ＭＴのセンサの指標にも依存するものとする。例えば、ルールは自動車の走行条件を含んでもよい。すなわち、自動車が走行中であり、上記のＣＡＮメッセージが到着した場合、ルール適用の条件は満たされるものとするが、自動車が走行中ではない場合、ルールは適用されないものとする。それは、後者のケースでは、そのようなメッセージの受信は、脆弱性の悪用やコンピュータ攻撃を示唆していないからである。

ルール適用時の処置には、１つの態様においては、特に、（ａ）少なくとも１つのＥＣＵに対してメッセージを送信すること、（ｂ）定義された侵害指標に含まれるメッセージのうち少なくとも１つのメッセージの送信を阻止すること、または（ｃ）定義された侵害指標に含まれるメッセージのうち少なくとも１つのメッセージに変更を加えること、が含まれる。

１つの態様においては、少なくとも１つのＥＣＵに対して送信されるメッセージは、ＭＴの補助電子システムのＥＣＵのリストのうち少なくとも１つのＥＣＵを切断することを指示するコマンドを含んでもよい。ジープの例においては、ＥＣＵのＡＢＳを切断してもよく、例えば、その結果、上記のコンピュータ攻撃は発生しなくなる。他の態様においては、少なくとも１つのＥＣＵに対して送信されるメッセージは、ＭＴの主電子システムのＥＣＵのリストのうち少なくとも１つのＥＣＵに対するセーフティモードをオンにする、すなわち、有効にすることを指示するコマンドを含んでもよい。セーフティモードにおいては、ＭＴの機能が制限されるため、危険状況における動作のリスクを完全に取り除くか、許容レベルに下げることができる。例えば、ＭＴの最高速度を制限することができる。制限速度内で走行中でも、運転者には、ＭＴを駐車させるか、サービスステーションまで行くかの選択肢がある（ＭＴは完全には遮断されていない）が、ＭＴの制御に関わるリスクは大幅に軽減される。

１つの特定の態様においては、上記ルールに含まれるメッセージの送信の阻止は、ルールに従って１つのサブネットワークから他のサブネットワークへのゲートウェイを介して行われる。例えば、図３のネットワークアーキテクチャ例の場合、セントラルゲートウェイ１０１は、例えば、ＣＡＮ−Ｂバス１５２とＣＡＮ−Ｃバス１５３の間の、１つのサブネットワークから他のサブネットワークへのメッセージの送信を阻止してもよい。ゲートウェイ１０１は、他のサブネットワークへの送信を行うように構成されているＭＴの電子システムの１つのサブネットワークから、メッセージを受信し、保護モジュール１０２を用いて、メッセージを送信できるか否かを確認する。メッセージの送信は、保護モジュールがこのメッセージの通過を許可する場合に限って、行われる。許可しない場合は、メッセージはその先へは送信されない。

他の態様においては、上記ルールに含まれるメッセージの送信の阻止は、ルールに従って同一バス上のＥＣＵ間で行われる送信に対して行われてもよい。例えば、図３のネットワークの場合、ＥＣＵ１ １２１とＥＣＵ２ １２２の間のＣＡＮ−Ｂバス１５２上のメッセージ送信の能力を阻止してもよい。１つのＥＣＵが同じバス上に位置する他のＥＣＵを用いてＣＡＮバス上のメッセージの送信を阻止するために、様々な技術を使うことができる。そのような方法の１つとして考えられるものを以下に説明する。メッセージをＣＡＮバス上で送信するとき、ビット0が、1に対応するビットと同時に送信される場合、1に対応するビットをビット0によって抑制してもよい（フレームのフォーマットを図６に示す）。ＣＡＮバス上のデータフレームは、メッセージのチェックサム（15ビット）を含むフィールドで終わるデータ構造を有している。したがって、セントラルゲートウェイ１０１は、保護モジュール１０２を用いて、フレーム内容をチェックすることができ、このメッセージのチェックサムを送信する過程で望ましくないメッセージが検出されたら、保護モジュール１０２は、ビット0から成る配列を送信することによって、チェックサムの値を変更することができる。ＣＡＮバスの動作原理に従って、この場合、元のチェックサムの値に代わって、別の値である0がバス上で設定されることになる。そのようなメッセージを受信すると、ＥＣＵに対する受信側は、メッセージのチェックサムの不一致を検出することになり、そのようなメッセージは処理されないことになる。

１つの特定の態様においては、ＭＴの補助電子システムのＥＣＵのリストは、特に、ａ）運転支援システム、ｂ）マルチメディアシステム、およびｃ）テレマティクスを含む。他の態様においては、ＭＴの主電子システムのＥＣＵのリストは、特に、ａ）ギアボックス、およびｂ）シャーシを含む。

さらに他の態様においては、受信されたログの解析は、機械学習の手法を使うか、または専門家によって行われる。

１つの態様においては、メッセージに含まれる悪意あるコマンドを除去するために、保護モジュール１０２は、定義された侵害指標に含まれるメッセージのうち少なくとも１つのメッセージに変更を加えてもよい。１つの実現形態においては、保護モジュール１０２は、保護モジュール１０２が存在するゲートウェイによって互いに接続されている１つのサブネットから他のサブネットに送信される、少なくとも１つのメッセージを修正することができる。例えば、図２Ｃに示すシステム例において、車両のトランスミッションの構成要素に関係する悪意あるコマンドを除去するために、バス１５３と１５４との間のゲートウェイ２０３に位置する保護モジュール１０２ｃは、バス１５４上のＥＣＵからバス１５３上の受信側のＥＣＵに送信されたメッセージを修正してもよい。他の態様においては、定義された侵害指標に含まれるメッセージのうち少なくとも１つのメッセージに加える変更を、（上述のような）メッセージの阻止、および上記ルールに従った侵害指標を含まない新しいメッセージの送信の、２つの処置に分割してもよい

１つの特定の態様においては、ルール適用時の処置に含まれるＥＣＵは、侵害指標に含まれるＥＣＵを含む。

機械学習の手法を用いると、ログエントリを異常がないことが分かっているデータと比較することによって、ログエントリの異常を発見することができる。さらに、交通手段の機能を記述したモデルを使用することもできる。そのようなモデルからの逸脱は、異常の形跡であり、さらなる調査が必要とされる。例えば、短期間のうちにＭＴの速度が大幅に変化したら、異常と考えることができる。異常のその他の例として、ＭＴのマルチメディアシステムのサブネットワークから、ＭＴのシャーシを制御するサブネットワークに対して、コマンドが送信されるかもしれない。

最初は、異常検知システムがいかなる問題も発見していないにもかかわらず、問題があるとみなす理由がある場合、必要な一連のスキルを有する専門家を参加させてもよい。例えば、明らかな背景が存在しない状況下で発生する一連の同種のＲＴＡを検出したら、追加解析を実施してもよい。他の一例においては、重大な結果を伴うＲＴＡを検出したら、他の手段によってＲＴＡの原因を特定できなかった場合に、追加解析を実施してもよい。

メッセージの目的やプロトコルの仕様に関する情報、および、その他の必要情報を有する専門家は、イベントの状況を再構成して、ＲＴＡがシステムの異常な挙動によって引き起こされたのか、あるいは、システムはＲＴＡの時点において正常に機能していたのかを説明するべきである。

コンピュータ攻撃を検出したら、１つの態様においては、侵害指標であるＥＣＵ（例えば、ＥＣＵのＡＢＳ）の供給業者に対して（または、ＭＴの製造者に対して）、ソフトウェアの更新を申し入れてもよい。コンピュータ攻撃が行われる可能性を是正した更新版をＥＣＵの供給業者（または、ＭＴの製造者）から受領し、対応するＥＣＵにその更新版をインストールした後は、上記ルールはもはや適さないため、そのルールを削除するスクリプトを追加してもよい（ステップ５３３）。

図４は、交通手段に対するコンピュータ攻撃を阻止するためのシステム４００を示す図である。システム４００は、コンピュータ攻撃を阻止するために、交通手段３０１の保護モジュール１０２によって実行される方法を実現するように構成される。したがって、システム４００および各態様の要素数は、図３に示すものと同じである。システムは、ＭＴの少なくとも１つのバスを収容し、そのバスには少なくとも１つのＥＣＵが接続されている。システムは保護モジュール１０２を収容し、保護モジュール１０２はＭＴのバスのうち少なくとも１つと接続されている。一例として、図２Ａに示すＭＴのネットワークアーキテクチャが使用される。保護モジュール１０２は、サーバ３０３から、ネットワーク３０２を介して、ルールを入手するように構成されている。入手された、侵害指標に基づいて作成されたルールは、ルール適用の少なくとも１つの条件、およびルール適用時の少なくとも１つの処置を含んでいる。侵害指標は、特に（ｉ）コンピュータ攻撃において使用されるメッセージ、および（ｉｉ）そのメッセージのうち少なくとも１つの受信側であるＭＴの少なくとも１つのＥＣＵに関する情報である。

さらに、保護モジュール１０２は、ログ３０４を用いて、入手したルール適用の条件をチェックするため、および、そのルール適用の条件が満たされた場合に、ルール適用時の処置を実行することで、ＭＴに対するコンピュータ攻撃を阻止するため、ＭＴのバス上で送信されているメッセージを傍受するように構成されている。

図３のシステムの上記の特定の態様は、図４のシステムにも適用可能である。

図５Ａおよび図５Ｂは、本開示の各態様、特に、図３および図４のシステムを実現する方法５００を図示するフローチャートである。ルールを作成するための方法は以下を含む。ステップ５０１において、サーバ３０３は、少なくとも１台のＭＴ３０１の保護モジュール１０２からログ３０４を受信する。ログ３０４は、メッセージ、および、ＭＴに関わるインシデント（例えば、ＲＴＡ）の発生時刻前後の特定期間中にＭＴ３０１のバス上の保護モジュール１０２によって傍受された前記メッセージのうち少なくとも１つの受信側である少なくとも１つのＥＣＵに関する情報を収容している。次に、ステップ５０２において、入手したログ３０４を解析することによって、コンピュータ攻撃の検出が実行される。その後、コンピュータ攻撃を検出すると、ステップ５０３において、特に、以下の侵害指標を決定する。すなわち、コンピュータ攻撃で使用されているメッセージ、およびメッセージの受信側であるＭＴの少なくとも１つのＥＣＵに関するメッセージごとの情報である。この結果、ステップ５０４において、侵害指標に基づいて、保護モジュール１０２のためのルールが作成される。ルールは、ＭＴに対するコンピュータ攻撃を検出するためのルール適用の少なくとも１つの条件、および、ＭＴに対するコンピュータ攻撃を阻止する、ルール適用時の少なくとも１つの処置を含む。

１つの特定の態様においては、コンピュータ攻撃が検出され、侵害指標が決定されたら、コンピュータ攻撃に関与した人物を突き止めて法の裁きを受けさせる（５１１）一連の処置を行うため、さらに補償支払限度額を決定する保険会社の必要性に応えるため、検出されたコンピュータ攻撃について専門家（法執行当局および保険会社）に通知してもよい。加えて、コンピュータ攻撃に関する情報（侵害指標、ログ３０４、ＭＴに関する情報、テレメトリデータなど）、および、ソフトウェアの更新の要請を、検出されたコンピュータ攻撃の実行に利用された（したがって、侵害指標に示された）ＭＴの製造者および／またはＥＣＵの供給業者に送信してもよい（５１２）。このステップによって、ＭＴの製造者およびＥＣＵの供給業者は、ＭＴの電子システム（特に上述のＥＣＵ）のソフトウェアの更新版を開発することができ（５１３）、それによって、コンピュータ攻撃が行われる可能性が取り除かれることになる。ソフトウェアの更新版は、開発後、配信され、検出されたコンピュータ攻撃が行われる可能性のあるすべてのＭＴにインストールされることになる（ステップ５３３）。さらに、ＭＴすべてをリコールすることが可能であり、コンピュータ攻撃が行われる可能性を取り除くためのサービスを実施することもできる。

他の特定の態様においては、ログ３０４の解析には、コンピュータ攻撃が行われた確率をログ３０４に基づいて決定することが含まれる。ステップ５１４において、コンピュータ攻撃が行われた確率が所定の値（例えば、0.997、すなわち、３標準偏差以内）を超える場合、または、ＭＴに関わるインシデントが重大な結果を伴った（例えば、深刻な結果を伴うＲＴＡであった）場合、コンピュータ攻撃が検出されたと考えるか、またはログ３０４のさらに詳細な解析を開始する（ステップ５１５）。

コンピュータ攻撃が行われている確率を計算する際、サーバ３０３は、各々は異常ではないものの全体としてＲＴＡをもたらす一連の要因によってＲＴＡが引き起こされたが、ＭＴの正常運転の過程でそれらの要因のすべてが同時に発生した確率は低いということを考慮に入れる。このようにして、インシデント発生時のＥＣＵの異常動作が判定され、コンピュータ攻撃が行われた確率は上記ＥＣＵのすべてが同時に異常動作する確率と等しいと判定される（各ＥＣＵが異常動作する確率は前もって分かっており、例えば、ＭＴまたはＥＣＵの製造者から情報提供され得る）。異なる３つの独立したＥＣＵのうちどの２つが故障してもＲＴＡには至らないが、３つの故障が組み合わされた結果、ＲＴＡが発生した例について考える。第１システムの故障確率は0.1、第２システムの故障確率は0.15、そして第３システムの故障確率は0.18と仮定する。この場合、これらの３システム全部の偶発故障の組み合わせ確率は0.0027であるため、故障の原因が偶然要因ではなかった確率は0.9973となり、しきい値を超えている。

他の態様においては、サーバ３０３は、コンピュータ攻撃が行われた確率の計算のために、短期間のうちに同種のＲＴＡが多数登録されることを考慮に入れる。特定期間中の所定のモデルのＭＴによる、所定のタイプのＲＴＡの確率を、統計的手法によって評価してもよい。同タイプのＲＴＡが短期間に多数発生したことが判明した場合、そのような一連のＲＴＡが偶然要因によって引き起こされた確率は非常に低いため、標的型行動の確率がしきい値を超えているという結果になる可能性がある。

コンピュータ攻撃によるＲＴＡの確率を計算するために利用することができる確率モデルは他にも多く存在する。１つの特定の態様においては、ベイジアン信念ネットワーク、マルコフ連鎖、およびその他の確率モデルを用いて、コンピュータ攻撃の結果としてＲＴＡが発生する確率を計算してもよい。

１つの特定の態様においては、コンピュータ攻撃が行われた確率の計算、および、それに続くさらなるログ３０４の解析に、セキュリティの専門家による手動解析を含んでもよい。さらに他の特定の態様においては、類似したインシデントすべてを集約して、機械学習の手法を用いた解析を実行してもよい。インシデントは、使用されたＭＴ、ＥＣＵ、およびゲートウェイの同一製造者およびモデルごと、インシデント（ＲＴＡ）の類似状況ごと、異なるＭＴに対して部分的に一致または重複するログ３０４ごと、およびその他の特徴ごとに集約してもよい。さらなる解析を実施した結果、コンピュータ攻撃が確認されるか、もしくは実行されたコンピュータ攻撃の痕跡が発見された場合（ステップ５１６）、続く次のステップ５０３において、コンピュータ攻撃の侵害指標が判定され、その後、ステップ５０４において、保護モジュール１０２のためのルールが作成される。言うまでもなく、ステップ５１４において、計算されたコンピュータ攻撃の確率が所定値よりも低く、インシデントが重大な結果を招かなかった（重大ではない結果を伴うＲＴＡであった）場合、方法は終了する（ステップ５１８）。同様に、ステップ５１５におけるさらなる解析の結果、コンピュータ攻撃の痕跡が発見されなかった場合、方法は終了する（ステップ５１７）。

１つの特定の態様においては、ステップ５０１から５０４でサーバ３０３によって作成されたルールは、その後、ＭＴに対するコンピュータ攻撃を阻止する方法で用いられる。ステップ５２１において、保護モジュール１０２は少なくとも１つのルールを受信する。次に、ステップ５２２において、保護モジュール１０２は、ＭＴのバス上で送信中のメッセージを傍受し、そして、メッセージを傍受する過程で、ステップ５２３において、保護モジュール１０２は傍受したメッセージをログ３０４に保存し、メッセージの受信側であるＭＴの少なくとも１つのＥＣＵに関する受信側情報も、傍受されたメッセージごとに保存する。いくつかの態様においては、保護モジュール１０２は、傍受されたＣＡＮメッセージから、受信側ＥＣＵを判定できる識別子を抽出する。

１つの態様においては、保護モジュール１０２は、車両の複数の電子制御ユニット（ＥＣＵ）間の第１通信バス上に伝送される複数のメッセージを傍受してもよい。いくつかの態様においては、第１通信バスはコントローラエリアネットワーク（ＣＡＮ）バスを含み、それによって、ＣＡＮバス上を送信されるメッセージがＣＡＮバスと通信可能に接続されたすべてのＥＣＵにブロードキャストされるようにする。保護モジュール１０２は、どのＥＣＵが第１通信バスと通信可能に接続されているかに基づいて、傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定してもよい。いくつかの態様においては、保護モジュール１０２は、ＣＡＮバス上のメッセージに含まれているＩＤに基づいて、傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定してもよい。保護モジュール１０２は、傍受されたメッセージ、および判定された少なくとも１つの受信側ＥＣＵを示す情報を、ログ３０４に保存してもよい。いくつかの態様においては、保護モジュール１０２は、傍受されたメッセージの傍受時刻に対応するタイムスタンプを、ログに保存してもよい。

メッセージを傍受する過程で、ステップ５２４において、保護モジュール１０２は、ログ３０４を用いて、受信したルールの適用条件をチェックする。１つの態様においては、保護モジュール１０２は、ログに保存されているメッセージと情報がルールの少なくとも１つの条件を満たすか否かに基づいて、車両へのコンピュータ攻撃を検出してもよい。いくつかの態様においては、さらにログ内のタイムスタンプに基づいて、コンピュータ攻撃を検出する。１つの例においては、ルールの少なくとも１つの条件は、車両の走行期間中のログの中に、定義された一群のメッセージが存在するということを規定する。いくつかの態様においては、ルールの少なくとも１つの条件は、メッセージの受信側である少なくとも１つの受信側ＥＣＵを示す情報が、定義された一群のＥＣＵと一致するということをさらに規定する。いくつかの態様においては、ルールの少なくとも１つの条件は車両の走行状態をさらに規定し、それによって、車両が走行中であると判定されるとルールが適用され、車両が走行中ではないと判定されるとルールが不適用とされるようにするものである。例えば、車両の走行中に上記の定義された一群のＣＡＮメッセージが到着した場合、ルール適用の条件は満たされるが、車両が走行中でない場合は、ルールは適用されない。それは、後者のケースでは、そのようなメッセージの受信と脆弱性の悪用やコンピュータ攻撃との関連はないとの結論を下すことができるからである。他の一例においては、ルールの少なくとも１つの条件は、定義された順番で配列された定義された一群のメッセージがログの中に存在し、かつ定義された期間中に当該メッセージが傍受されたということをさらに規定する。

少なくとも１つのルール適用の条件が満たされたら、ステップ５２５において、ルール適用時の処置を実行することによって、ＭＴに対するコンピュータ攻撃が阻止される。ルール適用の条件が満たされない場合、ログ３０４のエントリはコンピュータ攻撃の形跡を含んでいない（５３１）。

１つの態様においては、保護モジュール１０２は、ルールに応じた処置を実行することによって、車両に対するコンピュータ攻撃を阻止してもよい。例えば、ルールは、傍受されたメッセージの一部が第１の受信側への定義された一群のメッセージと一致すると判定された場合、すべてのメッセージが第１通信バス上を第１の受信側へ送信されないよう阻止するという処置を実行することを規定してもよい。

１つの態様においては、車両の補助電子システムのＥＣＵのリスト上の少なくとも１つのＥＣＵを切断するという決定に基づいて、少なくとも１つのＥＣＵを切断するコマンドを含むメッセージを少なくとも１つのＥＣＵに送信することによって、コンピュータ攻撃を阻止してもよい。例えば、上記のジープの例を使えば、ＥＣＵのＡＢＳを切断してもよく、例えば、その結果、上記のコンピュータ攻撃は発生しなくなる。他の態様においては、車両の主電子システムのＥＣＵのリスト上の少なくとも１つのＥＣＵに対するセーフティモードを有効にするコマンドを含むメッセージを少なくとも１つのＥＣＵに送信することによって、コンピュータ攻撃を阻止してもよい。

他の態様においては、少なくとも１つのメッセージのゲートウェイを介した車両の第１通信バスから第２通信バスへの送信を阻止することによって、コンピュータ攻撃を阻止してもよい。例えば、図３のネットワークアーキテクチャ例の場合、セントラルゲートウェイ１０１は、例えば、ＣＡＮ−Ｂバス１５２とＣＡＮ−Ｃバス１５３の間の、１つのサブネットワークから他のサブネットワークへのメッセージの送信を阻止してもよい。いくつかの態様においては、同一第１通信バス上で通信可能に接続されたＥＣＵ間で、少なくとも１つのメッセージ伝送を阻止することによって、コンピュータ攻撃を阻止してもよい。１つの実現形態においては、少なくとも１つのメッセージ伝送の阻止は、保護モジュール１０２がビット0の配列をバス上に伝送することで、少なくとも１つのメッセージと異なる値がバス上で生じ、メッセージのチェックサムの不一致をもとに受信側ＥＣＵにその少なくとも１つのメッセージを無視させることで、達成することができる。

言うまでもなく、ステップ５２１で受信したルールは、ステップ５０１から５０４の実施結果としてだけではなく、その他の場合でも作成可能である。例えば、サーバ３０３上、または、直接、ＭＴ３０１上でＭＴのセキュリティ監査を実施して、１つ以上のＥＣＵにおいて脆弱性を発見してもよい。ここでいう脆弱性は、ハッカーに悪用されたものでなくてもよい。さらに他の例においては、外部の調査員が、１つ以上のＥＣＵにおける脆弱性を発見して、それを製造者に報告することもある。その結果、該当するＥＣＵの更新版をリリースする前に、発見された脆弱性が悪用される恐れを防止するために、保護モジュール１０２のためのルールが作成される。ルールは、サーバ３０３が保護モジュール１０２に送信してもよく、あるいは、ＭＴのネットワークインターフェースを用いて、診断インターフェース１５５などを介して、サービスセンターなどで、ダウンロードしてもよい。

１つの特定の態様においては、コンピュータ攻撃の阻止５２５の後、ステップ５３２において、ＭＴの運転者にも通知してもよい。さらに他の特定の態様においては、ＭＴの運転者は、コンピュータ攻撃において使用されたＥＣＵモジュールの切断を許可するなどの、一連の処置を実行する必要があるかもしれない。

コンピュータ攻撃の実行の可能性を是正する更新版をＥＣＵの供給業者から受領して、該当するＥＣＵに更新版をインストールした後、スクリプトをサーバ３０３から入手して、適さなくなったルールを削除するよう実行してもよい（ステップ５３３）。１つの態様においては、ＥＣＵの脆弱性にパッチを当てるように構成されたソフトウェア更新版を車両の１つ以上のＥＣＵに適用した場合、保護モジュール１０２は、車両に対するコンピュータ攻撃を検出するための１つ以上のルールを削除してもよい。

図６は、ＣＡＮプロトコルのフレームのフォーマットを示す図である。図示したように、フレーム、すなわちメッセージは、バス内のメッセージの優先度を表す一意的な識別子である（例えば、11ビットの）識別子フィールドを含んでもよい。メッセージは、データフレームではドミナントな値（すなわち、値0）を、あるいは、リモート要求フレームではリセッシブな値（例えば、値1）を示す（例えば、1ビットの）遠隔送信要求（Remote Transmission Request：ＲＴＲ）フィールドをさらに含んでもよい。メッセージは、メッセージフレームに含まれるデータのバイト数を示すデータ長コード（Data Length Code：ＤＬＣ）フィールドをさらに含んでもよい。メッセージは、送信対象のデータを収容するデータフィールドを含んでいる。メッセージ中の追加フィールドには、ＣＲＣフィールド、ＡＣＫスロット、およびフレーム終了（End of Frame）指示を含んでもよい。

図７は、車両の電子システムに対する攻撃を検出するためのシステムおよび方法の各態様を態様例に従って実現可能なコンピュータシステム２０の例を示す図である。１つの特定の態様においては、コンピュータシステムを用いて、サーバ３０３、およびＭＴの電子システムを実現してもよい。また、他の特定の態様においては、専用集積回路を用いて、ＭＴの電子システムを実現してもよい。さらに他の特定の態様においては、専用コンピュータを用いて、ＭＴの電子システムを実現してもよい。

図示のように、コンピュータシステム２０（パーソナルコンピュータでもサーバでもよい）は、中央処理装置２１、システムメモリ２２、および、中央処理装置２１に付随するメモリなどの各種システム構成要素を接続するシステムバス２３を含んでいる。当業者には理解されるように、システムバス２３は、バスメモリまたはバスメモリコントローラ、周辺バス、および、他のいかなるバスアーキテクチャとも相互作用可能なローカルバスを備えていてもよい。システムメモリは固定記憶装置（ＲＯＭ）２４とランダムアクセスメモリ（Random-access Memory：ＲＡＭ）２５を含んでいてもよい。基本入出力システム（Basic Input/Output System：ＢＩＯＳ）２６は、ＲＯＭ２４を用いてオペレーティングシステムをロードするときの手順などの、コンピュータシステム２０の要素間の情報転送の基本的手順を記憶していてもよい。

また、コンピュータシステム２０は、データを読み書きするためのハードディスク２７、リムーバブル磁気ディスク２９を読み書きするための磁気ディスクドライブ２８、および、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、その他の光媒体などのリムーバブル光ディスク３１を読み書きするための光学ドライブ３０を備えていてもよい。ハードディスク２７、磁気ディスクドライブ２８、および光学ドライブ３０は、それぞれ、ハードディスクインターフェース３２、磁気ディスクインターフェース３３、および光学ドライブインターフェース３４を介して、システムバス２３と接続されている。これらのドライブおよび対応するコンピュータ情報媒体は、コンピュータシステム２０のコンピュータ命令、データ構造体、プログラムモジュール、およびその他のデータを記憶する、独立の電源で動作するモジュールである。

態様の一例は、コントローラ５５を介してシステムバス２３と接続されたハードディスク２７、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用するシステムを備えている。コンピュータで読み取り可能な形式でデータの保存が可能ないずれの種類の媒体５６（半導体ドライブ、フラッシュメモリカード、デジタルディスク、ランダムアクセスメモリ（ＲＡＭ）など）も利用できることは、当業者には理解されるであろう。

コンピュータシステム２０は、オペレーティングシステム３５が記憶されるファイルシステム３６の他に、追加的なプログラムアプリケーション３７、その他のプログラムモジュール３８、およびプログラムデータ３９を有する。コンピュータシステム２０のユーザは、キーボード４０、マウス４２、あるいは、その他、例えば、マイクロフォン、ジョイスティック、ゲームコントローラ、スキャナなどを含むがそれらに限られない当業者に公知の入力装置を使用して、コマンドおよび情報を入力することができる。そのような入力装置は、一般に、コンピュータシステム２０に、システムバスと接続されたシリアルポート４６を通して差し込まれるが、当業者は、入力装置を、例えば、限定はされないが、パラレルポート、ゲームポート、あるいはユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）などの他の方法で接続してもよいことを理解するであろう。モニタ４７または他の種類の表示装置も、ビデオアダプタ４８などのインターフェースを介してシステムバス２３と接続してもよい。パーソナルコンピュータは、モニタ４７に加えて、ラウドスピーカ、プリンタなどの他の周辺出力装置（図示せず）を備えてもよい。

コンピュータシステム２０を、１台以上のリモートコンピュータ４９とのネットワーク接続を用いて、ネットワーク環境下で動作させてもよい。リモートコンピュータ４９は、上記コンピュータシステム２０の特徴説明の中で述べた要素のほとんどまたは全部を備えたローカルコンピュータワークステーションまたはサーバであってもよい。例えば、ルータ、ネットワークステーション、ピアデバイス、その他のネットワークノードなどを含むがそれらに限られないその他の装置がコンピュータネットワークの中に存在してもよい。

ネットワーク接続によって、ローカルエリアコンピュータネットワーク（Local-Area Computer Network：ＬＡＮ）５０や広域コンピュータネットワーク（Wide-Area Computer Network：ＷＡＮ）を形成することができる。そのようなネットワークは企業コンピュータネットワークや社内ネットワークで利用され、一般に、インターネットにアクセスできる。ＬＡＮまたはＷＡＮネットワークにおいては、パーソナルコンピュータ２０は、ネットワークアダプタまたはネットワークインターフェース５１を介してローカルエリアネットワーク５０と接続されている。ネットワークを利用する場合、コンピュータシステム２０は、インターネットのような広域コンピュータネットワークとの通信を可能にするモデム５４またはその他の当業者に公知のモジュールを採用してもよい。モデム５４は、内部装置であっても外部装置であってもよいが、シリアルポート４６によってシステムバス２３と接続してもよい。上記ネットワーク接続は、１台のコンピュータが通信モジュールを使って他のコンピュータとの接続を確立する数多くの広く理解されている方法の非限定例であるということは、当業者には理解されるであろう。

様々な態様において、本明細書で説明したシステムおよび方法は、ハードウェア、ソフトウェア、ファームウェア、あるいはそれらの任意の組み合わせの中に実現されてもよい。ソフトウェア中に実現された場合、この方法は、非一時的なコンピュータ読み取り可能な媒体上に、１つ以上の命令またはコードとして記憶されてもよい。コンピュータ読み取り可能な媒体には、データストレージが含まれる。一例として、限定はされないが、そのようなコンピュータ読み取り可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、フラッシュメモリ、あるいは他の種類の電気的、磁気的、または光学的記憶媒体、もしくは、所望のプログラムコードを命令やデータ構造体の形で伝送または記憶するために利用可能で汎用コンピュータのプロセッサからアクセス可能な、その他の任意の媒体を含むことができる。

様々な態様において、本開示で説明したシステムおよび方法は、モジュールによって処理することができる。本明細書で使われている用語「モジュール」とは、例えば、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（Field-Programmable Gate Array：ＦＰＧＡ）などのハードウェア、あるいは、例えば、モジュールの機能を実行するマイクロプロセッサシステムおよび命令一式などのハードウェアとソフトウェアの組合せによって実行される、実装置、構成要素、または構成要素の配置のことであり、これらは（実行中に）マイクロプロセッサシステムを専用装置に変換する。モジュールは、特定の機能をハードウェアのみで実現し、その他の機能をハードウェアとソフトウェアの組み合わせによって実現する、上記２つの組み合わせとしても実現することができる。特定の実現形態においては、少なくとも一部、場合によっては全部のモジュールが、コンピュータのプロセッサ上（例えば、上記図７により詳細に示されているもの）で実行されてもよい。したがって、各モジュールは各種の適切な構成の中に実現可能であり、本明細書に例示したいかなる特定の実現形態にも限定されるべきではない。

明確化のために、本明細書は各態様の定型的な特徴のすべては示していない。本開示の実際の実現形態のいかなる開発においても、開発者の具体的目的を達成するために、実現形態に特有の多くの決定をする必要があり、具体的目的は、実現形態ごとおよび開発者ごとに異なるということが理解されるであろう。そのような開発努力は複雑で多くの時間を要するものであるが、それにもかかわらず、本開示から利益を得る当業者にとって、定型的な技術的取り組みであることが理解される。

本明細書で用いている表現や用語は説明上のものであって、限定のためではなく、本明細書の用語や表現は、当業者が、関連技術の熟練者の知識と組み合わせて、本明細書が提供する教示や手引きの観点から解釈すべきものと理解すべきである。加えて、明示的記載がない限り、本明細書や請求の範囲におけるいかなる用語も、一般的でない、あるいは特別な意味を持つものとみなされることは意図されていない。

本明細書に開示された様々な態様は、本明細書で例示により言及された公知のモジュールと均等な現在および将来の公知の均等物を包含する。加えて、態様および応用例を図示し、かつ、説明してきたが、本明細書に開示された発明の概念から逸脱することなく、上述したよりも多くの変更が可能であることは、この開示の利益を有する当業者には明らかであろう。

Claims (20)

1. 車両の電子システムに対する攻撃を阻止する、コンピュータ上で実現される方法であって、
   車両の複数の電子制御ユニット（Electronic Control Units：ＥＣＵ）の間の第１通信バス上で送信される複数のメッセージを傍受し、
   どのＥＣＵが前記第１通信バスと通信可能に接続されているかに基づいて、前記傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定し、
   前記傍受されたメッセージ、および、前記判定された少なくとも１つの受信側ＥＣＵを示す情報をログに保存し、
   コンピュータ攻撃に使用された悪意あるメッセージおよび当該悪意あるメッセージの受信側である少なくとも１つのＥＣＵに関する情報から成る１以上の侵害指標に依存するルールの少なくとも１つの条件を、前記ログに保存されたメッセージおよび情報が満たしていることを基に、前記車両に対するコンピュータ攻撃を検出し、
   前記ルールに応じた処置を実行することによって、前記車両に対する前記コンピュータ攻撃を阻止する、
   方法。
2. 前記第１通信バスは、コントローラエリアネットワーク（Controller Area Network：ＣＡＮ）バス、ローカル相互接続ネットワーク（Local Interconnect Network：ＬＩＮ）、メディア指向システムトランスポート（Media Oriented Systems Transport：ＭＯＳＴ）バス、フレックスレイ（FlexRay）バス、およびイーサネット（Ethernet）バスのうち少なくとも１つを含み、前記第１通信バス上を送信されるメッセージは、前記通信バスと通信可能に接続された前記ＥＣＵのすべてにブロードキャストされる、
   請求項１に記載の方法。
3. 前記傍受されたメッセージの傍受時刻に対応するタイムスタンプを前記ログに保存し、前記ログ内のタイムスタンプにさらに基づいて前記コンピュータ攻撃を検出することをさらに含む、
   請求項１に記載の方法。
4. 前記ルールの前記少なくとも１つの条件は、前記車両の走行期間中に、定義された一群のメッセージが前記ログ内に存在することを規定する、
   請求項１に記載の方法。
5. 前記ルールの前記少なくとも１つの条件は、前記メッセージの受信側である前記少なくとも１つの受信側ＥＣＵを示す前記情報が、定義された一群のＥＣＵと一致することをさらに規定する、
   請求項４に記載の方法。
6. 前記ルールの前記少なくとも１つの条件は、前記車両が走行中であると判定されると前記ルールが適用され、前記車両が走行中ではないと判定されると前記ルールが不適用とされるように、前記車両の走行状態をさらに規定する、
   請求項４に記載の方法。
7. 前記ルールは、前記傍受されたメッセージの一部が第１の受信側への定義された一群のメッセージと一致すると判定された場合、すべてのメッセージが前記第１通信バス上を前記第１の受信側へ送信されないよう阻止すると規定する、
   請求項１に記載の方法。
8. 前記ルールの前記少なくとも１つの条件は、定義された順番で並べられた定義された一群のメッセージがログ内に存在し、かつ定義された期間中に傍受されたことをさらに規定する、
   請求項１に記載の方法。
9. 前記ルールに応じた処置を実行することによって前記車両のコンピュータ攻撃を阻止することは、
   前記車両の補助電子システムのＥＣＵのリスト上にある少なくとも１つのＥＣＵを切断するコマンドを含むメッセージを、前記少なくとも１つのＥＣＵに送信することをさらに含む、
   請求項１に記載の方法。
10. 前記ルールに応じた処置を実行することによって前記車両のコンピュータ攻撃を阻止することは、
    前記車両の主電子システムのＥＣＵのリスト上にある少なくとも１つのＥＣＵに対するセーフティモードを有効にするコマンドを含むメッセージを、前記少なくとも１つのＥＣＵに送信することをさらに含む、
    請求項１に記載の方法。
11. 前記ルールに応じた処置を実行することによって前記車両のコンピュータ攻撃を阻止することは、
    ゲートウェイを介した前記車両の前記第１通信バスから第２通信バスへの少なくとも１つのメッセージの送信を阻止することをさらに含む、
    請求項１に記載の方法。
12. 前記ルールに応じた処置を実行することによって前記車両のコンピュータ攻撃を阻止することは、
    同一の第１通信バス上で通信可能に接続されたＥＣＵ間の少なくとも１つのメッセージの送信を阻止することをさらに含む、
    請求項１に記載の方法。
13. ビット0の配列を前記バス上で送信することによって、前記少なくとも１つのメッセージと異なる値が前記バス上で生じ、前記メッセージのチェックサムの不一致をもとに受信側ＥＣＵに前記少なくとも１つのメッセージを無視させることで、ＥＣＵ間の少なくとも１つのメッセージの前記送信を阻止する、
    請求項１２に記載の方法。
14. ＥＣＵの脆弱性にパッチを当てるように構成されたソフトウェア更新版を前記車両の１つ以上のＥＣＵに適用した場合、前記車両に対するコンピュータ攻撃を検出するための前記ルールを削除することをさらに含む、
    請求項１に記載の方法。
15. 前記ルールを適用する条件は少なくとも１つのＥＣＵの状態に依存する、
    請求項１に記載の方法。
16. 前記ルールを適用する条件は少なくとも１つの車両のセンサの指標に依存し、前記センサの指標は、少なくとも１つのＥＣＵが、車両の動きに影響を与える動作を実行した時を示す
    請求項１に記載の方法。
17. 車両の電子システムに対する攻撃を阻止するコンピュータシステムであって、
    複数の電子制御ユニット（Electronic Control Units：ＥＣＵ）と、
    前記複数のＥＣＵを通信可能に接続する第１通信バスと、
    前記複数のＥＣＵ間の前記第１通信バス上に伝送される複数のメッセージを傍受し、
    どのＥＣＵが前記第１通信バスと通信可能に接続されているかに基づいて、前記傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定し、
    前記傍受されたメッセージ、および、前記判定された少なくとも１つの受信側ＥＣＵを示す情報をログに保存し、
    コンピュータ攻撃に使用された悪意あるメッセージおよび当該悪意あるメッセージの受信側である少なくとも１つのＥＣＵに関する情報から成る１以上の侵害指標に依存するルールの少なくとも１つの条件を、前記ログに保存されたメッセージおよび情報が満たしていることを基に、前記車両に対するコンピュータ攻撃を検出し、
    前記ルールに応じた処置を実行することによって前記車両のコンピュータ攻撃を阻止する、
    ハードウェアプロセッサと、
    を備えるコンピュータシステム。
18. 前記第１通信バスは、コントローラエリアネットワーク（Controller Area Network：ＣＡＮ）バス、ローカル相互接続ネットワーク（Local Interconnect Network：ＬＩＮ）、メディア指向システムトランスポート（Media Oriented Systems Transport：ＭＯＳＴ）バス、フレックスレイ（FlexRay）バス、およびイーサネット（Ethernet）バスのうち少なくとも１つ含み、前記第１通信バス上を送信されるメッセージは、前記第１通信バスと通信可能に接続された前記ＥＣＵのすべてにブロードキャストされる、
    請求項１７に記載のコンピュータシステム。
19. 前記ルールの前記少なくとも１つの条件は、前記車両の走行期間中に、定義された一群のメッセージが前記ログ内に存在することを規定し、
    前記ルールの前記少なくとも１つの条件は、前記メッセージの受信側である前記少なくとも１つの受信側ＥＣＵを示す前記情報が、定義された一群のＥＣＵと一致することをさらに規定し、かつ、
    前記ルールの前記少なくとも１つの条件は、前記車両が走行中であると判定されると前記ルールが適用され、前記車両が走行中ではないと判定されると前記ルールが不適用とされるように、前記車両の走行状態をさらに規定する、
    請求項１７に記載のコンピュータシステム。
20. 車両の電子システムに対する攻撃を阻止する、コンピュータ実行可能命令を含む非一過性のコンピュータ読み取り可能な媒体であって、
    車両の複数の電子制御ユニット（Electronic Control Units：ＥＣＵ）の間の第１通信バス上で送信される複数のメッセージを傍受し、
    どのＥＣＵが前記第１通信バスと通信可能に接続されているかに基づいて、前記傍受されたメッセージの受信側である少なくとも１つの受信側ＥＣＵを判定し、
    前記傍受されたメッセージ、および、前記判定された少なくとも１つの受信側ＥＣＵを示す情報をログに保存し、
    コンピュータ攻撃に使用された悪意あるメッセージおよび当該悪意あるメッセージの受信側である少なくとも１つのＥＣＵに関する情報から成る１以上の侵害指標に依存するルールの少なくとも１つの条件を、前記ログに保存されたメッセージおよび情報が満たしていることを基に、前記車両に対するコンピュータ攻撃を検出し、
    前記ルールに応じた処置を実行することによって、前記車両に対する前記コンピュータ攻撃を阻止する、
    命令を含む、媒体。

Images