特許 7180686 情報処理装置、異常分析方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2022-11-21

(45)【発行日】2022-11-30

(54)【発明の名称】情報処理装置、異常分析方法及びプログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20221122BHJP

   G06F 21/55 20130101ALI20221122BHJP

【ＦＩ】

G06F11/07 151

G06F11/07 140R

G06F11/07 190

G06F11/07 193

G06F21/55 320

【請求項の数】 8

(21)【出願番号】P 2020551221

(86)(22)【出願日】2019-10-10

(86)【国際出願番号】 JP2019040017

(87)【国際公開番号】W WO2020075801

(87)【国際公開日】2020-04-16

【審査請求日】2021-03-23

(31)【優先権主張番号】P 2018192415

(32)【優先日】2018-10-11

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】長谷川 慶太

(72)【発明者】

【氏名】小山 卓麻

(72)【発明者】

【氏名】岡野 靖

(72)【発明者】

【氏名】田中 政志

【審査官】多賀 実

(56)【参考文献】

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

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

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

【文献】特開２０１１－０３４２０８（ＪＰ，Ａ）

【文献】国際公開第２０１７／１０４１１９（ＷＯ，Ａ１）

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

Ｇ０６Ｆ １１／０７

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

Ｇ０６Ｆ ２１／５５

Ｂ６０Ｒ １６／０２

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

【請求項1】

１つ又は複数の機器のうちいずれかの機器が出力した第１のデータの第１の異常スコアを計算する異常判定部と、
前記第１のデータ及び前記第１の異常スコアを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理部と、
１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ、第１の異常スコア及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析部と、
を有する情報処理装置。

【請求項2】

前記第１のデータに対して実施すべき対処方法を、前記第１のデータ又は前記第１の特徴コンテキストと対応付けて前記記憶部に登録する登録部を更に有する、請求項１に記載の情報処理装置。

【請求項3】

前記分析部は、前記記憶部から、前記受信した第２のデータに一致又は類似するデータ、又は前記取得した第２の特徴コンテキストに一致又は類似する特徴コンテキストを抽出し、当該抽出されたデータ又は特徴コンテキストに対する対処方法を出力する、請求項２に記載の情報処理装置。

【請求項4】

前記分析部における分析結果に基づいて、前記第２のデータを出力した機器の検知アルゴリズムを変更する変更部を更に有する、請求項１乃至３のうちいずれか１項に記載の情報処理装置。

【請求項5】

前記第１の特徴コンテキスト及び前記第２の特徴コンテキストは、機器の外部環境を示す空間的特徴コンテキスト、機器がデータを出力した時間を示す時間的特徴コンテキスト、及び機器の挙動を示す挙動的特徴コンテキストのうち少なくとも１つを含む、請求項１乃至４のうちいずれか１項に記載の情報処理装置。

【請求項6】

前記分析部は、特徴コンテキストに応じた重みを適用する、請求項１乃至５のうちいずれか１項に記載の情報処理装置。

【請求項7】

情報処理装置が、
１つ又は複数の機器のうちいずれかの機器が出力した第１のデータの第１の異常スコアを計算する異常判定手順と、
前記第１のデータ及び前記第１の異常スコアを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理手順と、
１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ、第１の異常スコア及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析手順と、
を実行する異常分析方法。

【請求項8】

請求項１乃至６のうちいずれか１項に記載の各部として情報処理装置を機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、異常分析方法及びプログラムに関する。

【背景技術】

【0002】

今後普及が見込まれるコネクテッドカー（外部ネットワークに接続する車両）においては、従来においてディーラーでの持ち込み作業であったＥＣＵ（Electronic Control Unit）のソフトウェアアップデートが無線で行われるなど、利便性の向上が期待されている。

【0003】

一方で、車両やその制御機器が外部ネットワークに繋がることにより、従来のＩＴ機器同様、悪意の有る攻撃者からのサイバー攻撃の対象となる懸念が指摘されている。実際に車両に搭載されたＥＣＵを、外部ネットワークからのアクセスによって不正に改竄し、車両制御を乗っ取ることが可能であったとする研究も報告されている。

