(57)【要約】  機器から取得されたログから、プロセスと当該プロセスに関連するオブジェクトとの関連付けを示すグラフ構造を生成する生成部と、前記機器のいずれかのオブジェクトが指定された場合、前記生成されたグラフ構造に基づいて、当該指定されたオブジェクトに関連するプロセスを特定し、当該特定されたプロセスに関連するオブジェクトを特定する特定部とを有する。
2020075808.tif 000002
【特許請求の範囲】
【請求項１】
機器から取得されたログから、プロセスと当該プロセスに関連するオブジェクトとの関連付けを示すグラフ構造を生成する生成部と、
前記機器のいずれかのオブジェクトが指定された場合、前記生成されたグラフ構造に基づいて、当該指定されたオブジェクトに関連するプロセスを特定し、当該特定されたプロセスに関連するオブジェクトを特定する特定部と、
を有する情報処理装置。
【請求項２】
前記特定部は、前記機器のいずれかのオブジェクトにおいて異常が検知された場合、前記生成されたグラフ構造に基づいて、当該異常が検知されたオブジェクトに関連する異常なプロセスを特定し、当該異常なプロセスに関連する異常なオブジェクトを特定し、当該異常なオブジェクトの中に前記機器の外部に接続するためのオブジェクトが存在するか否かを判断し、当該判断の結果に基づいて、前記異常が外部攻撃によって発生したと判断する、請求項１に記載の情報処理装置。
【請求項３】
前記特定部は、外部攻撃がない環境において前記機器から取得されたログから生成されたグラフ構造と、外部攻撃の可能性がある環境において前記機器から取得されたログから生成されたグラフ構造とを比較して、外部攻撃の発生を検知する、請求項１又は２に記載の情報処理装置。
【請求項４】
前記生成部は、予め作成されたオブジェクトとプロセスとの間の紐付け情報を用いて、前記グラフ構造の関連付けを補完する、請求項１乃至３のうちいずれか１項に記載の情報処理装置。
【請求項５】
前記特定されたプロセスに関連するオブジェクトに対するアクションを禁止する禁止部を更に有する、請求項１乃至４のうちいずれか１項に記載の情報処理装置。
【請求項６】
情報処理装置が、
機器から取得されたログから、プロセスと当該プロセスに関連するオブジェクトとの関連付けを示すグラフ構造を生成するグラフ構造生成手順と、
前記機器のいずれかのオブジェクトが指定された場合、前記生成されたグラフ構造に基づいて、当該指定されたオブジェクトに関連するプロセスを特定し、当該特定されたプロセスに関連するオブジェクトを特定する特定手順と、
を実行するログ分析方法。
【請求項７】
請求項１乃至５のうちいずれか１項に記載の各部として情報処理装置を機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、ログ分析方法及びプログラムに関する。
【背景技術】
【０００２】
今後普及が見込まれるコネクテッドカー（外部ネットワークに接続する車両）においては、従来においてディーラーでの持ち込み作業であったＥＣＵ（Electronic Control Unit）のソフトウェアアップデートが無線で行われるなど、利便性の向上が期待されている。【０００３】
一方で、車両やその制御機器が外部ネットワークに繋がることにより、従来のＩＴ機器同様、悪意の有る攻撃者からのサイバー攻撃の対象となる懸念が指摘されている。実際に車両に搭載されたコントローラを外部ネットワークからのアクセスによって不正に改竄し、コントローラからＥＣＵに対して偽指令を行うことで車両制御を乗っ取ることが可能であったとする研究も報告されている（例えば、非特許文献１）。【０００４】
車両へのサイバー攻撃を検知するために、車両の制御情報ネットワークであるＣＡＮ（Controller Area Network）に対する異常を検知するためのＩＤＳ（Intrusion Detection System）の検討が進められている（例えば、非特許文献２、３）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Sen Nie他, "FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN BUS"", BlackHat, 2017, ［online］, インターネット＜ＵＲＬ：https://www.blackhat.com/docs/us-17/thursday/us-17-Nie-Free-Fall-Hacking-Tesla-From-Wireless-To-CAN-Bus-wp.pdf＞
【非特許文献２】大塚敏史他, "既存ＥＵＣを変更不要な車載ＬＡＮ向け侵入検知手法", 情報処理学会研究報告, Vol. 2013-EMB-28 No. 6, pp.31-35, 2013年
【非特許文献３】岡野靖他, "Variance Gamma分布およびDouble Gamma分布を用いたコントロールエリアネットワークに対するメッセージ挿入攻撃の異常検知", SCIS 2018, 2018年
【発明の概要】
【発明が解決しようとする課題】
【０００６】
車両へのサイバー攻撃が発生したときに、ＩＤＳが異常を検知する検討は進められているが、異常がどのように引き起こされたかを分析することは困難である。【０００７】
非特許文献１のサイバー攻撃の例では、まず、車載Ｗｅｂブラウザが偽サイトにアクセスして不正コードをダウンロードする。その後、不正コードによって偽のコントローラ更新ソフトウェアがダウンロードされ、車両のコントローラのソフトウェアを更新する。その結果、コントローラからＥＣＵに偽指令が行われる。この例では、偽のコントローラ更新ソフトウェアをダウンロードする前後で攻撃経路が一旦中断される。このように、車両へのサイバー攻撃では、そのサイバー攻撃の発生から異常の検知までの攻撃経路が不連続になる可能性がある。ＥＣＵへの偽指令が行われたときにＩＤＳが異常を検知することができても、異常は当該ＥＣＵだけではなく、車載Ｗｅｂブラウザまでの攻撃経路に渡って存在し、異常の根本的な原因である不正コードのダウンロードまでの攻撃経路を特定することは困難である。【０００８】
なお、上記のような問題は、車両に限られず、ネットワークに接続される各種の機器について共通の課題であると考えられる。例えば、ＩｏＴ（Internet of Things）機器はクライアント機器として動作し得るため、車両へのサイバー攻撃と同様に、異常が検知される前に攻撃が行われており、攻撃経路が不連続になる可能性がある。ネットワークに接続される機器において、攻撃経路等の影響範囲を効率的に分析することが求められる。さらに、異常が検知された場合のみならず、外部攻撃が疑われる場合にも、その影響範囲を効率的に分析できることが望まれる。【０００９】
本発明は、上記の点に鑑みてなされたものであって、機器において指定された事象の影響範囲を効率的に分析することを目的とする。
【課題を解決するための手段】
【００１０】
そこで上記課題を解決するため、情報処理装置は、機器から取得されたログから、プロセスと当該プロセスに関連するオブジェクトとの関連付けを示すグラフ構造を生成する生成部と、前記機器のいずれかのオブジェクトが指定された場合、前記生成されたグラフ構造に基づいて、当該指定されたオブジェクトに関連するプロセスを特定し、当該特定されたプロセスに関連するオブジェクトを特定する特定部とを有する。
【発明の効果】
【００１１】
機器において指定された事象の影響範囲を効率的に分析することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。
【図３】本発明の実施の形態における車両２０のハードウェア構成例を示す図である。
【図４Ａ】本発明の実施例１における車両２０及び監視サーバ１０の機能構成例を示す図である。
【図４Ｂ】本発明の実施例１における車両２０の機能構成例を示す図である。
【図５Ａ】本発明の実施例２における車両２０及び監視サーバ１０の機能構成例を示す図である。
【図５Ｂ】本発明の実施例３における車両２０及び監視サーバ１０の機能構成例を示す図である。
【図６】ログの発生時における処理手順の一例を説明するためのフローチャートである。
【図７Ａ】正常時に実行される処理の一例を示すシーケンス図である。
【図７Ｂ】正常時に実行される処理の一例を示すシーケンス図である。
【図８】図７Ａ及び図７Ｂのシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。
【図９Ａ】外部攻撃時に実行される処理の一例を示すシーケンス図である。
【図９Ｂ】外部攻撃時に実行される処理の一例を示すシーケンス図である。
【図１０】図９Ａ及び図９Ｂのシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。
【図１１】グラフ構造の一例を示す図である。
【図１２】紐付け情報の一例を示す図である。
【図１３】グラフ構造の結合例を示す図である。
【図１４Ａ】正常時のグラフ構造を示す図である。
【図１４Ｂ】外部攻撃時のグラフ構造を示す図である。
【図１５】故障発生時に実行される処理の一例を示すシーケンス図である。
【図１６】図１５のシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。
【図１７Ａ】通常の故障時のグラフ構造を示す図である。
【図１７Ｂ】外部攻撃時のグラフ構造を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、複数の車両２０は、インターネット等のネットワークＮ１を介して各種のサーバ（監視サーバ１０、サービス提供サーバ３０ａ、サービス提供サーバ３０ｂ等）に接続される自動車（コネクテッドカー）である。例えば、各車両２０は、移動体通信網等の無線ネットワークを介してネットワークＮ１に接続し、各種のサーバと通信する。
【００１４】
サービス提供サーバ３０ａ及びサービス提供サーバ３０ｂ等（以下、それぞれを区別しない場合「サービス提供サーバ３０」という。）は、車両２０に対して、又は車両２０から収集される情報に基づいて所定のサービスを提供する１以上のコンピュータである。例えば、サービス提供サーバ３０ａは、テレマティクスサービスを提供してもよい。また、サービス提供サーバ３０ｂは、各車両２０から収集されるデータに基づくサービスを提供してもよい。
【００１５】
監視サーバ１０は、車両２０から送信（アップロード）されるデータに基づいて、車両２０における異常の発生の検知や、異常の内容の解析等を行う１以上のコンピュータである。異常の一例として、車両２０に対するネットワークを介したサイバー攻撃（外部攻撃）等が挙げられる。
【００１６】
図２は、本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。図２において、監視サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１７】
監視サーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１８】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って監視サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００１９】
図３は、本発明の実施の形態における車両２０のハードウェア構成例を示す図である。図３において、車両２０は、通信装置２１０、情報系サブシステム２２０、制御系サブシステム２３０及び関門器２４０等を含む。
【００２０】
通信装置２１０は、ネットワークＮ１に接続するための通信モジュールや、他の車両２０又は道路上の機器等と通信するための通信モジュールや、スマートフォン等と無線ＬＡＮ又は近距離無線通信を介して接続するための通信モジュール等を含む。
【００２１】
情報系サブシステム２２０は、インストールされたプログラムに応じた情報処理を実行する部分であり、ＣＰＵ２２１、メモリ装置２２２、補助記憶装置２２３、表示装置２２４及び入力装置２２５等を含む。補助記憶装置２２３には、インストールされたプログラムや、当該プログラムによって利用される各種データが記憶される。メモリ装置２２２は、起動対象とされたプログラムを補助記憶装置２２３から読み出して格納する。ＣＰＵ２２１は、メモリ装置２２２に格納されたプログラムに従って情報系サブシステム２２０に係る機能を実行する。表示装置２２４はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置２２５は、ボタン等やタッチパネル等の操作部品であり、様々な操作指示を入力させるために用いられる。なお、例えば、カーナビゲーション、カーオーディオのヘッドユニット等の車載機が情報系サブシステム２２０の一例である。
【００２２】
制御系サブシステム２３０は、車両２０の挙動を制御する部分であり、各種の制御のための複数のマイコン２３１等を含む。例えば、ＣＡＮ（Controller Area Network）のような非ＩＰプロトコルが制御系サブシステム２３０において利用される。なお、例えば、ＥＣＵ（Electronic Control Unit）がマイコン２３１の一例である。
【００２３】
関門器２４０は、情報系サブシステム２２０と制御系サブシステム２３０と接続するためのゲートウェイ（例えば、ＣＧＷ（Central Gateway））である。関門器２４０は情報系サブシステム２２０のネットワークと制御系サブシステム２３０のネットワーク間の通信の中継を行う。関門器２４０は、通信フィルタリングにより、必要十分な通信のみを中継（シグナル中継）する場合があり、情報系サブシステム２２０と制御系サブシステム２３０をハードウェア的・ソフトウェア的に適切に分離（アイソレーション）する役割を担う。
【００２４】
なお、図３に示したハードウェア構成は、一例に過ぎない。後述の機能を実現可能であれば、車両２０のハードウェア構成は特定のものに限定されない。
【００２５】
（実施例１）
本発明の実施例１では、監視対象とするデバイスから出力されたログを取得して、指定された事象に関する一連の動作を把握するための手段について説明する。
【００２６】
図４Ａは、本発明の実施例１における車両２０及び監視サーバ１０の機能構成例を示す図である。図４Ａにおいて、車両２０の情報系サブシステム２２０は、モニタ部２５１及びログ送信部２５３等を有する。これら各部は、情報系サブシステム２２０にインストールされた１以上のプログラムが、ＣＰＵ２２１に実行させる処理により実現される。情報系サブシステム２２０は、また、ログ管理ＤＢ２７１等のデータベース（記憶部）を有する。このデータベース（記憶部）は、例えば、メモリ装置２２２又は補助記憶装置２２３等を用いて実現可能であり、メモリ装置２２２又は補助記憶装置２２３等のメモリ保護領域に設けられてもよい。
【００２７】
モニタ部２５１は、監視対象とするデバイス（例えば、情報系サブシステム２２０、制御系サブシステム２３０のマイコン２３１、関門器２４０等）からログを取得する。モニタ部２５１がログを取得するタイミングは、一定の周期又は特定のイベントの発生等でもよく、例えば、異常検知装置（車両２０内のＩＤＳ等）が異常を検知したタイミングでもよく、モニタ部２５１の実行トリガが人手又は他の装置によって入力されたタイミングでもよい。例えば、モニタ部２５１は、ログを取得するタイミングにおいて、情報系サブシステム２２０のＣＰＵ２２１上で実行するプロセス、制御系サブシステム２３０のマイコン２３１上で実行するプロセス、関門器２４０上で実行するプロセスに関するログを取得する。デバイスやその内部のプロセスによっては必ずしも必要なログが出力されないことがあるが、モニタ部２５１は、システムコマンド等を利用することによってログを取得する。例えば、監視対象とするデバイスがＬｉｎｕｘ（登録商標）ベースのシステムである場合、ＳｙｓｔｅｍＴａｐによってカーネルの振る舞いを取得できる。また、例えば、監視対象とするデバイスがＢＳＤベースのシステムである場合、ＤＴｒａｃｅによってプロセスの動きを取得できる。ログは、監視対象とするデバイスと、当該デバイス上で実行するプロセスと、当該プロセスに関連するオブジェクトと、当該プロセスがオブジェクトに対して実行するアクション等の項目を含む。オブジェクトとは、プロセスの制御対象であり、例えば、ファイル、通信アドレス、プロセス（子プロセス）、デバイス等である。アクションは、オブジェクトに対する操作である。例えば、オブジェクトがファイルである場合、アクションは生成、削除、変更、読み出し等である。なお、モニタ部２５１は、ＣＰＵ２２１上で実行するアプリケーションのログを収集し、収集したログを上記の項目に加工してもよい。
【００２８】
モニタ部２５１により取得されたログはログ管理ＤＢ２７１に保存される。ログ管理ＤＢ２７１において、セキュリティのための署名や暗号化が行われてもよい。外部攻撃の発生から異常の検知までの時間を考慮して、必要な期間分のログがログ管理ＤＢ２７１に保持される。ログ管理ＤＢ２７１のリソースを節約するために、保持不要なログはログ管理ＤＢ２７１から削除されてもよい。例えば、車両２０において或るファームウェアのファイルが更新された場合、当該ファイルの規定した世代より前のログは削除されてもよい。
【００２９】
ログ送信部２５３は、監視サーバ１０への送信タイミングが到来したときに、ログ管理ＤＢ２７１に保存されているログを監視サーバ１０へ送信する。
【００３０】
一方、監視サーバ１０は、ログ受信部１５１、グラフ構造生成部１５２及びトラッキング部１５３等を有する。これら各部は、監視サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。監視サーバ１０は、また、ログ管理ＤＢ１７１、グラフ管理ＤＢ１７２及び紐付け情報ＤＢ１７３等のデータベース（記憶部）を利用する。これら各データベース（記憶部）は、例えば、補助記憶装置１０２、又は監視サーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能であり、補助記憶装置１０２又はネットワークを介して接続可能な記憶装置等のメモリ保護領域に設けられてもよい。
【００３１】
ログ受信部１５１は、車両２０から送信（アップロード）されるログを受信し、当該ログをログ管理ＤＢ１７１に記憶する。ログ管理ＤＢ１７１において、セキュリティのための署名や暗号化が行われてもよい。監視サーバ１０においても、外部攻撃の発生から異常の検知までの時間を考慮して、必要な期間分のログがログ管理ＤＢ１７１に保持される。ログ管理ＤＢ１７１のリソースを節約するために、保持不要なログはログ管理ＤＢ１７１から削除されてもよい。例えば、車両２０において或るファームウェアのファイルが更新された場合、当該ファイルの規定した世代より前のログは削除されてもよい。
【００３２】
グラフ構造生成部１５２は、ログ管理ＤＢ１７１に記憶されたログから、プロセスとオブジェクトとの関連付けを示すグラフ構造を生成する。グラフ構造には、有向非巡回グラフや二部グラフ等のグラフ理論に基づく生成アルゴリズムを用いることができる。生成されたグラフ構造は、グラフ管理ＤＢ１７２に保存される。グラフ管理ＤＢ１７２において、セキュリティのための署名や暗号化が行われてもよい。グラフ管理ＤＢ１７２のリソースを節約するために、グラフ構造は、ＬＯＵＤＳ（Level-Order Unary Degree Sequence）等の簡潔データ構造を用いてグラフ管理ＤＢ１７２に保存されてもよい。グラフ管理ＤＢ１７２のリソースを節約するために、保持不要なグラフ構造はグラフ管理ＤＢ１７２から削除されてもよい。例えば、保持不要なログがログ管理ＤＢ１７１から削除された場合、削除されたログに関連付けられたグラフ構造はグラフ管理ＤＢ１７２から削除されてもよい。
【００３３】
監視対象とするデバイスによっては、ログの一部の項目が不足してグラフ構造が生成できない場合が存在する。例えば、オブジェクトがファイルである場合、そのファイルが何のデバイスのプロセスに関連するかを特定できない場合が存在する。また、ログ自体が取得できない場合も存在する。例えば、ＣＡＮ通信が行われたが、通信相手のＥＣＵのログが取得できない場合が存在する。このような場合、予めオブジェクトとプロセスとの関連付けを紐付け情報として紐付け情報ＤＢ２７３において管理しておく。ファイルの例では、ファイルと当該ファイルを使用するプロセスとの関連付けを紐付け情報ＤＢ２７３において管理しておく。ＣＡＮ通信の例では、ＣＡＮ通信に関するオブジェクトと当該ＣＡＮ通信の通信相手のＥＣＵのプロセスとの関連付けを紐付け情報ＤＢ２７３において管理しておく。グラフ構造生成部１５２は、紐付け情報ＤＢ２７３に保存された紐付け情報を用いて、グラフ構造の関連付けを補完する。
【００３４】
トラッキング部１５３は、グラフ管理ＤＢ１７２に保存されたグラフ構造を用いて、指定のオブジェクト等に関連するプロセスを特定し、特定したプロセスに関連するオブジェクトを更に特定する。トラッキング部１５３がプロセス及びオブジェクトを特定するタイミングは、異常検知装置（車両２０内のＩＤＳ等）が異常を検知したタイミングでもよく、トラッキング部１５３の実行トリガが人手又は他の装置によって入力されたタイミングでもよい。例えば、車両２０内のＩＤＳにおいて或るマイコン２３１に異常が検知された場合、トラッキング部１５３は、当該マイコン２３１に関連する異常なプロセスを特定し、さらに、特定した異常なプロセスに関連するオブジェクトを特定する。なお、異常が検知されていない状態であっても疑わしいプロセス及びオブジェクトを特定するため、人手又は他の装置による実行トリガは、異常の検知とは異なるタイミングで行われてもよい。このように、トラッキング部１５３は指定された事象（異常の検知、外部攻撃の疑い等も含む）に関連するプロセス及びオブジェクトを特定することができ、指定された事象に関連しないプロセス及びオブジェクトを除外することができるため、指定された事象の影響範囲を特定することができる。また、指定された事象が発生するまでの経路を探索するための情報を提供できる。
【００３５】
図４Ａには、監視サーバ１０がグラフ構造生成部１５２及びトラッキング部１５３等の各部を含む例が示されているが、これらの機能部の一部又は全部が車両２０に含まれてもよい。
【００３６】
図４Ｂは、本発明の実施例１における車両２０の機能構成例を示す図である。図４Ｂでは、グラフ構造生成部２５４及びトラッキング部２５５の各部が車両２０に含まれ、グラフ管理ＤＢ２７２及び紐付け情報ＤＢ２７３の各データベースが車両２０に含まれている。グラフ構造生成部２５４及びトラッキング部２５５が実行する処理は、図４Ａにおけるグラフ構造生成部１５２及びトラッキング部１５３と同じである。なお、グラフ構造生成部が車両２０に含まれ、トラッキング部が監視サーバに含まれる構成も可能である。また、モニタ部が監視サーバ１０に含まれてもよい。
【００３７】
（実施例２）
本発明の実施例２では、外部攻撃の判定を行うための手段について説明する。
【００３８】
図５Ａは、本発明の実施例２における車両２０及び監視サーバ１０の機能構成例を示す図である。図５Ａにおいて、車両２０の情報系サブシステム２２０は、図４Ａに示すモニタ部２５１及びログ送信部２５３に加えて、異常判定部２５２を更に有してもよい。異常判定部２５２は、車両２０のＩＤＳ等によって実現されてもよい。異常判定部２５２も、情報系サブシステム２２０にインストールされた１以上のプログラムが、ＣＰＵ２２１に実行させる処理により実現される。
【００３９】
車両２０におけるモニタ部２５１及びログ送信部２５３の処理は、実施例１におけるモニタ部２５１及びログ送信部２５３の処理と同じである。
【００４０】
異常判定部２５２は、モニタ部２５１が取得したログに基づいて、異常の有無を判定する。例えば、マイコン２３１間の通信間隔や、マイコン２３１が出力したデータ値に基づいて異常の有無が判定されてもよい。また、例えば、ログを入力とし、異常度を出力とする学習済みのモデル（例えば、ニューラルネットワーク）に対し、モニタ部２５１が取得したログを入力することで、異常の有無が判定されてもよい。
【００４１】
監視サーバ１０におけるログ受信部１５１及びグラフ構造生成部１５２の処理は、実施例１におけるログ受信部１５１及びグラフ構造生成部１５２の処理と同じである。
【００４２】
トラッキング部１５３は、グラフ管理ＤＢ１７２に保存されたグラフ構造を用いて、指定のオブジェクト等に関連するプロセスを特定し、特定したプロセスに関連するオブジェクトを更に特定する。例えば、車両２０内のＩＤＳ又は異常判定部２５２等において或るマイコン２３１に異常が検知された場合、トラッキング部１５３は、当該マイコン２３１に関連する異常なプロセスを特定し、さらに、特定した異常なプロセスに関連するオブジェクトを特定する。このように、トラッキング部１５３は異常に関連するプロセス及びオブジェクトを特定することができ、異常に関連しないプロセス及びオブジェクトを除外することができるため、異常の影響範囲を特定することができる。また、異常が発生するまでの経路を探索するための情報を提供できる。
【００４３】
異常の検知においては、外部攻撃も故障も異常として検知される可能性がある。ほとんどの外部攻撃は外部起点があり、ほとんどの故障は外部起点がないという経験則を利用することで、トラッキング部１５３は、グラフ構造をたどって、外部起点があるとき、すなわち、車両２０の外部に接続するための通信装置２１０が関与するときに外部攻撃の可能性があると判断してもよい。ただし、ディーラー等が通信装置２１０にアクセスしたことによって異常が検知された場合には、外部攻撃の可能性がないと判断するため、トラッキング部１５３は、外部起点の通信アドレスに関して予め設定されたブラックリスト又はホワイトリストを参照して、外部攻撃の可能性を判断してもよい。
【００４４】
また、トラッキング部１５３は、外部攻撃がない環境において生成された正常時のグラフ構造と、外部攻撃の可能性がある環境において生成されたグラフ構造とを比較して、外部攻撃の発生を検知してもよい。また、トラッキング部１５３は、外部攻撃が発生していない故障時又は正常時のグラフ構造を参照することで、当該グラフ構造ではあり得ない経路が発生したときに外部攻撃の可能性があると判断してもよい。また、トラッキング部１５３は、仕様によって規定された経路を表すグラフ構造と比較して、当該グラフ構造ではあり得ない経路が発生したときに外部攻撃の可能性があると判断してもよい。また、トラッキング部１５３は、仕様上又はセキュリティ上の理由であってはならない経路を表すグラフ構造と比較して、当該グラフ構造に一致する経路が発生したときに外部攻撃の可能性があると判断してもよい。
【００４５】
なお、図５Ａには、車両２０が異常判定部２５２を含む例が示されているが、異常判定部２５２は監視サーバ１０に含まれてもよい。
【００４６】
（実施例３）
本発明の実施例３では、車両２０等における安全性を考慮して、外部攻撃等による被害を防ぐための手段について説明する。
【００４７】
図５Ｂは、本発明の実施例３における車両２０及び監視サーバ１０の機能構成例を示す図である。図５Ｂにおいて、監視サーバ１０は、図５Ａに示すログ受信部１５１、グラフ構造生成部１５２及びトラッキング部１５３に加えて、アクション禁止部１５４を更に有する。アクション禁止部１５４も、監視サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
【００４８】
車両２０におけるモニタ部２５１、異常判定部２５２及びログ送信部２５３の処理は、実施例２におけるモニタ部２５１、異常判定部２５２及びログ送信部２５３の処理と同じである。
【００４９】
監視サーバ１０におけるログ受信部１５１、グラフ構造生成部１５２及びトラッキング部１５３の処理は、実施例２におけるログ受信部１５１、グラフ構造生成部１５２及びトラッキング部１５３の処理と同じである。
【００５０】
アクション禁止部１５４は、トラッキング部１５３において特定された影響範囲内のオブジェクトに対するアクションを禁止し、異常による被害の拡大を防ぐ。例えば、アクション禁止部１５４は、Ｌｉｎｕｘベースのシステムである場合、ＡｐｐＡｒｍｏｒによってオブジェクトへのアクセス制御を行うことができる。
【００５１】
なお、図５Ｂには、監視サーバ１０がアクション禁止部１５４を含む例が示されているが、アクション禁止部１５４は車両２０に含まれてもよい。
【００５２】
（具体例）
以下、図５Ｂに示す機能構成例において、車両２０の情報系サブシステム２２０及び監視サーバ１０が実行する処理手順について説明する。図６は、ログの発生時における処理手順の一例を説明するためのフローチャートである。
【００５３】
まず、車両２０のモニタ部２５１は、監視対象とするデバイスが出力したログを取得する（Ｓ１０１）。例えば、モニタ部２５１は、一定の周期又は特定のイベントの発生等のタイミングにおいて、ＬｉｎｕｘのＳｙｓｔｅｍＴａｐやＢＳＤのＤＴｒａｃｅ等を用いることで、ログを取得する。監視対象とするデバイスに応じて、ログの取得タイミングは異なってもよい。
【００５４】
車両２０内で実行される処理に応じてモニタ部２５１がログを取得する具体例について説明する。
【００５５】
図７Ａ及び図７Ｂは、正常時に実行される処理の一例を示すシーケンス図である。図７Ａ及び図７Ｂにおいて、ＯＴＡ  Ｂ．（Over The Air Backend）は車外にあるサービス提供サーバ３０の１つであり、車両２０に対して更新ソフトウェアを提供する機能を有する。ＴＣＵ（Telematics Control Unit）は情報系サブシステム２２０の機能部であり、サービス提供サーバ３０と通信するための機能を有する。ＦＧ（Flashing Gateway）は情報系サブシステム２２０又は制御系サブシステム２３０の機能部であり、ＯＴＡ  Ｂ．から受信したソフトウェアを一時的に保存する機能を有する。ＣＴＬ（Controller）は関門器２４０に対応し、ＯＴＡ  Ｂ．から受信したソフトウェアを更新する機能（ＯＴＡ）を有する。ＵＩ（User Interface）は運転パネル等であり、情報系サブシステム２２０の表示装置２２４及び入力装置２２５に対応する。ＥＣＵ２はマイコン２３１に対応する。ＥＣＵ２からはログが取得できないと仮定する。制御系サブシステム２３０におけるＣＡＮ通信時に、ＣＴＬはＣＡＮ−ＩＤ１を使用し、ＥＣＵ２はＣＡＮ−ＩＤ２を使用することとする。
【００５６】
ＴＣＵは、一定の周期又は特定のイベントの発生等のタイミングにおいて、ＯＴＡ  Ｂ．に対して車両２０内で更新すべきファームウェアがあるか否かを確認する（ｔ１．１）。更新すべきファームウェアがある場合、ＴＣＵは、ＯＴＡ  Ｂ．に対して新たなファームウェアの更新ファイルを要求する（ｔ１．２）。ＴＣＵが更新ファイルを受信した場合、更新ファイルをＦＧに保存する（ｔ１．３）。
【００５７】
ＣＴＬは、一定の周期又は特定のイベントの発生等のタイミングにおいて、ＦＧに対してＣＴＬにおいて更新すべきファームウェアがあるか否かを確認し、更新すべきファームウェアがある場合、ＦＧから新たなファームウェアの更新ファイルを取得する（ｔ２．１）。ＣＴＬは、更新ファイルを用いてＣＴＬのファームウェアを更新し（ｔ２．２）、更新したファームウェアを有効にするためにＣＴＬを再起動する（ｔ２．３）。
【００５８】
ＵＩが運転手等からＥＣＵ２に対する操作命令を受け付けた場合、ＵＩは操作命令を示すメッセージをＣＴＬに送信する（ｔ３．１）。ＣＴＬはＴＣＵからのメッセージにＣＡＮ−ＩＤ１を付与してＥＣＵ２に中継する（ｔ３．２）。ＥＣＵ２はメッセージに付与されたＣＴＬのＩＤであるＣＡＮ−ＩＤ１を確認し、受信したメッセージに応じた動作を行う。
【００５９】
ｔ１．１〜ｔ１．３における更新ファイルのダウンロード、ｔ２．１〜ｔ２．３におけるファームウェアの更新、ｔ３．１〜ｔ３．２におけるＥＣＵ２への操作は、異なるタイミングに実施され、時間的に不連続になる。
【００６０】
図８は、図７Ａ及び図７Ｂのシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。モニタ部２５１は、ＴＣＵ、ＣＴＬ及びＵＩのデバイスを対象として、ＬｉｎｕｘのＳｙｓｔｅｍＴａｐやＢＳＤのＤＴｒａｃｅ等を実行し、日時、デバイス、プロセス、ＳＲＣ、ＤＳＴ及びアクションを含むログを取得する。日時はデバイス内のプロセスの実行日時である。デバイスは監視対象のデバイスであり、プロセスは監視対象のデバイス内で実行されたプロセスである。ＳＲＣはプロセスの制御元のオブジェクトであり、ＤＳＴはプロセスの制御先のオブジェクトである。アクションはオブジェクトに対して行われた操作である。
【００６１】
図８の１行目のログは、図７Ａにおけるｔ１．１に対応する。ｔ１．１の日時において、ＴＣＵのプロセス（ｔｃｕ  ｐｉｄ１）によって、送信元アドレス（ＩＰ：ｉｐ１：ｐｏｒｔ１）から宛先アドレス（ＩＰ：ｏｔａ＿ｉｐ：８０）に対して、更新すべきファームウェアがあるか否かを確認するアクション（http://ota_ip/info）を実行したときのログが取得される。同様に、ｔ１．２の日時においてＴＣＵが更新ファイルを要求するアクションを実行したときのログと、ｔ１．３の日時においてＴＣＵが更新ファイルをＦＧに保存するアクションを実行したときのログが取得される。「−」はログが取得できない項目である。
【００６２】
図８の４行目のログは、図７Ａにおけるｔ２．１に対応する。ｔ２．１の日時において、ＣＴＬがＯＴＡ機能のプロセス（ｏｔａ  ｐｉｄ１）によって、更新ファイルの取得先（ＦＧ：ＦｉｒｍｗａｒｅＣＴＬ）から、新たなファームウェアの更新ファイルを取得するアクション（ｆｉｌｅ：ｒｅａｄ）を実行したときのログが取得される。同様に、ｔ２．２の日時においてＣＴＬがファームウェアを更新するアクションを実行したときのログと、ｔ２．３の日時においてＣＴＬが自身のプロセスを終了するアクションを実行したときのログと、ＣＴＬが自身のプロセスを開始するアクションを実行したときのログが取得される。
【００６３】
図８の８行目のログは、図７Ｂにおけるｔ３．１に対応する。ｔ３．１の日時において、ＵＩがＵＩのプロセス（ｕｉ  ｐｉｄ１）によって、制御先のＣＴＬ（ＣＡＮ：ＩＤ１）に対してＣＡＮ通信のメッセージを送信するアクション（ＣＡＮ）を実行したときのログが取得される。同様に、ｔ３．２の日時においてＣＴＬがメッセージをＥＣＵ２に送信するアクションを実行したときのログが取得される。
【００６４】
図９Ａ及び図９Ｂは、外部攻撃時に実行される処理の一例を示すシーケンス図である。図９Ａ及び図９Ｂは、マルウェアに感染したときのシーケンス図であり、Ｍａｌ  ＣＴＬはマルウェアに感染した関門器２４０を示す。Ｃ＆Ｃ（Command and Control）は不正操作を実施するサーバである。
【００６５】
ＴＣＵのブラウザは、例えば販売店・代理店・スタンドのホットスポット等に偽装された偽サイトにアクセスする（ｔ１．１）。偽サイトへのアクセスによって攻撃スクリプトがＴＣＵに送信される。攻撃スクリプトは、ＴＣＵの脆弱性を悪用して、ブラウザが任意のコードを実行できるように改竄する。ブラウザは、偽サイトに対してマルウェアを要求する（ｔ１．２）。ＴＣＵがマルウェアを受信した場合、マルウェアを保存し（ｔ１．３）、マルウェアを実行する（ｔ１．４）。マルウェアは、ＴＣＵの脆弱性を悪用して、セキュリティ機能を無効してマルウェアの権限を昇格させる。マルウェアは、ＣＴＬのファームウェアの改竄ファイルを要求し（ｔ１．５）、改竄ファイルを受信したときに、改竄ファイルをＦＧに保存する（ｔ１．６）。
【００６６】
ＣＴＬは、一定の周期又は特定のイベントの発生等のタイミングにおいて、ＦＧに対してＣＴＬにおいて更新すべきファームウェアがあるか否かを確認し、更新すべきファームウェアがある場合、ＦＧから新たなファームウェアの更新ファイルを取得する（ｔ２．１）。この場合、改竄ファイルが取得される。ＣＴＬは、改竄ファイルを用いてＣＴＬのファームウェアを更新し（ｔ２．２）、更新したファームウェアを有効にするためにＣＴＬを再起動する（ｔ２．３）。その結果、ＣＴＬがマルウェアに感染し、ＣＴＬからのメッセージに任意のＩＤが付与できるように改竄される。
【００６７】
ＴＣＵ内のマルウェアは、Ｃ＆Ｃに対して不正コマンドを要求し（ｔ３．１）、Ｃ＆Ｃから不正コマンドを受信する。ＴＣＵは不正コマンドに含まれる操作命令を示すメッセージをＭａｌ  ＣＴＬに送信する（ｔ３．２）。Ｍａｌ  ＣＴＬはメッセージに任意のＩＤを付与できるように改竄されているため、不正なＩＤであるＣＡＮ−ＩＤ２をメッセージに付与することができる。Ｍａｌ  ＣＴＬはＥＣＵ２に成りすますためにＴＣＵ上のマルウェアからのメッセージにＣＡＮ−ＩＤ２を付与し中継する（ｔ３．３）。ＥＣＵ２はメッセージに付与されたＩＤであるＣＡＮ−ＩＤ２を確認し、受信したメッセージに応じた動作を行う。ここで、ｔ３．３におけるメッセージの送信が通常のタイミングから外れている等の理由で、ＩＤＳが異常を検知したとする。
【００６８】
ｔ１．１〜ｔ１．６における改竄ファイルのダウンロード、ｔ２．１〜ｔ２．３におけるファームウェアの更新、ｔ３．１〜ｔ３．３におけるＥＣＵ２への操作は、異なるタイミングに実施され、時間的に不連続になる。
【００６９】
図１０は、図９Ａ及び図９Ｂのシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。モニタ部２５１は、図８と同様にしてログを取得する。
【００７０】
図１０の１行目のログは、図９Ａにおけるｔ１．１に対応する。ｔ１．１の日時において、ＴＣＵがブラウザのプロセス（ｂｒｏｗｓｅｒ  ｐｉｄ１）によって、送信元アドレス（ＩＰ：ｉｐ１：ｐｏｒｔ１）から宛先アドレス（ＩＰ：ｉｐ２：８０）に対してアクセスするアクション（http://ip2/info）を実行したときのログが取得される。同様に、ｔ１．２の日時においてＴＣＵがマルウェアを要求するアクションを実行したときのログと、ｔ１．３の日時においてＴＣＵがマルウェアを保存するアクションを実行したときのログと、ｔ１．４の日時においてＴＣＵがマルウェアを実行するアクションを実行したときのログと、ｔ１．５の日時においてＴＣＵが改竄ファイルを要求するアクションを実行したときのログと、ｔ１．６の日時においてＴＣＵが改竄ファイルをＦＧに保存するアクションを実行したときのログが取得される。
【００７１】
図１０の７行目のログは、図９Ａにおけるｔ２．１に対応する。ｔ２．１の日時において、ＣＴＬがＯＴＡ機能のプロセス（ｏｔａ  ｐｉｄ３）によって、更新ファイルの取得先（ＦＧ：ＦｉｒｍｗａｒｅＣＴＬ）から、新たなファームウェアの更新ファイルを取得するアクション（ｆｉｌｅ：ｒｅａｄ）を実行したときのログが取得される。同様に、ｔ２．２の日時においてＣＴＬがファームウェアを更新するアクションを実行したときのログと、ｔ２．３の日時においてＣＴＬが自身のプロセスを終了するアクションを実行し、ＣＴＬが自身のプロセスを開始するアクションを実行したときのログが取得される。
【００７２】
図１０の１１行目のログは、図９Ｂにおけるｔ３．１に対応する。ｔ３．１の日時において、ＴＣＵがマルウェアのプロセス（ｍａｌｗａｒｅ  ｐｉｄ２）によって、送信元アドレス（ＩＰ：ｉｐ１：ｐｏｒｔ４）から宛先アドレス（ＩＰ：ｉｐ３：４４３）に対して不正コマンドを要求するアクション（https://ip3/command）を実行したときのログが取得される。同様に、ｔ３．２の日時においてＴＣＵが操作命令をＣＴＬに送信するアクションを実行したときのログと、ｔ３．３の日時においてＣＴＬがメッセージをＥＣＵ２に送信するアクションを実行したときのログが取得される。
【００７３】
なお、ＩＤＳによる異常検知に加えて、異常判定部２５２は、ログを確認して異常を検知することができる。異常の検知には公知技術を用いることができる。例えば、異常判定部２５２は、存在し得ないＳＲＣからＤＳＴへのアクションが存在する場合や、ＤＳＴがアクションを実行できる状態にない場合には異常であると判断する。また、例えば、異常判定部２５２は、ログの日時を確認して、異常なタイミングでアクションが実行されている場合には異常であると判断する。
【００７４】
ログはログ管理ＤＢ２７１に保存され、ログ送信部２５３は、ログ管理ＤＢ２７１に保存されているログを監視サーバ１０へ送信する。異常が検知されたｔ３．３の日時におけるログに、異常であることを示すフラグが付与されてもよい。また、異常は、ログとは別のタイミングで監視サーバ１０に通知されてもよい。
【００７５】
ログ受信部１５１は、ログを受信し、ログをログ管理ＤＢ１７１に記憶する。ログ管理ＤＢ１７１において、ｔ３．３の日時においてＣＡＮ−ＩＤ２が付与されたメッセージの異常が検知されたことも記憶される。
【００７６】
グラフ構造生成部１５２は、ログ管理ＤＢ１７１に記憶されたログの中で日時が近いログを抽出し、プロセスとオブジェクトとの関連付けを示すグラフ構造を生成する（Ｓ１０２）。例えば、図１０に示すログから、プロセスとオブジェクトとの関連付けを二部グラフ等で表現することができる。
【００７７】
図１１は、グラフ構造の一例を示す図である。グラフ構造生成部１５２は、原則として、プロセスに対してＤＳＴをオブジェクトとして関連付けを行い、二部グラフを生成する。グラフ構造生成部１５２は、図１０のｔ１．１の日時におけるログから、ブラウザのプロセス（ｂｒｏｗｓｅｒ  ｐｉｄ１）と、偽サイトのアドレスを示すオブジェクト（ＩＰ：ｉｐ２：８０）との関連付けを示すグラフ構造を生成する。ｔ１．１と同様に、グラフ構造生成部１５２は、ｔ１．２〜ｔ１．６の日時におけるログからグラフ構造を生成する。ただし、ｔ１．４の日時におけるアクション（ｐｒｏｃ：ｆｏｒｋ−ｅｘｅｃ）の場合、ＤＳＴ（ｍａｌｗａｒｅ  ｐｉｄ２）もプロセスとし、ＳＲＣ（ＦＩＬＥ：ｍａｌｗａｒｅ  ｈａｓｈ１）をオブジェクトとして扱い、ＳＲＣのオブジェクトを２つのプロセス（ｂｒｏｗｓｅｒ  ｐｉｄ１及びｍａｌｗａｒｅ  ｐｉｄ２に関連付ける。
【００７８】
さらに、グラフ構造生成部１５２は、ｔ２．１〜ｔ２．３の日時におけるログからグラフ構造を生成する。しかし、ｔ２．２の日時におけるアクション（ＣＡＮ：ｕｐｄａｔｅ）の場合、グラフ構造生成部１５２は、ログからはファームウェアの更新ファイルの情報が取得できない。このように、十分なログが取得できない場合に備えて、予めオブジェクトとプロセスとの関連付けが分かっているものを紐付け情報ＤＢ２７３において管理する。
【００７９】
図１２は、紐付け情報の一例を示す図である。紐付け情報ＤＢ２７３において管理される紐付け情報は、予め分かっているオブジェクトとプロセスとの関連付けである。例えば、ＣＴＬのファームウェアの更新ファイルはＣＴＬのプロセスに関係するため、ＦＧ：ＦｉｒｍｗａｒｅＣＴＬのオブジェクトとＣＴＬのプロセスとの関連付けが紐付け情報ＤＢ２７３に保存される。同様に、ＦＩＬＥ：ｃｔｌのオブジェクトはＣＴＬのＯＴＡ機能のプロセスに関係するため、これらの関連付けが紐付けＤＢ２７３に保存される。例えば、ＣＴＬやＥＣＵ等のデバイスがＣＡＮ通信に用いるＣＡＮ−ＩＤは予め分かっており、この例の場合、ＣＴＬはＣＡＮ：ＩＤ１を使用し、ＥＣＵ２はＣＡＮ：ＩＤ２を使用するため、ＣＡＮ：ＩＤ１のオブジェクトとＣＴＬのプロセスとの関連付けが紐付け情報ＤＢ２７３に保存され、ＣＡＮ：ＩＤ２のオブジェクトとＥＣＵ２のプロセスとの関連付けが紐付け情報ＤＢ２７３に保存される。なお、ＥＣＵ２のログは取得できないため、紐付け情報ＤＢ２７３にはＥＣＵ２のプロセスの代わりに、ＥＣＵ２のデバイス名が保存されてもよい。
【００８０】
ｔ２．２の日時におけるアクション（ｐｒｏｃ：ｕｐｄａｔｅ）の場合、グラフ構造生成部１５２は、ログを用いる代わりに、紐付け情報ＤＢ２７３の紐付け情報を用いて、ｏｔａ  ｐｉｄ３のプロセスをＦＩＬＥ：ｃｔｌのオブジェクトに関連付ける。また、グラフ構造生成部１５２は、ｔ２．３の日時におけるアクション（ｐｒｏｃ：ｓｔａｒｔ）の場合、ＣＴＬのプロセス（ｃｔｌ  ｐｉｄ５）をＳＲＣのオブジェクト（ＦＩＬＥ：ｃｔｌ  ｈａｓｈ３）に関連付ける。このように、ログのアクションによっては、グラフ構造生成部１５２は、紐付け情報ＤＢ２７３を用いてプロセスとオブジェクトとの関連付けをしてもよく、プロセスに対してＳＲＣをオブジェクトとして関連付けてもよい。
【００８１】
さらに、グラフ構造生成部１５２は、ｔ３．１〜ｔ３．３の日時におけるログからグラフ構造を生成する。ｔ３．３の日時において、グラフ構造生成部１５２は、紐付け情報ＤＢ２７３の紐付け情報を用いて、ＳＲＣのオブジェクト（ＣＡＮ：ＩＤ２）をＥＣＵ２のプロセスに関連付ける。このように、紐付け情報ＤＢ２７３における紐付け情報を用いて関連付けることができるオブジェクト及びプロセスが存在する場合、グラフ構造生成部１５２は紐付け情報を用いてグラフ構造を補完する。
【００８２】
ｔ１．１〜ｔ３．３の日時におけるログから、図１１に示す二部グラフが生成される。二部グラフの頂点はプロセス又はオブジェクトであり、辺はプロセスとオブジェクトとの関連付けである。図１１における実線の関連付けはログに基づいて生成されたものであり、点線の関連付けは紐付け情報ＤＢ２７３の紐付け情報に基づいて生成されたものである。生成された二部グラフは、グラフ管理ＤＢ１７２に保存される。
【００８３】
なお、実際のログから生成されたグラフだけでなく、仕様上又はセキュリティ上の理由であってはならない経路を表すグラフ構造をブラックリストとしてグラフ管理ＤＢ１７２に登録してもよく、仕様によって規定された経路を表すグラフ構造をホワイトリストとしてグラフ管理ＤＢ１７２に登録してもよい。
【００８４】
トラッキング部１５３は、或るオブジェクトにおける異常が検知された場合（Ｓ１０３：Ｙｅｓ）、グラフ管理ＤＢ１７２に保存されたグラフ構造を結合し、異常が検知されたオブジェクトに関連する異常なプロセスを特定する。さらに、トラッキング部１５３は、特定した異常なプロセスに関連するオブジェクトを特定する（Ｓ１０４）。
【００８５】
例えば、ＣＡＮ−ＩＤ２が付与されたメッセージの異常が検知された場合、トラッキング部１５３は、グラフ管理ＤＢ１７２からＣＡＮ：ＩＤ２を頂点とするグラフを抽出し、抽出したグラフの頂点（ｍａｌｗａｒｅ  ｐｉｄ２、ｃｔｌ  ｐｉｄ  ５、ＥＣＵ２）を有するグラフを更に抽出する。同様の手順で、ＣＡＮ：ＩＤ２に直接的又は間接的に繋がるグラフを抽出して、抽出したグラフを結合する。
【００８６】
図１３は、グラフ構造の結合例を示す図である。図１１に示すように、異常が検知されたオブジェクト（ＣＡＮ：ＩＤ２）に関連するプロセス（ｍａｌｗａｒｅ  ｐｉｄ２）を頂点とする２つの二部グラフが存在するため、これら２つの二部グラフが結合される。同様に、異常が検知されたオブジェクト（ＣＡＮ：ＩＤ２）に関連するプロセス（ｃｔｌ  ｐｉｄ５）を頂点とする２つの二部グラフが結合される。その結果、図１３から、異常が検知されたオブジェクト（ＣＡＮ−ＩＤ２）の影響範囲は、５個のプロセス（ｂｒｏｗｓｅｒ  ｐｉｄ１、ｍａｌｗａｒｅ  ｐｉｄ２、ｏｔａ  ｐｉｄ３、ｃｔｌ  ｐｉｄ５、ＥＣＵ２のプロセス）と、６個のオブジェクト（ＩＰ：ｉｐ２：８０、ＦＩＬＥ：ｍａｌｗａｒｅ  ｈａｓｈ１、ＦＧ：ＦｉｒｍｗａｒｅＣＴＬ  ｈａｓｈ２、ＦＩＬＥ：ｃｔｌ  ｈａｓｈ３、ＩＰ：ｉｐ３：４４３、ＣＡＮ：ＩＤ２）であることが特定できる。
【００８７】
なお、トラッキング部１５３は、異常が検知されない場合であっても、正常時のグラフ構造と外部攻撃時のグラフ構造を比較して、異常を検知できる。また、トラッキング部１５３は、グラフ管理ＤＢ１７２にブラックリスト又はホワイトリストとして登録されたグラフ構造と比較して、異常を検知してもよい。
【００８８】
図１４Ａは、正常時のグラフ構造を示す図であり、図１４Ｂは、外部攻撃時のグラフ構造を示す図である。正常時のグラフ構造は、図８のｔ１．１〜ｔ２．３の日時のログから、グラフ構造生成部１５２が生成した二部グラフを結合したものである。外部攻撃時のグラフ構造は、図１０のｔ１．１〜ｔ２．３の日時のログから、グラフ構造生成部１５２が生成した二部グラフを結合したものである。これらの２つのグラフを比較すると、外部攻撃時には正常時には存在しないプロセス（ｍａｌｗａｒｅ  ｐｉｄ２）及びオブジェクト（ＦＩＬＥ：ｍａｌｗａｒｅ  ｈａｓｈ１）が存在し、外部攻撃の可能性があると判断できる。外部攻撃の可能性があるプロセス（ｍａｌｗａｒｅ  ｐｉｄ２）及びオブジェクト（ＦＩＬＥ：ｍａｌｗａｒｅ  ｈａｓｈ１）を特定した場合、トラッキング部１５３は、図１３を参照して説明した通り、外部攻撃の影響範囲を特定できる。
【００８９】
アクション禁止部１５４は、トラッキング部１５３において特定された影響範囲内のオブジェクトに対するアクションを禁止する（Ｓ１０５）。例えば、図１３に示すように二部グラフを結合して影響範囲内の６個のオブジェクト（ＩＰ：ｉｐ２：８０、ＦＩＬＥ：ｍａｌｗａｒｅ  ｈａｓｈ１、ＦＧ：ＦｉｒｍｗａｒｅＣＴＬ  ｈａｓｈ２、ＦＩＬＥ：ｃｔｌ  ｈａｓｈ３、ＩＰ：ｉｐ３：４４３、ＣＡＮ：ＩＤ２）が特定された場合、アクション禁止部１５４は、これらの６個のオブジェクトに対するアクションを禁止する。
【００９０】
さらに、車両２０内で実行される処理に応じてモニタ部２５１がログを取得する具体例について説明する。
【００９１】
図１５は、故障発生時に実行される処理の一例を示すシーケンス図である。図１５には、図７Ｂ又は図９Ｂに示すシーケンス図に続く処理が示されている。
【００９２】
ＥＣＵ２における故障発生時に、ＥＣＵ２の動作が他ＥＣＵに切り替えられものとする（ｔ４．１）。その際に、ＥＣＵ２はＣＡＮ−ＩＤ２をメッセージに付与して他ＥＣＵに送信する（ｔ４．２）。ここで、他ＥＣＵの状態の不一致やＥＣＵ２から他ＥＣＵに送信されたメッセージのタイミングずれ等によって、ＩＤＳが異常を検知した場合、ＥＣＵ２はＣＡＮ−ＩＤ２と共に故障コードをＣＴＬに送信する（ｔ４．３）。ＣＴＬは故障コードを受信すると、ＣＡＮ−ＩＤ１と共に故障コードをＵＩに送信する（ｔ４．４）。ＵＩが故障コードを受信すると、故障警告灯が点灯する（ｔ４．５）。
【００９３】
図１６は、図１５のシーケンスにおいてモニタ部２５１が取得するログの一例を示す図である。モニタ部２５１は、図８と同様にしてログを取得する。
【００９４】
図１６の１行目のログは、図１５におけるｔ４．２に対応する。なお、ＥＣＵ２からはログを取得できないため、ｔ４．１に対応するログは存在しない。ｔ４．２の日時において、ＥＣＵ２のプロセスによってＥＣＵ２（ＣＡＮ：ＩＤ２）の故障検知が行われるアクションを実行したときのログが取得される。同様に、ｔ４．３の日時において、ＣＴＬが故障コードを受信するアクションを実行したときのログと、ｔ４．４の日時において、ＣＴＬが故障コードを送信するアクションを実行したときのログが取得される。なお、ｔ４．３におけるログとｔ４．４におけるログとを区別するため、ｔ４．３のログはＥＣＵ２が故障コードを送信するアクションを実行したときのログに相当するが、送信元のＣＡＮ：ＩＤ２をＤＳＴとして扱う。
【００９５】
図１１〜図１３を参照して説明した通り、グラフ構造生成部１５２は、プロセスとオブジェクトとの関連付けを示すグラフ構造を生成することができる。
【００９６】
図１７Ａは、通常の故障時のグラフ構造を示す図であり、図１７Ｂは、外部攻撃時のグラフ構造を示す図である。通常の故障時のグラフ構造は、図７Ｂに示すシーケンスに続いて図１５に示すシーケンスが発生したときのグラフ構造であり、外部攻撃時のグラフ構造は、図９Ｂに示すシーケンスに続いて図１５に示すシーケンスが発生したときのグラフ構造である。これらの２つのグラフを比較すると、外部攻撃時には通常の故障時には存在しないプロセス（ｍａｌｗａｒｅ  ｐｉｄ２）及びオブジェクト（ＩＰ：ｉｐ３：４４３）が存在し、外部攻撃の可能性があることを検知できる。また、外部攻撃時には、外部環境に接続するためのオブジェクト（ＩＰ：ｉｐ３：４４３）が存在するが、通常の故障時には、外部環境に接続するためのオブジェクトが存在しないことが分かる。このように、未知の外部環境に接続するためのオブジェクトが存在する場合、トラッキング部１５３は、故障が外部攻撃によって発生したと判断してもよい。
【００９７】
なお、図１５に示す例では、ＵＩにおいて故障警告灯を点灯させる例が示されているが、故障コードをＴＣＵ経由でディーラー等に送信することも考えられる。この場合、通常の故障時においても、外部環境に接続するためのオブジェクトが存在する。トラッキング部１５３は、通信アドレスに関して予め設定されたホワイトリスト又はブラックリストを参照して、故障が外部攻撃によって発生したか否かを判断してもよい。また、トラッキング部１５３は、経路の順序に基づいて、例えば、異常の検知の前の時刻の経路に外部アドレスが存在する場合には、攻撃が外部攻撃によって発生したと判断してもよい。
【００９８】
このように、本実施の形態では、ログからプロセスとオブジェクトとの関連付けがグラフ構造として表現できる。グラフ構造は、異常の検知にも利用できる。或る事象が指定された場合（例えば、異常が検知された場合）、グラフ構造を利用して、指定された事象の影響範囲であるプロセスと、当該プロセスに関連するオブジェクトとを特定することができる。
【００９９】
なお、本実施の形態では、車両２０を機器の一例として説明したが、通信機能を有する他の機器について本実施の形態が適用されてもよい。例えば、工場におけるロボット等の産業用制御機器、各地に配置されたセンサ、オーディオ機器、家電製品、通信端末（スマートフォン、タブレット端末等）や、一般的にＩｏＴ（Internet of Things）機器と呼ばれる機器について、本実施の形態が適用されてもよい。
【０１００】
上述したように、本実施の形態によれば、グラフ構造を利用して異常の影響範囲を特定することができ、その結果、異常の分析が効率化される。
【０１０１】
また、ログから生成されたグラフ構造や、ホワイトリスト又はブラックリストとして登録されたグラフ構造を利用して、異常を検知することが可能になる。
【０１０２】
また、異常の影響範囲の特定においてグラフ構造を利用することで、異常が外部攻撃によって発生したか、内部の故障によって発生したかを判断することが可能になる。
【０１０３】
また、異常の影響範囲が特定できた場合、その範囲内のオブジェクトに対するアクションを禁止することで、外部攻撃による被害の拡大を防ぐことができる。
【０１０４】
なお、本実施の形態において、車両２０は、機器の一例である。監視サーバ１０は、情報処理装置の一例である。グラフ構造生成部１５２は、生成部の一例である。トラッキング部１５３は、特定部の一例である。アクション禁止部１５４は、禁止部の一例である。
【０１０５】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１０６】
本国際出願は２０１８年１０月１１日に出願した日本国特許出願２０１８−１９２４１３号に基づく優先権を主張するものであり、２０１８−１９２４１３号の全内容を本国際出願に援用する。
【符号の説明】
【０１０７】
１０          監視サーバ
２０          車両
３０ａ        サービス提供サーバ
３０ｂ        サービス提供サーバ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１５１        ログ受信部
１５２        グラフ構造生成部
１５３        トラッキング部
１５４        アクション禁止部
１７１        ログ管理ＤＢ
１７２        グラフ管理ＤＢ
１７３        紐付け情報ＤＢ
２１０        通信装置
２２１        ＣＰＵ
２２２        メモリ装置
２２３        補助記憶装置
２２４        表示装置
２２５        入力装置
２２０        情報系サブシステム
２３０        制御系サブシステム
２３１        マイコン
２４０        関門器
２５１        モニタ部
２５２        異常判定部
２５３        ログ送信部
２５４        グラフ構造生成部
２５５        トラッキング部
２５６        アクション禁止部
２７１        ログ管理ＤＢ
２７２        グラフ管理ＤＢ
２７３        紐付け情報ＤＢ
Ｂ            バス
【図１】
2020075808.tif 000003
【図２】
2020075808.tif 000004
【図３】
2020075808.tif 000005
【図４Ａ】
2020075808.tif 000006
【図４Ｂ】
2020075808.tif 000007
【図５Ａ】
2020075808.tif 000008
【図５Ｂ】
2020075808.tif 000009
【図６】
2020075808.tif 000010
【図７Ａ】
2020075808.tif 000011
【図７Ｂ】
2020075808.tif 000012
【図８】
2020075808.tif 000013
【図９Ａ】
2020075808.tif 000014
【図９Ｂ】
2020075808.tif 000015
【図１０】
2020075808.tif 000016
【図１１】
2020075808.tif 000017
【図１２】
2020075808.tif 000018
【図１３】
2020075808.tif 000019
【図１４Ａ】
2020075808.tif 000020
【図１４Ｂ】
2020075808.tif 000021
【図１５】
2020075808.tif 000022
【図１６】
2020075808.tif 000023
【図１７Ａ】
2020075808.tif 000024
【図１７Ｂ】
2020075808.tif 000025
【国際調査報告】
2020075808.tif 000026
2020075808.tif 000027
2020075808.tif 000028
2020075808.tif 000029