処理中

しばらくお待ちください...

設定

設定

出願の表示

1. WO2020203352 - 異常検知方法及び異常検知装置

Document

明 細 書

発明の名称 異常検知方法及び異常検知装置

技術分野

0001  

背景技術

0002   0003   0004  

先行技術文献

特許文献

0005  

発明の概要

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

0006   0007  

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

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   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167  

産業上の利用可能性

0168  

符号の説明

0169  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14  

明 細 書

発明の名称 : 異常検知方法及び異常検知装置

技術分野

[0001]
 本開示は、通信ネットワークシステムに流れるフレームの集合に含まれる異常なフレームを検知する技術に関する。

背景技術

[0002]
 近年の自動車の中のシステムには、電子制御ユニット(Electronic Control Unit、以下、ECUと表記)と呼ばれる装置が多数配置されている。これらのECUをつなぐ通信ネットワークは、車載ネットワークと呼ばれている。車載ネットワークには多数の規格が存在するが、その中でも最も主流な規格の一つとしてController Area Network(以降、CANと表記)が挙げられる。
[0003]
 CANでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が規定されていない。そのため、何らの対策もしていなければ、例えば攻撃者に乗っ取られる等したノードが、CANのバスに不正なフレームを送信することで、車両を不正にコントロールすることが可能である。
[0004]
 特許文献1では、車載ネットワークに送信されたフレームに関する情報を不正検知サーバにアップロードし、そのフレームの異常度を不正検知サーバで算出する方法を開示している。特許文献2では、車載ネットワークの通信ログから特徴量を抽出し、抽出した特徴量を正常モデルと比較することによって通信の異常度を算出する方法を開示している。

先行技術文献

特許文献

[0005]
特許文献1 : 特許第642302号公報
特許文献2 : 特開2018-160078号公報

発明の概要

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

[0006]
 特許文献1又は特許文献2に開示された方法では、フレーム又は通信の異常度が算出されるのみで、例えば攻撃による異常への迅速な対応に利用可能な、より詳細な情報は得られない。
[0007]
 そこで、本開示は、車載ネットワーク等の通信ネットワークに流れるフレームに含まれる異常なフレームを検知した上で、攻撃による異常への迅速な対応等に利用可能な、より詳細な情報を出力する異常検知方法及び異常検知装置を提供する。

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

[0008]
 本開示の一態様に係る異常検知方法は、通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれる各フレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知方法であって、前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を取得するリファレンスモデル取得ステップと、前記観測データに含まれるフレームが異常であるか否かを判断するフレーム異常検知ステップと、異常部分出力ステップとを含み、前記リファレンスモデル取得ステップでは、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を取得し、前記フレーム異常検知ステップでは、前記リファレンスモデル取得ステップで取得された前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断し、前記異常部分出力ステップでは、前記フレーム異常検知ステップにおいて異常なフレームであると判断されたフレームがある場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、ペイロード内の1個以上の部分であるペイロード異常部分を出力する。
[0009]
 また、本開示の一態様に係る異常検知装置は、通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれるフレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知装置であって、前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を保持するリファレンスモデル保持部と、前記観測データに含まれるフレームが異常であるか否かを判断する異常検知部と、前記異常検知部において異常なフレームが検知された場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、前記フレームに含まれる1個以上の部分であるペイロード異常部分を出力する異常部分出力部とを備え、前記リファレンスモデル保持部は、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を保持しており、前記異常検知部は、前記リファレンスモデル保持部が保持する前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断する。
[0010]
 なお、これらの包括的又は具体的な態様は、システム、集積回路、コンピュータプログラム又はCD-ROM等のコンピュータ読み取り可能な記録媒体で実現されてもよく、装置、システム、方法、集積回路、コンピュータプログラム及び記録媒体のいずれかの任意な組み合わせで実現されてもよい。

発明の効果

[0011]
 本開示に係る異常検知方法及び異常検知装置では、車載ネットワーク等の通信ネットワークを流れるフレームに含まれる異常なフレームを検知した上で、異常への迅速な対応等に利用可能な、より詳細な情報を出力する。

図面の簡単な説明

[0012]
[図1] 図1は、実施の形態における、車載ネットワーク異常検知システムの概要を説明する図である。
[図2] 図2は、実施の形態における、車載ネットワークシステムの全体構成を示す図である。
[図3] 図3は、上記車載ネットワーク異常検知システムに含まれる異常検知サーバの機能構成を示すブロック図である。
[図4] 図4は、実施の形態における、攻撃内容の判定結果の一例を示す図である。
[図5] 図5は、上記異常検知サーバに含まれるリファレンスモデル保持部に格納される正常データ分布モデルの例を示す図である。
[図6] 図6は、上記異常検知サーバに含まれる攻撃種類判定テーブルの例を示す図である。
[図7] 図7は、上記異常検知サーバに含まれる攻撃レベル判定テーブルの例を示す図である。
[図8] 図8は、上記車載ネットワークシステムに含まれるECU及びテレマティクス制御ユニットの機能構成を示す図である。
[図9] 図9は、上記のECUが受信したフレームの受信履歴の一例を示す図である。
[図10] 図10は、上記車載ネットワークシステムに含まれるゲートウェイの構成を示す図である。
[図11] 図11は、上記車両及び異常検知サーバを含む車載ネットワーク異常検知システムで実行される処理シーケンスの一例を示す図である。
[図12] 図12は、上記の異常検知サーバでのログの分析処理の手順例を示すフローチャートである。
[図13] 図13は、上記の異常検知サーバでの攻撃種類判定処理の手順例を示すフローチャートである。
[図14] 図14は、上記の異常検知サーバでの攻撃レベル判定処理の手順例を示すフローチャートである。

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

[0013]
 (本開示の基礎となった知見)
 通信ネットワークに異常が発生した場合には、送信されたフレームに含まれる異常なフレームを特定するだけでなく、その異常の内容を把握し、その内容に応じた適切で迅速な対応が被害の発生防止又は最小化に重要である。ここでの異常の内容とは、例えばフレーム内の異常箇所、考えられる異常の原因及び異常の危険度である。しかしながら、「背景技術」の欄において記載した従来の方法を用いては、フレーム又は通信の異常度は把握できても、上記に挙げたような異常の内容に関する情報は得られない。
[0014]
 このような問題を解決するために創案された本開示の一態様に係る異常検知方法は、通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれる各フレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知方法であって、前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を取得するリファレンスモデル取得ステップと、前記観測データに含まれるフレームが異常であるか否かを判断するフレーム異常検知ステップと、異常部分出力ステップとを含み、前記リファレンスモデル取得ステップでは、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を取得し、前記フレーム異常検知ステップでは、前記リファレンスモデル取得ステップで取得された前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断し、前記異常部分出力ステップでは、前記フレーム異常検知ステップにおいて異常なフレームであると判断されたフレームがある場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、ペイロード内の1個以上の部分であるペイロード異常部分を出力する。
[0015]
 これにより、通信ネットワークで送受信される多数のフレームから異常なフレームを検知するだけでなく、フレームのペイロードにおける異常部分に関する情報が得られる。このようにして把握される異常の内容を用いることで、異常に対してより迅速で適切な対応が可能になる。
[0016]
 また、前記異常検知方法は、さらに、異常種類判定ステップをさらに備え、前記異常種類判定ステップでは、前記ペイロード異常部分に基づいてペイロード異常部分長を特定し、前記ペイロード異常部分長に応じて、異常種類を判定してもよい。
[0017]
 これにより、検知した異常なフレームに関して、どのような種類の異常が発生しているのかに関する情報が得られる。このようにしてさらに把握される異常の内容を用いることで、異常に対してより迅速で適切な対応が可能になる。
[0018]
 また、前記異常種類判定ステップでは、前記異常種類を、前記ペイロード異常部分長が第一範囲内であるときに状態値異常と判定し、前記ペイロード異常部分長が前記第一範囲より長い第二範囲内であるときにセンサ値異常と判定し、前記ペイロード異常部分長が前記第二範囲より長い第三範囲内であるときにトライアル攻撃異常であると判定してもよい。例えば、前記第一範囲は、上限が4ビット以下の範囲であり、前記第二範囲は、下限が8ビット以上、且つ、上限が16ビット以下の範囲であり、前記第三範囲は、下限が32ビットの範囲であってもよい。
[0019]
 このように、異常の内容である異常の種類の判定が、異常部分のビット長に基づいて可能である。このようにして把握される異常の内容を用いることで、異常に対してより迅速で適切な対応が可能になる。
[0020]
 また、異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数種類のフレームが異常であると検知され、かつ前記異常部分出力ステップにおいて出力される前記ペイロード異常部分が、前記複数種類のフレーム間で異なる場合に、前記ペイロード異常部分が前記複数種類のフレーム間で同じ場合よりも異常レベルを高く判定してもよい。
[0021]
 これにより、異常であると判断されたフレームの種類と、当該フレームのペイロードにおいて異常に寄与した部分に関する情報から、異常の危険のレベル(危険度)を判定することができる。このようにして把握される異常の内容を用いることで、例えば複数の異常が発生している場合には、危険度のより高い異常への対応を優先して実行するといった、安全性の点でより適切な対応が可能になる。
