JP2024051324A - ログ分析装置、ログ分析方法、及びログ分析プログラム - Google Patents

Abstract

【課題】攻撃経路等の攻撃推定に用いる前に、偽陽性のセキュリティイベントログを排除するログ分析装置、方法及びプログラムを提供する。【解決手段】車両の外部に設けられているログ分析装置と、車両に設けられ、電子制御システムと接続されているログ分析装置からなるログ分析システムにおいて、車両に設けられるログ分析装置１１は、車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得するログ取得部１０１と、異常が発生したときの車両の内部状態又は／及び外部状態を示す車両状態情報を取得する車両状態情報取得部１０２と、車両状態情報に基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する偽陽性判定部１０４と、偽陽性と判定されたセキュリティイベントログに対する処理を行う処理部１０６と、を備える。【選択図】図６

Description

本発明は、主に自動車をはじめとする移動体に搭載された電子制御システムに対する攻撃があった場合に出力されるセキュリティイベントログを分析する装置であるログ分析装置等に関する。

近年、車車間通信や路車間通信のようなＶ２Ｘをはじめ、運転支援や自動運転制御を行う技術が注目されている。これに伴い、車両が通信機能を備えるようになり、いわゆる車両のコネクティッド化が進んでいる。この結果、車両が不正アクセスといったサイバー攻撃を受ける可能性が増加している。そのため、車両に対するサイバー攻撃を分析して、その対応策を構築することが必要とされている。

車両に発生した異常を検知して、検知した異常に基づいてサイバー攻撃を分析する手法として、様々なものがある。例えば、特許文献１には、センタ装置２００の攻撃経路分析部２０３は、受信した異常ログを分析し車両に対する攻撃の攻撃経路を推定すること、そしてこの異常ログは、各ＥＣＵのセキュリティセンサで生成されセンタ装置２００に送信されたものであること、が記載されている。

特開２０２２－１７８７３号公報

ここで、本発明者は、以下の課題を見出した。
車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログに、サイバー攻撃に起因しない異常である偽陽性のセキュリティイベントログが含まれている場合、例えば、セキュリティイベントログを分析対象とする攻撃や攻撃経路等の推定精度の低下原因となる。

そこで、本発明の目的は、車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する技術を提供することにある。

本開示のログ分析装置（１１，１２，３１，３２）は、
車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得するログ取得部（１０１，３０１）と、
前記異常が発生したときの前記車両の内部状態又は／及び外部状態を示す車両状態情報を取得する車両状態情報取得部（１０２，３０２）と、
前記車両状態情報に基づき、前記セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する偽陽性判定部（１０４，３０４）と、
偽陽性と判定された前記セキュリティイベントログに対する処理を行う処理部（１０６，３０６）と、
を備える。

なお、特許請求の範囲、及び本項に記載した発明の構成要件に付した括弧内の番号は、本発明と後述の実施形態との対応関係を示すものであり、本発明を限定する趣旨ではない。

上述のような構成により、本開示のログ分析装置は、車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定することができる。

実施形態１のログ分析装置１１及びログ分析装置３１の配置を説明する説明図 実施形態２のログ分析装置１２の配置を説明する説明図 実施形態３のログ分析装置３２の配置を説明する説明図 各実施形態の電子制御システムの構成例を説明するブロック図 各実施形態の電子制御システムのセキュリティセンサから出力されるセキュリティイベントログを説明する説明図 実施形態１のログ分析装置１１の構成例を説明するブロック図 実施形態１で使用する車両シチュエーション推定テーブルを説明する説明図 実施形態１で使用する電源状態テーブルを説明する説明図 実施形態１で使用する電源状態・ネットワーク状態・診断状態テーブルを説明する説明図 実施形態１で使用するＥＣＵ状態テーブルを説明する説明図 実施形態１のログ分析装置の動作を説明するフロー図 実施形態１のログ分析装置３１の構成例を説明するブロック図 実施形態１で使用する、車両の位置と既知の偽陽性ログ発生パターンとの関係を記録したテーブルを説明する説明図 実施形態１で使用する、車両とセキュリティイベントログを無効とする期間との関係を記録したテーブルを説明する説明図 実施形態１で使用する、通信障害及び外部装置の稼働状況の期間を記録したテーブルを説明する説明図 実施形態２のログ分析装置１２の構成例を説明するブロック図 実施形態３のログ分析装置３２の構成例を説明するブロック図

以下、本発明の実施形態について、図面を参照して説明する。

なお、本発明とは、特許請求の範囲又は課題を解決するための手段の項に記載された発明を意味するものであり、以下の実施形態に限定されるものではない。また、少なくともかぎ括弧内の語句は、特許請求の範囲又は課題を解決するための手段の項に記載された語句を意味し、同じく以下の実施形態に限定されるものではない。

特許請求の範囲の従属項に記載の構成及び方法は、特許請求の範囲の独立項に記載の発明において任意の構成及び方法である。従属項に記載の構成及び方法に対応する実施形態の構成及び方法、並びに特許請求の範囲に記載がなく実施形態のみに記載の構成及び方法は、本発明において任意の構成及び方法である。特許請求の範囲の記載が実施形態の記載よりも広い場合における実施形態に記載の構成及び方法も、本発明の構成及び方法の例示であるという意味で、本発明において任意の構成及び方法である。いずれの場合も、特許請求の範囲の独立項に記載することで、本発明の必須の構成及び方法となる。

実施形態に記載した効果は、本発明の例示としての実施形態の構成を有する場合の効果であり、必ずしも本発明が有する効果ではない。

複数の実施形態がある場合、各実施形態に開示の構成は各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。例えば一の実施形態に開示の構成を、他の実施形態に組み合わせてもよい。また、複数の実施形態それぞれに開示の構成を集めて組み合わせてもよい。

発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の構成及び方法と共に発明の進歩性を肯定する事実である。

１．各実施形態の前提となる構成
（１）ログ分析装置の配置
図１～図３を用いて、まず各実施形態のログ分析装置の配置を説明する。
図１は、第１の実施形態のログ分析装置１１及びログ分析装置３１を示す。ログ分析装
置１１は「車両に設けられ」ており、同じく「車両」に搭載された電子制御システムＳと接続されている。ログ分析装置３１は車両の外部に設けられており、例えばＳＯＣ（Security Operations Center）やその他のサーバ装置等で実現されている。ログ分析装置１１とログ分析装置３１とを合わせて、ログ分析システム１とする。
ここで、
「車両に設けられ」ているとは、車両に直接固定されている場合の他、車両に固定されていないが車両と共に移動する場合も含む。例えば、車両に乗った人が所持している場合、車両に載置された積荷に搭載されている場合、が挙げられる。
「車両」とは、移動可能な物体をいい、移動速度は任意である。また車両が停止している場合も当然含む。例えば、自動車、自動二輪車、自転車、及びこれらに搭載される物を含み、またこれらに限らない。

