特開 2024-174057 分析装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024174057

(43)【公開日】2024-12-13

(54)【発明の名称】分析装置

(51)【国際特許分類】

   G06F 21/55 20130101AFI20241206BHJP

   G06F 21/57 20130101ALI20241206BHJP

【ＦＩ】

G06F21/55

G06F21/57 350

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2024167038

(22)【出願日】2024-09-26

(62)【分割の表示】P 2021037773の分割

【原出願日】2021-03-09

(71)【出願人】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】森田 伸義

(72)【発明者】

【氏名】藤井 康広

(72)【発明者】

【氏名】矢野 正

(72)【発明者】

【氏名】片岡 幹雄

(57)【要約】

【課題】攻撃事象の誤検知を低減することにより、異常通知を適切に出力する分析装置を提供する。
【解決手段】監視対象装置に対して通信可能に構成される分析装置において、前記分析装置は、前記監視対象装置の監視結果を収集し、前記監視結果に基づき、各前記監視対象装置の異常が発生したか否かを判定し、前記判定の結果と、前記判定前に取得された前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する。
【選択図】図２

【特許請求の範囲】

【請求項1】

監視対象装置に対して通信可能に構成される分析装置において、
前記分析装置は、
前記監視対象装置の監視結果を収集し、
前記監視結果に基づき、前記監視対象装置の異常が発生したか否かを判定し、
前記判定の結果と、前記判定前に取得された前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する、
分析装置。

【請求項2】

請求項１に記載の分析装置であって、
前記コード検証結果は、前記監視対象装置によって実行されるプログラムの改ざんがあったか否かを当該プログラムの実行開始に際して判定する、セキュアブート処理によって決定される、
分析装置。

【請求項3】

請求項１に記載の分析装置であって、
前記監視対象装置は車両に搭載されている、
分析装置。

【請求項4】

請求項２に記載の分析装置であって、
前記分析装置は、前記監視対象装置のいずれかについて、所定期間内に異常が発生しており、かつ改ざんがあったと判定された場合に、前記異常通知を出力すると決定する、
分析装置。

【請求項5】

請求項２に記載の分析装置であって、
前記分析装置は、前記監視対象装置のいずれについても改ざんがなかったと判定された場合に、前記異常通知を出力しないと決定する、
分析装置。

【請求項6】

請求項１に記載の分析装置であって、
前記分析装置は、さらに、所定期間内に前記監視対象装置のいずれかについて異常が発生した回数または所定期間内に同一の異常が発生した回数に基づき、前記異常通知を出力するか否かを決定する、
分析装置。

【請求項7】

請求項１に記載の分析装置であって、
前記分析装置は、さらに、前記監視対象装置のいずれかについて発生した異常の内容に基づき、前記異常通知を出力するか否かを決定する、
分析装置。

【請求項8】

請求項４に記載の分析装置であって、
前記所定期間は、前記監視対象装置が搭載された車両の動作期間または前記分析装置の動作期間である、
分析装置。

【請求項9】

請求項１に記載の分析装置であって、
前記異常通知は、異常が発生した回数に係る累積通知と、発生した異常の内容に係る即時通知とを含み、
前記異常通知は、当該異常通知が前記累積通知であるか、または前記即時通知であるかを示す情報を含む、
分析装置。

【請求項10】

請求項２に記載の分析装置であって、
前記コード検証結果が複数のトリップタイムを跨ぐ場合に、
前記監視対象装置によって実行されるプログラムの改ざんがなかった場合は、
前回のコード検証結果を消去する、及び／又はコード検証結果を車両の外部に通知する、
分析装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は分析装置に係る。より具体的には、本発明は車両に搭載された監視対象装置の監視結果に基づく異常検知を行う分析装置に係り、特に、車外に対して異常通知を出力するか否かを決定する分析装置に関する。

【背景技術】

【0002】

車両の出荷後における運用中のセキュリティを管理するために、自動車向けＳＯＣ（Security Operation Center）が検討されている。ＳＯＣでは、車両からセキュリティイベントに関するログを収集し、ＳＯＣのオペレータや分析官が当該ログに基づいて、当該車両の状況や他車両への影響を分析し、対策方針の策定および実行を行う。車両から収集するセキュリティイベントとして、車両に搭載された攻撃検知装置の検知結果を利用することが考えられる。

【0003】

コネクテッドカーは益々増加しており、ＳＯＣが監視する車両の台数は大規模になってくる。このような環境では、攻撃検知装置の誤検知が多ければ多いほど、オペレータや分析官に対する不要な作業負荷が増大してしまう。

【0004】

このため、攻撃検知技術として、誤検知の低減が求められる。攻撃検知の精度を高める技術として、特許文献１では、車載装置に対する不正な攻撃の侵入の深度に従って、車両の外部への通信方法を制御する技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１９－１２５３４４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、従来の技術では、異常通知を適切に出力することができない課題があった。

【0007】