【0004】

このような脅威に対して、様々な事前の対策技術が検討されているが、サイバー攻撃のリスクを完全に防ぐような対策手段というものは存在しない。したがって、万が一サイバー攻撃が発生した場合に対しても有効な事後の対策を考えておく必要がある。ＥＣＵを改竄することで車両の制御を乗っ取るような攻撃を考えた場合、車両での対策を取るためには、車載ネットワークで発生する通信を継続的に監視し、異常を検出する手法がある。しかしながら、一般に車載機器の計算リソースは潤沢ではない場合が多く、計算負荷の大きな異常検知手法は適用困難である場合が多い。

【0005】

そこで、昨今では、車両だけで対処するのではなく、クラウドと車両の双方を利用することによって、計算負荷の高い処理をクラウドで、計算負荷の低い処理や低遅延性が求められる処理を車載機で行うようなサーバクライアント連携でのサイバー攻撃への対処技術の検討が進んでいる（例えば、非特許文献１）。

【先行技術文献】

【非特許文献】

【0006】

【文献】"サイバー攻撃に対抗するオートモーティブ侵入検知防御システムを開発"、［online］、インターネット＜ＵＲＬ：https://news.panasonic.com/jp/press/data/2017/10/jn171010-2/jn171010-2.html＞

【発明の概要】

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

【0007】

車両に対するサイバー攻撃等の異常は、検知された全体の数から見れば圧倒的少数の事象であることが多い。つまり検知結果には、操作のミスや設定の変更、環境要因の変動等によって発生した、擬陽性の誤検知が含まれることが多い。サイバー攻撃の可能性があるという異常が検知された場合、検知結果に伴って実施すべき対処方法の決定等の分析を行う必要があるが、上記のような誤検知は分析コストを増加させるという問題がある。

【0008】

なお、上記のような問題は、車両に限られず、ネットワークに接続される各種の機器について共通の課題であると考えられる。

【0009】

本発明は、上記の点に鑑みてなされたものであって、機器が出力したデータを分析するコストを低減することを目的とする。

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

【0010】

そこで上記課題を解決するため、情報処理装置は、１つ又は複数の機器のうちいずれかの機器が出力した第１のデータの第１の異常スコアを計算する異常判定部と、
前記第１のデータ及び前記第１の異常スコアを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理部と、１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ、第１の異常スコア及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析部とを有する。

【発明の効果】

【0011】

機器が出力したデータを分析するコストを低減することができる。

【図面の簡単な説明】

【0012】

【図1】本発明の実施の形態におけるシステム構成例を示す図である。

【図2】本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。

【図3】本発明の実施の形態における車両２０のハードウェア構成例を示す図である。

【図4】本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。

【図5】ログの発生時における処理手順の一例を説明するためのフローチャートである。

【図6A】ログの構成例を示す図である。

【図6B】ログの構成例を示す図である。

【図7】制御系ログＤＢ２７１の構成例を示す図である。

【図8】センサログＤＢ２７２の構成例を示す図である。

【図9】ログの受信時における処理手順の一例を説明するためのフローチャートである。

【図10】特徴ナレッジＤＢ１７３の構成例を示す図である。

【図11】対処方法の決定時における処理手順の一例を説明するためのフローチャートである。

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

【0013】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、複数の車両２０は、インターネット等のネットワークＮ１を介して各種のサーバ（監視サーバ１０、サービス提供サーバ３０ａ、サービス提供サーバ３０ｂ等）に接続される自動車（コネクテッドカー）である。例えば、各車両２０は、移動体通信網等の無線ネットワークを介してネットワークＮ１に接続し、各種のサーバと通信する。

【0014】

サービス提供サーバ３０ａ及びサービス提供サーバ３０ｂ等（以下、それぞれを区別しない場合「サービス提供サーバ３０」という。）は、車両２０に対して、又は車両２０から収集される情報に基づいて所定のサービスを提供する１以上のコンピュータである。例えば、サービス提供サーバ３０ａは、テレマティクスサービスを提供してもよい。また、サービス提供サーバ３０ｂは、各車両２０から収集されるデータに基づくサービスを提供してもよい。