ログ分析装置１１と電子制御システムＳや電子制御システムＳを構成する電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）とは、例えばＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）といった車載通信ネットワークを介して接続されている。あるいは、Ｅｔｈｅｒｎｅｔ（登録商標）やＷｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等、有線無線を問わず任意の通信方式を用いて接続されてもよい。
なお、図１ではログ分析装置１１は電子制御システムＳの外部に設けられているが、ログ分析装置１１を電子制御システムＳの内部、すなわち電子制御システムＳの構成の一つとして設けるようにしてもよい。
また、接続とは、データのやり取りが可能な状態をいい、異なるハードウェアが有線又は無線の通信ネットワークを介して接続されている場合はもちろん、同一のハードウェア上で実現された仮想マシン同士が仮想的に接続されている場合も含む。

ログ分析装置３１と電子制御システムＳ、又はログ分析装置３１とログ分析装置１１とは、例えば、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））やＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）、ＨＳＰＡ（High Speed Packet Access）、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａ（Long Term Evolution Advanced）、４Ｇ、５Ｇ等といった、無線通信方式の通信ネットワークを介して接続されている。あるいは、ＤＳＲＣ（Dedicated Short Range Communication）を用いることができる。車両が駐車場に駐車されていたり、修理工場に収容されている場合は、無線通信方式に代えて、有線通信方式を用いることができる。例えば、Ｅｔｈｅｒｎｅｔ（登録商標）等のＬＡＮ（Local Area Network）やインターネット、光回線、固定電話回線を用いることができる。
この他、無線通信方式と有線通信方式とを組み合わせた回線であってもよい。例えば、電子制御システムＳとセルラーシステムにおける基地局装置との間は４Ｇ等の無線通信方式で、基地局装置とログ分析装置３１との間は通信事業者の基幹回線やインターネット等の有線通信方式で、それぞれ接続されてもよい。基幹回線とインターネットとの接点にはゲートウェイ装置を設けてもよい。

外部装置４０は、ログ分析装置３１と同様車両の外部に設けられており、例えばサーバ装置等で実現されている。外部装置４０は、例えば主にログ分析装置３１に対して各種の情報を提供する装置である。
外部装置４０とログ分析装置３１とは通常有線通信方式で接続されている。外部装置４０とログ分析装置１１とは、無線通信方式又は有線通信方式で接続されている。有線通信方式及び無線通信方式の例は、既に述べた通りである。

ログ分析装置１１は車両に設けられているので、電子制御システムＳ等から車両の内部状態を示す車両内部状態情報を主に取得するのに適している。また、ログ分析装置３１は車両の外部に設けられているので、外部装置４０等から車両の外部状態を示す車両外部情報を主に取得するのに適している。車両内部状態情報及び車両外部情報を併せて車両状態情報とする。実施形態１は、車両状態情報の種類によってログ分析をいずれのログ分析装置で行うかを振り分けている。
もっとも、ログ分析装置１１が車両外部情報を取得したり、ログ分析装置３１が車両内部状態情報を取得することを妨げるものではない。

図２は、第２の実施形態のログ分析装置１２を示す。実施形態１の場合と異なり、車両の外部に設けられたログ分析装置はなく、車両に設けられたログ分析装置１２のみで構成されている。そして、実施形態２のログ分析装置１２は、実施形態１のログ分析装置１１及びログ分析装置３１の両方の機能を有するものである。

図３は、第３の実施形態のログ分析装置３２を示す。実施形態１の場合と異なり、車両に設けられたログ分析装置はなく、車両の外部に設けられたログ分析装置３２のみで構成されている。そして、実施形態３のログ分析装置３２は、実施形態１のログ分析装置１１及びログ分析装置３１の両方の機能を有するものである。

（２）電子制御システムの構成
図４は、電子制御システムＳの構成例を示す図である。電子制御システムＳは、既に述べた車載通信ネットワークを介して接続された、外部通信ＥＣＵ及び統合ＥＣＵを含めた複数のＥＣＵから構成されている。図４は一つの外部通信ＥＣＵ、一つの統合ＥＣＵ、及び四つの個別ＥＣＵ（ＥＣＵ Ａ，Ｂ，Ｃ，Ｄ）を例示しているが、当然のことながら、電子制御システムＳは任意の数のＥＣＵから構成される。以下、外部通信ＥＣＵ、統合ＥＣＵ、個別ＥＣＵを包括的に指す用語として、ＥＣＵ、を用いる。

外部通信ＥＣＵは、外部との通信を行うＥＣＵである。外部通信ＥＣＵが用いる通信方式は、上述の無線通信方式及び有線通信方式で述べた通りである。なお、複数の通信方式を実現するため、外部通信ＥＣＵを複数設けるようにしてもよい。

統合ＥＣＵは、個別ＥＣＵや外部通信ＥＣＵを仲介するゲートウェイ機能を備えたＥＣＵである。また、統合ＥＣＵに電子制御システムＳの全体を制御する機能、例えばセキュリティ機能を設けるようにしてもよい。統合ＥＣＵは、ゲートウェイＥＣＵ（Ｇ－ＥＣＵ）やモビリティコンピュータ（ＭＣ）と呼ばれることもある。また、統合ＥＣＵは、中継装置やゲートウェイ装置であってもよい。

電子制御システムＳの個別ＥＣＵは任意の機能を有するＥＣＵで構成することができる。例えば、エンジン、ハンドル、ブレーキ等の制御を行う駆動系電子制御装置、メータやパワーウインドウ等の制御を行う車体系電子制御装置、ナビゲーション装置等の情報系電子制御装置、あるいは、障害物や歩行者との衝突を防止するための制御を行う安全制御系電子制御装置が挙げられる。また、ＥＣＵ同士は並列ではなく、マスタとスレーブとに分類されていてもよい。

さらに、ＥＣＵは、物理的に独立したＥＣＵである場合の他、仮想的に実現された仮想ＥＣＵ（あるいは、仮想マシンと呼ぶこともある。）であってもよい。

図４の電子制御システムＳにおいては、各ＥＣＵにセキュリティセンサが搭載されている。もっとも、全てのＥＣＵにセキュリティセンサが搭載されている必要は必ずしもない。

ログ分析装置１１（１２）を電子制御システムＳの外部に設ける場合は、図２の電子制御システムＳに車載通信ネットワークやその他の通信方式によるネットワークを介して接続すればよい。また、ログ分析装置１１（１２）を電子制御システムＳの内部に設ける場合は、統合ＥＣＵ内をはじめ任意のＥＣＵの内部に設けるようにすればよい。

また、ログ分析装置１１（１２）が電子制御システムＳの外部に設けられる場合であって、車両の外部の装置と通信を行う場合は、ログ分析装置１１（１２）に設けられた独立した通信装置を用いてもよいが、電子制御システムＳの外部通信ＥＣＵを用いるようにしてもよい。ログ分析装置１１（１２）が電子制御システムＳの内部に設けられる場合であって、車両の外部の装置と通信を行う場合は、当然外部通信ＥＣＵを用いることができる。

（３）セキュリティイベントログの詳細
図５は、電子制御システムＳを構成するＥＣＵのセキュリティセンサが生成したセキュリティイベントログの内容を示す図である。