特許文献１の技術によれば、車載装置に対する不正な攻撃の侵入の深度に従って攻撃の確度を高める、すなわち誤検知を低減することが期待される。しかしながら、最初に検知した攻撃事象からいくらかの時間が経過した後に別の攻撃事象が検知された場合には、誤検知なのか攻撃なのかの判定は困難となる。例えば、車両が起動してから停止するまでの期間（トリップタイム）において、あるトリップタイムで検知した攻撃事象と、数回あるいは数十回後のトリップタイムで検知した攻撃事象が、実際の攻撃なのか誤検知なのかを判断する方法については開示されていない。

【0008】

本発明は、以上の問題に鑑みなされたものであり、攻撃事象の誤検知を低減することにより、異常通知を適切に出力する分析装置を提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明に係る分析装置の一例は、
監視対象装置に対して通信可能に構成される分析装置において、
前記分析装置は、
前記監視対象装置の監視結果を収集し、
前記監視結果に基づき、前記監視対象装置の異常が発生したか否かを判定し、
前記判定の結果と、前記判定前に取得された前記監視対象装置のコード検証結果とに基づき、異常を示す異常通知を出力するか否かを決定する。

【発明の効果】

【0010】

本発明に係る分析装置は、攻撃事象の誤検知を低減することにより、異常通知を適切に出力することができる。

【図面の簡単な説明】

【0011】

【図1】本発明の実施例１に係る分析装置の構成を示す図

【図2】車両外部への通知タイミングを判定する処理の概要処理フローを示す図

【図3】図２のステップ２０６の詳細フローを示す図

【図4】車両外部への通知処理の概要処理フローを示す図

【図5】車載装置から収集するログ情報の例を示す図

【図6A】異常装置に基づく即時通知ルールの例を示す図

【図6B】ログの種類に基づく即時通知ルールの例を示す図

【図7】車載装置の影響範囲の例を示す図

【図8A】各車載装置の侵害有無の例を示す図

【図8B】車両全体の情勢情報の例を示す図

【図9】分析装置による車両情勢の判断結果の例を示す図

【発明を実施するための形態】

【0012】

以下、本発明の実施形態について、実施例を用い、図面を参照しながら詳細に説明する。

【実施例0013】

本実施例に係る分析装置は、車載装置から取得した異常なログ情報に基づいて、車両の外部に通知するタイミングを判定する方法を実行する。ただし、本発明の技術的思想は、この実施例に限定されるものではない。例えば、異常を検知する機能と、車両の外部に通知するタイミングを判定する機能とを、同一の装置に適用することも可能である。

【0014】

図１は、本実施例における分析装置１の構成を示す。分析装置１は、たとえば車両５０に搭載され、車両５０に関連する情報を分析する装置である。ただし、分析装置１は車両５０に搭載されないものであってもよく、車両５０以外の対象に関連する情報を分析する装置であってもよい。

【0015】

分析装置１は、通信バス２を介して車載装置３に接続されている。車載装置３は、車両５０に搭載される装置であり、本実施例において分析装置１によって監視される監視対象装置である。分析装置１は、複数の車載装置３に対して通信可能に接続される。

【0016】

通信バス２は物理的には複数の通信バスを含んでもよく、各通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格はＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。

【0017】

分析装置１は、不図示の演算手段および不図示の記憶手段を備える。演算手段はたとえばＣＰＵを備える。記憶手段はたとえばＲＯＭおよびＲＡＭを備える。記憶手段に格納されたプログラムを演算手段が実行することにより、分析装置１は本明細書に記載される機能を実現する。

【0018】

たとえば分析装置１はその機能部として、ログ収集部１２、ログ解析部１３、即時通知該否判定部１４、予兆活動判定部１５、車両状態更新部１６、攻撃検知判定部１７、通知情報生成部１８、通知判断部１９、指示内容解析部２０、通知タイミング制御部２１を備える。本明細書において、ＣＰＵまたはこれらの機能部が実行する処理は、分析装置１が実行するということもできる。

【0019】

また、記憶手段は、記憶部１００を備える。記憶部１００は、全体が不揮発性であってもよいし、一部が揮発性であってもよい。また、分析装置１は、通信インタフェースであり通信に必要な演算を行う通信部１１を備える。

【0020】

図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例においてログ解析部１３が実現する機能は、図１に示す他の機能部によって実現されてもよく、図１に示さない機能部によって実現されてもよい。

【0021】

通信部１１は、通信バス２を介して車載装置３からのメッセージを受信するとともに、通信バス２を介して車載装置３に対してメッセージを送信する。分析装置１は、通信部１１を用いて各車載装置３からの情報（たとえば異常状態を判断できる情報）を収集する。なお、車載装置３だけでなく、分析装置１自身が検知したログを収集および格納してもよい。

【0022】

ログ収集部１２は、車載装置３から収集された情報を車両ログ情報１０１に格納する。ログ解析部１３は、車載装置３から収集した情報において、異常を示す情報の有無を解析する。即時通知該否判定部１４は、異常を示す情報が即時通知ルール１０２に該当するかどうかを判定する。予兆活動判定部１５は、所定期間（たとえば完了している最新のトリップタイム）において車両情勢情報１０４に異常を示す情報が登録されているかどうかを判定する。車両状態更新部１６は、異常を示す情報に基づいて車両情勢情報１０４を更新する。攻撃検知判定部１７は、車両情勢情報１０４に基づいて攻撃検知の確定を判定し、情勢判断結果１０５を更新する。通知情報生成部１８は、車両５０の外部に対して通知する情報を生成する。通知判断部１９は、情勢判断結果１０５に基づいて車両５０の外部に対して通知するかどうかを決定する。指示内容解析部２０は、分析装置１の外部から受信した通知制御に関する指示内容を解析する。通知タイミング制御部２１は、所定のタイミングに基づいて車両５０の外部に検知した異常に関する情報を通知する。