【0015】

監視サーバ１０は、車両２０から送信（アップロード）されるデータに基づいて、車両２０における異常の発生の検知や、異常の内容の解析等を行う１以上のコンピュータである。異常の一例として、車両２０に対するネットワークを介したサイバー攻撃等が挙げられる。

【0016】

図２は、本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。図２において、監視サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0017】

監視サーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0018】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って監視サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0019】

図３は、本発明の実施の形態における車両２０のハードウェア構成例を示す図である。図３において、車両２０は、通信装置２１０、情報系サブシステム２２０、制御系サブシステム２３０及び関門器２４０等を含む。

【0020】

通信装置２１０は、ネットワークＮ１に接続するための通信モジュールや、他の車両２０又は道路上の機器等と通信するための通信モジュールや、スマートフォン等と無線ＬＡＮ又は近距離無線通信を介して接続するための通信モジュール等を含む。

【0021】

情報系サブシステム２２０は、インストールされたプログラムに応じた情報処理を実行する部分であり、ＣＰＵ２２１、メモリ装置２２２、補助記憶装置２２３、表示装置２２４及び入力装置２２５等を含む。補助記憶装置２２３には、インストールされたプログラムや、当該プログラムによって利用される各種データが記憶される。メモリ装置２２２は、起動対象とされたプログラムを補助記憶装置２２３から読み出して格納する。ＣＰＵ２２１は、メモリ装置２２２に格納されたプログラムに従って情報系サブシステム２２０に係る機能を実行する。表示装置２２４はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置２２５は、ボタン等やタッチパネル等の操作部品であり、様々な操作指示を入力させるために用いられる。なお、例えば、カーナビゲーション、カーオーディオのヘッドユニット等の車載機が情報系サブシステム２２０の一例である。

【0022】

制御系サブシステム２３０は、車両２０の挙動を制御する部分であり、各種の制御のための複数のマイコン２３１等を含む。例えば、ＥＣＵ（Electronic Control Unit）がマイコン２３１の一例である。

【0023】

関門器２４０は、情報系サブシステム２２０と制御系サブシステム２３０と接続するためのゲートウェイ（例えば、ＣＧＷ（Central Gateway））である。すなわち、情報系サブシステム２２０において扱われる通信プロトコルは、例えば、ＩＰプロトコルであり、制御系サブシステム２３０においてマイコン２３１間の通信に利用される通信プロトコルは、制御に特化した非ＩＰプロトコル（例えば、ＣＡＮ（Controller Area Network））である。したがって、これらの通信プロトコルの違いを吸収するための関門器２４０が設けられる。

【0024】

なお、図３に示したハードウェア構成は、一例に過ぎない。後述の機能を実現可能であれば、車両２０のハードウェア構成は特定のものに限定されない。

【0025】

図４は、本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。図４において、車両２０の情報系サブシステム２２０は、制御系ログ取得部２５１、センサログ生成部２５２、異常判定部２５３、特徴コンテキスト生成部２５４、ログ送信部２５５及び検知アルゴリズム受信部２５６等を有する。これら各部は、情報系サブシステム２２０にインストールされた１以上のプログラムが、ＣＰＵ２２１に実行させる処理により実現される。情報系サブシステム２２０は、また、制御系ログＤＢ２７１、センサログＤＢ２７２及び検知アルゴリズムＤＢ２７３等のデータベース（記憶部）を有する。これら各データベース（記憶部）は、例えば、メモリ装置２２２又は補助記憶装置２２３等を用いて実現可能である。

【0026】

制御系ログ取得部２５１は、制御系ログを取得し、制御系ログＤＢ２７１に保存（記憶）する。制御系ログとは、制御系サブシステム２３０における各マイコン２３１による通信に関するログデータをいう。通信内容のデータ自体が、制御系ログとされてもよい。したがって、制御系ログは、いずれかのマイコン２３１によって通信が行われるたびに発生する。なお、当該通信の内容は、例えば、車両２０の制御、オーディオ、カーナビのようなインフォメント系の情報、車両２０内のインジケータ表示等に関する通信等の内容を示すものである。