セキュリティイベントログは、セキュリティセンサが搭載されているＥＣＵの識別情報を示すＥＣＵＩＤ、セキュリティセンサの識別情報を示すセンサＩＤ、セキュリティイベントの識別情報を示すイベントＩＤ、イベントの発生回数を示すカウンタ、イベントの発生時刻を示すタイムスタンプ、及びセキュリティセンサの出力の詳細を示すコンテキストデータ、の各フィールドを有する。セキュリティイベントログは、さらに、プロトコルのバージョンや、各フィールドの状態を示す情報を格納したヘッダを有していてもよい。

ＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）で定めた仕様によれば、IdsM Instance IDがＥＣＵＩＤ、Sensor Instance IDがセンサＩＤ、Event Definition IDがイベントＩＤ、Countがカウンタ、Timestampがタイムスタンプ、Context Dataがコンテキストデータ、Protocol VersionやProtocol Header がヘッダ、にそれぞれ相当する。

なお、図５は異常を示す異常ログの例であるが、正常ログも図５と同じ仕様としてもよい。その場合、正常ログのコンテキストデータは省略することができる。また、ヘッダにコンテキストデータの有無を示すフラグを設定することにより、フラグを確認することで、異常ログと正常ログとを識別することができる。

また、図５は物理的に独立したＥＣＵが生成したセキュリティイベントログであるが、仮想ＥＣＵが生成したセキュリティイベントログであってもよい。

なお、セキュリティセンサが生成したセキュリティイベントログはＳＥｖ、絞り込み済の的確なセキュリティイベントログはＱＳＥｖ、と呼ばれる。例えば、図２の個別ＥＣＵのセキュリティセンサはＳＥｖを生成して図示しない侵入検知システムマネージャ（ＩｄｓＭ）にレポートし、ＩｄｓＭでＳＥｖが認定フィルタを通過して指定された基準を満たした場合にＱＳＥｖとして侵入検知レポータから車両の外部に送信される。本実施形態のセキュリティイベントログは、ＳＥｖ及びＱＳＥｖのいずれも含む概念である。

（４）ログ分析装置の概要
電子制御システムＳに対するサイバー攻撃を分析する装置として、攻撃分析装置がある。攻撃分析装置は、電子制御システムＳを構成するＥＣＵのセキュリティセンサから出力されるセキュリティイベントログを取得して、サイバー攻撃の種類やサイバー攻撃の攻撃経路を分析する装置である。

もっとも、ＥＣＵやネットワークの異常を検出して生成されるセキュリティイベントログは、必ずしもサイバー攻撃に起因するものではない。ここでは、サイバー攻撃に起因しないセキュリティイベントログを偽陽性ログ、サイバー攻撃に起因しないことを偽陽性と呼ぶ。そして、各実施形態のログ分析装置は、セキュリティイベントログが示す異常が偽陽性であるか否かを判定し、偽陽性ログに対する処理を行うものである。

このような機能を有する各実施形態のログ分析装置は、攻撃分析装置に含まれていてもよいし、攻撃分析装置の処理の前段に別に設けられてもよい。また、ログ分析装置を車両側に、攻撃分析装置をサーバ側に設けてもよい。ログ分析装置は、専用のハードウェア装置で実現されても、汎用のハードウェア装置及びソフトウェアで実現されてもよい。

２．実施形態１
（１）ログ分析装置１１の構成
図６は、本実施形態におけるログ分析装置１１の構成を示すブロック図である。ログ分析装置１１は、ログ取得部１０１、車両状態情報取得部１０２、車両シチュエーション推定部１０３、偽陽性判定部１０４、記憶部１０５、及び処理部１０６を備える。

ログ取得部１０１は、車両に搭載されたＥＣＵのセキュリティセンサが検出した異常を示すセキュリティイベントログを取得する。ログ取得部１０１は電子制御システムＳに接続されているので、ログ取得部１０１が取得するセキュリティイベントログは、例えばＳＥｖである。取得したセキュリティイベントログは、後述の記憶部１０５に記憶してもよい。
セキュリティイベントログを取得するタイミングは、セキュリティイベントログが発生する度であることが望ましいが、ある一定期間内に電子制御システムＳ側で蓄積されたセキュリティイベントログを一括して受信するようにしてもよい。

車両状態情報取得部１０２は、「異常が発生したとき」の車両の内部状態又は／及び外部状態を示す車両状態情報を取得する。車両状態情報のうち車両の内部状態を示す情報を内部状態情報、車両状態情報のうち車両の外部状態を示す情報を外部状態情報、とする。車両状態取得部１０２は、車両に設けられているので、主に内部状態情報を取得する。もっとも、外部装置４０等から外部状態情報を取得することを妨げるものではない。取得した車両状態情報は、後述の記憶部１０５に記憶してもよい。
ここで、「異常が発生したとき」とは、異常が発生した時間の他、異常を示すセキュリティイベントログが生成された時間やセキュリティイベントログを受信した時間のように、異常発生時に近接した時間であってもよい。

異常が発生したときの車両状態情報を取得する方法は様々な方法がある。例えば、セキュリティイベントログのタイムスタンプを読み出し、タイムスタンプが示す時刻と同じ又はそれに近接した時刻に発生した車両状態情報を電子制御システムＳのＥＣＵやセンサに対して要求することにより取得することができる。あるいは、車両状態情報を連続的に取得して記憶部１０５に記憶しておくとともに、タイムスタンプが示す時刻と同じ又はそれに近接した時刻に発生した車両状態情報を読み出すことにより取得することができる。タイムスタンプが示す時刻に代え、セキュリティイベントログの送信時刻や受信時刻をもって異常が発生したときとすることもできる。

車両状態情報の具体例は後述するが、車両状態情報には、内部状態又は外部状態が発生した「時刻」、又は内部状態又は外部状態が継続した「時間」が含まれていてもよい。
ここで、
「時刻」とは、時間軸における所定の点を示すものであればよく、狭義の時刻の他、タイマー、クロック等、時刻が間接的に示される場合も含む。
「時間」とは、時的な長さを示すものであればよく、狭義の時間の他、始点及び終点の時刻、タイマー、クロックの数、周期等、時間が間接的に示される場合も含む。
それ以外の車両状態情報の具体例とそれらを用いた偽陽性の判定方法については実施例１～３で説明する。

偽陽性判定部１０４は、車両状態情報取得部１０２で取得した車両状態情報に「基づき」、ログ取得部１０１で取得したセキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。例えば、車両状態情報と判定基準を定めたテーブルを用いて判定したり、車両状態情報に基づく演算結果で判定すればよい。
ここで、「基づき」とは、車両状態情報を直接用いる場合の他、車両状態情報を間接的に用いる場合も含む。すなわち、車両状態譲情報から中間事実を推定し、中間事実を用い
て偽陽性判定を行う場合も含む。

記憶部１０５は、ログ取得部１０１で取得したセキュリティイベントログ、車両状態情報取得部１０２で取得した車両状態情報、偽陽性判定部１０４での判定結果、及びその他の情報を記憶する。もっとも、これらを記憶することは必須ではない。