【0023】

記憶部１００は、以下の機能部を備える。
‐車載装置３から取得した情報を保持する車両ログ情報１０１。
‐検知した異常について即時に車両５０の外部に出力するか否かを判定するための即時通知ルール１０２。
‐車載装置３相互の影響関係を示す装置間影響情報１０３。たとえば、異常に係る車載装置３と、攻撃対象となる可能性のある他の車載装置３との関係を示す。
‐各車載装置３の侵害有無および侵害状況を保持する車両情勢情報１０４。
‐車両情勢情報１０４に基づいた車両５０の状態を示す情勢判断結果１０５。

【0024】

記憶部１００についても同様に、図１に示す機能ブロック図は例示であり、機能の単位および名称はこれに限らない。たとえば、本実施例において車両ログ情報１０１が保持する情報は、図１の記憶部１００に示す他の機能部によって保持されてもよく、図１の記憶部１００に示さない機能部によって保持されてもよい。

【0025】

図２は、分析装置１が車両５０の外部に異常を通知するタイミングを判定する際の処理を示すフローチャートである。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。

【0026】

ステップ２０１では、ログ収集部１２は通信部１１を用いて各車載装置３の監視結果を収集し、分析装置１の車両ログ情報１０１に格納する。監視結果はたとえばログ情報として収集される。例えば、分析装置１が起動してから周期的にログ情報を収集してもよく、或いは事前に任意に設定されたタイミングでログ情報を収集してもよく、或いは各車載装置３が決定するタイミングで車載装置３から送信されるログ情報を受け取ってもよい。また、ログ収集部１２は、決められた期間の間、ログを収集してもよい。この決められた期間は、複数のトリップタイム（またはそれらの一部）を含んでもよく、たとえば複数のトリップタイムを跨いでもよい。複数のトリップタイムを跨いだ場合、車両５０、或いは分析装置１が起動した後、各車載装置３から最初にログを取得する際に、コード検証結果としてプログラムの改ざんがなかったことが示された場合には（または、改ざんがあったことが示されなかった場合には）、前回に収集されたログ（たとえば異常ログ）を消去してもよい。或いは、トリップタイムを跨いだ場合でも、コード検証結果に関わらず前回のログはそのまま残しておき、当該ログを車両５０の外部に通知した後に消去してもよい。

【0027】

図５に、上記ステップ２０１において収集されるログ情報を保持する車両ログ情報１０１の例を示す。車両ログ情報１０１に含まれる各ログは車載装置ごとに構成される。ログは異常ログ（異常が発生したことを示すログ）を含み、異常ログは以下の情報を含む。
‐異常ログの種類ごとに割り振られる識別子の異常ＩＤ１０１１。
‐異常ログの内容を示すテキストデータである異常内容１０１２。
‐当該車載装置３において異常が発生した箇所を示す異常箇所１０１３。
‐異常を検知した時刻を示す時刻１０１４。この時刻１０１４は、そのログが分析装置１の動作期間のいずれかに含まれるか否か、または、車両５０の動作期間のいずれかに含まれるか否かを示す。なお、分析装置１の動作期間とは、たとえば分析装置１が起動してから停止するまでの期間であってもよく、車両５０の動作期間とは、たとえば車両５０が起動してから停止するまでの期間であってもよい。

【0028】

ステップ２０１に先立ち、各車載装置３は、公知技術等に基づいてログを生成することができる。例えば、車載装置Ａが監視する通信チャンネルＣｈ１を経由して、車外装置として登録されていない端末からのアクセスがあった場合には、車載装置Ａは、ログにおいて、異常内容１０１２「未登録端末アクセス」、当該異常の異常ＩＤ「０ｘ００１」、異常箇所１０１３「Ｃｈ１」、検知した時刻「２０２０／０２／０１ １１：１０：２０」を登録する。このログがステップ２０１において収集される。

【0029】

ステップ２０２では、ログ解析部１３は上記ステップ２０１で格納した車両ログ情報１０１に、異常ログが含まれているかどうかを判定することにより、異常ログを抽出する。すなわち、ログ解析部１３は、車載装置３の監視結果に基づき、各車載装置３の異常が発生したか否かを判定する。本実施例では、異常ログのみが保持されているが、他のログ情報を保持してもよく、その場合は、異常ログを特定できる識別子を備えてもよい。この判定は、たとえば異常ＩＤ１０１１に基づいて行うことができる。また、ログ情報は、コード検証結果を含んでもよい。たとえば、コード検証結果として、改ざんがあったと判定された、改ざんがなかったと判定された、等を示す情報を含んでもよい。

【0030】