[0022]
 また、異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、前記複数の種類のフレーム間で同じ場合よりも異常レベルを高く判定してもよい。
[0023]
 これにより、通信ネットワークにおいて異常であると判断されたフレームの種類数と、フレームに発生している異常の種類数との組み合わせから、異常の危険度を判定することができる。このようにして把握される異常の内容を用いることで、例えば複数の異常が発生している場合には、危険度のより高い異常への対応を優先して実行するといった、安全性の点でより適切な対応が可能になる。
[0024]
 また、異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、1以上の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、トライアル攻撃異常のみである場合に、判定された異常種類にトライアル攻撃異常が含まれない場合よりも異常レベルを低く判定してもよい。
[0025]
 これにより、異常の種類から、発生している異常が危険度の低い異常であるか否かを判定することができる。このようにして把握される異常の内容を用いることで、例えば複数の異常が発生している場合には、危険度のより高い異常への対応を優先して実行するといった、安全性の点でより適切な対応が可能になる。また、危険度が低い場合には、異常への対応としての通信ネットワークシステムの機能に対する制限を緩いものにすることで、ユーザの利便性の犠牲を抑えることができる。
[0026]
 また、異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、1以上の種類のフレームが異常であると判定された場合に、前記異常であると判定された前記フレームの種類、異常であると判定された前記フレームの種類数、前記異常部分出力ステップにおいて出力されたペイロード異常部分、前記異常種類判定ステップにおいて判定された異常種類のいずれか1以上の要素をパラメータとする所定の計算式に基づいて異常レベルを判定してもよい。
[0027]
 これにより、異常であると検知したフレームの異常の内容に関する複数の条件から、異常の危険度を判定することができる。このようにして把握される異常の内容を用いることで、例えば複数の異常が発生している場合には、危険度のより高い異常への対応を優先して実行するといった、安全性の点でより適切な対応が可能になる。
[0028]
 また、前記異常種類判定ステップでは、1のフレームに含まれる前記ペイロード異常部分が複数ある場合に、複数の前記ペイロード異常部分の間にある中間ビットの数が所定の基準以下であるときは、複数の前記ペイロード異常部分及び前記中間ビットをあわせて1つのペイロード異常部分として扱ってもよい。
[0029]
 これにより、異常と判定されたフレームのペイロードにおける異常部分長に基づく異常種類の判断が、より正確に行える可能性が高まる。
[0030]
 また、前記通信ネットワークシステムは、車載ネットワークシステムであってもよい。
[0031]
 これにより、車載ネットワークシステムで送受信される多数のフレームを監視してその中に含まれる異常なフレームを検知することができ、また、異常の内容を把握してより迅速で適切な対応につなげることができる。その結果、自動車の安全性を向上させることができる。
[0032]
 また、本開示の一実施態様の異常検知装置は、通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれるフレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知装置であって、前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を保持するリファレンスモデル保持部と、前記観測データに含まれるフレームが異常であるか否かを判断する異常検知部と、前記異常検知部において異常なフレームが検知された場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、前記フレームに含まれる1個以上の部分であるペイロード異常部分を出力する異常部分出力部とを備え、前記リファレンスモデル保持部は、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を保持しており、前記異常検知部は、前記リファレンスモデル保持部が保持する前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断する。
[0033]
 これにより、通信ネットワークで送受信される多数のフレームから異常なフレームを検知するだけでなく、フレームのペイロードにおける異常部分に関する情報が得られる。このようにして把握される異常の内容を用いることで、異常に対してより迅速で適切な対応が可能になる。
[0034]
 なお、これらの包括的又は具体的な態様は、システム、集積回路、コンピュータプログラム又はCD-ROM等のコンピュータ読み取り可能な記録媒体で実現されてもよく、装置、システム、方法、集積回路、コンピュータプログラム及び記録媒体のいずれかの任意な組み合わせで実現されてもよい。
[0035]
 以下、図面を参照しながら、本開示に係る異常検知方法及び異常検知装置の実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも包括的又は具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序等は例示の目的で示されるものであり、本発明を限定する趣旨ではない。
[0036]
 (実施の形態)
 以下、通信ネットワークシステムで送受信されるフレームに混じる、異常であるフレームの検知、当該フレーム内の異常部分の特定、異常の種類及び危険度の判断方法について説明する。この説明では、複数の電子制御ユニット(ECU)がCANバスを用いて構成されるネットワークを介して通信する車載ネットワークシステムを搭載した車両と、異常であるフレームを検知するサーバとを含む車載ネットワーク異常検知システムを例に用いる。
[0037]
 [1.1 車載ネットワーク異常検知システムの概要]
 図1は、本実施の形態における車載ネットワーク異常検知システムの概要を示す図である。車載ネットワーク監視システムは、異常検知サーバ60と、車両10とが、通信路となるネットワーク20で接続されて構成される。ネットワーク20は、インターネット又は専用回線を含み得る。車両10が搭載する車載ネットワークシステムは、車内のバス(CANバス)を介して通信を行う複数のECUを含む。これらのECUは、車内の制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器に接続されている。
[0038]
 本実施の形態では、車載ネットワークシステムにおける各ECUはCANプロトコルに従って通信を行う。CANプロトコルにおけるフレームの種類には、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。ここでは主としてデータフレームに注目して説明する。CANプロトコルでは、データフレームは、データを格納するデータフィールド、データフィールドのデータ長を示すDLC(Data Length Code)、及びデータフィールドに格納されるデータに基づく種類を示すIDを格納するIDフィールドを含むと規定されている。なお、本実施の形態に係る異常検知方法又は異常検知装置は、データフレーム以外の種類のCANプロトコルのフレーム、又は他の通信プロトコルに従う通信ネットワークシステムにも、適用可能である。
[0039]
 [1.2 車載ネットワークシステムの構成]
 図2は、車両10が備える車載ネットワークシステムの構成の一例を示す図である。
[0040]
 車両10における車載ネットワークシステムは、バス(CANバス)1000、2000、3000、4000及び5000に接続された複数のECU(ECU100、101、200、201、300、301、302、400、401)及びこれらのバス間の通信を中継するゲートウェイ900といった各ノードを含む。なお、ゲートウェイ900もECUである。
[0041]
 図2では省略しているものの、車載ネットワークシステムには、さらに多くのECUが含まれ得る。ECUは、例えば、プロセッサ(マイクロプロセッサ)、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ROM(Read-Only Memory)及びRAM(Random Access Memory)であり、プロセッサにより実行される制御プログラム(コンピュータプログラム)を記憶することができる。例えばプロセッサが、制御プログラムに従って動作することにより、ECUは各種機能を実現する。なお、コンピュータプログラムとは、所定の機能を実現するために、プロセッサに対する命令コードが複数個組み合わされたものである。
[0042]
 バス1000には、モータ、燃料、電池の制御といった車両10の駆動に関連するパワートレイン系のECUが接続されている。エンジン110に接続されたECU(エンジンECU)100及びトランスミッション111に接続されたECU(トランスミッションECU)101は、本実施の形態におけるパワートレイン系のECUの例である。
[0043]
 バス2000には、「曲がる」、「止まる」等といった車両10の操舵及び制動等の制御に関連するシャーシ系のECUが接続されている。ブレーキ210に接続されたECU(ブレーキECU)200及びステアリング211に接続されたECU(ステアリングECU)201は、本実施の形態におけるシャーシ系のECUの例である。
[0044]
 バス3000には、画像情報を基に運転支援の認知・判断・制御を行う機能や、オーディオヘッドユニットに関わる機能、及び車車間通信といった情報系に関連するECUが接続されている。それぞれカメラ310、カーナビゲーションシステム311、テレマティクス制御ユニット(TCU:Telematic Control Unit)312に接続されたECU300、ECU301及びECU302は、本実施の形態における情報系のECUの例である。
[0045]
 バス4000には、ドア、エアコン、ウィンカー等といった車両の装備の制御に関連するボディ系のECUが接続されている。ドア410に接続されたECU400、及びライト411に接続されたECU401は、本実施の形態におけるボディ系のECUの例である。
[0046]
 バス5000には、例えばOBD2(On-Board Diagnostics 2nd generation)等の、外部の診断ツール(故障診断ツール)等と通信するためのインタフェースである診断ポート510が接続されている。
[0047]
 上記のECU(ECU100、200等)のそれぞれは、接続されている機器(エンジン110、ブレーキ210等)の状態を示す情報を取得し、この状態を表すデータフレーム等(以下、データフレームのことを単にフレームともいう)を車載ネットワークシステムつまりCANバスに定期的に送信している。
[0048]
 ゲートウェイ900は、異なる複数の通信路間でデータを転送するECUである。図2の例を参照すると、ゲートウェイ900は、バス1000、バス2000、バス3000、バス4000、バス5000と接続している。つまり、ゲートウェイ900は、一方のバスから受信したフレームを、一定条件下で他のバス(つまり条件に応じて選択した転送先バス)に転送する機能を有するECUである。
