(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-23
(45)【発行日】2022-03-31
(54)【発明の名称】データ解析装置、データ解析方法及びプログラム
(51)【国際特許分類】
H04L 12/28 20060101AFI20220324BHJP
B60R 16/02 20060101ALI20220324BHJP
G06F 21/55 20130101ALI20220324BHJP
H04L 43/08 20220101ALI20220324BHJP
【FI】
H04L12/28 100A
B60R16/02 660W
G06F21/55 320
H04L43/08
(21)【出願番号】P 2018161560
(22)【出願日】2018-08-30
【審査請求日】2021-03-10
(32)【優先日】2018-01-22
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】100109210
【氏名又は名称】新居 広守
(74)【代理人】
【識別番号】100137235
【氏名又は名称】寺谷 英作
(74)【代理人】
【識別番号】100131417
【氏名又は名称】道坂 伸一
(72)【発明者】
【氏名】佐々木 崇光
(72)【発明者】
【氏名】高橋 良太
(72)【発明者】
【氏名】芳賀 智之
【審査官】安藤 一道
(56)【参考文献】
【文献】特開2017-111796(JP,A)
【文献】特開2017-108351(JP,A)
【文献】特表2017-514189(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 12/28
H04L 43/00
B60R 16/02
G06F 21/55
(57)【特許請求の範囲】
【請求項1】
1本以上の
ネットワークを含む車載ネットワークを搭載する第一車両及び第二車両
における、少なくとも異常データを特定する情報を
含む車載ネットワークの異常を解析した結果である異常解析結果を
前記第一車両及び前記第二車両のそれぞれから取得するデータ取得部と、
前記第一車両及び前記第二車両のそれぞれについて、
取得した前記異常解析結果を用いて、
前記車載ネットワークに接続されるECU(Electronic Control Unit)のう
ち異常データ
を送信した可能性が高いECUを一次ECU
として特定し、
前記1本以上の
ネットワークのうち、前記一次ECUが接続されている
ネットワークに接続されている複数のECUを二次ECU群として特定し、
前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる
共通のECUを異常関連ECUとして特定し、
少なくとも前記異常関連ECUを示す情報を出力する関連ECU特定部と
を備えるデータ解析装置。
【請求項2】
前記第一車両及び前記第二車両は、
(1)所定期間内の走行地域が異なること、
(2)車種が異なること、
(3)メーカーが異なること、
(4)前記車載ネットワークの構成が異なること、及び
(5)前記
異常データが生成された時間帯が異なること
のいずれか一つ又は複数の組み合わせからなる条件を満たす、
請求項1に記載のデータ解析装置。
【請求項3】
前記関連ECU特定部はさらに、前記データ解析装置のユーザに、当該ユーザが持つアクセス権限に応じて、前記一次ECU、前記二次ECU群及び前記
異常データの少なくとも一部を出力する、
請求項1又は2に記載のデータ解析装置。
【請求項4】
前記
共通のECUとは、
(1)機種が同一であること、
(2)メーカーが同一であること、
(3)搭載するプロセッサの機種が同一であること、
(4)前記プロセッサのファームウェアが同一であること、及び
(5)前記プロセッサの製造メーカーが同一であること
のいずれか一つ又は複数の組み合わせである、
請求項1に記載のデータ解析装置。
【請求項5】
プロセッサ及びメモリを備えるコンピュータに、
1本以上の
ネットワークを含む車載ネットワークを搭載する第一車両及び第二車両
における、少なくとも異常データを特定する情報を
含む車載ネットワークの異常を解析した結果である異常解析結果を
前記第一車両及び前記第二車両のそれぞれから取得させ、
前記第一車両及び前記第二車両のそれぞれについて、
取得した前記異常解析結果を用いて、
前記車載ネットワークに接続されるECU(Electronic Control Unit)のう
ち異常データ
を送信した可能性が高いECUを一次ECU
として特定させ、
前記1本以上の
ネットワークのうち、前記一次ECUが接続されている
ネットワークに接続されている複数のECUを二次ECU群として特定させ、
前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる
共通のECUを異常関連ECUとして特定させ、
少なくとも前記異常関連ECUを示す情報を出力させる、
プログラム。
【請求項6】
プロセッサ及びメモリを備えるコンピュータに実施させるデータ解析方法であって、
1本以上のネットワークを含む車載ネットワークを搭載する第一車両及び第二車両における少なくとも異常データを特定する情報を含む車載ネットワークの異常を解析した結果である異常解析結果を前記第一車両及び前記第二車両のそれぞれから取得させ、
前記第一車両及び前記第二車両のそれぞれについて、
取得した前記異常解析結果を用いて、
前記車載ネットワークに接続されるECU(Electronic Control Unit)のうち異常データを送信した可能性が高いECUを一次ECUとして特定させ、
前記1本以上のネットワークのうち、前記一次ECUが接続されているネットワークに接続されている複数のECUを二次ECU群として特定させ、
前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる、共通のECUを異常関連ECUとして特定させ、
少なくとも前記異常関連ECUを示す情報を出力させる、
データ解析方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車載ネットワークを備える車両へのサイバー攻撃に対するセキュリティ技術に関する。
【背景技術】
【0002】
車載ネットワークを備える車両へのサイバー攻撃に対するセキュリティ技術が提案されている。例えば、通信規格であるCAN(Controller Area Network)に準拠する車載ネットワークを流れるCANデータを解析することで、CANデータに潜む攻撃の不正データを検知する技術が提案されている(特許文献1及び特許文献2参照)。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2014-146868号公報
【文献】特開2008-114806号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、なりすましの手法等によって高度化した攻撃を検知できない可能性がある。
【0005】
そこで本発明は、高度化した攻撃であってもより高い精度で検知することができるデータ解析装置を提供する。
【課題を解決するための手段】
【0006】
本発明の一態様に係るデータ解析装置は、1本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部と、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるECU(Electronic Control Unit)のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ECUを特定し、前記1本以上のバスのうち、前記一次ECUが接続されているバスに接続されている複数のECUを二次ECU群として特定し、前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる、所定の条件を満たすECUを異常関連ECUとして特定し、少なくとも前記異常関連ECUを示す情報を出力する関連ECU特定部とを備える。
【0007】
なお、これらの包括的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なCD-ROMなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【0008】
本発明の一態様に係るデータ解析装置は、高度化した攻撃であってもより高い精度で検知することができる。
【図面の簡単な説明】
【0009】
【
図1】
図1は、実施の形態1におけるデータ解析装置を含むネットワークセキュリティシステムの概要を説明するための図である。
【
図2】
図2は、
図1に記載のネットワークセキュリティシステムにおける、車載ネットワークの構成例を示す図である。
【
図3】
図3は、上記の車載ネットワークの機能構成例を示すブロック図である。
【
図4】
図4は、
図1に記載のデータ解析サーバの機能構成例を示すブロック図である。
【
図5】
図5は、
図1に記載の車両からデータ解析サーバに提供される車両データのデータ構造の一例を示す図である。
【
図6】
図6は、上記の車両の走行状態を示す車両データのデータ構造の他の例を示す図である。
【
図7】
図7は、
図1に記載の交通基盤システムからデータ解析サーバに提供される車外データのデータ構造の一例を示す図である。
【
図8】
図8は、実施の形態1におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。
【
図9】
図9は、実施の形態1において、車両で異常が発生したと判断される場合のシーケンス図である。
【
図10】
図10は、実施の形態1において、交通基盤システムで異常が発生したと判断される場合のシーケンス図である。
【
図11】
図11は、実施の形態1における車両データ解析装置による処理の手順の一例を示すフロー図である。
【
図12】
図12は、実施の形態1における交通基盤システムによる処理の手順の一例を示すフロー図である。
【
図13A】
図13Aは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図13B】
図13Bは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図13C】
図13Cは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図13D】
図13Dは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図13E】
図13Eは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図13F】
図13Fは、実施の形態1におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。
【
図14】
図14は、実施の形態2において各車両が備える車両データ解析装置による処理の手順の一例を示すフロー図である。
【
図15】
図15は、実施の形態2において異常レベルの判定のために実行される車両データの解析の結果のデータ構造の一例を示す図である。
【
図16A】
図16Aは、実施の形態2におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。
【
図16B】
図16Bは、実施の形態2におけるデータ解析サーバによる処理の手順の他の例を示すフロー図である。
【
図17】
図17は、実施の形態2におけるネットワークセキュリティシステムのシーケンス図である。
【
図18】
図18は、実施の形態3において各車両が備える車両データ解析装置による処理の手順の一例を示すフロー図である。
【
図19】
図19は、実施の形態3におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。
【
図20】
図20は、実施の形態3において用いられる、車載の情報処理装置(ECU)と送信CANメッセージとの関連付けを示すデータの例を示す図である。
【
図21】
図21は、実施の形態3において用いられる、車載ネットワークを構成するバスと各バスに接続されているECUとの関連付けを示すデータの例を示す図である。
【
図22】
図22は、実施の形態3におけるネットワークセキュリティシステムのシーケンス図である。
【
図23】
図23は、実施の形態3におけるネットワークセキュリティシステムのユーザへの情報提示の手順の一例を示すフロー図である。
【発明を実施するための形態】
【0010】
(本発明の基礎となった知見)
本発明者は、「背景技術」の欄において記載したセキュリティ技術に関し、以下の問題が生じることを見出した。
【0011】
今日の自動車は、ECU(Electronic Control Unit)と呼ばれる情報処理装置を複数備える。これらのECUは安全性、利便性又は快適性の向上のための様々な機能を発揮し、また、CANネットワーク等の車載ネットワークを介してデータをやり取りして連携し、自動運転を含むより高度な機能の実現も可能である。なお、本開示でのECUの語は、各々の用途に応じてIVI(In-Vehicle Infotainment)、TCU(Telematics Communication Unit)、ゲートウェイ等の他の名称で呼ばれる、車載ネットワークに接続されてデータを送信又は受信する各種の機器も含めて指して用いられる。
【0012】
車両へのサイバー攻撃には、例えば車載ネットワークに接続された不正な機器、又はプログラムが不正に書き換えられたECUから攻撃データを流すことでその車両の機能を混乱させる手法が従来ある。特許文献1又は2に記載の技術は、そのような攻撃手法への対抗手段として提案されるものである。
【0013】
しかしながら、従来技術は対象車両の正常データと攻撃データを比べることで攻撃データを検知する技術であり、正常データを高度に模した攻撃データに対しては、検知が困難であるという課題がある。
【0014】
また従来技術は、送信された不正データを検知して攻撃による悪影響を防ぐことはできても、不正データを送信している機器の特定は対象としておらず、不正データを送信する機器の停止などのより根本的な解決が困難な場合もある。
【0015】
また、さらに高度な機能を実現するために、他の車両又は交通基盤システム等の外部と、直接、又はインターネット等の通信ネットワークを介してデータを送受信する車載ネットワークを搭載する車両も登場している。このように拡大したデータの流通経路は、不正なデータの伝播経路にもなり得、被害を拡大させかねない。しかしながら従来技術は、被害拡大に繋がる不正データの伝搬を防止することができない。
【0016】
このような問題を解決するために、本発明の一態様に係るデータ解析装置は、1本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部と、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるECU(Electronic Control Unit)のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ECUを特定し、前記1本以上のバスのうち、前記一次ECUが接続されているバスに接続されている複数のECUを二次ECU群として特定し、前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる、所定の条件を満たすECUを異常関連ECUとして特定し、少なくとも前記異常関連ECUを示す情報を出力する関連ECU特定部とを備える。
【0017】
例えば、前記第一車両及び前記第二車両は、(1)所定期間内の走行地域が異なること、(2)車種が異なること、(3)メーカーが異なること、(4)前記車載ネットワークの構成が異なること、及び(5)前記データが生成された時間帯が異なることのいずれか一つ又は複数の組み合わせからなる条件を満たしてもよい。
【0018】
これにより、異常に対して条件の異なる車両同士で比較をすることで、攻撃に関連するECUの特定がより効率的に行え、早急な対策が可能になる。
【0019】
例えば、前記関連ECU特定部はさらに、前記データ解析装置のユーザに、当該ユーザが持つアクセス権限に応じて、前記一次ECU、前記二次ECU群及び前記データの少なくとも一部を出力してもよい。
【0020】
これにより、例えばサイバー攻撃に対する脆弱性等の異常を有するECUの絞り込みに利用された情報であって、異常の解消などの問題解決に利用されるもののうち、ユーザ間で秘匿されるべき情報の秘匿性を保つことができる。
【0021】
例えば、前記所定の条件は、(1)機種が同一であること、(2)メーカーが同一であること、(3)搭載するプロセッサの機種が同一であること、(4)前記プロセッサのファームウェアが同一であること、及び(5)前記プロセッサの製造メーカーが同一であることのいずれか一つ又は複数の組み合わせであってもよい。
【0022】
これにより、サイバー攻撃に対する脆弱性等の問題を共通に抱える可能性の高いECUが絞り込まれ、早急な対策が可能になる。
【0023】
なお、これらの包括的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なCD-ROM等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
【0024】
以下、実施の形態に係るデータ解析装置について、図面を参照しながら説明する。
【0025】
なお、以下の各実施の形態は、いずれも本発明の包括的又は具体的な例を示すものである。したがって、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ(工程)及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
【0026】
(実施の形態1)
[1.概要]
図1は、実施の形態1におけるデータ解析装置を含むネットワークセキュリティシステムの概要を説明するための図である。ネットワークセキュリティシステム1は、V2X通信をする車両及びその通信相手を攻撃対象とするサイバー攻撃への対策のためのセキュリティシステムである。
図1に示されるように、ネットワークセキュリティシステム1では、車両10A及び車両10B(以下、これらをまとめて、又は区別せずに一方を指して車両10ともいう)、データ解析サーバ200及び交通基盤システム300は、インターネットなどの通信回線を用いて構築される通信ネットワーク900を介してデータをやり取りする。また、車両10A及び車両10Bは相互に、また交通基盤システム300と直接データをやり取りする。なお、交通基盤システム300とは、信号機、ETC(Electronic Toll Collection)ゲート、交通量計測装置等の、車両10が走行する道路沿いに設置される各種の交通基盤関連機器(本開示ではこれらの機器を路側機ともいう、図示なし)、及びこれらの路側機と通信し、制御及び管理するためのシステムを指す。
【0027】
ネットワークセキュリティシステム1では、車両10又は交通基盤システム300を対象とするサイバー攻撃が精度よく検知され、被害の拡大を抑えるための措置が図られる。以下、このようなサイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ200によって提供される場合を例に本実施の形態を説明する。
【0028】
[2.構成]
[2-1.車両の情報システム構成]
車両10の情報システム構成について、車両10Aを例に説明する。
図2は、車両10Aが備える車載ネットワーク100の構成例を示す図である。
【0029】
車両10Aは車載ネットワーク100を備える。車両10AからV2X通信で車両10B、データ解析サーバ200及び交通基盤システム300に送信されるデータは、車載ネットワーク100を流れるデータである。
【0030】
車載ネットワーク100は、外部通信装置110、ゲートウェイ120、車両データ解析装置130及び複数のECU150を含む。この例におけるECU150は、情報系、制御系等の機能系統ごとに共通のバスに接続されてひとつの機能系統ネットワークを構成している。これらの機能系統は例であり、車載ネットワーク100には、例えばボディ系統等のさらに別の機能系統が含まれ得る。各ECU150には、図示しない車載のセンサ、スイッチ又はアクチュエータ等の機器が接続され、ECU150は、このセンサが計測した結果を示すセンシングデータをバスに送出したり、センサの計測結果を入力として処理したプログラムが出力する制御信号をスイッチ又はアクチュエータに送出したりする。なお、以下の説明では、車載ネットワーク100がCANネットワークである例を用いることがあるが、本実施の形態及び後述のその変形例は、CAN以外の通信プロトコルに準拠する車載ネットワークにも適用可能である。また、車載ネットワーク100には、異なるプロトコルに準拠するネットワークが混在してもよい。
【0031】
外部通信装置110及びゲートウェイ120もそれぞれECUを用いて実現され、上記のように用途に応じた呼称を用いて示すものである。外部通信装置110は、外部の通信ネットワーク900又は他の車両10Bと通信するための通信モジュールを備える情報処理装置であり、例えばTCUと呼ばれる。ゲートウェイ120は、上記の各機能系統間、及び各機能系統と外部通信装置110との間のデータの転送機能を備え、この転送の際に、必要に応じて通信プロトコルの違いに応じたデータの変換を行う情報処理装置である。
【0032】
車両データ解析装置130は、車載ネットワーク100を流れる車両データを解析し、解析結果をデータ解析サーバ200に提供する。本実施の形態の説明に用いる構成例では、車載ネットワーク100は、ゲートウェイ120が備えるプロセッサがプログラムを実行することで実現される機能的な構成要素である。
図3は、車両データ解析装置130の機能構成をさらに詳細に説明するためのブロック図である。
【0033】
車両データ解析装置130は、車両データ取得部131、車外データ取得部132、走行状態解析部133、蓄積部135、解析結果送信部136及び車両制御データ送信部137を備える。
【0034】
車両データ取得部131は、車載ネットワーク100を流れる、車両10Aの走行状態を示す車両データを取得する。この走行状態を示す車両データの例には、上記のECU150から送出されるセンシングデータが含まれる。
【0035】
車外データ取得部132は、外部通信装置110がV2X通信で受信したデータを取得する。このデータには、周辺の車両、この例では車両10B、若しくは交通基盤システム300で取得されたデータが含まれる。より具体的には、車両10Aは、車両10Bからは、車両10Bの車載ネットワークを流れる車両データを、交通基盤システム300からは、路側機が有する測定機能又は通信機能によって得られたデータを車外データとして取得する。
【0036】
走行状態解析部133は、車両データ取得部131が取得した車両データを解析し、その結果として車両10Aの走行状態の情報を得る。この情報には、例えば、車速、旋回曲率、加速度、ヨーレート、アクセル開度、操舵量、シフトポジション、車両の位置情報等が含まれ得る。
【0037】
蓄積部135は、車両データ取得部131が取得した車内データ、車外データ取得部132が取得した車外データ、又は走行状態解析部133による解析結果のデータを必要に応じて保持する。この例では、蓄積部135はゲートウェイ120が備える記憶装置を用いて実現される。
【0038】
解析結果送信部136は、走行状態解析部133による解析結果のデータを、外部通信装置110を介してデータ解析サーバ200へ送信する。
【0039】
車両制御データ送信部137は、走行状態解析部133による解析結果又は車外データ取得部132に基づいて、異常の有無又はレベルに応じて実行すべき所定の動作のための指示発する。この指示は、ゲートウェイ120に接続されるバスに送出されて関連するECU150によって受信される。
【0040】
なお、上記のようにゲートウェイ120上にある車両データ解析装置130は、車載ネットワーク100上における車両データ解析装置130の実装形態の一例であり、他の形態で実装されてもよい。例えば車載ネットワーク100に接続される、ゲートウェイ120とは別個の一台以上の情報処理装置を用いて実現されてもよい。
【0041】
また、ネットワークセキュリティシステム1に接続する車両10にとって上記の構成の情報システムが必須というわけではない。例えば、車両10Bが備える車載ネットワーク100上の情報システムは、走行状態解析部133を備えず、解析結果送信部136に代えて、センシングデータ等の未解析の車両データを外部に送信する送信部を備える構成であってもよい。この場合、車両10Bの車両データに基づく走行状態の解析は、車両10Bの外部、例えば車両10Bの車両データを受信するデータ解析サーバ200で実行されてもよい。あるいは、車両10A又は交通基盤システム300で実行されてもよい。車両10Bの走行状態の解析が車両10A又は交通基盤システム300で実行された場合、その結果は、通信ネットワーク900を介してデータ解析サーバ200に提供される。
【0042】
[2-2.データ解析サーバの構成]
次に、データ解析サーバ200の構成について説明する。
図4は、データ解析サーバ200の機能構成例を示すブロック図である。なお、データ解析サーバ200は、プロセッサ及びメモリを備える一台以上のコンピュータ資源を用いて実現される。データ解析サーバ200は、通信ネットワーク900を介して車両10及び交通基盤システム300から受信するデータを解析してサイバー攻撃による異常を検知、又はさらに異常レベルの判定を実行し、必要に応じて車両10又は交通基盤システム300に情報を提供する。このような機能を、データ解析サーバ200は所定のプログラムを実行して提供する。また、このプログラムでは、例えば機械学習によって作成された異常検知モデル、又はさらに分類モデルが用いられる。
【0043】
データ解析サーバ200は、データ取得部210、データ解析部220、判定部230、蓄積部240、関連ECU特定部250、アクセス権管理部260、情報送信部270及び情報表示部280を備える。これらは機能的な構成要素であり、データ解析サーバ200で、プロセッサによって上記の所定のプログラムが実行されることで実現される。
【0044】
データ取得部210は、車両10の走行状態を示す車両データを取得する。ここでの車両10の走行状態を示す車両データとは、例えば上述の車両10Aから送信される、走行状態解析部133による解析の結果のデータである。また、データ解析サーバ200に送信されるデータが上述の車両10Bのように未解析のデータである場合には、データ解析部220によってこのデータに対する解析が行われた結果のデータである。つまりデータ解析部220は、走行状態解析部133と同様の解析を実行する。
【0045】
図5及び
図6は、データ取得部210が取得する、車両10の走行状態を示す車両データのデータ構造の一例を示す図である。
【0046】
図5に示される例では、一定間隔(図示の例では5秒)の異なる時刻に測定された車両10の走行状態を示す値が時系列で格納されている。
図6に示される例では、車両10の走行状態を示す値として、一定期間(図示の例では10分間)にわたる測定値から算出された平均値等が時系列で格納されている。なお、車両データの内容はこれらの例に限定されない。図中の速度、旋回曲率などの各項目は例示の目的で示すものであって必須ではなく、また、さらに他の項目が含まれてもよい。また、各項目の値は、例えば一定期間ごとの最大値と最小値、一定期間内に所定の閾値を超えた又は下回ったか否か、一定期間内に所定の閾値を超えた又は下回った時間長等であってもよい。また、解析結果は、車両10で発生した事象、例えばユーザ又は自動運転システムによる所定の運転操作(例えば発進、停止、ギヤチェンジ)を契機に取得されてもよい。この場合には、発生した事象を示す項目がさらにあってもよい。また
図5及び
図6では、位置情報は経緯度で示されているが、これに限定されない。例えば、車両が走行している場所の地名若しくは道路、区間、交差点名、最寄りのランドマークの名称、若しくは郵便番号等、又はこれらを示す識別情報(例えば道路の区間又はさらにその上下方向を示すID)が用いられてもよい。また、各車両10から送信されるデータには、送信元である車両を一意に識別する識別情報が付加され、データ解析サーバ200は車両データの各件と、この識別情報とを関連付けて管理する。
【0047】
データ取得部210はさらに、交通基盤システム300から、車両10が走行するエリアにおける車両10の車外で認識された状況(以下、車外状況という)を示す車外データを取得する。
【0048】
車外データが示す車外状況とは、より具体的には、例えば道路情報又は交通情報である。
【0049】
図7は、交通基盤システム300からデータ解析サーバ200に提供される車外データのデータ構造の一例を示す図である。
【0050】
図7に示される例では、車外状況を示すデータとして、路側機による一定期間(図示の例では5分間)にわたる測定値から算出された平均値等が時系列で格納されている。このようなデータは路側機におけるセンシングデータの解析の結果であり、この解析は、路側機又は交通基盤システム300において実行されてもよいし、データ解析部220によって解析されてもよい。なお、車外データの内容はこの例に限定されない。図中の制限速度、規制などの各項目は例示の目的で示すものであって必須ではなく、また、さらに他の項目が含まれてもよい。また、各項目の値は、例えば一定期間ごとの最大値と最小値、一定期間内に所定の閾値を超えた又は下回ったか否か、一定期間内に所定の閾値を超えた又は下回った時間長等であってもよい。また、解析結果は、交通基盤システム300で発生した事象、例えば制限速度の変更を契機に取得されてもよい。この場合には、発生した事象を示す項目がさらにあってもよい。なお、
図7の例では、車外状況を示すデータの送信元である各路側機の位置情報として、当該路側機が設置されている道路の区間を示す識別情報である道路IDが用いられている。また、交通基盤システム300から送信される車外データには、車外データを生成した路側機を一意に識別する識別情報が付加されてもよい。
【0051】
判定部230は、データ取得部210が取得した、車両データが示す車両10の走行状態と、車外データが示す車外状況とに不整合があるかを判定し、この判定の結果を出力する。
【0052】
蓄積部240は、データ取得部210が取得した車両データ及び車外データ、判定部230による判定結果のデータ等、データ解析サーバ200の各機能的構成要素が生成した又は用いるデータを、必要に応じて保持する。この例では、蓄積部240はデータ解析サーバ200が備える記憶装置を用いて実現される。
【0053】
関連ECU特定部250は、判定部230によって、車両10で異常の発生があると判定された場合に、この異常に関連するECUを特定する。
【0054】
アクセス権管理部260は、データ取得部210が取得したデータ、データ解析部220による解析結果のデータ、又は判定部230による判定結果等のデータに対する、データ解析サーバ200のユーザのアクセス権を管理する。なお、ここでのデータ解析サーバ200のユーザとは、例えば車両10又はその部品のメーカーである。
【0055】
情報送信部270は、判定部230がした判定の結果に応じた情報を示すデータを、車両10若しくは交通基盤システム300、又はその両方に送信する。情報表示部280は、判定部230がした判定の結果に応じた情報をユーザに表示する。判定の結果に応じた情報については後述する。
【0056】
[3.動作]
次に、本実施の形態においてデータ解析装置の機能を提供するデータ解析サーバ200の動作について説明する。
図8は、データ解析サーバ200による処理の手順の一例を示すフロー図である。また、ネットワークセキュリティシステム1におけるデータ(情報)の流れを示す、
図9及び
図10のシーケンス図もこの説明の中で適宜参照する。また、車両10及び交通基盤システム300において実行される処理の手順を示す
図11及び
図12のフロー図も適宜参照する。
【0057】
データ解析サーバ200では、データ取得部210が、車両10から車両データを、交通基盤システム300から車外データを受信して取得する(ステップS10、S11)。この例では、車両データは、車両10で解析がなされてからデータ解析サーバ200に提供される。
図11は、車両10における車両データの取得からデータ解析サーバ200への送信までの手順を示すフロー図である。また、車外データは、交通基盤システム300で解析がなされてからデータ解析サーバ200に提供される。
図12は、交通基盤システム300における車外データの取得からデータ解析サーバ200への送信までの手順を示すフロー図である。
【0058】
次にデータ解析サーバ200で実行されるステップS12では、車両データと車外データとを比較して、車両10の走行状態と当該車両10の車外状況との間に不整合があるか否かを判定される。この車両データ及び車外データは、この比較の手順までに解析がなされて
図5から
図7に例示されるよう情報が整えられていればよく、その解析の場所(主体)は、各データの提供元であってもよいし、データの提供を受けたデータ解析サーバ200であってもよい。本開示では、この解析の前後を特に区別せず車両データ又は車外データと呼んでいる。なお、車両10の走行状態と当該車両10の車外状況との間の不整合については、例を用いて後述する。
【0059】
ステップS12は、判定部230によって実行される。判定部230は、車両データが示す時刻及び位置情報と、車外データが示す時刻及び位置情報とを用いて、判定対象の車両データと比較する車外データを選択する。時刻又は位置情報が車両データと車外データとで異なる形式で表現されている場合には、蓄積部240に保持されている対応テーブル(図示なし)を参照したり、換算のための計算を実行したりしてもよい。また、判定部230では、時刻情報及び位置情報が必ずしも完全に一致するデータ同士で比較するのではなく、それぞれが部分的に、又は少なくとも一方が重複するデータ同士を比較の対象として選択してもよい。また、重複がなくてもある一件の車両データが含む時刻情報が示す時刻から遡る所定時間内の時刻を示す車外データ、又は遡る所定件数の車外データが比較の対象に選択されてもよい。時間的に近いために現在の交通量、現在の交通規制など現在の車外状況をよりよく反映する可能性の高い車外データを用いることで、より現状に適した異常判定の結果を得ることができる。また、車両データが含む位置情報が示す位置と地理的に近隣(例えば一定の距離若しくは道程範囲内、又は所定のグリッドで画定される領域のうち、同一の領域若しくはさらにその周囲の領域)のエリアの車外状況を示す車外データであれば、車両10の車外状況を示す車外データとして扱い、当該車両データとの比較の対象に選択されてもよい。
【0060】
不整合はないと判定部230が判定した場合(ステップS13でNO)、車両10及び交通基盤システム300のいずれでも、受信した各データから判るサイバー攻撃による異常はないものとして、データ解析サーバ200での処理は終了する。
【0061】
不整合があると判定部230が判定した場合(ステップS13でYES)、判定部230は車両10及び車外データのいずれかに異常が発生しているものと判定する。このように車両データだけでなく、車外データも用いて異常判定することで、車両データ単体で異常判定する場合より高精度に異常を判定することができる。つまり、ある車両Aがサイバー攻撃により不正制御されたケースにおいて、不正制御による走行状態が、当該車両A単体の走行状態としてあり得る範疇のものである場合、車両単体データにより異常を検知することは困難である。例えば、ある車両Aが時速30km/hで走行中に、サイバー攻撃の結果、時速100km/hで走行してしまったとする。このとき、当該車両Aは時速100km/hで走行すること自体はあり得ることであるから、このことだけで異常と判定することはできない。しかしながら、車両データと車外データとを比較することで、このように不正制御の範疇が当該車両単体の走行状態としてあり得る走行状態であった場合でも、異常を検知できるようになる。例えば、先の例において、サイバー攻撃を受けた車両Aの周辺車両がいずれも時速30km/hで走行しているという車外データがあったとする。すると、車両Aの走行状態は、周辺車両と調和的に走行可能な走行状態から明らかに逸脱していることが分かり、車両Aに異常が発生していると判定することができる。
【0062】
また、不整合があると判定部230が判定した場合(ステップS13でYES)、判定部230はさらに、位置情報が示す位置が上記のエリア内にある他の車両10から提供された車両データについて過去に行われた車外データとの比較による判定結果を、蓄積部240から取得する。他の車両10の車両データと車外データとの比較による判定結果は、上述のように、車両データの各件と関連付けて管理され、送信元である車両の識別情報を参照して選択される。また、このとき判定結果が取得される他の車両データは、例えば示す時刻が時間的に近いものから一定件数取得されてもよいし、示す時刻が一定期間遡る範囲にある全件であってもよい。
【0063】
そして判定部230は、不整合のあることを示す結果であった車両データの件数が所定基準以上であるか否かを判定する(ステップS14)。この判定の基準は、例えば50%以上のように割合で設定されてもよいし、具体的な件数の値で設定されてもよいし、又はこれらが併用(例えば30%以上かつ5件以上)されてもよい。
【0064】
不整合のあることを示す結果であった車両データの件数が所定基準未満である場合(ステップS14でNO)、判定部230は、サイバー攻撃による異常が、ステップS43で不整合と判定された車両データの送信元である車両10で発生していると判定する(ステップS15)。判定部230からは、この判定結果が情報送信部270に出力される。この判定結果の入力を受けた情報送信部270は、少なくとも交通基盤システム300に当該車両10を示す情報を送信する(ステップS16)。また、情報送信部270は、当該車両10に、異常発生時の動作を実行させる情報を送信する(ステップS17)。この情報は、単に判定の結果を示す情報であってもよいし、当該車両10に対する制御信号で示されるものであってもよい。
図8では、車両10に送信されるのは制御信号である例が示されている。
【0065】
図8に示される一連の手順で、ステップS14でNOである場合のネットワークセキュリティシステム1におけるデータ(情報)の流れを示すのが
図9である。
【0066】
ステップS16で情報送信部270から送信された、異常な車両10を示す情報(図中「異常車両情報」)を受信した交通基盤システム300では、当該車両10からV2I通信(車両と交通基盤システムとが行う通信)で受信したデータの利用を停止する。サイバー攻撃を受けた車両10から提供される情報は、虚偽の内容を含んでいる可能性がある。つまり、このような情報を用いた判定が交通基盤システム300で行われれば、実際の交通状況に合わない動作をする等の悪影響が出るおそれがある。したがって、交通基盤システム300に、サイバー攻撃を受けて異常が発生している車両10を示す情報が提供されることで、このようなサイバー攻撃の悪影響の拡大が抑えられる。なお、このような情報は、交通基盤システム300のみならず、異常が発生している車両10の周辺を走行する他の車両10にも提供されてもよい。V2V通信(車両と車両とが直接行う通信)を行う車両10では、他の車両10からのデータに基づいて動作の判定が行われることがあり、この判定が虚偽の情報に基づいて行われることを防ぐためである。
【0067】
また、サイバー攻撃を受けている車両10は、異常な動作をする可能性がある。したがって、情報送信部270からこの車両10に上記の情報又は制御信号を送信して、周辺の車両又はそのドライバーに、異常の発生を報知するための動作等を当該車両10にさせることで、事故の発生の可能性を抑えることができる。異常の発生を報知するための動作とは、例えばハザードランプによる警告等である。または、当該車両10が遠隔操作に対応する場合には、退避動作を実行させてもよい。
【0068】
一方、不整合のあることを示す結果であった車両データの件数が所定基準以上である場合(ステップS14でYES)、判定部230は、サイバー攻撃による異常が、ステップS13で車両データと不整合と判定された車外データの送信元である交通基盤システム300又はその一部である路側機で発生していると判定する(ステップS15)。判定部230からは、この判定結果が情報送信部270に出力される。この判定結果の入力を受けた情報送信部270は、少なくとも交通基盤システム300に、例えば当該異常が発生していると判定された車外データを送信した路側機に関する情報を送信する(ステップS19)。路側機に関する情報とは、例えば、当該車外データを生成した異常な路側機を一意に示す識別情報であってもよいし、また、当該車外データが示す位置情報であってもよい。
図8では、交通基盤システム300に送信されるのは、異常な路側機を示す情報である例が示されている。
【0069】
また、
図8に示される一連の手順で、ステップS14でYESである場合のネットワークセキュリティシステム1におけるデータ(情報)の流れを示すのが
図10である。
【0070】
ステップS19で情報送信部270から送信された、異常な車両10を示す情報(図中「異常路側機情報」)を受信した交通基盤システム300では、当該路側機で計測などにより生成された車外データの利用を停止する。これにより、サイバー攻撃の悪影響の拡大が抑えられる。なお、このような情報は、交通基盤システム300のみならず、ステップS13での判定の対象となった車両データを送信した車両10、又は異常な路側機の周辺を走行する他の車両10にも提供されてもよい。V2I通信を行う車両10では、路側機からのデータに基づいて動作の判定が行われることがあり、この判定が虚偽の情報に基づいて行われることを防ぐためである。
【0071】
なお、ここまでの説明では、データ解析サーバ200が車両10から受信した車両データと比較する車外データは交通基盤システム300から提供されたものである例を用いたが、車両データと比較されるデータは交通基盤システム300からのデータに限定されない。例えば、車両10Aの周辺を走行する車両10Bから受信したデータが、車両10Aから受信した車両データと比較する車外データとして用いられてもよい。例えば車両10Bが搭載する周辺を撮影するためのイメージセンサが生成した画像データが解析されて、データ解析サーバ200では、この画像データが示す画像に映る車両10Aの状況と、車両10Aの車載ネットワークから取得された車両データが示す車両10Aの走行状態とが不整合であるか否かが判定されてもよい。また、車両10Aの車両データが示す車両10Aの加減速、操舵等の走行状態と、車両10Bの車両データが示す車両10Bの加減速、操舵等の走行状態とが不整合であるか否かが判定されてもよい。つまり、車両10Bの車両データは、車両10Aとの関係で言えば、車両10Aの車外で認識された状況を示す車外データであり、データ解析サーバ200では、ステップS13での車両10Aの車両データとの比較対象として用いられ得る。また、車両10Aと車両10Bとを入れ替えても同様のことが言える。
【0072】
以下、このような判定が実行される場合も含めて、不整合の具体的な例を挙げる。
【0073】
図13Aから
図13Fは、それぞれ本実施の形態において、データ解析サーバ200による処理の手順の一具体例を示すフロー図である。ただし、いずれも
図8のフロー図との差異はステップS13の不整合に関する判定のステップであるため、他のステップについての説明は省略する。
【0074】
図13AのステップS13Aでは、車内データが示す車両10の走行速度と、車外データが示す、車両10が走行するエリアの制限速度との間での不整合について判定される。この制限速度の情報は、例えば
図7に示されるような交通基盤システム300からの車外データの「制限速度」の欄に含まれているものが利用される。また別の例として、他の車両からデータ解析サーバ200に送信された画像データであってもよい。この場合、この画像データの解析結果に含まれる、制限速度を示す道路標識又は道路標示の表示内容が、車内データが示す車両10の走行速度と比較される。例えばこの走行速度と制限速度との差が所定の大きさ以上である、又は表示内容が示す制限速度について予め定められた所定の速度範囲外である場合に、ステップS13AでYESと判定される。
【0075】
図13BのステップS13Bでは、車内データが示す車両10の走行速度と、車外データが示す、この車両10の周辺を走行している他の車両の走行速度との間での不整合について判定される。この、他の車両の走行速度の情報は、例えば
図7に示されるような交通基盤システム300車外データの「平均走行速度」の欄に含まれるものが利用される。また別の例として、他の車両からデータ解析サーバ200に送信された車内データが示す速度又はその平均であってもよい。このように、ネットワークセキュリティシステム1では、ある車両にとっての車内データは、その他の車両にとっての車外データとして利用される場合もある。例えばこれらの走行速度間との差が所定の大きさ以上である場合に、ステップS13BでYESと判定される。
【0076】
これらの例に示されるように、データ解析サーバ200は、ある一台の車両10の速度が、走行性能に照らせば正常範囲内である場合でも、制限速度又は周囲の車両の走行速度という周囲の状況に照らしても正常であるか又は異常の可能性があるか判定をすることができる。
【0077】
図13CのステップS13Cでは、車内データが示す車両10の操舵角度と、車外データが示す、車両10が走行するエリア(道路)の道路曲率との間での不整合について判定される。この道路曲率の情報は、例えば交通基盤システム300からの車外データに含まれているものが利用される(図示なし)。この場合、車外データに含まれる道路曲率と、車内データが示す車両10の操舵角度とが比較される。例えばこの道路曲率と操舵角度との差が所定の大きさ以上である場合に、ステップS13CでYESと判定される。
【0078】
この例に示されるように、データ解析サーバ200は、ある一台の車両10の操舵角度が、操舵性能に照らせば正常範囲内である場合でも、道路の形状という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。
【0079】
図13DのステップS13Dでは、車内データが示す車両10の走行速度と、車外データが示す、この車両10の周辺を走行している他の車両で計測された当該車両10の走行速度との間での不整合について判定される。この車外データは、他の車両が備えるレーダー等の周囲の物体の相対速度を計測可能な機器のセンシングデータの解析結果として得られる当該車両の速度である。または、上記のような他の車両でのイメージセンサで生成された画像データの解析によって得られてもよい。例えばこれらの走行速度間との差が所定の大きさ以上である場合に、ステップS13DでYESと判定される。
【0080】
この例に示されるように、データ解析サーバ200は、ある一台の車両10の走行速度が、走行性能に照らせば正常範囲内である場合でも、周囲の車両で認識された自車の走行速度という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。
【0081】
図13EのステップS13Eでは、車内データが示す車両10の制動灯の動作状態と、車外データが示す、車両10の制動灯の動作状態の間での不整合について判定される。この場合の車外データは、例えば、車両10の後続車からデータ解析サーバ200に送信された画像データあってもよい。この画像データの解析結果に含まれる、車両10の制動灯の経時的な動作状態が、車両10から送信された車内データが示す車両10の制動灯の経時的な動作状態と比較される。例えばこの動作状態に一定以上の相違がある場合に、ステップS13EでYESと判定される。
【0082】
この例に示されるように、データ解析サーバ200は、ある一台の車両10の制動灯の動作が、仕様上は正常範囲内である場合でも、周囲の車両で認識された自車の制動灯の動作という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。
【0083】
図13FのステップS13Fでは、車内データが示す車両10の走行状態と、車外データが示す、他の車両の走行状態との間での不整合について判定される。この場合の車外データは、例えば、車両10の先行車からデータ解析サーバ200に送信された車内データが示す、この先行車の走行状態(速度、操舵角等)の時系列データであってもよい。つまりこの例でも、ある車両にとっての車内データが、その他の車両にとっての車外データとして利用される。この先行車の車内データの解析結果に含まれる走行状態の時系列データが、車両10の車内データの解析結果に含まれる走行状態の時系列データと比較される。例えばこの走行状態に一定以上の相違がある場合に、ステップS13FでYESと判定される。
【0084】
この例に示されるように、データ解析サーバ200は、ある一台の車両10の走行状態全般が、性能又は仕様に照らせば正常範囲内である場合でも、同じ道路を走る他の車両の走行状態という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。
【0085】
このように、ある車両へのサイバー攻撃の発生についての判定は、当該車両由来のデータ(車両データ)と、交通基盤システム又は他の車両等、判定対象の車両の外部由来のデータであって当該車両が走行する環境又は当該車両の状況を示すデータ(車外データ)とを比較し、その整合性を確認することで、当該車両単体のデータのみで判定するよりも、より高い精度での検知が可能になる。
【0086】
また、精度よくサイバー攻撃が検知されることで、データ通信が頻繁なV2X通信の普及が進んだ状況においても、不正データの拡散による被害の拡大を抑制することができる。
【0087】
また、交通基盤システムも情報化が進むことでサイバー攻撃の対象となる可能性がある。本実施の形態におけるネットワークセキュリティシステム1で実行される異常判定の手法は、その交通基盤システムへのサイバー攻撃の検知の手段としても有用である。そして、このような一連の判定により、車両も交通基盤システムも含めて、サイバー攻撃の検出感度がより高く、その被害の拡大を抑えることができる車社会を実現することができる。
【0088】
なお、上記の説明では、車両へのサイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ200によって提供される場合を例に用いたが、本実施の形態はこれに限定されない。例えば車両10に車載の車両データ解析装置130によって、上述のデータ解析サーバ200に相当する機能が提供されてもよい。例えば、車両データ解析装置130において、外部通信装置110を介するV2X通信で周囲の他の車両又は路側機から取得する車外データが示す状況と、車両データが示す車両10の走行状態との間に不整合があるか否かが判定される。不整合がある場合には、さらに車両10の走行しているエリアでの不整合の発生状況についての情報を、蓄積部135に蓄積されているデータから取得したり、外部通信装置110を介して周辺の車両又は路側機に問い合わせたりして取得してもよい。
【0089】
(実施の形態2)
[1.概要]
V2X通信が実行される状況においてサイバー攻撃の検知の精度を向上させる、別の手法に係る実施の形態を説明する。
【0090】
V2X通信が実行される状況で利用されるネットワークセキュリティシステムでは、データ解析サーバ又は車載の車両データ解析装置で実行された車両データの異常に関する解析で、異常レベル、別の表現をすると、車両におけるサイバー攻撃の発生確度が、中程度という結果になる場合がある。従来の仕組みでは、車両単体のデータからでは、このような車両データは、サイバー攻撃の発生の判定には利用できないか、実用的な確実性をもって利用できるようになるまでに時間がかる。本実施の形態では、このような車両データの解析結果を検証してサイバー攻撃の発生の判定に利用する新たな手法をもって、従来に比べて精度よくかつ迅速な判定を実現する。
【0091】
より具体的には、本実施の形態におけるネットワークセキュリティシステムでは、複数の車両における異常レベルの判定の結果に応じて、対応が即必要ではない中程度の異常としていた状況を、直ちに対応が必要な異常として扱うようにする。
【0092】
本実施の形態も、サイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ200によって提供される場合を例に説明する。構成については、実施の形態1と共通であるため説明を省略し、各構成要素は
図1から
図4に示す参照符号をもって示す。
【0093】
以下、本実施の形態におけるデータ解析サーバ200の動作について説明する。
【0094】
[2.動作]
本実施の形態におけるネットワークセキュリティシステム1では、複数の車両10から、各車両10の車両データ解析装置130で実行された車両データの解析結果に基づいて判定される、サイバー攻撃による異常のレベルを示すデータがデータ解析サーバ200に送信される。
【0095】
図14は、本実施の形態において各車両10が備える車両データ解析装置130による処理の手順の一例を示すフロー図である。
【0096】
車両データ解析装置130は、車載ネットワークを流れる車両データを取得すると(ステップS40)、その車両データを解析して異常レベルを判定する(ステップS41)。異常レベルの判定は、例えば正常状態を示す基準との乖離の程度に応じて決定される。例えば正常状態を示す基準の最大速度が時速100kmである場合に、車両データが示す走行速度が時速180kmであれば、異常レベルは高であると判定され、車両データが示す走行速度が時速140kmであれば、異常レベルは中であると判定される。別の例を挙げると、正常状態を示す基準の最大ステアリング回転角が720度である場合に、車両データが示すステアリング回転角が900度であれば、異常レベルは高であると判定され、車両データが示すステアリング回転角が750度であれば、異常レベルは中であると判定される。このようなサイバー攻撃の発生確度に基づく異常レベルの判定の基準は、車両10の情報システムの設計時に定められてもよいし、使用履歴から動的に設定されてもよい。
【0097】
ステップS41での判定の結果が高である場合(ステップS42でYES)、車両10では攻撃対応措置が実行される(ステップS43)。ここでの攻撃対応措置の例としては、ハザードランプの動作による周辺車両への告知、又は車両10を路側帯など交通の妨げにならない場所に停める強制退避動作である。また、ステップS41で実行された解析結果がデータ解析サーバ200に送信される(ステップS44)。
図15は、ステップS44においてデータ解析サーバ200に送信される、異常レベルの判定のための車両データの解析結果のデータ構造の一例を示す図である。この例は、CANに準拠する車載ネットワークで高レベルの異常が発生した場合の解析結果のデータである。この例では、車両10での異常の発生箇所、異常のレベル及び異常があったCANメッセージの種類を示すCANメッセージのIDといった、異常と判定されたデータに関する情報に加えて、車両10を一意に識別するための車両ID、異常が検知された時の車両10の位置を示す情報が含められている。なお、異常の発生時にデータ解析サーバ200に送信されるデータに含まれる情報はこれらに限定されない。例えば後述する、グループに関連する情報が含まれていてもよい。
【0098】
ステップS41での判定の結果が中である場合(ステップS42でNO、ステップS45でYES)、ステップS41で実行された解析結果がデータ解析サーバ200に送信される(ステップS46)。この場合のデータ構造も、
図15に示されるものと同様である。なお、異常レベルが中である場合には、車両10では攻撃対応措置は実行されない。
【0099】
ステップS45がNOの場合、つまり異常レベルは低(又は正常)である場合、ステップS41で取得された車両データに対する異常レベルの判定の処理はそのまま終了する。
【0100】
次に、複数の車両10からステップS44又はステップS46で送信される解析結果のデータを受信するデータ解析サーバ200の処理の手順について説明する。
図16Aは、本実施の形態におけるデータ解析サーバ200による処理の手順の一例を示すフロー図である。
【0101】
データ解析サーバ200において、データ取得部210は、複数の車両10のそれぞれから、当該車両10へのサイバー攻撃の発生確度に基づく異常レベルを示す解析結果のデータを取得する(ステップS50)。なお、この処理の説明では、異常レベルは、高、中、低の三段階であるとの前提を便宜上用いる。
【0102】
次に、データ解析部220が、データ取得部210が取得した解析結果に基づいて、蓄積部240に保持される解析結果の統計を更新する(ステップS51)。この統計は、解析結果を、所定の条件に基づいて分類されるグループごとに取られる。ここでいう所定の条件とは、解析結果の送信元である車両10に関して、(1)所定期間内に所定の地域内を走行していること、(2)車種が同一であること、(3)メーカーが同一であること、(4)搭載する車載ネットワークの構成が共通であること、及び(5)解析された車内データの生成の時間帯が共通であることのいずれか一つ又は複数の組み合わせである。このような条件に含まれる共通性がある車載ネットワーク同士では、例えば同じ路側機又は車両からV2X通信で同じ不正メッセージを受信していたり、共通の脆弱性を有していたりする可能性がある。つまり、このような条件で絞られた車両10のグループは、同じサイバー攻撃を受ける可能性が高い。したがって、このような条件で絞った車両10のグループ単位で見ることで、異常のレベルについてより高い精度で判定できる可能性が高まる。なお、条件(4)の車載ネットワークの構成とは、準拠する通信規格、接続されているECUの機種及びそのファームウェアに関する。
【0103】
なお、このグループの判別は、上記のように各車両10から送信される解析結果に付加される情報に基づいて実行されてもよいし、蓄積部240に保持される、各車両IDに対応付けられたグループを示すデータが参照されて実行されてもよい。
【0104】
次に、判定部230が、異常レベルの検証の対象である解析結果のデータの送信元の車両10と同グループの統計を蓄積部240から取得する(ステップS52)。
【0105】
次に、判定部230は、検証の対象である解析結果が示す異常レベルが高であるか否か確認する(ステップS53)。高である場合(ステップS53でYES)、処理は終了する。
【0106】
ステップS53でNOの場合、判定部230はさらに、その異常レベルが中であるか否かを確認する(ステップS54)。
【0107】
異常レベルが中の場合(ステップS54でYES)、次に判定部230は、ステップS52で取得したグループ内で、異常レベルが高の件数が所定基準以上であるか否かを判定する(ステップS55A)。つまり、サイバー攻撃を受ける可能性に関して共通性のある車両10のグループ内で高レベルの異常がある程度より多く発生しているか否か判定する。この判定の基準は、例えば50%以上のように割合で設定されてもよいし、具体的な件数の値で設定されてもよいし、又はこれらが併用(例えば30%以上かつ5件以上)されてもよい。
【0108】
ステップS55AでYESの場合、情報送信部270から、当該検証の対象である解析結果のデータの送信元の車両10へ、異常レベルを中から高へ変更する指示が送信される(ステップS56)。なお、ステップS54又はステップS55AでNOの場合、処理は終了する。
【0109】
図16Bは、本実施の形態におけるデータ解析サーバ200による処理の手順の他の例を示すフロー図である。
【0110】
この他の例における処理は、
図16Aに示される処理と、受信した異常レベルが中である場合(ステップS54でYES)の以降のステップの内容が異なる。
図16Aに示される処理では、異常レベルが中である解析結果のデータの検証において、そのデータ送信元の車両10と同一グループの車両10で異常レベルが高という解析結果の件数が所定基準以上ある場合に、その検証対象の解析結果の異常レベルが高に引き上げられる。つまり、共通性のあるグループの中で、サイバー攻撃を受けている確度が高い又はサイバー攻撃を受けていることが確実であるという事例が多いため、中レベルの異常が発生した車両においても、より慎重な対応を取らせる処理である。
【0111】
これに対し、
図16Bに示される処理では、異常レベルが中である解析結果のデータの検証において、そのデータ送信元の車両10と同一グループの車両10で異常レベルが中という解析結果の件数が所定基準(例えば50%)以上ある場合(S55BでYES)に、その検証対象の解析結果の異常レベルが高に引き上げられる。つまり、共通性のあるグループの中で、サイバー攻撃を受けている確度が高い又はサイバー攻撃を受けていることが確実であるという事例は多くなくても、中レベルの異常が発生している事例が所定基準(例えば70%)以上ある場合には、中レベルの異常が発生した車両においてより慎重な対応を取らせる処理である。この場合、ステップS56の指示は、検証の対象である解析結果のデータの送信元の車両10のみへ送られてもよいし、交通のサイバー攻撃に対する安全性を速効的に高めるために、この車両10と同一グループで中レベルの異常が発生したという解析結果を送信したすべての車両10にも送信されてもよい。
【0112】
図17は、本実施の形態におけるネットワークセキュリティシステム1のシーケンス図である。
図17では便宜的に、解析結果の検証対象であるデータを送信した車両10を、他の車両10から独立させて示している。
【0113】
図17に示されるように、各車両10から、解析によって異常レベルが中又は高と判定された結果を示すデータがデータ解析サーバ200に送信される。データ解析サーバ200では、受信したデータを用いて統計が更新される。解析結果の検証時には、最新の統計から該当するグループの統計が取得される。検証の対象の解析結果が示す異常レベルが中であり、取得した統計が示す異常レベルが高又は中の件数が所定基準以上の場合、検証の対象の解析結果が示すレベルは高に修正される。この高レベルは、本実施の形態における修正レベルの例である。そして、異常レベルの修正レベルへの変更指示がデータ解析サーバ200から車両10に送信される。この変更指示を受信した車両10では、
図14に示すステップS42でYESと判定された場合と同様に、ステップS43での攻撃対応措置が実行される。
【0114】
なお、ステップS56の変更指示を受信した車両10では、攻撃対応措置に加えて、走行状態解析部133による車両データの解析の基準を変更してもよい。つまり、従前は解析によって中レベルの異常と判定していた車両データに対しても、次回以降に車両データ解析装置130で取得されたときには、高レベルであると判定するように基準を変更してもよい。これにより、車載ネットワーク100では、以降の同種の攻撃に対する車両10の攻撃対応措置は、より速やかに実行される。
【0115】
また、上記では便宜上、高中低の2段階の異常レベル間での検証、修正で説明をしたが、本実施の形態の発想は、2段階又は4段階以上の異常レベル間での検証、修正にも適用できる。つまり、設定された異常レベルの段階数を問わず、車両での解析によって判定される異常レベルについて、同じサイバー攻撃による影響を受ける可能性の高い他の車両で判定された異常レベルを用いて検証及び修正がなされてもよい。
【0116】
また、4段階以上の異常レベルが設定されている場合において、同一グループの統計でのより高い異常レベルの判定状況(件数又はその割合)に応じて、引き上げるレベル数が変更されてもよい。つまり、同一グループ内での異常レベルの判定状況に応じてに、異常レベルをいちどに2段階以上引き上げる指示がデータ解析サーバ200から出されてもよい。例えば、異常レベルが昇順でレベル1~5まで設定され、レベル2~4がステップS54で「中」と判定される場合を想定する。この場合の以降のステップでは、例えば「中」の件数は所定以上で、かつその過半数を占めるのがレベル2又は3である場合には、受信した異常レベルがレベル2であればレベル3へ、レベル3であればレベル4へと1段階、過半数を占めるのがレベル4である場合には、受信した異常レベルがレベル2であればレベル4に、レベル3又は4であればレベル5へと、1段階又は2段階引き上げられてもよい。別の例として、「中」の件数は所定以上で、かつその過半数を占めるのがレベル2又は3である場合には、受信した異常レベルがレベル2であってもレベル3であってもレベル4へと1段階又は2段階引き上げられ、過半数を占めるのがレベル4である場合には、受信した異常レベルがレベル2~4のいずれであってもレベル5へと1から3段階引き上げられてもよい。
【0117】
また、車両10では異常レベルの判定が実行されず、車両データをデータ解析サーバ200に送信し、車両データを受信したデータ解析サーバ200において、データ解析部220が車両データを解析して異常レベルを判定してからステップS51以降の処理が行われてもよい。
【0118】
(実施の形態3)
[1.概要]
V2X通信が実行される状況において、サイバー攻撃の検知の精度を向上させるさらに別の手法に係る実施の形態を説明する。
【0119】
従来の車両単体の車両データを用いてサイバー攻撃による異常検知をする手法では、不正データの検出は可能であっても、なりすまし等の高度な手法、又は採用されている通信プロトコルの制約によって、その不正データを送出している機器の特定までは不可能な場合がある。例えばCANでは、送信されるデータ(メッセージ)に送信元を特定する情報は含まれない。メッセージには、メッセージの種類を示すIDが含まれており、このIDから設計上の送信元を特定することは可能である。しかしながら、不正データを送出する機器がその送信元になりすますことも技術上可能である。本実施の形態では、このような状況でも不正データの発生源である機器を絞り込むことができる。
【0120】
より具体的には、本実施の形態におけるネットワークセキュリティシステムでは、個別の車両それぞれで発生した異常に関連した機器(ECU)から、いずれの異常にも関連した機器を割り出す。
【0121】
本実施の形態も、サイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ200によって提供される場合を例に説明する。構成については、実施の形態1と共通であるため説明を省略し、各構成要素は
図1から
図4に示す参照符号をもって示す。
【0122】
以下、本実施の形態におけるデータ解析サーバ200の動作について説明する。
【0123】
[2.動作]
本実施の形態におけるネットワークセキュリティシステム1では、複数の車両10から、各車両10の車両データ解析装置130で実行された車両データの解析結果に基づいて判定される、サイバー攻撃による異常の有無を示すデータがデータ解析サーバ200に送信される。
【0124】
図18は、本実施の形態において各車両10が備える車両データ解析装置130による処理の手順の一例を示すフロー図である。
【0125】
車両データ解析装置130は、車載ネットワークを流れる車両データを取得すると(ステップS60)、その車両データを解析して異常レベルを判定する(ステップS61)。このとき、不正な車両データ、この例では攻撃のための不正な内容を含むCANメッセージ(以下、攻撃CANメッセージという)が特定される(ステップS62)。ステップS62で攻撃CANメッセージが特定される、つまり攻撃が発生すると(ステップS63でYES)、この攻撃CANメッセージを特定して示すデータがデータ解析サーバ200に送信される(ステップS64)。ここで送信されるデータは、例えば実施の形態2の説明で参照した
図15と同様のデータであってもよい。このデータでは、攻撃CANメッセージがメッセージIDを用いて特定されている(攻撃CANメッセージIDの欄を参照)。
【0126】
次に、複数の車両10のそれぞれからステップS64で送信されるデータを受信するデータ解析サーバ200の処理の手順について説明する。
図19は、本実施の形態におけるデータ解析サーバ200による処理の手順の一例を示すフロー図である。
【0127】
データ解析サーバ200において、データ取得部210は、車両10から、当該車両10に異常を発生させた攻撃CANメッセージを特定して示す異常解析結果のデータを取得する(ステップS70)。異常解析結果が示す攻撃CANメッセージは、本実施の形態における異常データの一例である。
【0128】
次に、関連ECU特定部250が、データ取得部210が取得した異常解析結果のデータを用いて、攻撃CANメッセージのメッセージIDを持つCANメッセージの設計上の本来の送信元であるECU(以下、一次ECUともいう)を特定する(ステップS71、S72)。この特定には、蓄積部240に保持される、当該車両10で送信されるCANメッセージのIDと設計上の送信元であるECUとを関連付けたデータが参照される。
図20は、本実施の形態における、車両10の車載ネットワーク100を構成するECUと各ECUが送信するCANメッセージとの関連付けを示すデータの例を示す図である。例えばステップS70で受信された解析結果のデータが
図15に示すものである場合、この解析結果のデータを参照して攻撃CANメッセージのID、CAN-001を取得する(ステップS71)。次に関連ECU特定部250は
図20のデータを参照し、ECU IDが関連付けられた送信メッセージIDに攻撃CANメッセージIDであるCAN-001が含まれているECU、つまりこの例ではECU IDがECU-001のECUを一次ECUとして特定する(ステップS72)。
【0129】
一次ECUは、攻撃CANメッセージと同じメッセージIDのCANメッセージを設計上で送信するECUであるから、攻撃CANメッセージを送信した可能性が高いECUといえる。例えば、一次ECUが不正に乗っ取られ、設計上は意図されていない動作をしている場合である。しかしながら、確実に攻撃CANメッセージを送信したとは言えない。なぜなら例えば、一次ECU以外のECUが乗っ取られ、設計上は送信することのないメッセージIDを持つ攻撃CANメッセージを送信している可能性があるからである。
【0130】
そこで次に、一次ECU以外のECUも含めて、上記のような攻撃CANメッセージを送信した可能性のあるECUを二次ECU群として特定する。
【0131】
関連ECU特定部250は、車両10の車載ネットワーク100において、ステップS72で特定した一次ECUと同一のバス上にあるECUを二次ECU群として特定する(ステップS73)。この特定には、蓄積部240に保持される、当該車両10の車載ネットワーク100におけるバスと各バスに接続されるECUとを関連付けたデータが参照される。
図21は、本実施の形態における、車両10の車載ネットワーク100を構成するバスと各バスに接続されるECUとの関連付けを示すデータの例を示す図である。ステップS72で特定された一次ECUの例を用いると、ステップS73で特定される二次ECU群には、ECU-001、ECU-002、ECU-003、ECU-004及びECU-005が含まれる。ステップS74で特定された二次ECU群がある場合(ステップS74でYES)、この特定された二次ECU群はいったん蓄積部240に保持される。
【0132】
二次ECU群は、攻撃CANメッセージが送信されたバスと同じバスに接続されたECU群であるから、この二次ECU群の中のいずれかのECUが攻撃CANメッセージを送信した可能性が非常に高いと言える。しかしながら、二次ECU群の中のすべてのECUについて、攻撃CANメッセージを送信したか否か調査するために各ECUの動作又は送受信データの解析を行うことは、多くの計算資源及び時間を消費する。
【0133】
そこで次に、この二次ECU群の中から攻撃CANメッセージを送信した可能性が高いECUをさらに絞り込むため、関連ECU特定部250は、この二次ECU群と、別のグループに属する車両10についてステップS70からS73までを実行して特定した二次ECU群とを比較して共通のECUを含むか否か判定する(ステップS75)。ここでいう別グループとは、(1)所定期間内の走行地域が異なること、(2)車種が異なること、(3)メーカーが異なること、(4)搭載する車載ネットワークの構成が異なること、及び(5)車内データが生成された時間帯が異なること、のいずれか一つ又は複数の組み合わせからなる条件を満たすことを指す。なお、(4)の車載ネットワークの構成とは、準拠する通信規格、接続されているECUの機種及びそのファームウェアに関する。
【0134】
攻撃を受けた、又は異常が検知された車両10の二次ECU群どうしを比較し、共通するECUがあれば、その共通ECUが、攻撃CANメッセージを送信した可能性が高いECU、又は攻撃者に車載ネットワーク100への侵入を許す脆弱性を抱える可能性が高いECUと言える。ここで、上記の条件で分けられる別グループに属する車両10の二次ECU群間では、同グループに属する車両10の二次ECU群間と比べ、共通ECUの数は少ない可能性が高い。したがって、別グループに属する車両10の二次ECU群どうしを比較することで、攻撃を受けたECUをより少ない候補に絞り込んで効率的に特定することができる。
【0135】
なお、各ECUが共通(メーカー、機種名、型番、搭載するプロセッサ、プロセッサのファームウェアのバージョン、及びプロセッサのメーカーのうち、一つ以上が同じ)であるか否かの判定は、例えば蓄積部240にECU IDごとのデータベース(図示なし)を保持し、このデータベースを参照して行われる。
【0136】
ステップS75の比較の結果、1個以上の共通のECUが存在する場合(ステップS76でYES)、関連ECU特定部250はこの共通ECUを攻撃関連ECUとして特定する(ステップS77)。また、情報提示部280が、特定された攻撃関連ECUをデータ解析サーバ200のユーザに提示する(ステップS78)。ここでいう攻撃関連ECUとは、例えば攻撃CANメッセージの送信元である可能性が高いECU、又は攻撃CANメッセージの送信元であるか否かに拘わらず、攻撃者に車載ネットワーク100への侵入を許す脆弱性を抱える可能性が高いECUである。攻撃関連ECUは、本実施の形態における異常関連ECUの一例である。
【0137】
ステップS74で二次ECU群がなかった場合(ステップS74でNO)、又は複数の二次ECU群で共通ECUが存在しなかった若しくは比較対象の二次ECU群が存在しなかった場合(ステップS76でNO)には、攻撃関連ECUの特定がされないで処理が終了する。
【0138】
このように、本実施の形態におけるデータ解析サーバ200の処理では、複数の車両10に対する解析結果を組み合わせることにより、攻撃を受けたECUを効率的に特定することができる。
【0139】
図22は、
図19で示したデータ解析サーバ200による処理に対応する、ネットワークセキュリティシステム1のシーケンス図である。
図22に示されるように、ユーザへの情報の提示は、ユーザの要求に応じてなされてもよい。また、提示される情報には、ステップS77で特定された攻撃関連ECUのみならず、脆弱性の解決に資するその他のデータ、例えばS70で車両10から受信されたデータ、一次ECU、二次ECU群等の情報も含まれてもよい。ただし、ネットワークセキュリティシステム1の複数のユーザの中には、車両又はECUその他供給部品の異なるメーカーが含まれる場合もある。このような場合には、データ解析サーバ200から提示可能な情報には、ユーザによって秘匿すべき情報が含まれることもある。このような場合、データ解析サーバ200では、ユーザのアクセス権を管理するアクセス権管理部260が、各データ(情報)に対するユーザごとのアクセス権を管理し、このアクセス権に応じた情報の提示がなされる。
図23は、本実施の形態における、ネットワークセキュリティシステム1のユーザへの情報提示の手順の一例を示すフロー図である。
【0140】
データ解析サーバ200が、図示しないユーザインタフェースを介してユーザからの情報提示要求を受信する(ステップS80)。このユーザは、例えば一意のIDとパスワードを用いてデータ解析サーバ200にログインしている。アクセス権管理部260は、IDで特定されるこのユーザのアクセス権の内容を、蓄積部240に保持されているアクセス権管理情報(図示なし)を参照して確認する(ステップS81)。そして。アクセス権管理部260は、この確認したアクセス権の内容にしたがって、当該ユーザがアクセス可能な情報又はその一覧を、情報提示部280を通じてユーザに提示する(ステップS82)。例えばある車両メーカーに属するユーザは、自社の車両の情報のみにアクセスできるようアクセス権が管理されているとする。この場合、ステップS82で当該ユーザに提示されるのは、このユーザの属する会社の製品である車両で発生した攻撃CANメッセージ、この攻撃CANメッセージと関連付けられた一次ECU、その二次ECU群及び最終的に攻撃関連ECUと特定されたECUの情報のみを取得することができる。
【0141】
このようなアクセス権管理を併用することで、データ解析サーバ200には、他社に対して秘匿すべきデータを扱うメーカーを含む多様なユーザによる利用が促される。多様なユーザによる利用が実現すれば、データ解析サーバ200にはより多く、より多様な車両から車両データが集められ、本実施の形態におけるステップS75で比較対象となる二次ECU群がより多く存在する可能性が高まる。その結果、攻撃関連ECUを特定できる可能性も高まる。
【0142】
なお、上記の説明ではサイバー攻撃の結果として攻撃CANメッセージを送信するようになったECU、又は車載ネットワーク100への侵入に対する脆弱性を抱える可能性が高いECUが特定の対象であったが、本実施の形態の技術は、サイバー攻撃に限らず、製造不良に起因する機械的な欠陥、バグ、又は使用上の故障等の各種の異常を抱える可能性が高いECUの特定にも適用することができる。この場合、データ解析サーバ200では、
図19に示される処理が、攻撃CANメッセージに代えて異常なメッセージを用いて実行される。つまり、これらの異常に起因してECUから送信される異常なメッセージを特定して示す異常解析結果が取得される。この異常なメッセージは、本実施の形態における、異常データの他の例である。また、関連ECU特定部250は、見出した共通ECUを、ステップS77で異常関連ECUとして特定する。
【0143】
また、本実施の形態においても、データ取得部210が取得するのは、各車両10において解析された攻撃などの異常の結果に限定されない。例えば、異常の有無の解析機能を有さない車両10から送信されたCANメッセージがデータ解析部220によって解析された結果でもよい。
【0144】
(他の実施の形態)
以上のように、本発明に係る技術の例示として実施の形態を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。
【0145】
例えば、上記の各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
【0146】
このプログラムとは、例えばプロセッサ及びメモリを備えるコンピュータに、1本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得させ、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるECUのうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ECUを特定させ、前記1本以上のバスのうち、前記一次ECUが接続されているバスに接続されている複数のECUを二次ECU群として特定させ、前記第一車両について特定された前記二次ECU群及び前記第二車両について特定された前記二次ECU群のいずれにも含まれる、所定の条件を満たすECUを異常関連ECUとして特定させ、少なくとも前記異常関連ECUを示す情報を出力させるプログラムである。
【0147】
また、上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
【産業上の利用可能性】
【0148】
本発明は、車載ネットワークを含む車載セキュリティシステムに利用可能である。
【符号の説明】
【0149】
1 ネットワークセキュリティシステム
10、10A、10B 車両
100 車載ネットワーク
110 外部通信装置
120 ゲートウェイ
130 車両データ解析装置
131 車両データ取得部
132 車外データ取得部
133 走行状態解析部
135 蓄積部
136 解析結果送信部
137 車両制御データ送信部
150 ECU
200 データ解析サーバ
210 データ取得部
220 データ解析部
230 判定部
240 蓄積部
250 関連ECU特定部
260 アクセス権管理部
270 情報送信部
280 情報提示部
300 交通基盤システム
900 通信ネットワーク