処理部１０６は、偽陽性と判定されたセキュリティイベントログに「対する」処理を行う。
ここで、「対する」とは、セキュリティイベントログに対し直接的に処理を行う場合の他、セキュリティイベントログの判定結果を報告する等、セキュリティイベントログに対し間接的に処理を行う場合も含む。

処理の具体的な内容としては、用途や目的に応じて定めればよい。例えば、偽陽性と判定された偽陽性ログを削除しログ分析装置１１から偽陽性ログを出力しないようにする、偽陽性と判定された偽陽性ログに偽陽性であることのフラグを立てて攻撃分析装置に出力する、偽陽性ログが発生したことを外部装置等に通知する、等がある。
この他、処理部１０６は、偽陽性と判定されなかったセキュリティイベントログを攻撃分析装置に出力する。

（２）ログ分析装置１１における車両状態情報の種類と偽陽性の判定方法
（実施例１）車両シチュエーションを推定する情報（内部状態情報）
実施例１は、内部状態情報が、車両シチュエーションを推定する情報である場合の例である。

実施例１においては、ログ分析装置１１は、さらに車両シチュエーション推定部１０３を有する。
車両シチュエーション推定部１０３は、車両状態情報取得部１０２で取得した車両状態情報のうち車両の内部状態を示す内部状態情報から車両の走行に関する状態である車両シチュエーションを推定する。さらに、推定した車両シチュエーションの変化に伴う電子制御システムＳを構成する各ＥＣＵの電源状態の変化を推定する。

まず、車両シチュエーションを推定する方法を説明する。
図７は、車両シチュエーションと内部状態情報の関係を示す車両シチュエーション推定テーブルの例である。
車両シチュエーションとは、車両の走行に関する状態であるが、この例においては車両の挙動や状態をいう。車両シチュエーション推定部１０３は、車両シチュエーション推定テーブルを用いて、内部状態情報として、車両の挙動や状態に関係する情報であって車両に搭載されたＥＣＵやセンサから出力される情報から車両シチュエーションを推定する。車両シチュエーション推定テーブルは、記憶部１０５に記憶しておき、適宜読み出して参照するようにすればよい。

図７のテーブルを用いる場合、例えば内部状態情報として、車両速度、モード、乗員数、バッテリー電圧、充電状態、シフト位置、のそれぞれを示す情報を用いて、車両シチュエーションを推定する。例えば、車両速度が微速あるいは中速であり、モードが通常モードであり、乗員が１以上であり、バッテリー電圧が既定値内であり、充電状態が開放状態であり、シフト位置がＰ、Ｒ以外であるときは、車両シチュエーションが市街走行中であると推定する。あるいは、車両速度が高速で、その他の内部状態情報が市街走行中の例と同じ場合は、高速走行中であると推定する。
これらの内部状態情報は例示であって、それ以外の情報も用いてもよい。また、これらの内部状態情報の全てを必ずしも用いる必要はない。車両シチュエーションの推定に際し、さらに外部状態情報も用いるようにしてもよい。

次に、推定した車両シチュエーションの変化からＥＣＵの電源状態の変化を推定する方法を説明する。
図８は、車両シチュエーション毎のＥＣＵの電源状態を示す電源状態テーブルの例である。
電子制御システムＳの各ＥＣＵは、必要とされる機能を提供するときに起動していれば足りる。そこで、例えば車両シチュエーションに応じて制御に不必要な一部のＥＣＵの機能を停止したりスリープ状態にすることで、電子制御システムＳ全体の消費電力を低減することができる。このような制御を行うことができる技術はパーシャルネットワークと呼ばれる。

例えば図８において、市街走行中にはＥＣＵ Ａ、Ｂ、Ｄ、Ｅ、Ｆ、Ｇ、Ｉが電源ＯＮ状態で起動しているのに対し、ＥＣＵ Ｃ、Ｈ、Ｊはスリープ状態となっている。つまり、車両シチュエーションが推定できれば、各ＥＣＵの電源状態を特定することが可能となる。

車両シチュエーション推定部１０３は、図８の電源状態テーブルを用いて、推定した車両シチュエーションに対応するＥＣＵの電源状態を取得する。電源状態テーブルは、記憶部１０５に記憶しておき、適宜読み出して参照するようにすればよい。

このような電源状態の推定方法を用い、車両シチュエーション推定部１０３は、車両シチュエーションの変化を検出し、車両シチュエーションの変化に伴うＥＣＵの電源状態の変化を推定する。例えば、車両シチュエーション推定部１０３は、セキュリティイベントログで示された異常が発生したときを挟んだ前後の内部状態情報から、それぞれの車両シチュエーションを推定する。そして、車両シチュエーション推定部１０３は、車両シチュエーションが変化したことを検出した場合、変化前の車両シチュエーションと変化後の車両シチュエーションに対応する電源状態を推定し、それらがどのように変化したのかを推定する。

例えば、異常が発生する前は市街走行中であり、異常が発生した後は高速走行中であったとする。図８によれば、この車両シチュエーションの変化に伴い、ＥＣＵ Ｃ、Ｈはスリープ状態から電源ＯＮ状態に変化し、ＥＣＵ Ｇは電源ＯＮ状態からスリープ状態に変化したと推定できる。

そして、偽陽性判定部１０４は、電源状態の変化に基づき、セキュリティイベントログが示す異常が偽陽性であるか否かを判定する。具体的には、電源状態が変化した場合、電源状態が変化してから一定期間は電気的に不安定な状態に置かれていることを踏まえ、電源状態が変化したＥＣＵのセキュリティセンサから出力されたセキュリティイベントログを偽陽性と判定する。

例えば、一定期間を１秒としたとき、ＥＣＵ Ｃ、Ｇ、又はＨの電源状態が変化してから１秒の期間内にＥＣＵ Ｃ、Ｇ、又はＨのセキュリティセンサから出力されたセキュリティイベントログを偽陽性と判定する。

電気的に不安定な状態になる理由は様々であるが、例えば以下の理由が考えられる。
・ＡＣＣ ＯＮ時に各ＥＣＵが初期化中のため死活判定に必要な情報を送信できず、センサ故障であると誤判定してしまう。
・電源電圧が不安定、若しくは安定電圧に達しない状態において、ソフトウェアモジュール間の連携ができず誤判定が生じてしまう。

なお、上述の例は、電源ＯＮ状態からスリープ状態への変化、スリープ状態から電源ＯＮ状態への変化のいずれも対象とした。しかし、電源ＯＮ状態からスリープ状態に変化する場合は、セキュリティイベントログの送信が完了してからスリープ状態に移行することに照らせばセキュリティイベントログを送信する可能性自体が低いことから、スリープ状態から電源ＯＮ状態への変化のみを対象としてもよい。

また、異常が発生したときの内部状態情報を取得する方法としては、上述の車両状態情報を取得する方法と同じである。すなわち、セキュリティイベントログのタイムスタンプが示す時刻等を元にＥＣＵやセンサに対して内部状態情報を要求することにより取得したり、内部状態情報を連続的に取得して記憶部１０５に記憶しておき、タイムスタンプが示す時刻等に発生した内部状態情報を読み出すことにより取得することができる。