[0049]
 ECU302は、バス3000に流れるフレームを受信して保持し、定期的に異常検知サーバ60へアップロードする機能を持つ。フレームはTCU312から、携帯電話回線等の通信回線を含むネットワーク20を介して異常検知サーバ60へアップロードされる。
[0050]
 [1.3 異常検知サーバの構成]
 図3は、サーバ(異常検知サーバ)60の機能構成を示すブロック図である。車両10の車載ネットワークシステムで送信される不正なフレームに対処するための異常検知サーバ60は、例えばプロセッサ、メモリ、通信インタフェース等を含む一台以上のコンピュータにより実現される。異常検知サーバ60は、通信部610と、異常検知部620と、異常部分特定部630と、攻撃種類判定部640と、攻撃レベル判定部650と、結果出力部660と、リファレンスモデル保持部670と、攻撃種類判定テーブル680と、攻撃レベル判定テーブル690とを含む。
[0051]
 リファレンスモデル保持部670、攻撃種類判定テーブル680、及び攻撃レベル判定テーブルのそれぞれの機能は、例えば、メモリ、ハードディスクといった記憶媒体に所定の構成で保持されるデータとして実現され得る。これらのデータについては、例を用いて後述する。
[0052]
 また、異常検知部620、異常部分特定部630、攻撃種類判定部640、攻撃レベル判定部650及び結果出力部660それぞれの機能は、例えば、メモリに格納された制御プログラムがプロセッサにより実行されることにより実現され得る。
[0053]
 通信部610は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。通信部610は、ネットワーク20を介して車両10と通信することで、車両10の車載ネットワークシステムに関する情報を受信する。車載ネットワークシステムに関する情報には、例えば、車載ネットワークシステムのCANバス上に流されたフレームの内容(ペイロード情報)、受信タイミング(間隔、頻度等)に関する情報が含まれ得る。
[0054]
 異常検知部620は、通信部610から通知される車載ネットワークシステムのログのデータ(観測データセットD′)が異常であるかを判断する。この時、リファレンスモデル保持部670に格納されている正常走行時の車載ネットワークログ(リファレンスモデルデータセットD)を参照し、観測データセットとリファレンスモデルデータセットとの差異に基づいて観測データセットに異常なフレームのデータが含まれるか否かを判断する。
[0055]
 観測データセットD′が異常であるかの判定には、例えば密度比推定による異常検知方法が利用可能である。密度比推定は、リファレンスモデルデータセットDの分布と、観測データセットD′の分布との異なる箇所を検知する技術である。例えば外れ値を含まないデータフレームを用いる攻撃による異常は、外れ値検出のみを用いる手法では検知が困難である。しかしこの技術では、このような異常であっても正常なデータとの値の分布の差異に基づいて検知することができる。
[0056]
 以下に、密度比推定アルゴリズムの一例を示す。密度比推定アルゴリズムは、リファレンスモデルデータセットDを構成する正常走行時の各データフレームのデータのラベルを0とし、観測データセットD′に含まれる各データフレームのデータのラベルを1として、正常データと観測データとを分類するよう分類器を学習させる。分類器にはMLP(Multi Layer Perceptron)、ロジスティック回帰、ランダムフォレスト、k-近傍法等のモデルが利用可能である。
[0057]
 1つのデータフレームに対応する観測データ(詳細は後述)をxとしたとき、密度比r(x)はベイズの定理から下記の式1にて求められる。
[0058]
  r(x) = p D(x)/p D′(x) = p(x|y=0)/p(x|y=1) = p(y=1)p(y=0|x)/p(y=0)p(y=1|x)
  ......(式1)
[0059]
 ここで、p(y=1|x)は観測データxが観測データセットD′に属する確率であり、分類器の出力である。また、p(y=0|x)は観測データxが正常データセットDに属する確率であり、1から分類器の出力を引いたものである。p(y=1)、p(y=0)はそれぞれ、データセット全体に対する観測データセット、リファレンスモデルデータセットの大きさの比率である。
[0060]
 r(x)の絶対値が所定の閾値を超えた場合、すなわち、観測データxに対して分類器が、観測データセットD′(又はリファレンスモデルデータセットD)に属する確率が高いと判断した場合に、観測データx(に対応するデータフレーム)が異常であると判定する。観測データxは1つのデータフレームのペイロードから抽出される特徴量であり、例えば、CANのデータフレームに含まれるデータフィールドの各ビット値を1つの特徴量とした64次元の特徴量である。
[0061]
 なお、各特徴量はデータフィールドの各ビット値でなくてもよく、データフィールドの値全体を所定のビット長で区切ったものであってもよい。したがって観測データxは、例えば、64ビットのデータフィールドの値を4ビット毎に区切って得られる16個の値を1つの特徴量としてなる16次元の特徴量としてもよいし、8ビット毎に区切って得られる8個の値を1つの特徴量としてなる8次元の特徴量としてもよい。さらに固定長のビットで区切らなくてもよい。例えば、ペイロード内に含まれる、それぞれ意味をなす各サブフィールドに対応して特徴量を抽出してもよい。
[0062]
 また、上記分類器は、データフレームに含まれるIDごとに用意して学習させてもよいし、所定の組み合わせのIDのデータフレーム又はすべてのIDのデータフレームをまとめて1つの分類器に学習させてもよい。異常検知部620は、異常であると判定したデータフレームのID、特徴量、及び判定に用いた分類器の情報を異常部分特定部630へ通知する。
[0063]
 異常部分特定部630は、異常検知部620から通知された情報をもとに、異常と判定されたデータフレームのペイロードにおける各特徴量(ここでは1データフレームから抽出された高次元の特徴量をなす各特徴量を指す)の異常への寄与の程度(以下、異常寄与度ともいう)を算出する。特徴量iの異常寄与度c は密度比r(x)を入力xで微分することで求める(式2参照)。
[0064]
  c i = δr(x)/δx  ......(式2)
[0065]
 具体的には、特徴量iの値に対して(ビット)反転させたとき、あるいは微小な変化を加えたときの密度比r(x)の変化量を異常寄与度とする。異常部分特定部630は、この異常寄与度を、異常と判定されたデータフレームの各特徴量iについて算出し、所定の閾値以上の異常寄与度を示した特徴量iを、当該データフレームの異常に寄与している特徴量であると判定する。そして異常部分特定部630は、この特徴量を示した部分のペイロードにおけるビット位置を、ペイロード異常部分として特定する。
[0066]
 異常部分特定部630は、異常検知部620から通知された情報に加えて、異常に寄与ていると判定した特徴量及び特定したペイロード異常部分の情報を攻撃種類判定部640へ通知する。
[0067]
 攻撃種類判定部640は、異常部分特定部630から通知された情報及び攻撃種類判定テーブル680を参照して、異常なフレームを生じさせている攻撃の種類を判定する機能を持つ。
[0068]
 攻撃種類判定部640は、まず異常部分特定部630から通知されたペイロード異常部分から、ペイロード内の異常部分長を特定する。例えば第1特徴量、第2特徴量、第3特徴量・・・がそれぞれペイロードの最上位1ビット、2ビット、3ビット・・・と対応している場合、異常部分のビット位置が連続している範囲を共通の異常に関与する異常部分であると判断する。そして、第1特徴量から第10特徴量までがペイロード異常部分であると判定されているときは、ペイロードのビット位置1~10の10ビットが異常部分長であると特定する。
[0069]
 なお、異常部分長の特定方法は上記の方法に限らない。例えば上記のような第1特徴量から第4特徴量及び第6特徴量から第10特徴量が異常部分である場合に、第5特徴量を含めた第1特徴量から第10特徴量をひとつの連続するペイロード異常部分として扱って、異常部分長を10ビットとしてもよい。なお、この例では、2つの隣り合うペイロード異常部分の間にあるビット(以下、中間ビットという)の数が1である場合にその隣り合うペイロード異常部分と中間ビットとをあわせて1つのペイロード異常部分として扱われているが、これは限定的なものではない。隣り合うペイロード異常部分と中間ビットとをあわせて1つのペイロード異常部分として扱われる中間ビットの長さ(ビット数)は別途定め得る設計事項である。つまり、中間ビットがこのように扱われる基準としてのビット数は、1より大きい値でもよい。また、複数のペイロード異常部分とその間にある中間ビットとの合計ビット数に対する当該中間ビットのビット数の割合を基準として、この割合が所定の値以下の場合に、これらが1つのペイロード異常部分として扱われてもよい。
[0070]
 次に攻撃種類判定部640は、異常部分長(ビット数)に応じて攻撃種類を判定する。例えば、異常部分長が4ビット以下のときは、状態を示すフラグ又は状態を示す値が占める部分で値の偽装又は改ざんが攻撃によって行われているとして、攻撃種類判定部640は「状態値偽装」と判定する。また例えば、異常部分長が5ビット以上31ビット以下のときは、攻撃種類判定部640は「センサ値偽装」と判定する。また例えば、異常部分長が32ビット以上のときは、ランダムな値若しくは何らかの類推に基づく値の注入、又は取り得るすべての値での総当たり等による試行的な攻撃である「トライアル攻撃」と判定される。攻撃種類判定部640は、車両10から通知された、車載ネットワークシステムで所定の時期又は所定の長さの時間(以下、特に区別せず所定の期間ともいう)に観測されたデータフレームに対応する車載ネットワークログで、異常部分特定部630から通知される、異常検知部20が異常であると判定したデータフレームに対して上記の判定を実行し、攻撃種類に関する一連の判定結果を攻撃レベル判定部650へ通知する。
