特許 6913206 ログ解析方法及びログ優先度テーブル管理方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6913206

(24)【登録日】2021年7月13日

(45)【発行日】2021年8月4日

(54)【発明の名称】ログ解析方法及びログ優先度テーブル管理方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20210727BHJP

   G06F 11/07 20060101ALI20210727BHJP

   G06F 21/55 20130101ALI20210727BHJP

   B60R 16/023 20060101ALI20210727BHJP

【ＦＩ】

   G06F11/34 176

   G06F11/07 178

   G06F21/55 320

   B60R16/023 P

【請求項の数】6

【全頁数】19

(21)【出願番号】特願2020-80833(P2020-80833)

(22)【出願日】2020年4月30日

(62)【分割の表示】特願2016-164804(P2016-164804)の分割

【原出願日】2016年8月25日

(65)【公開番号】特開2020-129395(P2020-129395A)

(43)【公開日】2020年8月27日

【審査請求日】2020年4月30日

(73)【特許権者】

【識別番号】000001487

【氏名又は名称】フォルシアクラリオン・エレクトロニクス株式会社

(74)【代理人】

【識別番号】110002365

【氏名又は名称】特許業務法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】安藤 英里子

(72)【発明者】

【氏名】永井 靖

(72)【発明者】

【氏名】森田 伸義

【審査官】 金田 孝之

(56)【参考文献】

【文献】 特開２０１６−０５７９７１（ＪＰ，Ａ）

【文献】 特開２０１６−１２２３３７（ＪＰ，Ａ）

【文献】 特表２０１４−５０４１１１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１６／０１１９１５１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８ −１１／３６

Ｇ０６Ｆ ２１／１２ −２１／１６

Ｇ０６Ｆ ２１／５０ −２１／５７

Ｂ６０Ｒ １６／００ ー１６／０８

(57)【特許請求の範囲】

【請求項1】

車両に搭載される複数の車載装置とネットワークにより接続され、前記車載装置において蓄積されたログを受信して解析するサーバ装置におけるログ解析方法であって、
前記複数の車載装置から受信したログを解析し、各車載装置において攻撃が発生した可能性の判断する第１ステップと、
前記第１ステップにおいて攻撃が発生した可能性があると判断した場合、前記複数の車載装置のうち臨時ログの収集対象となる車載装置を決定する第２ステップと、
前記第２ステップにおいて臨時ログの収集対象となった車載装置に対して、当該車載装置が蓄積するログの優先度を示すログ優先度テーブルの変更を要求する、ログ優先度テーブル変更要求メッセージを送信する第３ステップと、
前記第３ステップにおいて前記ログ優先度テーブル変更要求メッセージを送信した車載装置から臨時ログを受信した場合に、当該臨時ログを解析して攻撃発生の有無を判断する第４ステップと、
前記第４ステップにおいて攻撃が発生したと判断した場合、及び、前記第３ステップにおいて前記ログ優先度テーブル変更要求メッセージを送信した車載装置から所定時間以内に臨時ログを受信しない場合に、攻撃発生の通知を行なう第５ステップと、
を有することを特徴とするログ解析方法。

【請求項2】

請求項１に記載のログ解析方法において、
前記第５ステップにおける攻撃発生の通知は、前記サーバ装置のオペレータに対する通知であって、前記オペレータがサービスの緊急停止が必要と判断した場合に、当該オペレータから前記サーバ装置にサービスの緊急停止が指示されることを特徴とするログ解析方法。

【請求項3】

請求項１に記載のログ解析方法において、
前記第２ステップにおける前記臨時ログの収集対象となる車載装置は、前記第１ステップにおいて攻撃が発生した可能性があると判断された車両装置から所定距離内に存在する車両装置であることを特徴とするログ解析方法。

【請求項4】

請求項１に記載のログ解析方法において、
前記第２ステップにおける前記臨時ログの収集対象となる車載装置は、前記第１ステップにおいて攻撃が発生した可能性があると判断された車両装置と同じ機種または類似する機種であることを特徴とするログ解析方法。

【請求項5】

請求項１に記載のログ解析方法において、
前記第３ステップにおいて送信される前記ログ優先度テーブル変更要求メッセージにより追加が要求されるレコードの優先度は他のレコードに対して最優先とされることを特徴とするログ解析方法。

【請求項6】