以上、実施例１によれば、内部状態情報から推定された車両シチュエーションの変化に伴うＥＣＵの電源状態の変化から、その変化を原因とする異常を検出した可能性のあるセキュリティイベントログを特定することができる。

（実施例２）車両の電源状態、通信ネットワークの状態、診断状態を示す情報（内部状態情報）
実施例２は、内部状態情報が、車両の電源状態、通信ネットワークの状態、診断状態を示す情報の少なくとも一つである場合の例である。

図９は、日時と、車両の電源状態、通信ネットワークの状態、診断状態との関係を記録したテーブルである。
車両の電源状態は、車両を構成する機器に対する電源供給状態を示すもので、通常ＯＦＦ、ＡＣＣ、ＯＮ、ＳＴＡＲＴのモードがあるがこれに限られない。図９のテーブルにおいては、ＡＣＣ ＯＮとＡＣＣ ＯＦＦの状態の例を示している。
通信ネットワークの状態は、車載通信ネットワークの種類とその状態を示すものである。図９のテーブルにおいては、車両の電子制御システムＳが、Ｅｔｈｅｒｎｅｔ、ＣＡＮ１、ＣＡＮ２の３つの車載通信ネットワークを有する場合を示している。そして、それぞれのネットワークが準備状態（Ready）か、稼働状態（Run）かを示している。
診断状態は、車両のモードが通常モードか診断モードかを示すものである。図９のテーブルにおいては、ダイアグモード、非ダイアグモードの状態の例を示している。

車両状態取得部１０２は、図９に示すテーブルを内部状態情報として取得する。取得のタイミングは、図９においては内部状態情報が変化した時である。例えば、９：５２：０１は、全ての車載通信ネットワークにおいてReadyからRunに変化した時、１１：０８：００は、診断状態が非ダイアグモードからダイアグモードに変化した時、１１：５０：００は、電源状態がＡＣＣ ＯＮからＡＣＣ ＯＦＦに変化するとともに、全ての車載通信ネットワークにおいてRunからReadyに変化した時、１２：１０：００は、電源状態がＡＣＣ ＯＦＦからＡＣＣ ＯＮに変化した時、である。
この場合、図９の日時は、内部状態が発生した時刻に相当する。

図９では、車両の内部状態が変化した時の内部状態情報を記録しているが、これに代えて、又はこれと共に、定期的に内部状態情報を記録するようにしてもよい。

偽陽性判定部１０４は、車両の電源状態、通信ネットワークの状態、診断状態の少なくとも一つの内部状態情報に基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。

例えば、１１：０８：００から１１：４０：００の期間は、ダイアグモードが継続するとともにダイアグモードから非ダイアグモードに切り替わって車載通信ネットワークが準備状態になっている期間であるので、修理や診断により車両が通常の使用上想定される状態にないことから、各セキュリティセンサが正常な検知ができる状態にはない。したがって、この期間に生成されたセキュリティイベントログが示す異常はサイバー攻撃に起因しない異常である可能性が高いので、偽陽性と判定する。

例えば、１１：５０：００から１２：１０：００の期間は、ＡＣＣ ＯＦＦであり車載通信ネットワークが準備状態になっていない期間、及びＡＣＣ ＯＮとなったがまだ車載通信ネットワークが準備状態になっていない期間であるので、車載通信ネットワークで正常な通信ができる状態にはないことから、各セキュリティセンサが正常な検知ができる状態にはない。したがって、この期間に生成されたセキュリティイベントログが示す異常はサイバー攻撃に起因しない異常である可能性が高いので、偽陽性と判定する。

以上、実施例２によれば、車両の電源状態、通信ネットワークの状態、診断状態の少なくとも一つからなる内部状態情報を用いて、セキュリティセンサが正常な検知ができる状態であるかどうかを判定することにより、偽陽性の可能性のあるセキュリティイベントログを特定することができる。

（実施例３）ＥＣＵの状態を示す情報（内部状態情報）
実施例３は、内部状態情報が、ＥＣＵの状態を示す情報である場合の例である。

図１０は、日時と、電子制御システムＳを構成する各ＥＣＵの状態を記録したテーブルである。
各ＥＣＵの状態は、各ＥＣＵが正常に稼働しているか否かを示すものである。図１０のテーブルにおいては、正常に稼働している（Run）か、停止している（Stop）か、を示している。

車両状態取得部１０２は、図１０に示すテーブルを内部状態情報として取得する。取得のタイミングは、図１０においては内部状態情報が変化した時である。例えば、１２：１０：０１はＥＣＵ Ａが停止した時、１３：３０：００は、ＥＣＵ Ｂが停止した時、１３：３５：００はＥＣＵ Ａ及びＥＣＵ Ｂが稼働した時、である。ＥＣＵの稼働状態は、例えば各ＥＣＵの死活情報を元に判定すればよい。死活情報は、例えば、図５のイベントＩＤに格納してもよい。
この場合、図１０の日時は、内部状態が発生した時刻に相当する。

図１０では、車両の内部状態が変化した時のＥＣＵの状態を記録しているが、これに代えて、又はこれと共に、定期的にＥＣＵの状態を記録するようにしてもよい。

偽陽性判定部１０４は、ＥＣＵの状態に基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。

例えば、１２：１０：０１から１３：３５：００の期間は、ＥＣＵ Ａが停止しているので、この期間にＥＣＵ Ａのセキュリティセンサが生成したセキュリティイベントログは誤動作により生成された可能性が高い。したがって、この期間にＥＣＵ Ａで生成されたセキュリティイベントログに示す異常はサイバー攻撃に起因しない異常である可能性が高いので、偽陽性と判定する。

例えば、１３：３０：００から１３：３５：００の期間は、ＥＣＵ Ｂが停止しているので、この期間にＥＣＵ Ｂのセキュリティセンサが生成したセキュリティイベントログはサイバー攻撃とは別の要因で生成された可能性が高い。したがって、この期間にＥＣＵ Ｂで生成されたセキュリティイベントログに示す異常はサイバー攻撃に起因しない異常である可能性が高いので、偽陽性と判定する。

以上、実施例３によれば、ＥＣＵの状態からなる内部状態情報を用いて、ＥＣＵが稼働状態か否かと矛盾するセキュリティイベントログが生成されているかどうかを判定することにより、偽陽性の可能性のあるセキュリティイベントログを特定することができる。

（３）ログ分析装置１１の動作
次に、図１１を参照して、ログ分析装置１１の動作を説明する。図１１は、ログ分析装置１１で実行される攻撃分析方法を示すだけでなく、ログ分析装置１１で実行可能な攻撃分析プログラムの処理手順を示すものでもある。そして、これらの処理は、図１１に示した順序には限定されない。すなわち、あるステップでその前段のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。その他の実施形態のフロー図も同様である。

ログ分析装置１１のログ取得部１０１は、車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得する（Ｓ１０１）。
車両状態情報取得部１０２は、セキュリティセンサが検出した異常が発生したときの車両の内部状態又は／及び外部状態を示す車両状態情報を取得する（Ｓ１０２）。
偽陽性判定部１０４は、Ｓ１０２で取得した車両状態情報に基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する（Ｓ１０３）。
処理部１０６は、Ｓ１０３で偽陽性と判定されたセキュリティイベントログに対する処理を行う（Ｓ１０４）。