[0071]
 攻撃レベル判定部650は、攻撃種類判定部640から通知される攻撃種類及び攻撃レベル判定テーブル690を参照し、異常が発生したデータフレームの種類に関する条件、ペイロード異常部分に関する条件、及び判定された攻撃種類に関する条件を組み合わせて用いて、発生している異常の危険度を示す攻撃レベルを判定し、判定結果を結果出力部660へ通知する。この例では、攻撃レベルは、低、中、高の3段階で判定される。
[0072]
 結果出力部660は、攻撃レベル判定部650から通知される情報を、用途に応じたデータ形式で出力する。例えば結果出力部660は、当該情報を車載ネットワーク異常検知システムの管理者へアラートとして通知するために、接続されるディスプレイ攻撃による異常の発生の旨及びその攻撃レベルを当該ディスプレイ上に表示するための画像データを出力する。また例えば結果出力部660は、異常検知サーバ60の一部を、管理者がこのような情報を閲覧するためのソフトウェア(例えば汎用のウェブブラウザ、又は専用のアプリケーションソフトウェア)を用いてアクセスするWebサーバとして機能させる構成を有してもよい。また例えば結果出力部660は、異常検知サーバ60の一部を、管理者にこのような情報をメールで通知するメールサーバとして機能する構成を有していてもよい。また例えば結果出力部660は、このような情報をインシデントログとして電子媒体等に記録するためのデータ形式で出力してもよい。なお、上記の管理者は、車載ネットワーク監視システムからの車両10の車載ネットワークシステムにおいて発生した異常の通知先の一例である。この通知先の他の例として、車載ネットワークシステムの監視業務を委託されたセキュリティオペレーションセンターのセキュリティアナリストであってもよい。
[0073]
 結果出力部660から出力される情報の一例を図4に示す。図4に示す例では、車種Aである車両の車載ネットワークシステムに異常が発生した(又は車載ネットワークログから異常が検知された)時刻が2020年1月15日の13時15分でることを示している。さらにこの例では、この異常を引き起こした攻撃の攻撃レベルは高であり、異常が検知されたフレームのID、つまりデータフレームの種類は0x100及び0x200であること、IDが0x100のデータフレームに関しては、ペイロード(データフィールド)のビット位置0~15の部分がセンサ値偽装による異常部分であり、0x200のデータフレームに関してはペイロードのビット位置33~36の部分が状態値偽装による異常部分であることを示している。
[0074]
 上記の管理者又はセキュリティアナリストは、このような情報の通知を受けることで、危険度(上記の例では攻撃レベル)に応じた各異常への対応の優先順序付けが可能になるだけでなく、異常を引き起こしている攻撃の種類を把握することで、その対応の内容をより迅速かつ適切に決定することができる。
[0075]
 リファレンスモデル保持部670は、車両10の正常走行時に車載ネットワークシステムで送受信されるフレームのデータ分布を示すリファレンスモデル(以下、正常データ分布モデルともいう)を保持している。正常走行時のデータは観測データとは異なるタイミングで取得されるデータである。例えば、車両10又は同仕様の他車両出荷前のテスト走行時に収集したデータであってもよいし、攻撃を受けていないと判断されている車両10又は同仕様の他車両からアップロードされる車載ネットワークデータであってもよい。図5にリファレンスモデル保持部670に格納される正常データ分布モデルの例を示し、詳細は後述する。
[0076]
 攻撃種類判定テーブル680は、異常部分長に基づいて攻撃種類を判定するテーブルを保持する。図6に攻撃種類判定テーブルの一例を示し、詳細は後述する。
[0077]
 攻撃レベル判定テーブル690は、異常が発生したIDの種類数に関する条件、ペイロードの異常部分に関する条件、判定された攻撃種類に関する条件の組み合わせを用いて、危険度を判定するテーブルを保持する。図7に攻撃レベル判定テーブルの一例を示し、詳細は後述する。
[0078]
 [1.4 正常データ分布モデル]
 図5は、異常検知サーバ60のリファレンスモデル保持部670が保持する正常データ分布モデルの一例を示す図である。図5に示すように、正常データ分布モデルには、CANのデータフレームのID(図中「CAN ID」欄参照)ごとにペイロード値の度数分布が保持されている。
[0079]
 具体的には、IDが0x100のデータフレームでは、ペイロード値0x0000000000000000の出現回数は10回、ペイロード値0x0000000000000011の出現回数は22回、ペイロード値0x00FF000000000000の出現回数は10000回、ペイロード値0x00FF008888000011の出現回数は8000回であることを示している。また、IDが0x200のデータフレームでは、ペイロード値0xFF00FFFF00000088の出現回数は50回であることを示している。
[0080]
 なお、図5の例に示されるモデルは、ペイロード値の出現回数の実計測値をそのまま用いた度数分布の形式であるが、IDごとに正規化した値、例えば相対度数の度数分布の形式であってもよい。また、停車中、走行中などの車両の状況別の正常データの度数分布が保持されてもよい。また、リファレンスモデル保持部670が保持するモデルは暗号化されていてもよい。
[0081]
 [1.5 攻撃種類判定テーブル]
 図6は、異常検知サーバ60の攻撃種類判定テーブル680に格納される攻撃種類判定テーブルの一例を示す図である。
[0082]
 図6に示す攻撃種類判定テーブル680によれば、ペイロード異常部分、すなわち、データフレームのペイロードにおいて異常に寄与した特徴量に対応する部分のビット長(異常部分長)が1ビット以上4ビット以下の場合、攻撃種類判定部640は、状態値偽装であると判定する。また、異常部分長が8ビット以上31ビット以下である場合はセンサ値偽装、32ビット以上であるときはトライアル攻撃であると判定される。
[0083]
 [1.6 攻撃レベル判定テーブル]
 図7は、異常検知サーバ60の攻撃レベル判定テーブル690に格納される攻撃レベル判定テーブルの一例を示す図である。
[0084]
 図7に示す攻撃レベル判定テーブル690によれば、異常であると判断されたデータフレームが複数ある場合に、データフレームの種類数、つまりこれらのデータフレームが含むIDが単一であるか複数であるかに関する第一条件と、攻撃種類又は攻撃種類の数及びペイロード異常部分(ペイロードにおけるビット位置)に関する第二条件との組み合わせによって攻撃レベルを判定する。
[0085]
 第一条件である異常と判定されたデータフレームのIDが単一又は複数のいずれであっても、第二条件である攻撃種類がトライアル攻撃のみである場合、攻撃レベル判定部650は攻撃レベルが低であると判定する。これは、車両制御のコマンドを把握していない攻撃者による攻撃であり、車両制御への影響は低い可能性が高いためである。
[0086]
 第一条件である異常と判定されたデータフレームのIDが単一であり、第二条件である攻撃種類がトライアル攻撃以外の場合、攻撃レベル判定部650は攻撃レベルが中であると判定する。これは、攻撃対象とすべきデータフレームの種類を特定している攻撃者による攻撃であって、車両制御への影響を及ぼしてより危険な可能性が高いためである。また、第一条件である異常と判定されたデータフレームのIDが複数であるが、第二条件である攻撃種類がトライアル攻撃以外の1種類であって、かつ、ペイロード異常部分が同一である場合は、攻撃レベルは中と判定される。少なくともデータフィールドにおいて攻撃すべき部分を特定している攻撃者による攻撃であって、危険度はより高いと可能性が高いためである。
[0087]
 第一条件である異常と判定されたデータフレームのIDが複数であり、第二条件である異なる種類の攻撃が組み合わせで実行されている、又はデータフレームの各IDによって異常部分が異なる場合は、攻撃レベルは高と判定される。不正制御に必要最低限のデータフレームの偽装又は改ざんが可能な攻撃者による、危険度の高い攻撃である可能性が高いためである。
[0088]
 [1.7 ECUの構成]
 図8は、ECU302及びTCU312の構成図である。なお、他のECUもECU302と基本的に同様の構成であり、外部機器制御部350に接続される機器がECUによって異なる。図8に示すように、ECU302は、フレーム送受信部330と、フレーム解釈部340と、外部機器制御部350と、フレーム生成部360と、受信履歴保持部370とを備える。これらの構成要素の各機能は、例えば通信回路、メモリに格納された制御プログラムを実行するプロセッサ又はデジタル回路等により実現される。
[0089]
 フレーム送受信部330はバス3000と接続され、バス3000から受信したデータフレームをフレーム解釈部340へ通知する。