【0027】

センサログ生成部２５２は、センサログを生成し、センサログＤＢ２７２に保存する。センサログとは、車両２０の各所に配置されているセンサ（例えば、加速度計やＧＰＳ（Global Positioning System）受信機等）から取得されるデータ（例えば、センサによる計測値等）を含むログデータをいう。各センサからのデータの取得及び、当該データに基づくセンサログの生成は、例えば、一定周期、又は特定のイベントの発生等のタイミングにおいて実行される。センサごとにセンサログの生成タイミングは異なっていてもよい。また、センサログが生成されるセンサは、車両２０が有する全センサのうちの一部でもよい。

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

例えば、車両２０のブレーキの制御を担うマイコン２３１が閾値を超えて稼働していると異常判定部２５３が判定した結果、当該マイコン２３１の制御系ログからブレーキの挙動を示す挙動的特徴コンテキストが生成され、ＧＰＳ受信機のセンサログ、カメラ又は距離センサのセンサログ、ＶＩＣＳ（登録商標）（Vehicle Information and Communication System）情報、Ｖ２Ｖ（Vehicle-to-Vehicle）又はＶ２Ｉ（Vehicle-to-Infrastructure）によって得られる情報から、車両２０の場所を示す空間的特徴コンテキストと、渋滞の発生を示す交通ドメイン依存コンテキストが生成されたと仮定する。車両２０の状態を示す車両ドメイン依存コンテキスト等の他の特徴コンテキストも生成されるが、ブレーキの制御に関係する特徴コンテキストに高い重みが適用される。重みは、誤検知を含む異常の判定において特徴コンテキストに加味される係数であり、例えば、特徴コンテキストに対する対数係数のような形で実装されてもよい。ここでは、挙動的特徴コンテキスト、空間的特徴コンテキスト及び交通ドメイン依存コンテキストの類似度に着目するため、これらの特徴コンテキストに高い重みが適用される。誤検知・対処方法判断部１５２は、一致又は類似する過去のレコードを特徴ナレッジＤＢ１７３から検索する。一致又は類似する過去のレコードの異常スコアが異常検知閾値未満である場合、誤検知・対処方法判断部１５２は、渋滞によって誤検知が発生したと判断し、特徴ナレッジＤＢ１７３において当該マイコン２３１の制御系ログに関する異常スコアの値を更新する。また、一致又は類似する過去のレコードに対して自動的に実施可能な対処方法が設定されている場合、誤検知・対処方法判断部１５２は、当該対処方法を実施する。

【0064】

例えば、車両２０のワイパーの制御を担うマイコン２３１が閾値を超えて稼働していると異常判定部２５３が判定した結果、当該マイコン２３１の制御系ログからワイパーの挙動を示す挙動的特徴コンテキストが生成され、外部のサーバから天候が雨天であることを示す空間的特徴コンテキストが生成され、車種を示す車両ドメイン依存コンテキストが生成されたと仮定する。ここでは、ワイパーの制御に関して挙動的特徴コンテキスト、空間的特徴コンテキスト及び車両ドメイン依存コンテキストの類似度に着目するため、これらの特徴コンテキストに高い重みが適用される。誤検知・対処方法判断部１５２は、一致又は類似する過去のレコードを特徴ナレッジＤＢ１７３から検索する。一致又は類似する過去のレコードの異常スコアが異常検知閾値未満である場合、誤検知・対処方法判断部１５２は、ワイパーの異常を判定するための閾値が適正でないことによって誤検知が発生したと判断し、特徴ナレッジＤＢ１７３において当該マイコン２３１の制御系ログに関する異常スコアの値を更新する。また、一致又は類似する過去のレコードに対して自動的に実施可能な対処方法が設定されている場合、誤検知・対処方法判断部１５２は、当該対処方法を実施する。