（４）小括
以上、本実施形態のログ分析装置１１によれば、車両状態情報のうち主に内部状態情報を用いてセキュリティイベントログが偽陽性であるか否かを判定するので、主に車両の内部状態に起因する偽陽性ログに対する対策を講じることができる。
また、セキュリティセンサ自体にサイバー攻撃に起因しない異常の検出を完全に排除する仕組みを設けなくても、車両において検出された異常が、サイバー攻撃に起因しない異常であるか否かを推定することが可能になる。

（５）ログ分析装置３１の構成
図１２は、本実施形態におけるログ分析装置３１の構成を示すブロック図である。ログ分析装置３１は、ログ取得部３０１、車両状態情報取得部３０２、偽陽性判定部３０４、記憶部３０５、及び処理部３０６を備える。ログ分析装置３１の構成はログ分析装置１１の構成と基本的に同じであるが、接続先や処理の内容が若干異なる。以下、ログ分析装置１１との相違点を中心に説明し、ログ分析装置１１と同じ構成及び機能の場合は説明を省略し、ログ分析装置１１の説明を引用する。

ログ取得部３０１は、車両に搭載されたＥＣＵのセキュリティセンサが検出した異常を示すセキュリティイベントログを取得する。例えば、電子制御システムＳの外部通信ＥＣＵから送信されたセキュリティイベントログを受信することにより取得する。セキュリティイベントログは、例えばＱＳＥｖであるが、ＳＥｖであってもよい。
セキュリティイベントログを取得するタイミングは、ある一定期間に車両側で蓄積されたセキュリティイベントログを一括して受信することが望ましいが、セキュリティイベントログが発生する度に受信するようにしてもよい。

車両状態情報取得部３０２は、「異常が発生したとき」の車両の内部状態又は／及び外部状態を示す車両状態情報を取得する。車両状態取得部３０２は、車両の外部に設けられているので、主に外部状態情報を取得する。もっとも、電子制御システムＳやログ分析装置１１等から内部状態情報を取得することを妨げるものではない。

異常が発生したときの車両状態情報を取得する方法は様々な方法がある。例えば、セキュリティイベントログのタイムスタンプを読み出し、タイムスタンプが示す時刻と同じ又はそれに近接した時刻に発生した車両状態情報を外部装置４０に対して要求することにより取得することができる。あるいは、車両状態情報を連続的に取得して記憶部３０５に記憶しておくとともに、タイムスタンプが示す時刻と同じ又はそれに近接した時刻に発生した車両状態情報を読み出すことにより取得することができる。タイムスタンプが示す時刻に代え、セキュリティイベントログの送信時刻や受信時刻をもって異常が発生したときとすることもできる。

車両状態情報の具体例は後述するが、車両状態情報には、内部状態又は外部状態が発生した「時刻」、又は内部状態又は外部状態が継続した「時間」が含まれていてもよい。
それ以外の車両状態情報の具体例とそれらを用いた偽陽性の判定方法については実施例４～６で説明する。

偽陽性判定部３０４は、車両状態情報取得部３０２で取得した車両状態情報に「基づき」、ログ取得部３０１で取得したセキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。

記憶部３０５は、ログ取得部３０１で取得したセキュリティイベントログ、車両状態情報取得部３０２で取得した車両状態情報、偽陽性判定部３０４での判定結果、及びその他の情報を記憶する。もっとも、これらを記憶することは必須ではない。

処理部３０６は、偽陽性と判定されたセキュリティイベントログに「対する」処理を行う。

処理の具体的な内容としては、用途や目的に応じて定めればよい。例えば、偽陽性と判定された偽陽性ログを削除し、ログ分析装置１１から偽陽性ログを出力しないようにする、偽陽性と判定された偽陽性ログに偽陽性であることのフラグを立てて攻撃分析装置に出力する、偽陽性ログが発生したことを外部装置等に通知する、等がある。
この他、処理部３０６は、偽陽性と判定されなかったセキュリティイベントログを攻撃分析装置に出力する。

（６）ログ分析装置３１における車両状態情報の種類と偽陽性の判定方法
（実施例４）位置情報（内部状態情報）、既知の偽陽性ログ発生パターン（外部状態情報）
実施例４は、内部状態情報が車両の位置情報であり、外部状態情報が位置に紐付けられた既知の偽陽性ログ発生パターンの場合の例である。

図１３は、位置と既知の偽陽性ログ発生パターンとの関係を記録したテーブルである。
イベントは、車両に対するイベントが記載されている。
イベント座標は、イベントが行われている座標を示している。
イベント時刻は、イベントが行われている期間（「時間」に相当）を示している。
既知の偽陽性ログ発生パターンは、イベントにおける既知のログ発生パターン（「ログ発生パターンを示す情報」に相当）を示している。

車両状態情報取得部３０２は、内部状態情報として、車両の「位置情報」を取得する。例えば、車両に設けられたＧＰＳ受信機や加速度センサ等の各種センサの出力によって生成された位置情報を、車両に設けられた電子制御システムＳの外部通信ＥＣＵから受信することにより取得する。取得するタイミングは、セキュリティイベントログと同時かつセキュリティイベントログと紐づけて取得することが望ましい。例えば、セキュリティイベントログのコンテキストデータに位置情報を格納したものを受信するようにすればよい。
ここで、「位置情報」とは、ＧＰＳ等で取得する緯度経度で特定された位置情報の他、車両が位置する場所を特定する情報であってもよい。

また、車両状態情報取得部３０２は、図１３に示すテーブルを取得する。車両状態取得部３０２は、例えばディーラＡやカー用品店Ｂが随時更新する外部サーバ４０から当該テーブルを取得することが望ましい。取得のタイミングは、テーブルの更新時が望ましいが、定期的に取得してもよい。

偽陽性判定部３０４は、位置情報、及び図１３に示すテーブルに基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。具体的には、位置情報で示される車両の位置がイベント座標を中心とする所定の範囲と一致し、セキュリティイベントログで示される異常が発生した時刻がイベント時刻の範囲に含まれる場合であって、セキュリティイベントログが既知の偽陽性ログ発生パターンと一致する場合は、当該セキュリティイベントログは偽陽性であると判定する。

例えば、位置情報が東経Ｘ１、北緯Ｙ１であり、セキュリティイベントログのタイムスタンプがｔ１～ｔ２の範囲に含まれ、セキュリティイベントログが既存ＥＣＵの未接続ログである場合、ディーラＡで既存ＥＣＵを脱着するイベントが発生したために検知した異常であるとして、当該セキュリティイベントログは偽陽性であると判定する。

以上、実施例４によれば、車両の位置からなる内部状態情報、及び位置に紐づけられた偽陽性ログ発生パターンからなる外部状態情報を用いることにより、偽陽性の可能性のあるセキュリティイベントログを特定することができる。