ステップ２０３では、上記ステップ２０２で異常ログが含まれていた場合、ステップ２０４に進む。一方、異常ログが含まれていなかった場合には、本処理フローを終了する。終了後、所定のタイミングでステップ２０１に進んでもよい。なお、変形例として、コード検証結果を示すログが含まれていた場合にも、ステップ２０４に進むように構成してもよい。その場合には、コード検証結果として改ざんがなかったと判定された場合に、ステップ２０４に進むように構成してもよい。

【0031】

ステップ２０４では、即時通知該否判定部１４は即時通知ルール１０２に基づいて、車両ログ情報１０１に含まれる異常ログに、車両５０の外部に即時に通知すべき異常ログが存在するかどうかを判定する。

【0032】

図６Ａに、上記ステップ２０４において即時通知該否判定部１４が参照する即時通知ルール１０２の例を示す。この例は、異常装置１０２１に基づくものである。例えば、即時通知該否判定部１４は、異常ログに係る車載装置３が、即時通知ルール１０２における異常装置１０２１に該当する場合、その異常ログについて即時通知を出力すると判定する。即時通知とは、異常を示す通知（異常通知）の一種である。ある異常ログについて即時通知を出力すると判定することは、その異常ログについて異常通知を出力すると決定することに対応する。

【0033】

図６Ａの例では、車載装置Ｉに係る異常ログについては、即時通知を出力すると判定される。また、車載装置Ｇに係る異常ログと、車載装置Ｈに係る異常ログとが、同時刻または所定時間内に存在する場合には、それらの異常ログについて即時通知を出力すると判定される。

【0034】

なお、図６Ａの例では、即時通知該否判定部１４は、車載装置３のいずれかについて発生した異常（たとえば単一回の異常）の内容に基づき、異常通知を出力するか否かを決定することができる（車載装置Ｉの例）。このようにすると、重大な異常が発生した場合に確実に異常通知を出力することができる。

【0035】

また、即時通知ルール１０２は、異常装置１０２１に該当する異常ログが複数回発生することを条件として含んでもよい。たとえば、即時通知該否判定部１４は、さらに、所定期間内に車載装置３のいずれかについて異常が発生した回数に基づき、即時通知を出力すると判定してもよい。たとえば、所定期間内に、ある同一の車載装置３に係る異常ログが複数存在する場合に、それらの異常ログを即時通知対象と判定してもよい。このようにすると、頻発する異常を見逃すことがなくなる。

【0036】

図６Ｂに、上記ステップ２０４において即時通知該否判定部１４が参照する即時通知ルール１０２の別の例を示す。この例は、異常ログの種類に基づくものである。例えば、上記ステップ２０４において即時通知該否判定部１４は、異常ＩＤ１０１１が、即時通知対象異常ＩＤ１０２２に該当する場合、即時通知を出力すると判定する。

【0037】

なお、図６Ｂの例では、即時通知該否判定部１４は、車載装置３のいずれかについて発生した単一の異常の内容に基づき、異常通知を出力するか否かを決定することができる。ただし、変形例として、即時通知ルール１０２は、即時通知対象異常ＩＤ１０２２に該当する異常ログが複数回発生することを条件として含んでもよい。たとえば、即時通知該否判定部１４は、さらに、所定期間内に同一の異常が発生した回数に基づき、即時通知を出力すると判定してもよい。たとえば、所定期間内に、ある同一の異常ＩＤに係る異常ログが複数存在する場合に、それらの異常ログを即時通知対象と判定してもよい。このようにすると、頻発する異常を見逃すことがなくなる。

【0038】

図６Ａに示すルールと、図６Ｂに示すルールとは、いずれか一方のみを判定に使用してもよいし、双方を判定に使用してもよい。双方を使用する場合には、いずれか一方に該当する異常ログについて即時通知を出力すると判定してもよいし、双方に該当する異常ログのみ即時通知を出力すると判定してもよい。

【0039】

ステップ２０５では、即時通知該否判定部１４は上記ステップ２０４で即時通知を出力すると判定した場合、ステップ２０８に進み、即時通知を出力しないと判定した場合、ステップ２０６に進む。

【0040】

ステップ２０６では、攻撃検知判定部１７は上記ステップ２０２で抽出した異常ログに対して、後述する車両情勢情報１０４に基づいて攻撃の有無を判定し、車両の外部に対して通知するかどうかを判定する。この判定の詳細は図３等に関連して後述する。

【0041】

ステップ２０７では、攻撃検知判定部１７は、情勢判断結果１０５（図９等に関連して後述）に基づいて、異常通知を出力するか否かを決定する。なお、情勢判断結果１０５は、各車載装置３の異常が発生したか否か（上述のステップ２０３）と、各車載装置３のコード検証結果（後述するステップ３０２）とに基づいて生成されるものであるため、攻撃検知判定部１７は、各車載装置３の異常が発生したか否かに関する判定の結果と、各車載装置３のコード検証結果とに基づき、異常通知を出力するか否かを決定するということができる。

【0042】