[0090]
 フレーム解釈部340は、フレーム送受信部330から通知されたデータフレームを解釈し、その解釈の結果に応じて、外部機器制御部350へ外部機器の制御通知を行う。ECU302の場合は、受信したデータフレームは受信履歴保持部370に受信履歴として一旦保持される。この受信履歴は、車載ネットワークログとして、TCU312を介して、所定の間隔で、異常検知サーバ60へアップロードされる。
[0091]
 外部機器制御部350は、ECU302に接続される外部機器、図8の例ではTCU312を制御する機能を持つ。また、外部機器の状態又は外部機器との通信内容に基づいて、フレーム生成部360にフレームの生成を指示する。
[0092]
 フレーム生成部360は、フレーム生成の指示を受けると、フレームを生成し、生成したフレームの送信をフレーム送受信部330に要求する。
[0093]
 受信履歴保持部370は、所定の間隔でバス3000から受信されたデータフレームの履歴、つまり受信履歴を保持する。図9に、受信履歴保持部370に保持される受信履歴の一例を示す。受信履歴の詳細は後述する。
[0094]
 TCU312は、サーバ通信部380を備える。
[0095]
 サーバ通信部380は、ネットワーク20を介して異常検知サーバ60と通信を行う。例えばサーバ通信部380は、ECU302から受信した受信履歴を異常検知サーバ60へアップロードする。
[0096]
 [1.8 フレーム受信履歴]
 図9は、ECU302の受信履歴保持部370に保持される受信履歴の一例を示した図である。図9に示すように、受信履歴には、CANのデータフレームのID(図中「CAN ID」欄参照)ごとにペイロード値の度数分布が格納されている。
[0097]
 具体的には、IDが0x100のデータフレームでは、ペイロード値0x00FF000000000022の出現回数は4回、ペイロード値0x00FF000000000011の出現回数は6回、ペイロード値0x00FF000000000000の出現回数は10回であることを示している。また、IDが0x200のデータフレームでは、ペイロード値0xFF00FFFF00000088の出現回数は3回、ペイロード値が0xFF00FFF0000000F0の出現回数は2回であることを示している。また、IDが0x300のデータフレームでは、ペイロード値0x5500FF00330011E4の出現回数は3回であることを示している。
[0098]
 なお、図9の例に示される受信履歴はペイロード値の出現回数の実計測値をそのまま用いた度数分布の形式であるが、IDごとに正規化した値、例えば相対度数の形式であってもよい。また、停車中、走行中等の車両の状況別のペイロード値の度数分布が保持されてもよい。また、受信履歴保持部370が保持する受信履歴は暗号化されていてもよい。受信履歴のデータ構成は、ここまでに述べた例に限らない。例えば、各データフレームの受信時刻とペイロード値とを時系列順に並べた形式のデータであってもよい。
[0099]
 [1.9 ゲートウェイの構成]
 図10は、車両10の車載ネットワークシステムにおけるゲートウェイ900の構成を示す。図10に示すように、ゲートウェイ900は、フレーム送受信部910と、フレーム解釈部920と、転送制御部930と、フレーム生成部940と、転送ルール保持部950とを備える。これらの構成要素の各機能は、例えば通信回路、メモリに格納された制御プログラムを実行するプロセッサ又はデジタル回路等により実現される。
[0100]
 フレーム送受信部910は、バス1000、バス2000、バス3000、バス4000及びバス5000と接続され、それぞれとCANプロトコルに従ったフレームを送受信する。フレーム送受信部910は、各バスからフレームを1ビットずつ受信してフレーム解釈部920に通知する。また、フレーム生成部940から転送先のバスを示すバス情報及び送信用のフレームの通知を受けると、当該フレームを、バス1000、バス2000、バス3000、バス4000、バス5000のうち、バス情報が示すバスに1ビットずつ送信する。
[0101]
 フレーム解釈部920は、フレーム送受信部910から受け取ったフレームを構成するビットの値を、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。その後、受信したデータフレームに関する情報を転送制御部930へ通知する。フレーム解釈部920は、受け取ったフレームがCANプロトコルに則っていないと判断した場合は、エラーフレームを送信するようにフレーム生成部940へ通知する。また、フレーム解釈部920は、エラーフレームを受信した場合、つまり受け取ったフレームを構成するビットの値からエラーフレームであると解釈した場合には、以降のそのフレームを破棄する、つまりフレームの解釈を中止する。
[0102]
 転送制御部930は、転送ルール保持部950が保持する転送ルールに従って、受信したフレームのID及び転送元バス、つまりそのフレームを受信したバスに応じた転送先のバスを選択し、転送先のバスを示すバス情報と、転送対象のフレームの内容、例えばフレーム解釈部920から通知されたID、DLC、データフィールド等をフレーム生成部940へ通知して転送先のバスへの送信を要求する。
[0103]
 フレーム生成部940は、転送制御部930からの送信の要求に応じて、転送制御部930から通知されたフレームの内容を用いて送信用のフレームを生成し、その送信用のフレーム及びバス情報に基づく転送先情報、例えば転送先のバスの識別子等をフレーム送受信部910へ通知する。
[0104]
 転送ルール保持部950は、バスごとのフレームの転送についてのルールを示す転送ルール情報を保持する。例えば転送ルール情報には、転送元としての各バスについて、そのバスから受信される転送対象のデータフレームのIDと、転送先のバスと、転送先におけるデータフレームのIDとの対応を示す。
[0105]
 [1.10 車両と異常検知サーバと間の処理シーケンス]
 図11は、異常検知サーバ60及び車両10を含む車載ネットワーク異常検知システムでの処理シーケンスの一例を示す図である。より詳細には、車両10が備える車載ネットワークシステムのCANバスで送受信されたデータフレームのペイロードに関する情報を含む車載ネットワークログが異常検知サーバ60に送信され、異常検知サーバ60で、このログの分析を行う処理の一例である。具体的には、車両10のECU302がバス3000に送信されたデータフレームを受信したときの処理の一例である。
[0106]
 車両10の車載ネットワークにおけるバス3000に接続されたECUのひとつ(カメラECU300、カーナビゲーションシステムECU301及びゲートウェイ900のいずれか)がバス3000にCANのデータフレームを送信することで、バス3000にデータフレームが流れる(ステップS101、S103、S105)。
[0107]
 車両10のECU302は、ステップS101、S103、S105でバス3000に送信されたデータフレームを受信し、受信したデータフレームの集合の受信履歴(図9の例参照)を保持する(ステップS102、S104、S106)。
[0108]
 ECU302は、所定の期間が経過すると、受信したデータフレームのペイロードの分布に関わる情報を含む車載ネットワークログ(図中は「ログ」と表記)を、TCU312からネットワーク20を介して異常検知サーバ60へアップロードさせる(ステップS107)。
[0109]
 異常検知サーバ60は、車両10のから送信された車載ネットワークログを車両10から受信する(ステップS108)。
[0110]
 そして、異常検知サーバ60は、受信した車載ネットワークログと、異常検知サーバ60に格納されている正常モデル(図5の例参照)を用いてこの車載ネットワークログの分析を行う(ステップS109)。
[0111]
 最後に、異常検知サーバ60は車載ネットワークログの分析結果を出力する(ステップS110)。
[0112]
 [1.11 異常検知サーバにおける車載ネットワークログの分析処理]
 図12は、異常検知サーバ60で実行される、車両10から受信した車載ネットワークログの分析処理の手順例を示すフローチャートである。以下、このフローチャートに即して、車両10のログ情報の分析処理について説明する。
[0113]
 異常検知サーバ60は、車両10からアップロードされた車載ネットワークログ、すなわち、車両10の車載ネットワークシステムで送受信されたデータフレームのペイロードの分布に関する情報を含むログと、異常検知サーバ60のリファレンスモデル保持部670に格納される正常データ分布モデルとを用いて、異常検知のために観測されるデータ(観測データ)と正常データとを分類するよう分類器に学習させる(ステップS201)。
[0114]
 次に異常検知サーバ60は、車両10から異常検知処理の対象としてアップロードされた車載ネットワークログに含まれる各データフレームのペイロード(以下、受信データともいう)をステップS201で学習した分類器に入力する(ステップS202)。
[0115]
 なお、ステップS202で車両10からアップロードされる車載ネットワークログは、車載ネットワークシステムで送受信され、実際の異常検知のための観測対象として取得されたデータフレームの集合(観測データ)に基づくものである。これに対し、ステップS201で車両10からアップロードされる車載ネットワークログは、ステップS202でアップロードされる車載ネットワークログが基づく観測データとは別の機会に車載ネットワークシステムで送受信されたデータフレームに基づくものであり、分類器の学習のための訓練データとして用いられるものである。
[0116]
 受信データを分類器に入力した結果、入力した受信データが、観測データに属するスコアが所定値以上(又は正常データに属するスコアが所定値以下)の場合、すなわち受信データ(に対応するデータフレーム)は異常であると判定された場合(ステップS203でYes)、異常検知サーバ60は、ステップS205を実行する。受信データが異常でない場合(ステップS203でNo)、異常検知サーバ60は、ステップS204を実行する。