（実施例５）車両を特定する情報（内部状態情報）、セキュリティイベントログを無効とする条件を示す情報（外部状態情報）
実施例５は、内部状態情報が車両を特定する情報であり、外部状態情報がセキュリティイベントログを無効とする条件を示す情報の場合の例である。

図１４は、車両と、セキュリティイベントログを無効とする期間との関係を記録したテーブルである。
車両は、セキュリティイベントログを無効とすべき車両を示している。
状態は、車両が置かれている状態を示している。
開始時刻は、状態が開始する時刻（「時刻」又は「期間」に相当）を示している。
終了時刻は、状態が終了する時刻（「時刻」又は「期間」に相当）を示している。
つまり、図１４では、セキュリティイベントログを無効とする条件として、期間を定めたものである。

車両状態情報取得部３０２は、内部状態情報として、車両を特定する情報を取得する。例えば、車両に保存された当該車両を特定する情報を、車両に設けられた電子制御システムＳの外部通信ＥＣＵから受信することにより取得する。取得するタイミングは、セキュリティイベントログと同時かつセキュリティイベントログと紐づけて取得することが望ましい。例えば、セキュリティイベントログのコンテキストデータに車両を特定する情報を格納したものを受信するようにすればよい。

また、車両状態情報取得部３０２は、図１４に示すテーブルを取得する。車両状態取得部３０２は、例えばメーカやディーラが随時更新する外部装置４０から当該テーブルを取得することが望ましい。取得のタイミングは、テーブルの更新時が望ましいが、定期的に取得してもよい。

偽陽性判定部３０４は、車両を特定する情報、及び図１４に示すテーブルに基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。具体的には、車両を特定する情報で示される車両が図１４のテーブルの車両と一致し、セキュリティイベントログで示される異常が発生した時刻が図１４のテーブルの開始時刻及び終了時刻の範囲にある場合は、当該セキュリティイベントログは偽陽性であると判定する。

以上、実施例５によれば、車両を特定する情報からなる内部状態情報、及びセキュリティイベントログを無効とする条件を示す情報からなる外部状態情報を用いることにより、偽陽性の可能性のあるセキュリティイベントログを特定することができる。

（実施例６）通信障害、外部装置の稼働状態（外部状態情報）
実施例６は、外部状態情報がセキュリティイベントログを無効にするイベント及びその時刻や時間帯である例であり、ここでは通信障害又は外部装置の稼働状態を示す情報について説明する。

図１５は、通信障害及び外部装置の稼働状況の期間を記録したテーブルである。
イベントは、外部通信装置又は通信障害に関するイベントが記載されている。
開始時刻は、イベントが開始する時刻（「時刻」又は「期間」に相当）を示している。
終了時刻は、イベントが終了する時刻（「時刻」又は「期間」に相当）を示している。

車両状態情報取得部３０２は、図１５に示すテーブルを取得する。車両状態取得部３０２は、例えばサーバ運営者や通信事業者が随時更新する外部装置４０から当該テーブルを取得することが望ましい。取得のタイミングは、テーブルの更新時が望ましいが、定期的に取得してもよい。

偽陽性判定部３０４は、図１５に示すテーブルに基づき、セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する。具体的には、セキュリティイベントログで示される異常が発生した時刻が図１５のテーブルの開始時刻及び終了時刻の範囲にある場合は、当該セキュリティイベントログは偽陽性であると判定する。

イベントとしては、図５の例の他、外気温が所定の温度よりも高温又は低温の場合、降雨量が所定量よりも多い場合、等、外部状態情報として得られる情報であって実施例５のようなメーカやディーラ以外から提供される情報に基づくイベントであってもよい。

以上、実施例６によれば、通信障害及び外部装置の稼働状態を示す情報からなる外部状態情報を用いることにより、偽陽性の可能性のあるセキュリティイベントログを特定することができる。

（７）ログ分析装置３１の動作
ログ分析装置３１の動作はログ分析装置１１の動作と同じであるので、ログ分析装置１１の動作の記載及び図１１をログ分析装置３１の動作として引用する。

（８）小括
以上、本実施形態のログ分析装置３１によれば、車両状態情報のうち主に外部状態情報を用いてセキュリティイベントログが偽陽性であるか否かを判定するので、主に車両の外部状態に起因する偽陽性ログに対する対策を講じることができる。
また、セキュリティセンサ自体にサイバー攻撃に起因しない異常の検出を完全に排除する仕組みを設けなくても、車両において検出された異常が、サイバー攻撃に起因しない異常であるか否かを推定することが可能になる。

３．実施形態２
本実施形態のログ分析装置１２は、図２で説明した通り、車両の外部に設けられたログ分析装置はなく、車両に設けられたログ分析装置１２のみで構成されている。そして、本実施形態のログ分析装置１２は、実施形態１のログ分析装置１１及びログ分析装置３１の両方の機能を有するものである。

図１６は、本実施形態におけるログ分析装置１２の構成を示すブロック図である。ログ分析装置１２は、ログ取得部１０１、車両状態情報取得部１０２、車両シチュエーション推定部１０３、偽陽性判定部１０４、記憶部１０５、及び処理部１０６を備える。ログ分析装置１２の構成はログ分析装置１１の構成と基本的に同じであるのでログ分析装置１１の説明を引用する。

もっとも、本実施形態では、実施形態１の実施例４、実施例５、及び実施例６についても車両に設けられたログ分析装置１２で実行されるので、車両状態情報取得部１０２は、外部状態情報も取得することができる。外部状態情報は、例えば外部装置４０から無線通信方式を用いて取得することができる。

４．実施形態３
本実施形態のログ分析装置３２は、図３で説明した通り、車両に設けられたログ分析装置はなく、車両の外部に設けられたログ分析装置３２のみで構成されている。そして、本実施形態のログ分析装置３２は、実施形態１のログ分析装置１１及びログ分析装置３１の両方の機能を有するものである。

図１７は、本実施形態におけるログ分析装置３２の構成を示すブロック図である。ログ分析装置３２は、ログ取得部３０１、車両状態情報取得部３０２、車両シチュエーション推定部３０３、偽陽性判定部３０４、記憶部３０５、及び処理部３０６を備える。ログ分析装置３２の構成は、車両シチュエーション推定部３０３を除き、ログ分析装置３１の構成と基本的に同じであるのでログ分析装置３１の説明を引用する。また、ログ分析装置３２の車両シチュエーション推定部３０３は、ログ分析装置１１の車両シチュエーション推定部１０３の構成と基本的に同じであるのでログ分析装置１１の説明を引用する。

もっとも、本実施形態では、実施形態１の実施例１、実施例２、及び実施例３についても車両の外部に設けられたログ分析装置３２で実行されるので、車両状態情報取得部３０２は、内部状態情報も取得することができる。内部状態情報は、例えば車両の電子制御システムＳの外部通信ＥＣＵを介して、無線通信方式を用いて取得することができる。

３．総括
以上、本発明の各実施形態におけるログ分析装置等の特徴について説明した。

各実施形態で使用した用語は例示であるので、同義の用語、あるいは同義の機能を含む用語に置き換えてもよい。