ここで、攻撃検知判定部１７が異常通知を出力すると決定することは、車両５０または車載装置３のいずれかが攻撃を受けていると判定することに対応する。また、攻撃検知判定部１７が異常通知を出力しないと決定することは、車両５０または車載装置３のいずれも攻撃を受けていないと判定することに対応するか、または、車両５０または車載装置３が攻撃を受けている可能性はあるが、様子見として継続監視すべきと判定することに対応する。

【0043】

たとえば、情勢判断結果１０５の情勢判断ＩＤ１０５１（図９等に関連して後述）が「０ｘ００」または「０ｘ０１」である場合には異常通知を出力しないと決定し、「０ｘ１０」または「０ｘ１１」である場合には異常通知を出力すると決定する。出力される異常通知の内容は、たとえば上述の即時通知または後述の累積通知とすることができる。

【0044】

異常通知を出力すると決定した場合にはステップ２０８に進み、異常通知を出力しないと決定した場合には本処理フローを終了する。

【0045】

ステップ２０８では、通知情報生成部１８は車両の外部に通知する情報として異常通知を生成する。例えば、異常通知は車両ログ情報１０１、車両情勢情報１０４、情勢判断結果１０５に基づく情報を含んでもよい。また、異常通知は、攻撃を検知したことを表す情報を含んでもよい。

【0046】

ステップ２０９では、通知判断部１９は上記ステップ２０８で生成した異常通知を車両５０の外部に対して出力する。出力先は車両５０の外部にある装置であってもよく、その場合には車載装置３の何れかを経由して通信してもよい。また、出力先は車両５０に搭載された装置であってもよく、たとえば車両５０に搭載されたランプを点灯させることにより、攻撃を検知したことを車両５０の外部から認識できるようにしてもよい。

【0047】

ステップ２１０では、分析装置１は情勢判断結果１０５に基づいて、車両５０のセキュリティ対応を行うための対処モードに移行する。対処モードにおける動作の具体的な内容は、公知技術等に基づいて当業者が適宜設計することができる。なおステップ２１０は省略してもよい。

【0048】

以上のステップによって、分析装置１は攻撃を検知した適切なタイミングで車両の外部に異常を通知できる。

【0049】

図３は、上記ステップ２０６における処理の詳細なフローチャートである。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。図３の処理は、たとえばステップ３０７を除いて異常ログごとに実行され、ステップ３０７は図２の処理が実行されることに応じて実行される。

【0050】

ステップ３０１では、予兆活動判定部１５は車両情勢情報１０４を参照し、攻撃の予兆活動が記録されているかどうかを判定する。以下、図７、図８Ａおよび図８Ｂを用いて、ステップ３０１の具体的な処理例について説明する。

【0051】

図７に、異常ログに係る車載装置３（被害装置１０３１）と、その異常によって影響を受ける影響先となる車載装置３（影響先１０３２）とを関係付ける装置間影響情報１０３の例を示す。

【0052】

影響先１０３２は、異常が発生している被害装置１０３１と関連性があり、攻撃の影響を受ける可能性がある。また、監視対象グループＩＤ１０３３は、被害装置１０３１と影響先１０３２とからなるグループを特定する識別情報である。

【0053】

例えば、図５に示す異常ＩＤ１０１１が「０ｘ００２」の異常ログについて、予兆活動判定部１５は、当該異常ＩＤが登録されている車載装置「車載装置Ａ」を被害装置として特定し、装置間影響情報１０３の被害装置１０３１における車載装置Ａに該当する影響先１０３２「車載装置Ｄ」を特定する。

【0054】

図８Ａに、予兆活動が記録される車両情勢情報１０４の例を示す。車両情勢情報１０４は、車両５０に搭載される車載装置３を識別する車載装置ＩＤ１０４１と、当該車載装置に侵害があったかどうかを示す侵害有無１０４２とを含む。

【0055】

図８Ａの車両情勢情報１０４は、ステップ３０１の実行に先立って生成しておくことができる。たとえば、所定の期間（情勢情報記録期間）内に異常が発生した車載装置３については「１」を記録し、そうでない車載装置３については「０」を記録しておくことができる。

【0056】

異常の発生は、攻撃の予兆活動の可能性を示唆するものであるため、情勢情報記録期間内に異常が発生したか否かを表す情報は、各車載装置３について攻撃の予兆活動があったか否かを表す情報であるということもできる。

【0057】

情勢情報記録期間の始点および終点は任意に設計可能であるが、たとえば車両５０の動作期間（たとえば車両５０が起動してから停止するまでの期間）であってもよく、分析装置１の動作期間（たとえば分析装置１が起動してから停止するまでの期間）であってもよい。このようにすると、異常ログの記録と、分析装置１または車両５０の動作期間とを整合させ、より適切な判定を行うことができる。

【0058】

また、この情勢情報記録期間は、特定のイベント信号に基づいて決定される期間であってもよく、予め定められた時刻に基づく期間であってもよい。

【0059】