[0117]
 異常検知サーバ60は、処理対象である一連の受信データについて、対応するデータフレームの異常の判定が終わったか否か、つまり分類器へ未入力の受信データが存在するか否かを確認する(ステップS204)。分類器への未入力の受信データがある場合(ステップS204でYes)、異常検知サーバ60は、未入力の受信データに対してステップS202を実行する。分類器への未入力の受信データがない場合(ステップS204でNo)、異常検知サーバ60は、ステップS206を実行する。
[0118]
 異常検知サーバ60は、異常と判定された受信データに対応するデータフレームのペイロードにおける、異常に寄与した特徴量を示した部分のビット位置(異常部分)、及び異常部分のビット長(異常部分長)を算出し、ID、ペイロードデータと共に保持する(ステップS205)。
[0119]
 異常検知サーバ60は、車両10からアップロードされた車載ネットワークログについて、異常と判定されたデータフレームが存在するかを確認する(ステップS206)。異常と判定されたデータフレームが存在する場合(ステップS206でYes)は、異常検知サーバ60は、ステップS207を実行し、異常と判定された受信データが存在しない場合(ステップS206でNo)は、異常検知サーバ60は、処理を終了する。
[0120]
 異常検知サーバ60は、攻撃種類判定テーブル680に格納されている攻撃種類判定テーブルを参照し、異常と判定された各データフレームについて、異常部分長から攻撃種類を判定する(ステップS207)。ステップS207の詳細な処理内容については図13を用いて後述する。
[0121]
 次に異常検知サーバ60は、異常と判定された各データフレームのIDの種類数と、ペイロードにおける異常部分の位置、及び攻撃種類の組み合わせから攻撃レベルを判定する(ステップS208)。ステップS208の詳細な処理内容については図14を用いて後述する。
[0122]
 最後に異常検知サーバ60は、判定結果を出力し(図11のステップS110に相当)、処理を終了する。
[0123]
 [1.12 異常検知サーバによる攻撃種類判定処理]
 図13は、異常検知サーバ60における攻撃種類判定処理の手順例を示すフローチャートである。この手順例は、図12に示す車載ネットワークログの分析処理のステップS207の詳細である。
[0124]
 異常検知サーバ60は、異常と判定されたデータフレームの異常部分長が1ビット以上4ビット以下であるか否かを確認する(ステップS2071)。異常部分長が1ビット以上4ビット以下である場合(ステップS2071でYes)、異常検知サーバ60は、攻撃種類を状態値偽装と判定する(ステップS2072)。異常部分長が1ビット以上4ビット以下でない場合(ステップS2071でNo)、異常検知サーバ60は、異常部分長が5ビット以上31ビット以下であるか否かを確認する(ステップS2073)。異常部分長が5ビット以上31ビット以下である場合(ステップS2073でYes)は、異常検知サーバ60は、攻撃種類をセンサ値偽装と判定する(ステップS2074)。異常部分長が、5ビット以上31ビット以下でもない場合(ステップS2073でNo)、つまり異常部分長が32ビット以上の場合、異常検知サーバ60は、攻撃種類をトライアル攻撃と判定する(ステップS2075)。
[0125]
 異常検知サーバ60は、異常であると判定されたデータフレームであって攻撃種類について未判定のデータフレームがなくなるまで上記処理を行う。
[0126]
 [1.13 異常検知サーバの攻撃レベル判定処理]
 図14は、異常検知サーバ60における攻撃レベル判定処理の手順例を示すフローチャートである。この手順例は、図12に示す車載ネットワークログの分析処理のステップS208の詳細である。
[0127]
 異常検知サーバ60は、攻撃種類について未判定のデータフレームが存在するか否かを確認する(ステップS2081)。攻撃種類について未判定のデータフレームが存在する場合(ステップS2081でYes)、異常検知サーバ60は、攻撃種類について未判定のデータフレームがなくなるまで待つ。
[0128]
 攻撃種類について未判定のデータフレームがない場合(ステップS2081でNo)は、異常検知サーバ60は、判定された攻撃種類がトライアル攻撃のみであるか否かを確認する(ステップS2082)。攻撃種類がトライアル攻撃のみである場合(ステップS2082でYes)、異常検知サーバ60は、攻撃レベルを「低」と判定する(ステップS2083)。
[0129]
 攻撃種類が、トライアル攻撃のみでない場合(ステップS2082でNo)、異常検知サーバ60は、異常であると判定されたデータフレームのIDが一種類のみであるか否かを確認する(ステップS2084)。異常であると判定されたデータフレームのIDが一種類のみである場合(ステップS2084でYes)、異常検知サーバ60は、攻撃レベルを「中」と判定する(ステップS2085)。
[0130]
 異常であると判定されたデータフレームのIDが一種類のみでない、つまり複数ある場合(ステップS2084でNo)、異常検知サーバ60は、異なるIDを持つデータフレームの間で、ステップS207で判定された攻撃種類が共通であり、かつ異常部分も共通であるか否かを確認する(ステップS2086)。攻撃種類及び攻撃箇所が共通である場合(ステップS2086でYes)、異常検知サーバ60は、攻撃レベルを「中」と判定する(ステップS2085)。そうでない場合(ステップS2086でNo)、異常検知サーバ60は、攻撃レベルを「高」と判定する(ステップS2087)。
[0131]
 [1.14 実施の形態の効果]
 本実施の形態に係る車載ネットワーク監視システムでは、異常検知サーバ60が車両10から、車載ネットワークシステムで送受信されるフレームのペイロード値の分布に関する情報を取得して、この分布を異常検知サーバ60が保持している正常なデータフレームのペイロード値の分布と比較することで異常なデータフレームの検知を行う。これにより異常検知サーバ60は、異常検知のための観測を行う所定の期間内のペイロード値の分布の変化を捉える。攻撃のためにペイロードに外れ値ではなく、正常な範囲内のペイロード値が注入されたデータフレームであったとしても、この変化に基づいて異常なデータフレームとして検知される。このような異常検知サーバ60は異常なデータフレームの検知精度が高く、車載ネットワークシステムのセキュリティが高まり得る。
[0132]
 さらに異常検知サーバ60は、異常であると判定されたデータフレームに対して、データフレームのペイロード内の異なる部分に対応する複数の特徴量のうち、どの部分に対応する特徴量が異常に寄与しているかの異常寄与度を算出する。これにより、異常なデータフレームを検知するだけでなく、データフレームにおけるペイロード異常部分を把握することが可能となり、攻撃内容の詳細な把握が容易となる。
[0133]
 さらに異常検知サーバ60は、異常と判断されたデータフレームのペイロード異常部分の長さ(異常部分長)に基づいて、異常を発生させた攻撃種類を判定する。これにより、ペイロードの中でどのサブフィールドが偽装されているのかが判定可能になり、攻撃内容をより抽象的に把握することが可能となり、異常に対するより迅速で適切な対応につながる。
[0134]
 さらに、異常検知サーバ60は、異常と判断されたデータフレームの種類を示すID、ペイロード異常部分、及び異常部分長から把握される攻撃種類に関する条件に基づいて、危険度を示す攻撃レベルを判定する。これにより、車両の不正制御に関わるような危険度の高い攻撃への対応を優先的に実行することが可能となり、事故発生のリスクを早期に低減させることができる。
[0135]
 [変形例及び補足]
 以上、一つまたは複数の態様に係る、異常検知方法又は異常検知装置について、実施の形態に基づいて説明したが、本開示に係る異常検知方法及び異常検知装置は、これらの実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、異なる実施の形態における構成要素を組み合わせて構築される形態、及び当業者が思いつく各種変形を本実施の形態に施したものも一つまたは複数の態様の範囲内に含まれてもよい。以下に、上記の実施の形態のこのような変形例、及び上記の実施の形態の説明への補足を挙げる。
[0136]
 (1)上記の実施の形態では、車載ネットワークシステムをCANのプロトコルに則るものとして説明したが、本開示に係る異常検知方法及び異常検知装置が適用可能な通信ネットワークシステムは、これに限定されない。その他の規格、例えばCAN-FD(CAN with Flexible Data rate)、Ethernet(登録商標)、LIN(Local Interconnect Network)、又はFlexRay(登録商標)に準拠する車載ネットワークシステムであってもよい。各々いずれかに準拠する複数のネットワークが混在する車載ネットワークシステムであってもよい。さらに、上記実施の形態では、本開示に係る異常検知方法及び異常検知装置を自動車に搭載される車載ネットワークシステムに適用されるセキュリティ対策技術として説明したが、適用範囲はこれに限られない。本開示に係る異常検知方法及び異常検知装置は自動車に限らず、建機、農機、船舶、鉄道、飛行機、ドローン等のモビリティの通信ネットワークシステムにも適用してもよい。また、工場又はビルなど施設における産業制御システムで利用される通信ネットワークシステム、組込みデバイスを制御するための通信ネットワークシステムに適用してもよい。