【0065】

一方、一致又は類似する過去のレコードが特徴ナレッジＤＢ１７３に存在しない場合（Ｓ２０４：Ｎｏ）、又は、当該レコードに対して自動的に実施可能な対処方法が特徴ナレッジＤＢ１７３に存在しない場合（Ｓ２０５：Ｎｏ）、誤検知・対処方法判断部１５２は、未知の検知であるため詳細な分析が必要であるという警告を出力する（Ｓ２０７）。警告は、監視サーバ１０から他の分析器又は分析官等に通知されてもよい。

【0066】

上記のブレーキの制御を担うマイコン２３１の異常検知の例、又はワイパーの制御を担うマイコン２３１の異常検知の例において、誤検知・対処方法判断部１５２は、誤検知であるかを判断できない場合、詳細な分析を他の分析器又は分析官等に要求する。

【0067】

他の分析器又は分析官等は、制御系ログＤＢ１７１又はセンサログＤＢ１７２に保存されているログと、特徴ナレッジＤＢ１７３に保存されている特徴コンテキストとを参照して、異常の分析を行う。ログに特徴コンテキストが付与されているため、サイバー攻撃等の大規模な異常（複数の車両２０に跨る異常）の発生の可能性の有無も判定できる。斯かる異常の分析方法は、所定の方法に限定されない。例えば、学習済みのモデル（ニューラルネットワーク等）に基づいて行われてもよいし、他の公知技術を用いて行われてもよい。また、異常の発生の可能性の有無の判定には、自動車会社のＣＥＲＴ（Computer Emergency Response Team）、別の企業が有するＳＯＣ（Security Operation Center）、セキュリティベンダからの発表等の情報が利用されてもよい。

【0068】

他の分析器又は分析官等の分析結果に応じて対処方法が決定される。例えば、誤検知であると判断されたログに対しては、異常として検知されなくするように検知アルゴリズムを変更する対処方法が決定される。例えば、誤検知でないと判断されたログに対しては、故障箇所の点検又は修理、マイコン２３１や補助記憶装置２２３等のソフトウェアの更新等の対処方法が決定される。

【0069】

以下、他の分析器又は分析官等による分析が終了した後に、監視サーバ１０が実行する処理手順について説明する。図１１は、対処方法の決定時における処理手順の一例を説明するためのフローチャートである。

【0070】

対処方法登録部１５５は、他の分析器又は分析官等により決定された対処方法を受け取る（Ｓ３０１）。対処方法には、自動的に実施可能な対処方法と、ディーラーでの点検又は修理等が必要であり自動的に実施不可能な対処方法が存在する。自動的に実施可能な対処方法には、例えば、異常判定部２５３が用いる検知アルゴリズムを変更すること、誤検知として扱うこと、車両２０の所有者等の予め設定された連絡先に通知すること等が含まれる。

【0071】

対処方法登録部１５５は、自動的に実施可能な対処方法を受け取った場合（Ｓ３０２：Ｙｅｓ）、当該対処方法を特徴ナレッジＤＢ１７３に登録する（Ｓ３０３）。なお、自動的に実施不可能な対処方法についても、自動的に実施不可能であるという内容を特徴ナレッジＤＢ１７３に登録してもよい。

【0072】

また、検知アルゴリズムを変更するという対処方法が特徴ナレッジＤＢ１７３に登録された場合（Ｓ３０４：Ｙｅｓ）、誤検知・対処方法判断部１５２は、検知アルゴリズムの変更を検知アルゴリズム変更部１５３に要求し、検知アルゴリズム変更部１５３は、検知アルゴリズムＤＢ１７４に記憶されている検知アルゴリズムを変更する（Ｓ３０５）。検知アルゴリズムの変更には、異常判定部２５３が用いる特徴量の抽出方法の変更、特徴量に対する重みの変更、閾値の調節、異常と判定しない条件を示すホワイトリストの設定等が含まれる。

【0073】