車両情勢情報１０４は、任意のタイミングで更新されるよう設計することができる。たとえば情勢情報記録期間が終了することに応じて更新されてもよい。たとえば、車両情勢情報１０４が第１の情勢情報記録期間に関する情報を保持している場合に、第２の情勢情報記録期間が終了すると、車両情勢情報１０４は第２の情勢情報記録期間に対応する内容に更新されてもよい。なお、情勢判断結果１０５は、任意のタイミングで初期化することができる。例えば、トリップタイムが変わった場合（すなわちそれまでのトリップタイムが終了し、新たなトリップタイムが開始された場合）には、情勢判断結果１０５を維持してもよいし、情勢判断結果１０５を初期化すなわち「０ｘ００」に設定してもよい。車両５０外部からの所定の手続き（たとえば、ＳＯＣによって問題ないことが確認された、問題のあったプログラムが修正された、等）が行われた場合に情勢判断結果１０５を初期化してもよい。或いは、すべての車載装置３または該当する車載装置３から、コード検証結果として改ざんがなかったことを示すログが収集された場合に、情勢判断結果１０５を初期化してもよい。

【0060】

ステップ３０１において、たとえば図５に示す異常ＩＤ１０１１が「０ｘ００２」の異常ログについて、予兆活動判定部１５は、まず当該異常ログに係る車載装置（この場合には車載装置Ａ）に予兆活動があったか否かを判定する。たとえば、車載装置Ａに対応する侵害有無１０４２の値が「１」であれば予兆活動があったと判定し、「０」であれば予兆活動がなかったと判定する。この例では「車載装置Ａ」となる車載装置ＩＤ１０４１に該当する侵害有無１０４２の値が「０」であるので、車載装置Ａについて予兆活動がなかったと判定される。

【0061】

次に、予兆活動判定部１５は、上記のように装置間影響情報１０３に基づいて影響先を車載装置Ｄとして特定し、車載装置Ｄに予兆活動があったか否かを判定する。たとえば、車載装置Ｄに対応する侵害有無１０４２の値が「１」であれば予兆活動があったと判定し、「０」であれば予兆活動がなかったと判定する。この例では「車載装置Ｄ」となる車載装置ＩＤ１０４１に該当する侵害有無１０４２の値が「１」であるので、車載装置Ｄについて予兆活動があったと判定される。

【0062】

また、たとえば車載装置Ｃに係る異常ログについて、図７において被害装置１０３１が車載装置Ｃである場合には、影響先１０３２として、車載装置Ｄおよび車載装置Ｅを含むグループと、車載装置Ｆのみを含むグループとが関連付けられている。このため、車載装置Ｃに係る異常ログについては、車載装置Ｄに対応する侵害有無１０４２と、車載装置Ｅに対応する侵害有無１０４２とがいずれかまたは双方が「１」である場合には、車載装置Ｄ或いは車載装置Ｅ、或いは双方について予兆活動があったと判定され、双方とも「０」である場合には、車載装置Ｄおよび車載装置Ｅについて予兆活動がなかったと判定される。また、車載装置Ｆに対応する侵害有無１０４２が「１」である場合には、車載装置Ｆについて予兆活動があったと判定され、「０」である場合には、車載装置Ｆについて予兆活動がなかったと判定される。

【0063】

予兆活動判定部１５は、すべての異常ログについて上記のように予兆活動の有無を判定してもよい。また、予兆活動判定部１５は、上記ステップ２０２で、車両ログ情報１０１から抽出した異常ログに基づき、異常が発生している被害装置を特定し、装置間影響情報１０３を用いて当該被害装置の影響範囲を特定し、当該被害車載装置と影響範囲に含まれる車載装置に該当する車載装置ＩＤ１０４１について侵害有無１０４２を参照し、これによって攻撃予兆の有無を判定してもよい。

【0064】

ステップ３０１における判定の結果、いずれかの車載装置において予兆活動があったと判定した場合にはステップ３０２に進み、予兆活動がなかったと判定した場合にはステップ３０３に進む。

【0065】

ステップ３０２では、攻撃検知判定部１７はコード検証結果を参照する。たとえば、ステップ３０１において予兆活動があったと判定された車載装置３のコード検証結果が参照される。コード検証結果の具体例はとくに図示しないが、たとえば車載装置３によって実行されるプログラムの改ざんがあったか否かを示すものであり、公知技術等に基づいて生成可能である。なお、上記ステップ２０１で取得したログが、車載装置３のコード検証結果（たとえば改ざんの有無）を表すログである場合には、ステップ３０２において、当該ログの内容が、改ざんがあったことを示すか否かを判定してもよい。例えば、分析装置１は、車両５０起動時（或いは分析装置１の起動時）に、上記ステップ２０１において、各車載装置３から、各車載装置３のコード検証結果（改ざんの有無）を収集し、本ステップ３０２において、コード検証結果を判定してもよい。

【0066】

コード検証結果は、たとえばセキュアブート処理によって生成される。セキュアブート処理は、車載装置３によって実行されるプログラムの改ざんがあったか否かを、当該プログラムの実行開始に際して判定するための処理である。なお、コード検証結果はセキュアブート処理によるものに限らず、プログラムの実行開始後の任意のタイミングで実行される検証の結果であってもよい。

【0067】

予兆活動があった車載装置３によって実行されるプログラムの改ざんがあったと判定された場合には、処理はステップ３０４に進む。そうでない場合には、処理はステップ３０５に進む。