[0137]
 (2)上記の実施の形態では、検知される異常の原因が通信ネットワークシステムに対する攻撃であるとし、その攻撃の種類について判定がなされるものとして説明したが、本開示に係る異常検知方法及び異常検知装置で検知される異常の原因は攻撃に限らない。例えば、通信ネットワークに接続される各種の機器の故障、破損若しくは欠陥、又は外因(例:温度、湿度、外来ノイズ)による不具合等を原因とする異常種類が判定されてもよい。上記の実施の形態において攻撃種類判定部640が判定する攻撃種類とは、この異常種類の一例であるとも言い得る。また、攻撃に限られないこれらの異常種類に関する条件を用いて、危険度を示す異常レベルが判定されてもよい。上記の実施の形態において攻撃レベル判定部650が判定する攻撃レベルとは、この異常レベルの一例であるとも言い得る。
[0138]
 (3)上記の実施の形態では、異常検知処理をサーバで行っているが、車両等の通信ネットワークシステム内のローカルで実行されてもよい。例えば、車載ネットワークシステムを構成するヘッドユニットのGPU(Graphics Processing Unit)で行ってもよい。これにより、サーバで行う場合に比べて、異常検知の即時性を高めることができる。この場合、サーバは、各車両上等のローカルで実行された異常検知処理の結果を集約してもよい。また、このときにローカルで使用されるリファレンスモデルは、ローカルの通信ネットワークシステム内の記憶装置であらかじめ保持されていてもよいし、サーバから適宜ダウンロードされてもよい。また、例えば通信ネットワークシステムでは異常部分の特定までが実行され、サーバでは以降の攻撃種類の判定及び攻撃レベルの判定が実行される、というように、ローカルの通信ネットワークシステムとサーバとで異常検知処理が分担されてもよい。
[0139]
 (4)上記の実施の形態では、異常検知サーバにあらかじめリファレンスモデルが保持されているが、リファレンスモデルがあらかじめ保持されていなくてもよい。例えば、異常が発生していないと判定されたログ情報が、次回以降の異常判定で、異常が発生していない時のデータの分布を示すリファレンスモデルとして用いられてもよい。また、異常検知サーバに保持されているリファレンスモデルが、車載ネットワークログを用いて更新されてもよい。
[0140]
 (5)上記の実施の形態では、異常検知サーバの形態を特に例示していないが、ローカル、つまり上記の実施の形態でいえば、車両に近いエッジサーバとして用意したサーバで実行するようにしてもよい。このようにすることで、異常検知処理をクラウドサーバに担わせるよりもネットワーク遅延の影響が少なくなる。例えばエッジサーバは路側機であって、路側機がネットワークでクラウドサーバと接続されており、車両は路側機に車載ネットワークログをアップロードする。路側機は受信した車載ネットワークログに対して異常検知処理を実行し、その結果を車両に返し、また、クラウドサーバにアップロードもしてもよい。
[0141]
 (6)上記の実施の形態では、車両又はサーバで異常が検知された場合にアラートを通知する情報の提供先として車載ネットワーク監視システムの管理者又はセキュリティアナリストを設定しているが、それに限定されない。例えば、カーメーカやECUサプライヤ、又は運転者若しくは所有者等の車両のユーザが使用している情報端末に情報を提供してもよい。また、複数のカーメーカ間で共通で利用可能なセキュリティプロバイダに情報が提供されてもよい。
[0142]
 (7)上記の実施の形態では、異常検知サーバへは、TCUに接続されるECUが受信したデータフレームのログが、このTCUからアップロードされているが、データフレームの車両から異常検知サーバへのアップロードの形態はこれに限らない。例えば、車載ネットワークシステム内でより広範囲からデータフレームを受信するゲートウェイが受信したデータフレームのログが、異常検知サーバにアップロードされてもよい。また、このログ情報は、ゲートウェイから異常検知サーバにアップロードされてもよい。
[0143]
 (8)上記の実施の形態では、ECUが車載ネットワークのデータフレームのログを定期的にアップロードしていたが、アップロードの機会又は頻度はこれに限定されない。車載ネットワークログは、例えば、異常検知サーバからの要求に応じてアップロードされてもよいし、車内に設置されたIDS(Intrusion Detection System)により異常が検知された場合のみアップロードされてもよい。ネットワークの混雑及び異常検知サーバの過負荷は、異常検知処理の遅滞を招き、その結果に基づく対応の遅延に繋がる。しかし、これにより、ネットワークの通信量の抑制及び異常検知サーバの処理負荷の抑制につながり、対応の遅延発生が抑制される。
[0144]
 (9)上記の実施の形態では、異常検知サーバは、車両からアップロードされた車載ネットワークログが示すすべてのデータフレームを異常検知処理の対象としている、一部のデータフレームが対象であってもよい。例えば、特定のIDのデータフレームのみを異常検知処理の対象としてもよい。これにより、異常検知サーバでの処理負荷が抑制される。また、対象となるデータフレームのIDは、動的に切り替えられてもよい。これにより、異常検知サーバでの異常検知処理の負荷を抑制させつつ、すべてのIDのデータフレームに対し異常検知処理を実施することができ、安全性の維持と異常への対応の遅延回避とを、バランスを取りながら両立させることができる。
[0145]
 (10)上記の実施の形態では、車載ネットワークログをアップロードするECUは、所定の期間に受信したすべてのデータフレームのペイロード情報に基づくログ情報をアップロードしている、異常検知サーバにアップロードするログ情報をすべてのデータフレームのペイロード情報に基づくものでなくてもよい。アップロードされるログ情報は、例えば特定のIDのデータフレームのペイロード情報に基づくものであってもよい。これによりネットワークの通信量の抑制及び異常検知サーバの処理負荷の抑制につながる。また、アップロード対象となるデータフレームのIDは動的に切り替えられてもよい。これにより、異常検知サーバでの異常検知処理の負荷を抑制させつつ、すべてのIDのデータフレームに対して異常検知処理を実施することができ、安全性の維持と異常への対応の遅延回避とを、バランスを取りながら両立させることができる。
[0146]
 (11)上記の実施の形態では、異常検知サーバは、データフレームのペイロード値に対応する多次元の特徴量の全てを入力とした異常検知処理を行っていたが、入力する特徴量の次元を削減してもよい。例えば、ペイロードに含まれるカウンタ又はチェックサムのサブフィールドが既知の場合は、これらのサブフィールドに対応する特徴量を異常検知処理の入力から除外してもよい。これにより、不正な制御に直接的に影響のない部分を異常検知処理の対象から除外して計算量を削減し、かつ、適切に異常検知を実行することができる。
[0147]
 (12)上記の実施の形態では、異常検知サーバでは、攻撃種類がセンサ値偽装、状態値偽装、及びトライアル攻撃の3種類に分類している、攻撃の分類はこれらに限らない。例えば、同一データフレーム内に上記の複合的な攻撃が含まれるような分類が用いられてもよい。また、上記の実施の形態において、攻撃その他の異常種類の判定に用いられているペイロードの異常部分長の値は例であり、これに限定されない。なお、センサ値の異常の場合に異常部分長が取り得る範囲を第一範囲、状態値の異常の場合に異常部分長が取り得る範囲を第二範囲、トライアル攻撃による異常の場合に異常部分長が取り得る範囲を第三範囲とすると、第一範囲、第二範囲、第三範囲の順により長くなりやすいと考えられ、上記の例はこの考えを反映している。また、第一範囲、第二範囲及び第三範囲どうしは、必ずしも連続していなくてもよい。例えば第一範囲の上限は4ビットである場合に、第二範囲の下限は5ビットでなくてもよく、例えば8ビットであってもよい。これらの各範囲の上限および下限は、車載ネットワークシステムの設計、仕様又は準拠する規格等に基づいて導かれる取り得る値に定め得る。また、上記のような複合的な攻撃の発生を示すような異常部分長の範囲が用いられてもよい。
[0148]
 (13)上記の実施の形態では、異常検知サーバは、攻撃レベルを低、中、高と分類したが、分類方法はこれに限られない。例えば、より多段階のスコアが用いられてもよい。攻撃レベルのスコアは、例えば異常であると判定されたフレームのID、異常であると判定されたフレームのIDの個数(つまりデータフレームの種類数)、攻撃種類、又は異常部分長、ペイロードにおける異常部分の位置にそれぞれ基づくパラメータを含む所定の計算式を用いて算出されてもよい。これにより、発生した異常に対し、より細分化した危険度に応じて対応することが可能になり、解析の優先度付けをより的確に行うことができる。
[0149]
 (14)上記の実施の形態では、異常検知サーバは異常部分、すなわちペイロードの異常に寄与した部分の、ビット長に基づいて攻撃種類を判定しているが、攻撃種類の判定方法はこれに限らない。例えば、異常寄与度をさらに用いて攻撃種類を判定してもよい。また、異常寄与度を学習させた攻撃種類の分類器に、異常検知処理対象のデータフレームのペイロードについて算出した異常寄与度を入力して、攻撃種類を判定してもよい。また、ペイロードのサブフィールド情報を表したデータベースを保持しておき、異常部分とこのデータベースとを照らし合わせることで、攻撃種類を判定してもよい。