実施形態の説明に用いたブロック図は、装置の構成を機能毎に分類及び整理したものである。それぞれの機能を示すブロックは、ハードウェア又はソフトウェアの任意の組み合わせで実現される。また、機能を示したものであることから、ブロック図は方法の発明、及び当該方法を実現するプログラムの発明の開示としても把握できるものである。

各実施形態に記載した処理、フロー、及び方法として把握できる機能ブロック、については、一のステップでその前段の他のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。

各実施形態、及び特許請求の範囲で使用する、第１、第２、乃至、第Ｎ（Ｎは整数）、の用語は、同種の２以上の構成や方法を区別するために使用しており、順序や優劣を限定するものではない。

また、本発明のログ分析装置の形態の例として、以下のものが挙げられる。
部品の形態として、半導体素子、電子回路、モジュール、マイクロコンピュータが挙げられる。
半完成品の形態として、電子制御装置（ＥＣＵ（Electric Control Unit））、システムボードが挙げられる。
完成品の形態として、携帯電話、スマートフォン、タブレット、パーソナルコンピュータ（ＰＣ）、ワークステーション、サーバが挙げられる。
その他、通信機能を有するデバイス等を含み、例えばビデオカメラ、スチルカメラ、カーナビゲーションシステムが挙げられる。

またログ分析装置に、アンテナや通信用インターフェースなど、必要な機能を追加してもよい。

本発明のログ分析装置は、特にサーバ側で用いられることにより、各種サービスの提供を目的とするために用いられることが想定される。これらのサービスの提供に伴い、本発明のログ分析装置が使用され、本発明の方法が使用され、又は／及び本発明のプログラムが実行されることになる。

加えて、本発明は、各実施形態で説明した構成及び機能を有する専用のハードウェアで実現できるだけでなく、メモリやハードディスク等の記録媒体に記録した本発明を実現するためのプログラム、及びこれを実行可能な専用又は汎用ＣＰＵ及びメモリ等を有する汎用のハードウェアとの組み合わせとしても実現できる。

専用や汎用のハードウェアの非遷移的実体的記録媒体（例えば、外部記憶装置（ハードディスク、ＵＳＢメモリ、ＣＤ／ＢＤ等）、又は内部記憶装置（ＲＡＭ、ＲＯＭ等））に格納されるプログラムは、記録媒体を介して、あるいは記録媒体を介さずにサーバから通信回線を経由して、専用又は汎用のハードウェアに提供することもできる。これにより、プログラムのアップグレードを通じて常に最新の機能を提供することができる。

本発明のログ分析装置は、車両以外に搭載された電子制御システムのセキュリティセンサが生成するセキュリティイベントログの分析に使用してもよい。

１１，１２，３１，３２ ログ分析装置、１０１，３０１ ログ取得部、１０２，３０２ 車両状態情報取得部、１０３，３０３ 車両シチュエーション推定部、１０４，３０４ 偽陽性判定部、１０５，３０５ 記憶部、１０６，３０６ 処理部、４０ 外部装置

Claims (13)

1. 車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得するログ取得部（１０１，３０１）と、
   前記異常が発生したときの前記車両の内部状態又は／及び外部状態を示す車両状態情報を取得する車両状態情報取得部（１０２，３０２）と、
   前記車両状態情報に基づき、前記セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定する偽陽性判定部（１０４，３０４）と、
   偽陽性と判定された前記セキュリティイベントログに対する処理を行う処理部（１０６，３０６）と、を備える、
   ログ分析装置（１１，１２，３１，３２）。
2. 前記車両状態情報は、前記内部状態又は前記外部状態が発生した時刻、又は前記内部状態又は前記外部状態が継続した時間を含む、
   請求項１記載のログ分析装置。
3. さらに、前記車両状態情報のうち前記内部状態を示す内部状態情報から前記車両の走行に関する状態である車両シチュエーションを推定するとともに、前記車両シチュエーションの変化に伴う前記電子制御装置の電源状態の変化を推定する車両シチュエーション推定部（１０３，３０３）を備え、
   前記偽陽性判定部は、前記電源状態の変化に基づき、前記セキュリティイベントログが示す異常が前記偽陽性であるか否かを判定する、
   請求項２記載のログ分析装置。
4. 前記車両状態情報のうち前記内部状態を示す内部状態情報は、前記車両の電源状態、前記車両の通信ネットワークの状態、及び前記車両の診断状態、を示す情報の少なくとも一つである、
   請求項２記載のログ分析装置。
5. 前記車両状態情報のうち前記内部状態を示す内部状態情報は、前記電子制御装置の状態を示す情報である、
   請求項２記載のログ分析装置。
6. 前記車両状態情報のうち前記内部状態を示す内部状態情報は、前記車両の位置情報であり、
   前記車両状態情報のうち前記外部状態を示す外部状態情報は、位置に紐づけられた、サイバー攻撃に起因しない異常で生成されたセキュリティイベントログのログ発生パターンを示す情報である、
   請求項２記載のログ分析装置。
7. 前記車両状態情報のうち前記内部状態を示す内部状態情報は、前記車両を特定する情報であり、
   前記外部状態情報は、さらに、セキュリティイベントログを無効とする条件を示す情報である、
   請求項２記載のログ分析装置。
8. 前記車両状態情報のうち前記外部状態を示す外部状態情報は、前記車両が外部装置と通信する場合の通信障害を示す情報である、
   請求項２記載のログ分析装置。
9. 前記車両状態情報のうち前記外部状態を示す外部状態情報は、前記車両が外部装置と通信する場合の前記外部装置の稼働状態を示す情報である、
   請求項２記載のログ分析装置。
10. 当該ログ分析装置は、前記車両に設けられている、
    請求項１～５いずれかに記載のログ分析装置（１１，１２）。
11. 当該ログ分析装置は、前記車両の外部に設けられている、
    請求項１～２、６～９いずれかに記載のログ分析装置（３１，３２）。
12. ログ分析装置（１１，１２，３１，３２）で実行されるログ分析方法であって、
    車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得し（Ｓ１０１）、
    前記異常が発生したときの前記車両の内部状態又は／及び外部状態を示す車両状態情報を取得し（Ｓ１０２）、
    前記車両状態情報に基づき、前記セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定し（Ｓ１０３）、
    偽陽性と判定された前記セキュリティイベントログに対する処理を行う（Ｓ１０４）、
    ログ分析方法。
13. ログ分析装置（１１，１２，３１，３２）で実行可能なログ分析プログラムであって、
    車両に搭載された電子制御装置のセキュリティセンサが検出した異常を示すセキュリティイベントログを取得し（Ｓ１０１）、
    前記異常が発生したときの前記車両の内部状態又は／及び外部状態を示す車両状態情報を取得し（Ｓ１０２）、
    前記車両状態情報に基づき、前記セキュリティイベントログが示す異常がサイバー攻撃に起因しない異常である偽陽性であるか否かを判定し（Ｓ１０３）、
    偽陽性と判定された前記セキュリティイベントログに対する処理を行う（Ｓ１０４）、
    ログ分析プログラム。