【0068】

ステップ３０３、３０４および３０５において、車両状態更新部１６は車両ログ情報１０１から抽出した新規の異常ログに基づいて、車両情勢情報１０４を更新する。

【0069】

図８Ｂに、上記ステップ３０３において更新する車両情勢情報１０４の例を示す。なお、本実施例では、車両情勢情報１０４が図８Ａに示す情報および図８Ｂに示す情報の双方を含むが、これらの情報はそれぞれ異なる領域（たとえば異なるデータベース、ＲＡＭ、データフラッシュ）に含まれてもよい。

【0070】

図８Ｂに示す車両情勢情報１０４は、以下の情報を含む。
‐互いに関連する装置のグループを特定する監視対象グループＩＤ１０４３。
‐各グループに含まれる車載装置を示す関連装置１０４４。各グループに含まれる装置間の関係は、図７の装置間影響情報１０３と対応するものであってもよい。本実施例において、図８Ｂに示す関係は図７に示す関係と対応するが、変形例においてはこれらが対応する必要はない。
‐各車載装置における侵害状況を示す侵害情勢１０４５。
‐侵害情勢１０４５に基づいて、異常通知を出力するか否かを判定する際に用いる閾値を示す閾値１０４６。

【0071】

車両状態更新部１６は、異常ログに係る車載装置（たとえば車載装置Ａ）に該当する侵害有無１０４２を「０」から「１」に更新する。たとえば、車載装置Ａに係る異常ログについては、当該車載装置Ａを被害装置１０３１とするグループのＩＤ｛０ｘ０１｝を図７の監視対象グループＩＤ１０３３から取得し、図８Ｂにおいてこれに対応するグループの侵害情勢１０４５（図８Ｂの例では｛１、１｝となっている）が｛０、０｝であれば、これを｛１、０｝に更新する。

【0072】

ステップ３０６では、攻撃検知判定部１７は、車両情勢情報１０４における侵害情勢１０４５と閾値１０４６とを比較する。たとえば、各グループについて、侵害情勢１０４５に含まれる数の和と、閾値とを比較する。和が閾値を超過している場合には、累積通知を出力すると判定する。累積通知とは異常通知の一種である。和が閾値を超過していない場合には、異常通知を出力しないと判定する。

【0073】

なお、変形例としてステップ３０６の判定を省略してもよく、その場合には異常通知を出力しないと決定してもよい（和が閾値を超過していない場合と同様）。

【0074】

ステップ３０７では、車両状態更新部１６はステップ３０３、３０４または３０６の結果に応じて情勢判断結果１０５を更新する。

【0075】

図９に、情勢判断結果１０５の例を示す。情勢判断結果１０５は、車両の情勢を識別する情勢判断ＩＤ１０５１と、車両の情勢内容を示すステータス１０５２とを含む。

【0076】

例えば、初期状態（たとえば、いかなる異常ログも記録されていない状態）として、情勢判断ＩＤ１０５１は「０ｘ００」であり、ステータス１０５２は「通常」である。

【0077】

ステップ３０７の前にステップ３０３が実行されていた場合には、情勢判断ＩＤ１０５１は「０ｘ０１」となり、ステータス１０５２は「継続監視」となる。

【0078】

ステップ３０７の前にステップ３０４が実行されていた場合には、情勢判断ＩＤ１０５１は「０ｘ１１」となり、ステータス１０５２は「即時通知」となる。

【0079】

ステップ３０７の前にステップ３０６が実行されており、閾値を超過していた場合には、情勢判断ＩＤ１０５１は「０ｘ１０」となり、ステータス１０５２は「累積通知」となる。また、ステップ３０７の前にステップ３０６が実行されており、閾値を超過していなかった場合には、情勢判断ＩＤ１０５１は「０ｘ０１」となり、ステータス１０５２は「継続監視」となる。

【0080】

なお、複数の異常ログについて結果が異なる場合には、情勢判断ＩＤ１０５１は結果のうち最大の値が優先される。たとえば、ある異常ログについて「継続監視」（情勢判断ＩＤ１０５１は「０ｘ０１」）と判定され、別の異常ログについて「即時通知」（情勢判断ＩＤ１０５１は「０ｘ１１」）と判定された場合には、結果として情勢判断ＩＤ１０５１は「０ｘ１１」となる。

【0081】

図９に示すように、本実施例において、異常通知は、異常が発生した回数に係る累積通知と、発生した異常の内容に係る即時通知とを含む。

【0082】

異常通知は、当該異常通知が累積通知であるか、または即時通知であるかを示す情報を含んでもよい。このようにすると、異常の内容をより詳細に出力することができる。

【0083】

以上の処理によって、分析装置１は、異常通知を車両の外部に出力するか否かを決定できる。異常通知を出力すると決定された場合には、早期対処につなげるための適切なタイミングで車両の外部に通知できる。

【0084】

図３のステップ３０１、３０２および３０４によれば、分析装置１は、車載装置３のいずれかについて、予兆活動があり（すなわち所定期間内に異常が発生しており）、かつ改ざんがあったと判定された場合に、異常通知を出力すると決定する。このため、過去の予兆活動と、最新のコード検証結果とに基づいて、より適切な判定を行うことができる。