請求項１に記載されたログ解析方法を行うサーバ装置にネットワークにより接続された車載装置におけるログ優先度テーブル管理方法であって、
前記サーバ装置から前記ログ優先度テーブル変更要求メッセージを受信する第６ステップと、
受信した前記ログ優先度テーブル変更要求メッセージにしたがって、当該車載装置内に格納されたログ優先度テーブルを更新する第７ステップと、
前記ログ優先度テーブルにおいて、臨時であることを示されたレコードについて、有効時間が経過済みであるレコードを削除する第８ステップと、
を有することを特徴とするログ優先度テーブル管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ログ解析方法及びログ優先度テーブル管理方法に関する。

【背景技術】

【0002】

近年、車載装置のネットワーク化等に伴い、車載装置システムの分野においても、適切なセキュリティの必要性が高まっている。こうした車載装置のセキュリティ技術に関して、車載装置の状況をネットワーク上のサーバが把握し、サーバが車載装置の異常を検出する構成が広く知られている。特許文献１には、車両等の移動体から、その位置情報等の移動体情報を状況に応じた適切な方法で送信することのできる装置が開示されている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

上記のようなサーバを用いた車載装置の異常検出では、車載装置において多数の詳細な情報をログとして収集しサーバに送信することで、車載装置で発生した様々な異常をサーバが検出できる。しかし、一般に車載装置は、設置スペースの制約等によりリソースが乏しく、収集できる情報量が限定される。そのため、車載装置のおかれた状況に応じて適切なログを収集する必要があるが、特許文献１に記載されている発明では、これを行うことができない。

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

【0005】

本発明の第１の態様によるログ解析方法は、車両に搭載される複数の車載装置とネットワークにより接続され、前記車載装置において蓄積されたログを受信して解析するサーバ装置におけるログ解析方法であって、前記複数の車載装置から受信したログを解析し、各車載装置において攻撃が発生した可能性の判断する第１ステップと、前記第１ステップにおいて攻撃が発生した可能性があると判断した場合、前記複数の車載装置のうち臨時ログの収集対象となる車載装置を決定する第２ステップと、前記第２ステップにおいて臨時ログの収集対象となった車載装置に対して、当該車載装置が蓄積するログの優先度を示すログ優先度テーブルの変更を要求する、ログ優先度テーブル変更要求メッセージを送信する第３ステップと、前記第３ステップにおいて前記ログ優先度テーブル変更要求メッセージを送信した車載装置から臨時ログを受信した場合に、当該臨時ログを解析して攻撃発生の有無を判断する第４ステップと、前記第４ステップにおいて攻撃が発生したと判断した場合、及び、前記第３ステップにおいて前記ログ優先度テーブル変更要求メッセージを送信した車載装置から所定時間以内に臨時ログを受信しない場合に、攻撃発生の通知を行なう第５ステップと、を有する。
本発明の第２の態様によるログ優先度テーブル管理方法は、第１の態様によるログ解析方法を行うサーバ装置にネットワークにより接続された車載装置におけるログ優先度テーブル管理方法であって、前記サーバ装置から前記ログ優先度テーブル変更要求メッセージを受信する第６ステップと、受信した前記ログ優先度テーブル変更要求メッセージにしたがって、当該車載装置内に格納されたログ優先度テーブルを更新する第７ステップと、前記ログ優先度テーブルにおいて、臨時であることを示されたレコードについて、有効時間が経過済みであるレコードを削除する第８ステップと、を有する。

【発明の効果】

【0006】

本発明によれば、車載装置のおかれた状況に応じて適切なログを収集することができる。

【図面の簡単な説明】

【0007】

【図1】ログ収集システムの構成図

【図2】ログ優先度テーブルの構成を例示する図

【図3】ログテーブルの構成を例示する図

【図4】臨時ログテーブルの構成を例示する図

【図5】車載装置がログを取得し蓄積する処理をあらわすフローチャート

【図6】サーバがログを収集した後の一連の処理をあらわすフローチャート

【図7】車載装置によるログ優先度テーブルの更新処理を示すフローチャート

【図8】車載装置が、ログ収集部として機能するプログラムを更新するプログラム更新処理を示すフローチャート

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

【0008】