検知アルゴリズム送信部１５４は、無線等のインタフェース装置１５０を介して検知アルゴリズムを車両２０に送信する（Ｓ３０６）。検知アルゴリズムの送信は、一定周期で行われてもよく、検知アルゴリズムの変更に応じて行われてもよい。なお、検知アルゴリズム送信部１５４は、検知アルゴリズムの更新が必要であることを車両２０の所有者等の予め設定された連絡先に通知し、車両２０における検知アルゴリズムの更新は、ディーラー等で行われてもよい。車両２０の検知アルゴリズム受信部２５６は、検知アルゴリズムを受信し、検知アルゴリズムＤＢ２７３を変更する。変更された検知アルゴリズムは、図５のステップＳ１０２において異常スコアを判定するために用いられる。

【0074】

このように、本実施の形態では、ログに特徴コンテキストが付与されるため、異常が検知された状態を把握することが容易になる。その結果、検知結果の正誤判定や意味づけ等の分析に要するコストが低減できる。また、誤検知であるという判断に応じて検知アルゴリズムを更新することで、誤検知の発生を低減できる。

【0075】

なお、本実施の形態では、車両２０を機器の一例として説明したが、通信機能を有する他の機器について本実施の形態が適用されてもよい。例えば、工場におけるロボット等の産業用制御機器、各地に配置されたセンサ、オーディオ機器、家電製品、通信端末（スマートフォン、タブレット端末等）や、一般的にＩｏＴ（Internet of Things）機器と呼ばれる機器について、本実施の形態が適用されてもよい。

【0076】

上述したように、本実施の形態によれば、車両２０において発生するデータ（ログ）に対して特徴コンテキストが付与されて監視サーバ１０へ送信される。監視サーバ１０は、送信されたログ及び特徴コンテキストを紐付けて特徴ナレッジＤＢ１７３に保存することにより、ログの分析に要するコストを低減することができる。

【0077】

また、監視サーバ１０は、自動的に実施可能な対処方法を特徴ナレッジＤＢ１７３に登録することにより、分析官等が分析すべきログの量を減少させることができる。

【0078】

また、監視サーバ１０は、過検知が発生したときに、当該過検知が発生しないように車両２０の検知アルゴリズムを変更することで、過検知の発生を低減することができる。

【0079】

なお、本実施の形態において、車両２０は、機器の一例である。監視サーバ１０は、情報処理装置の一例である。ログ受信部１５１は、記憶処理部の一例である。誤検知・対処方法判断部１５２は、分析部の一例である。対処方法登録部１５５は、登録部の一例である。検知アルゴリズム変更部１５３及び検知アルゴリズム送信部１５４は、変更部の一例である。

【0080】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【0081】

本国際出願は２０１８年１０月１１日に出願した日本国特許出願２０１８－１９２４１５号に基づく優先権を主張するものであり、２０１８－１９２４１５号の全内容を本国際出願に援用する。

【符号の説明】

【0082】

１０ 監視サーバ
２０ 車両
３０ａ サービス提供サーバ
３０ｂ サービス提供サーバ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１５１ ログ受信部
１５２ 誤検知・対処方法判断部
１５３ 検知アルゴリズム変更部
１５４ 検知アルゴリズム送信部
１５５ 対処方法登録部
１７１ 制御系ログＤＢ
１７２ センサログＤＢ
１７３ 特徴ナレッジＤＢ
１７４ 検知アルゴリズムＤＢ
２１０ 通信装置
２２１ ＣＰＵ
２２２ メモリ装置
２２３ 補助記憶装置
２２４ 表示装置
２２５ 入力装置
２２０ 情報系サブシステム
２３０ 制御系サブシステム
２３１ マイコン
２４０ 関門器
２５１ 制御系ログ取得部
２５２ センサログ生成部
２５３ 異常判定部
２５４ 特徴コンテキスト生成部
２５５ ログ送信部
２５６ 検知アルゴリズム受信部
２７１ 制御系ログＤＢ
２７２ センサログＤＢ
２７３ 検知アルゴリズムＤＢ
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】