【0085】

図４は、分析装置１が車両の外部に対して車載装置の情報を出力する処理の一例を示すフローチャートである。分析装置１は、図２に示すステップ２０９に加えて、またはこれに代えて、図４に示す処理によって異常通知を出力してもよい。

【0086】

図４では、特に、定時報告として出力するケースと、車両の外部からの指示に従って出力するケースとについて説明する。以下に説明する各ステップの実行主体は、たとえば分析装置１の不図示のＣＰＵである。また、本処理フローは、たとえば車両５０の起動に際して実行される。さらに本処理フローは、所定のタイミングで実行してもよく、定期的に繰り返し実行してもよく、異常を通知した後に実行してもよい。

【0087】

ステップ４０１では、指示内容解析部２０は車両の外部からの通知指示を受信したかどうかを確認し、通知指示を受信した場合はステップ４０２に進み、通知指示を受信していない場合はステップ４０５に進む。

【0088】

ステップ４０２では、指示内容解析部２０は車両の外部から受信した指示内容を解析する。例えば、指示内容は、車両の外部に出力する情報を指定する情報を含む。たとえば、指示内容は、特定の車載装置に対する指定、特定のログ情報に対する指定、他の車載装置から追加で収集すべきログ情報に対する指定、車両において保持されている他の情報に対する指定、等を含んでもよい。また、指示内容は、分析装置１の機能または構成を変更するための情報を含んでもよい。

【0089】

ステップ４０３では、通知情報生成部１８は上記ステップ４０２で解析した内容に基づいて、必要な情報を分析装置１、或いは車載装置３から収集する。

【0090】

ステップ４０４では、通知情報生成部１８は上記ステップ４０３で収集した情報から車両の外部に出力する情報を生成する。

【0091】

ステップ４０５では、通知タイミング制御部２１は、現時刻が所定の通知タイミングになっているかどうかを確認する。例えば、所定のタイミングは、所定のイベント或いは処理が発生したタイミング（たとえば起動時）、或いは所定の日時でもよい。

【0092】

ステップ４０６では、通知タイミング制御部２１は、上記ステップ４０５の確認結果に基づいて、現時刻が所定のタイミングである判定した場合にはステップ４０７に進み、それ以外の場合には本処理フローを終了する。

【0093】

ステップ４０７では、通知情報生成部１８は車両の外部に出力する定型データを生成する。例えば、分析装置１の記憶部に保持する情報の一部あるいはすべてからなる情報を生成する。

【0094】

ステップ４０８では、通知判断部１９は上記ステップ４０４、或いは上記ステップ４０７で生成した情報を車両の外部に出力する。出力先は図２のステップ２０９と同様に設計することができる。

【0095】

以上の処理によれば、分析装置１は、各車載装置３の異常が発生したか否かに関する判定の結果と、各車載装置３のコード検証結果とに基づき、異常通知を出力するか否かを決定する。

【0096】

また、たとえば、センタ側の運用負荷やデータ通信コストを考慮したタイミングで定期的に所定の情報を通知できるとともに、攻撃が発生したと判断したような事態において、車両の外部からの要求指示に従って柔軟に追加の情報を通知できる。

【0097】

このため、分析装置１は車載装置から取得した異常ログと即時通知ルールに基づいて、車両の外部に対して適切なタイミングで異常通知を出力できる。

【0098】

より具体的には、分析装置１は、異常ログと予兆活動に基づいて、攻撃を受けていると判定し、車両の外部に対して異常通知を出力できる。

【0099】

また、コード検証結果に関わらず、車両情勢の侵害度に基づいて、車両の外部に対して異常通知を出力できる。これにより、緊急性を要する異常ログを検知した場合は即時に異常通知を出力できる。

【0100】

また、実施例１によれば、攻撃を受けていないときに通知するケースを低減でき、一方で、攻撃の可能性が高いケースを見逃しにくくなる。このため、ＳＯＣのようなセンタサービスと連携する際の負荷を適正化できる。

【0101】

また、実施例１によれば、コード検証結果はセキュアブート処理によって生成することができるので、セキュアブート処理の結果を有効に活用することができる。

【0102】

また、実施例１のステップ３０６を省略する変形例によれば、分析装置１は、車載装置３のいずれについても改ざんがなかったと判定された場合に、異常通知を出力しないと決定する。この場合には、異常ログに基づく攻撃の誤検知を抑制することができる。

【0103】

実施例１において、図２および図３の処理は例であり、適宜変更することができる。たとえば、ステップ２０４における判定の基準、ステップ３０２における判定の基準、等は任意に変更可能である。また、たとえばステップ３０１を省略し、ステップ２０６においては常にステップ３０２を実行するようにしてもよい。

【0104】

また、判定に用いる情報の形式は、適宜追加、省略または変更することができる。たとえば図６Ａ、図７、図８Ｂの情報を省略してもよく、その場合には被害装置と影響先の装置とを同一の装置としてもよい。

【符号の説明】

【0105】

１…分析装置、３…車載装置（監視対象装置）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8A】

【図8B】

【図9】