以下、図１〜図８を参照して、ログ収集システムの実施の形態を説明する。
図１は、ログ収集システムの構成図である。ログ収集システム１は、サーバ１０、および車載装置３０から構成される。サーバ１０と車載装置３０は、ネットワーク２０を介して接続される。図１では車載装置３０は１台のみ記載されているが、サーバ１０は複数の車載装置３０と接続される。サーバ１０に接続される複数の車載装置３０は、それぞれ異なる車両に搭載される。車載装置３０は、１または複数のプログラムを実行することで、様々なサービスを車両の乗員に提供可能である。車載装置３０において実行されるプログラムは、車載装置３０の出荷時に組み込まれる。

【0009】

（サーバの構成）
サーバ１０は、ＣＰＵ１００、メモリ１１０、サーバ通信部１２０、入力部１３０、および出力部１４０を備える。以下では、サーバ１０の入力部１３０を操作する者を「オペレータ」と呼ぶ。
ＣＰＵ１００は、不図示のＲＯＭに格納されるプログラムを実行し、サーバ１０を動作させるための各種の演算処理を実行する。このプログラムは、メモリ１１０に記憶されているデータを利用する。ＣＰＵ１００は、ログ解析部１０１、臨時ログ情報作成部１０２、ログ優先度変更指示部１０３、ログ変更指示部１０４、サービス指示部１０５を機能的に有する。

【0010】

ログ解析部１０１は、車載装置３０から収集したログを解析し、車載装置３０への攻撃の可能性の検出、および車載装置３０への攻撃の検出を行う。臨時ログ情報作成部１０２は、ログ解析部１０１が車載装置３０への攻撃の可能性を検出すると、後述するログテーブルおよび後述するログ優先度テーブルを書き換える。ログ優先度変更指示部１０３は、臨時ログ情報作成部１０２が書き換えたログ優先度テーブルの情報を車載装置３０へ通知するためのログ優先度テーブル変更要求メッセージを作成し、車載装置３０へ送信する。なお、ログ優先度テーブル変更要求メッセージには、書き換え後のログ優先度テーブルの全体の内容が含まれる。ログ変更指示部１０４は、臨時ログ情報作成部１０２が書き換えたログテーブルの情報を車載装置３０へ通知する。ただし後述するように本実施の形態ではログテーブルの情報はプログラムに内包されるため、ログ変更指示部１０４は車載装置３０へプログラムを送信することによりログテーブルの変更を車載装置３０へ通知する。サービス指示部１０５は、ログ解析部１０１によりサービスを直ちに停止する必要があると判断された場合に、車載装置３０に対してサービス停止の指示を出力する。

【0011】

メモリ１１０には、データが格納される。メモリ１１０は、収集ログ格納部１１１、ログテーブル集格納部１１２、ログ優先度テーブル集格納部１１３、および臨時ログテーブル格納部１１４を機能的に有する。
収集ログ格納部１１１には、それぞれの車載装置３０から収集したログが格納される。
ログテーブル集格納部１１２には、それぞれの車載装置３０がログとして収集する情報を特定するログテーブルが格納される。ログテーブルは車載装置３０ごとに異なるので、ログテーブル集格納部１１２には、サーバ１０に接続される車載装置３０と同数のログテーブルが格納される。ただしいくつかの車載装置３０がログテーブルを共有し、ログテーブル集格納部１１２に格納されるログテーブルの数が、サーバ１０に接続される車載装置３０の数よりも少なくてもよい。

【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】

１ … ログ収集システム
１０ … サーバ
２０ … ネットワーク
３０ … サーバ
３０ … 車載装置
１０１ … ログ解析部
１０２ … 臨時ログ情報作成部
１０３ … ログ優先度変更指示部
１０４ … ログ変更指示部
１０５ … サービス指示部
１１０ … サービス停止指令部
１１０ … メモリ
１１１ … 収集ログ格納部
１１２ … ログテーブル集格納部
１１３ … ログ優先度テーブル集格納部
１１４ … 臨時ログテーブル格納部
１２０ … サーバ通信部
１５１ … ログ収集部
１５２ … ログ優先度テーブル管理部
１５３ … プログラム更新部
１５４ … サービス制御部
１６０ … メモリ
１６１ … ログテーブル格納部
１６２ … ログ優先度テーブル格納部
１６３ … ログ格納部
１６４ … 車載装置情報格納部
１６５ … 更新プログラム格納部
１７０ … 車載通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】