[0150]
 (15)上記の実施の形態では、使用されているリファレンスモデルは1つである例を示したがこれに限られない。例えば車両であれば、車種、年式、オプション構成、車載ネットワークシステムの構成等に応じた異なる正常モデルが用いられてもよい。
[0151]
 (16)上記の実施の形態では、リファレンスモデルは車両の正常走行時のデータの分布を示すモデルであるが、リファレンスモデルが示すのはこれに限らない。例えば、異常が発生していると既知の通信ネットワークシステムから収集されたデータに基づく、異常発生時のデータの分布を示すモデルであってもよい。
[0152]
 (17)上記の実施の形態では、異常検知サーバは、異常と判断されたデータフレームのIDの種類数、判定された攻撃種類、ペイロードにおける異常部分の位置に関する条件の組み合わせに基づいて攻撃レベルを判定していたが、これらすべての条件を用いずに攻撃レベルを判定してもよい。例えば、異常と判断されたIDの種類数が1つの場合は、常に攻撃レベルを中と判定してもよい。これにより、より柔軟に攻撃レベルの算出が可能となる。
[0153]
 (18)上記の実施の形態では、異常検知サーバは、密度比が所定の閾値を超えた場合に対応するフレームを異常であると判断するとしたが、所定の閾値は、リファレンスモデルの特徴量において密度比が最大となった時の値としてもよい。これにより、正常なフレームを誤って異常と判定する可能性が低くなり、解析コストの低減につながる。
[0154]
 (19)上記の実施の形態では、異常検知サーバはIDごとにペイロード値の分布をリファレンスモデルとして保持しているが、IDごとに分けずにペイロード値の分布を保持していてもよい。これにより、リファレンスモデルのデータサイズを効果的に削減することができる。
[0155]
 (20)上記の実施の形態では、異常検知サーバに通知する車両ログは、CANのフレームにかかわる情報であったが、異常検知サーバに通知する車両ログはこれに限らない。例えばEthernetのフレーム、CAN-FDフレーム、FlexRayフレームであってもよいし、車載ネットワークフレームでなくてもよい。例えば、車両の現在位置を表すGPS情報、オーディオヘッドユニットへのアクセスログ、動作プロセスに関するログ、ファームウェアのバージョン情報等といった情報であってもよい。
[0156]
 (21)上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ROM、RAM、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。RAM又はハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
[0157]
 (22)上記の実施の形態における各装置は、構成する構成要素の一部または全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしてもよい。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAMなどを含んで構成されるコンピュータシステムである。RAMには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムLSIは、その機能を達成する。
[0158]
 また、上記の各装置を構成する構成要素の各部は、個別に1チップ化されていてもよいし、一部又はすべてを含むように1チップ化されてもよい。
[0159]
 また、ここでは、システムLSIとしたが、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)、又はLSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
[0160]
 さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
[0161]
 (23)上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なICカードまたは単体のモジュールから構成されているとしてもよい。ICカードまたはモジュールは、マイクロプロセッサ、ROM、RAMなどから構成されるコンピュータシステムである。ICカードまたはモジュールは、上記の超多機能LSIを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ICカードまたはモジュールは、その機能を達成する。このICカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
[0162]
 (24)本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。
[0163]
 また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD-ROM、MO、DVD、DVD-ROM、DVD-RAM、BD(Blu-ray(登録商標) Disc)、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
[0164]
 また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
[0165]
 また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
[0166]
 また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号をネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
[0167]
 (25)上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

産業上の利用可能性

[0168]
 本開示は、車載ネットワークシステム等の通信ネットワークシステムにおいて、例えば外れ値を含まない不正なフレームが攻撃者によって送信された場合も、当該フレームが異常であるか否か判定することができる。さらに、異常なフレームのペイロードのおける異常部分を算出し、この異常部分に基づいて、異常の種類及び以上のレベルといった内容を迅速に把握し、対処することができ、安全性の向上に効果的である。

符号の説明

[0169]
 10 車両
 20 ネットワーク
 60 異常検知サーバ
 100、101、200、201、300、301、302、400、401 電子制御ユニット(ECU)
 110 エンジン
 111 トランスミッション
 210 ブレーキ
 211 ステアリング
 310 カメラ
 311 カーナビゲーションシステム
 312 テレマティクス制御ユニット(TCU)
 330、910 フレーム送受信部
 340、920 フレーム解釈部
 350 外部機器制御部
 360、940 フレーム生成部
 370 受信履歴保持部
 380 サーバ通信部
 410 ドア
 411 ライト
 510 診断ポート
 610 通信部
 620 異常検知部
 630 異常部分特定部
 640 攻撃種類判定部
 650 攻撃レベル判定部
 660 結果出力部
 670 リファレンスモデル保持部
 680 攻撃種類判定テーブル
 690 攻撃レベル判定テーブル
 900 ゲートウェイ
 930 転送制御部
 950 転送ルール保持部
 1000、2000、3000、4000、5000 バス

請求の範囲

[請求項1]
 通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれる各フレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知方法であって、
 前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を取得するリファレンスモデル取得ステップと、前記観測データに含まれるフレームが異常であるか否かを判断するフレーム異常検知ステップと、異常部分出力ステップとを含み、
 前記リファレンスモデル取得ステップでは、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を取得し、
 前記フレーム異常検知ステップでは、前記リファレンスモデル取得ステップで取得された前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断し、
 前記異常部分出力ステップでは、前記フレーム異常検知ステップにおいて異常なフレームであると判断されたフレームがある場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、ペイロード内の1個以上の部分であるペイロード異常部分を出力する、
 異常検知方法。
[請求項2]
 異常種類判定ステップをさらに備え、
 前記異常種類判定ステップでは、前記ペイロード異常部分に基づいてペイロード異常部分長を特定し、前記ペイロード異常部分長に応じて、異常種類を判定する、
 請求項1に記載の異常検知方法。
[請求項3]
 前記異常種類判定ステップでは、前記異常種類を、前記ペイロード異常部分長が第一範囲内であるときに状態値異常と判定し、前記ペイロード異常部分長が前記第一範囲より長い第二範囲内であるときにセンサ値異常と判定し、前記ペイロード異常部分長が前記第二範囲より長い第三範囲内であるときにトライアル攻撃異常であると判定する、
 請求項2に記載の異常検知方法。
[請求項4]
 前記第一範囲は、上限が4ビット以下の範囲であり、
 前記第二範囲は、下限が8ビット以上、且つ、上限が16ビット以下の範囲であり、
 前記第三範囲は、下限が32ビットの範囲である
 請求項3に記載の異常検知方法。
[請求項5]
 異常レベル判定ステップをさらに備え、
 前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数種類のフレームが異常であると検知され、かつ前記異常部分出力ステップにおいて出力される前記ペイロード異常部分が、前記複数種類のフレーム間で異なる場合に、前記ペイロード異常部分が前記複数種類のフレーム間で同じ場合よりも異常レベルを高く判定する
 請求項2から4のいずれか1項に記載の異常検知方法。
[請求項6]
 異常レベル判定ステップをさらに備え、
 前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、前記複数の種類のフレーム間で同じ場合よりも異常レベルを高く判定する、
 請求項2から4のいずれか1項に記載の異常検知方法。
[請求項7]
 異常レベル判定ステップをさらに備え、
 前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、1以上の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、トライアル攻撃異常のみである場合に、判定された異常種類にトライアル攻撃異常が含まれない場合よりも異常レベルを低く判定する、
 請求項2から4のいずれか1項に記載の異常検知方法。
[請求項8]
 異常レベル判定ステップをさらに備え、
 前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、1以上の種類のフレームが異常であると判定された場合に、前記異常であると判定された前記フレームの種類、異常であると判定された前記フレームの種類数、前記異常部分出力ステップにおいて出力されたペイロード異常部分、前記異常種類判定ステップにおいて判定された異常種類のいずれか1以上の要素をパラメータとする所定の計算式に基づいて異常レベルを判定する、
 請求項2から4のいずれか1項に記載の異常検知方法。
[請求項9]
 前記異常種類判定ステップでは、1のフレームに含まれる前記ペイロード異常部分が複数ある場合に、複数の前記ペイロード異常部分の間にある中間ビットの数が所定の基準以下であるときは、複数の前記ペイロード異常部分及び前記中間ビットをあわせて1つのペイロード異常部分として扱う、
 請求項2から8のいずれか1項に記載の異常検知方法。
[請求項10]
 前記通信ネットワークシステムは、車載ネットワークシステムである、
 請求項1から9のいずれか1項に記載の異常検知方法。
[請求項11]
 通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれるフレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知装置であって、
 前記フレームに含まれるペイロードを構成する1ビット以上の部分に関する複数の特徴量のデータ分布を保持するリファレンスモデル保持部と、
 前記観測データに含まれるフレームが異常であるか否かを判断する異常検知部と、
 前記異常検知部において異常なフレームが検知された場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、前記フレームに含まれる1個以上の部分であるペイロード異常部分を出力する異常部分出力部とを備え、
 前記リファレンスモデル保持部は、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を保持しており、
 前記異常検知部は、前記リファレンスモデル保持部が保持する前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断する、
 異常検知装置。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]