知財求人 - 知財ポータルサイト「IP Force」
▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-17
(45)【発行日】2024-10-25
(54)【発明の名称】異常検知方法及び異常検知装置
(51)【国際特許分類】
G06F 21/55 20130101AFI20241018BHJP
G05B 23/02 20060101ALI20241018BHJP
【ＦＩ】
G06F21/55
G05B23/02 302V
【請求項の数】
11
(21)【出願番号】P 2021511446
(86)(22)【出願日】2020-03-19
(86)【国際出願番号】 JP2020012301
(87)【国際公開番号】W WO2020203352
(87)【国際公開日】2020-10-08
【審査請求日】2022-12-23
(31)【優先権主張番号】P 2019067627
(32)【優先日】2019-03-29
(33)【優先権主張国・地域又は機関】JP
【前置審査】
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
(74)【代理人】
【識別番号】100137235
【弁理士】
【氏名又は名称】寺谷 英作
(74)【代理人】
【識別番号】100131417
【弁理士】
【氏名又は名称】道坂 伸一
(72)【発明者】
【氏名】佐々木 崇光
(72)【発明者】
【氏名】芳賀 智之
(72)【発明者】
【氏名】田中 大貴
(72)【発明者】
【氏名】山田 誠
(72)【発明者】
【氏名】鹿島 久嗣
(72)【発明者】
【氏名】岸川 剛
【審査官】松平 英
(56)【参考文献】
【文献】国際公開第２０１８／１０５３３０（ＷＯ，Ａ１）
【文献】国際公開第２０１８／１６８２９１（ＷＯ，Ａ１）
【文献】特開２００６－１１５１２９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０５Ｂ２３／００－２３／０２
Ｇ０６Ｆ１２／１４
２１／００－２１／８８
Ｈ０４Ｌ１２／００－１２／２８
１２／４４－１２／６６
４５／００－４９／９０５７
(57)【特許請求の範囲】
【請求項1】
通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれる各フレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知方法であって、前記フレームに含まれるペイロードを構成する１ビット以上の部分に関する複数の特徴量のデータ分布を取得するリファレンスモデル取得ステップと、前記観測データに含まれるフレームが異常であるか否かを判断するフレーム異常検知ステップと、異常部分出力ステップとを含み、
前記リファレンスモデル取得ステップでは、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を取得し、
前記フレーム異常検知ステップでは、前記リファレンスモデル取得ステップで取得された前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断し、
前記異常部分出力ステップでは、前記フレーム異常検知ステップにおいて異常なフレームであると判断されたフレームがある場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、ペイロード内の１個以上の部分であるペイロード異常部分を出力し、
異常種類判定ステップをさらに備え、
前記異常種類判定ステップでは、前記ペイロード異常部分に基づいてペイロード異常部分長を特定し、前記ペイロード異常部分長に応じて、異常種類を判定する、
異常検知方法。
【請求項2】
前記異常種類判定ステップでは、前記異常種類を、前記ペイロード異常部分長が第一範囲内であるときに状態値異常と判定し、前記ペイロード異常部分長が前記第一範囲より長い第二範囲内であるときにセンサ値異常と判定し、前記ペイロード異常部分長が前記第二範囲より長い第三範囲内であるときにトライアル攻撃異常であると判定する、請求項１に記載の異常検知方法。
【請求項3】
前記第一範囲は、上限が４ビット以下の範囲であり、前記第二範囲は、下限が８ビット以上、且つ、上限が１６ビット以下の範囲であり、
前記第三範囲は、下限が３２ビットの範囲である
請求項２に記載の異常検知方法。
【請求項4】
異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数種類のフレームが異常であると検知され、かつ前記異常部分出力ステップにおいて出力される前記ペイロード異常部分が、前記複数種類のフレーム間で異なる場合に、前記ペイロード異常部分が前記複数種類のフレーム間で同じ場合よりも異常レベルを高く判定する
請求項１から３のいずれか１項に記載の異常検知方法。
【請求項5】
異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、複数の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、前記複数の種類のフレーム間で異なる場合に、前記異常種類が前記複数の種類のフレーム間で同じ場合よりも異常レベルを高く判定する、
請求項１から３のいずれか１項に記載の異常検知方法。
【請求項6】
異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、１以上の種類のフレームが異常であると検知され、かつ前記異常種類判定ステップにおいて判定された異常種類が、トライアル攻撃異常のみである場合に、判定された異常種類にトライアル攻撃異常が含まれない場合よりも異常レベルを低く判定する、
請求項１から３のいずれか１項に記載の異常検知方法。
【請求項7】
異常レベル判定ステップをさらに備え、前記異常レベル判定ステップでは、前記フレーム異常検知ステップにおいて、１以上の種類のフレームが異常であると判定された場合に、前記異常であると判定された前記フレームの種類、異常であると判定された前記フレームの種類数、前記異常部分出力ステップにおいて出力されたペイロード異常部分、前記異常種類判定ステップにおいて判定された異常種類のいずれか１以上の要素をパラメータとする所定の計算式に基づいて異常レベルを判定する、
請求項１から３のいずれか１項に記載の異常検知方法。
【請求項8】
前記異常種類判定ステップでは、１のフレームに含まれる前記ペイロード異常部分が複数ある場合に、複数の前記ペイロード異常部分の間にある中間ビットの数が所定の基準以下であるときは、複数の前記ペイロード異常部分及び前記中間ビットをあわせて１つのペイロード異常部分として扱う、請求項１から７のいずれか１項に記載の異常検知方法。
【請求項9】
前記通信ネットワークシステムは、車載ネットワークシステムである、請求項１から８のいずれか１項に記載の異常検知方法。
【請求項10】
通信ネットワークシステムにおいて、所定の期間に観測される前記通信ネットワークシステム上で送受信されるフレームの集合からなる観測データに含まれるフレームが異常であるかを判断し、異常であると判断されたフレームのペイロードの異常部分を出力する異常検知装置であって、前記フレームに含まれるペイロードを構成する１ビット以上の部分に関する複数の特徴量のデータ分布を保持するリファレンスモデル保持部と、
前記観測データに含まれるフレームが異常であるか否かを判断する異常検知部と、
前記異常検知部において異常なフレームが検知された場合に、前記異常なフレームから抽出した前記複数の特徴量の異常寄与度を算出し、前記異常寄与度が所定値以上である特徴量と対応する、前記フレームに含まれる１個以上の部分であるペイロード異常部分を出力する異常部分出力部とを備え、
前記リファレンスモデル保持部は、前記観測データの取得タイミングとは異なるタイミングで取得した前記通信ネットワークシステム上で送受信されるフレームの集合に対しての前記データ分布を保持しており、
前記異常検知部は、前記リファレンスモデル保持部が保持する前記データ分布と、前記観測データに含まれる前記フレームから抽出される特徴量のデータ分布との差異を算出し、前記差異が所定値以上となる特徴量をもつフレームを異常なフレームであると判断し、
さらに、判定部を備え、
前記判定部は、前記ペイロード異常部分に基づいてペイロード異常部分長を特定し、前記ペイロード異常部分長に応じて、異常種類を判定する、
異常検知装置。
【請求項11】
請求項１から９のいずれか１項に記載の異常検知方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信ネットワークシステムに流れるフレームの集合に含まれる異常なフレームを検知する技術に関する。
【背景技術】
【0002】
近年の自動車の中のシステムには、電子制御ユニット（Electronic Control Unit、以下、ＥＣＵと表記）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐ通信ネットワークは、車載ネットワークと呼ばれている。車載ネットワークには多数の規格が存在するが、その中でも最も主流な規格の一つとしてController Area Network（以降、ＣＡＮと表記）が挙げられる。
【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】
本実施の形態では、車載ネットワークシステムにおける各ＥＣＵはＣＡＮプロトコルに従って通信を行う。ＣＡＮプロトコルにおけるフレームの種類には、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。ここでは主としてデータフレームに注目して説明する。ＣＡＮプロトコルでは、データフレームは、データを格納するデータフィールド、データフィールドのデータ長を示すＤＬＣ（Data Length Code）、及びデータフィールドに格納されるデータに基づく種類を示すＩＤを格納するＩＤフィールドを含むと規定されている。なお、本実施の形態に係る異常検知方法又は異常検知装置は、データフレーム以外の種類のＣＡＮプロトコルのフレーム、又は他の通信プロトコルに従う通信ネットワークシステムにも、適用可能である。
【0039】
［１．２ 車載ネットワークシステムの構成］
図２は、車両１０が備える車載ネットワークシステムの構成の一例を示す図である。
図２は、車両１０が備える車載ネットワークシステムの構成の一例を示す図である。
【0040】
車両１０における車載ネットワークシステムは、バス（ＣＡＮバス）１０００、２０００、３０００、４０００及び５０００に接続された複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１）及びこれらのバス間の通信を中継するゲートウェイ９００といった各ノードを含む。なお、ゲートウェイ９００もＥＣＵである。
【0041】
図２では省略しているものの、車載ネットワークシステムには、さらに多くのＥＣＵが含まれ得る。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ（Read-Only Memory）及びＲＡＭ（Random Access Memory）であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラムに従って動作することにより、ＥＣＵは各種機能を実現する。なお、コンピュータプログラムとは、所定の機能を実現するために、プロセッサに対する命令コードが複数個組み合わされたものである。
【0042】
バス１０００には、モータ、燃料、電池の制御といった車両１０の駆動に関連するパワートレイン系のＥＣＵが接続されている。エンジン１１０に接続されたＥＣＵ（エンジンＥＣＵ）１００及びトランスミッション１１１に接続されたＥＣＵ（トランスミッションＥＣＵ）１０１は、本実施の形態におけるパワートレイン系のＥＣＵの例である。
【0043】
バス２０００には、「曲がる」、「止まる」等といった車両１０の操舵及び制動等の制御に関連するシャーシ系のＥＣＵが接続されている。ブレーキ２１０に接続されたＥＣＵ（ブレーキＥＣＵ）２００及びステアリング２１１に接続されたＥＣＵ（ステアリングＥＣＵ）２０１は、本実施の形態におけるシャーシ系のＥＣＵの例である。
【0044】
バス３０００には、画像情報を基に運転支援の認知・判断・制御を行う機能や、オーディオヘッドユニットに関わる機能、及び車車間通信といった情報系に関連するＥＣＵが接続されている。それぞれカメラ３１０、カーナビゲーションシステム３１１、テレマティクス制御ユニット（ＴＣＵ：Telematic Control Unit）３１２に接続されたＥＣＵ３００、ＥＣＵ３０１及びＥＣＵ３０２は、本実施の形態における情報系のＥＣＵの例である。
【0045】
バス４０００には、ドア、エアコン、ウィンカー等といった車両の装備の制御に関連するボディ系のＥＣＵが接続されている。ドア４１０に接続されたＥＣＵ４００、及びライト４１１に接続されたＥＣＵ４０１は、本実施の形態におけるボディ系のＥＣＵの例である。
【0046】
バス５０００には、例えばＯＢＤ２（On-Board Diagnostics 2nd generation）等の、外部の診断ツール（故障診断ツール）等と通信するためのインタフェースである診断ポート５１０が接続されている。
【0047】
上記のＥＣＵ（ＥＣＵ１００、２００等）のそれぞれは、接続されている機器（エンジン１１０、ブレーキ２１０等）の状態を示す情報を取得し、この状態を表すデータフレーム等（以下、データフレームのことを単にフレームともいう）を車載ネットワークシステムつまりＣＡＮバスに定期的に送信している。
【0048】
ゲートウェイ９００は、異なる複数の通信路間でデータを転送するＥＣＵである。図２の例を参照すると、ゲートウェイ９００は、バス１０００、バス２０００、バス３０００、バス４０００、バス５０００と接続している。つまり、ゲートウェイ９００は、一方のバスから受信したフレームを、一定条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有するＥＣＵである。
【0049】
ＥＣＵ３０２は、バス３０００に流れるフレームを受信して保持し、定期的に異常検知サーバ６０へアップロードする機能を持つ。フレームはＴＣＵ３１２から、携帯電話回線等の通信回線を含むネットワーク２０を介して異常検知サーバ６０へアップロードされる。
【0050】
［１．３ 異常検知サーバの構成］
図３は、サーバ（異常検知サーバ）６０の機能構成を示すブロック図である。車両１０の車載ネットワークシステムで送信される不正なフレームに対処するための異常検知サーバ６０は、例えばプロセッサ、メモリ、通信インタフェース等を含む一台以上のコンピュータにより実現される。異常検知サーバ６０は、通信部６１０と、異常検知部６２０と、異常部分特定部６３０と、攻撃種類判定部６４０と、攻撃レベル判定部６５０と、結果出力部６６０と、リファレンスモデル保持部６７０と、攻撃種類判定テーブル６８０と、攻撃レベル判定テーブル６９０とを含む。
図３は、サーバ（異常検知サーバ）６０の機能構成を示すブロック図である。車両１０の車載ネットワークシステムで送信される不正なフレームに対処するための異常検知サーバ６０は、例えばプロセッサ、メモリ、通信インタフェース等を含む一台以上のコンピュータにより実現される。異常検知サーバ６０は、通信部６１０と、異常検知部６２０と、異常部分特定部６３０と、攻撃種類判定部６４０と、攻撃レベル判定部６５０と、結果出力部６６０と、リファレンスモデル保持部６７０と、攻撃種類判定テーブル６８０と、攻撃レベル判定テーブル６９０とを含む。
【0051】
リファレンスモデル保持部６７０、攻撃種類判定テーブル６８０、及び攻撃レベル判定テーブルのそれぞれの機能は、例えば、メモリ、ハードディスクといった記憶媒体に所定の構成で保持されるデータとして実現され得る。これらのデータについては、例を用いて後述する。
【0052】
また、異常検知部６２０、異常部分特定部６３０、攻撃種類判定部６４０、攻撃レベル判定部６５０及び結果出力部６６０それぞれの機能は、例えば、メモリに格納された制御プログラムがプロセッサにより実行されることにより実現され得る。
【0053】
通信部６１０は、通信インタフェース、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。通信部６１０は、ネットワーク２０を介して車両１０と通信することで、車両１０の車載ネットワークシステムに関する情報を受信する。車載ネットワークシステムに関する情報には、例えば、車載ネットワークシステムのＣＡＮバス上に流されたフレームの内容（ペイロード情報）、受信タイミング（間隔、頻度等）に関する情報が含まれ得る。
【0054】
異常検知部６２０は、通信部６１０から通知される車載ネットワークシステムのログのデータ（観測データセットＤ′）が異常であるかを判断する。この時、リファレンスモデル保持部６７０に格納されている正常走行時の車載ネットワークログ（リファレンスモデルデータセットＤ）を参照し、観測データセットとリファレンスモデルデータセットとの差異に基づいて観測データセットに異常なフレームのデータが含まれるか否かを判断する。
【0055】
観測データセットＤ′が異常であるかの判定には、例えば密度比推定による異常検知方法が利用可能である。密度比推定は、リファレンスモデルデータセットＤの分布と、観測データセットＤ′の分布との異なる箇所を検知する技術である。例えば外れ値を含まないデータフレームを用いる攻撃による異常は、外れ値検出のみを用いる手法では検知が困難である。しかしこの技術では、このような異常であっても正常なデータとの値の分布の差異に基づいて検知することができる。
【0056】
以下に、密度比推定アルゴリズムの一例を示す。密度比推定アルゴリズムは、リファレンスモデルデータセットＤを構成する正常走行時の各データフレームのデータのラベルを０とし、観測データセットＤ′に含まれる各データフレームのデータのラベルを１として、正常データと観測データとを分類するよう分類器を学習させる。分類器にはＭＬＰ（Multi Layer Perceptron）、ロジスティック回帰、ランダムフォレスト、ｋ－近傍法等のモデルが利用可能である。
【0057】
１つのデータフレームに対応する観測データ（詳細は後述）をxとしたとき、密度比r(x)はベイズの定理から下記の式１にて求められる。
【0058】
r(x) = pD(x)/pD′(x) = p(x|y=0)/p(x|y=1) = p(y=1)p(y=0|x)/p(y=0)p(y=1|x)
......（式１）
......（式１）
【0059】
ここで、p(y=1|x)は観測データxが観測データセットＤ′に属する確率であり、分類器の出力である。また、p(y=0|x)は観測データxが正常データセットＤに属する確率であり、１から分類器の出力を引いたものである。p(y=1)、p(y=0)はそれぞれ、データセット全体に対する観測データセット、リファレンスモデルデータセットの大きさの比率である。
【0060】
r(x)の絶対値が所定の閾値を超えた場合、すなわち、観測データxに対して分類器が、観測データセットＤ′（又はリファレンスモデルデータセットＤ）に属する確率が高いと判断した場合に、観測データx（に対応するデータフレーム）が異常であると判定する。観測データxは１つのデータフレームのペイロードから抽出される特徴量であり、例えば、ＣＡＮのデータフレームに含まれるデータフィールドの各ビット値を１つの特徴量とした６４次元の特徴量である。
【0061】
なお、各特徴量はデータフィールドの各ビット値でなくてもよく、データフィールドの値全体を所定のビット長で区切ったものであってもよい。したがって観測データxは、例えば、６４ビットのデータフィールドの値を４ビット毎に区切って得られる１６個の値を１つの特徴量としてなる１６次元の特徴量としてもよいし、８ビット毎に区切って得られる８個の値を１つの特徴量としてなる８次元の特徴量としてもよい。さらに固定長のビットで区切らなくてもよい。例えば、ペイロード内に含まれる、それぞれ意味をなす各サブフィールドに対応して特徴量を抽出してもよい。
【0062】
また、上記分類器は、データフレームに含まれるＩＤごとに用意して学習させてもよいし、所定の組み合わせのＩＤのデータフレーム又はすべてのＩＤのデータフレームをまとめて１つの分類器に学習させてもよい。異常検知部６２０は、異常であると判定したデータフレームのＩＤ、特徴量、及び判定に用いた分類器の情報を異常部分特定部６３０へ通知する。
【0063】
異常部分特定部６３０は、異常検知部６２０から通知された情報をもとに、異常と判定されたデータフレームのペイロードにおける各特徴量（ここでは１データフレームから抽出された高次元の特徴量をなす各特徴量を指す）の異常への寄与の程度（以下、異常寄与度ともいう）を算出する。特徴量ｉの異常寄与度cｉは密度比r(x)を入力xで微分することで求める（式２参照）。
【0064】
ci ＝ δr(x)/δx ......（式２）
【0065】
具体的には、特徴量iの値に対して（ビット）反転させたとき、あるいは微小な変化を加えたときの密度比r(x)の変化量を異常寄与度とする。異常部分特定部６３０は、この異常寄与度を、異常と判定されたデータフレームの各特徴量iについて算出し、所定の閾値以上の異常寄与度を示した特徴量iを、当該データフレームの異常に寄与している特徴量であると判定する。そして異常部分特定部６３０は、この特徴量を示した部分のペイロードにおけるビット位置を、ペイロード異常部分として特定する。
【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】
（１）上記の実施の形態では、車載ネットワークシステムをＣＡＮのプロトコルに則るものとして説明したが、本開示に係る異常検知方法及び異常検知装置が適用可能な通信ネットワークシステムは、これに限定されない。その他の規格、例えばＣＡＮ－ＦＤ（CAN with Flexible Data rate）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＬＩＮ（Local Interconnect Network）、又はＦｌｅｘＲａｙ（登録商標）に準拠する車載ネットワークシステムであってもよい。各々いずれかに準拠する複数のネットワークが混在する車載ネットワークシステムであってもよい。さらに、上記実施の形態では、本開示に係る異常検知方法及び異常検知装置を自動車に搭載される車載ネットワークシステムに適用されるセキュリティ対策技術として説明したが、適用範囲はこれに限られない。本開示に係る異常検知方法及び異常検知装置は自動車に限らず、建機、農機、船舶、鉄道、飛行機、ドローン等のモビリティの通信ネットワークシステムにも適用してもよい。また、工場又はビルなど施設における産業制御システムで利用される通信ネットワークシステム、組込みデバイスを制御するための通信ネットワークシステムに適用してもよい。
【0137】
（２）上記の実施の形態では、検知される異常の原因が通信ネットワークシステムに対する攻撃であるとし、その攻撃の種類について判定がなされるものとして説明したが、本開示に係る異常検知方法及び異常検知装置で検知される異常の原因は攻撃に限らない。例えば、通信ネットワークに接続される各種の機器の故障、破損若しくは欠陥、又は外因（例：温度、湿度、外来ノイズ）による不具合等を原因とする異常種類が判定されてもよい。上記の実施の形態において攻撃種類判定部６４０が判定する攻撃種類とは、この異常種類の一例であるとも言い得る。また、攻撃に限られないこれらの異常種類に関する条件を用いて、危険度を示す異常レベルが判定されてもよい。上記の実施の形態において攻撃レベル判定部６５０が判定する攻撃レベルとは、この異常レベルの一例であるとも言い得る。
【0138】
（３）上記の実施の形態では、異常検知処理をサーバで行っているが、車両等の通信ネットワークシステム内のローカルで実行されてもよい。例えば、車載ネットワークシステムを構成するヘッドユニットのＧＰＵ（Graphics Processing Unit）で行ってもよい。これにより、サーバで行う場合に比べて、異常検知の即時性を高めることができる。この場合、サーバは、各車両上等のローカルで実行された異常検知処理の結果を集約してもよい。また、このときにローカルで使用されるリファレンスモデルは、ローカルの通信ネットワークシステム内の記憶装置であらかじめ保持されていてもよいし、サーバから適宜ダウンロードされてもよい。また、例えば通信ネットワークシステムでは異常部分の特定までが実行され、サーバでは以降の攻撃種類の判定及び攻撃レベルの判定が実行される、というように、ローカルの通信ネットワークシステムとサーバとで異常検知処理が分担されてもよい。
【0139】
（４）上記の実施の形態では、異常検知サーバにあらかじめリファレンスモデルが保持されているが、リファレンスモデルがあらかじめ保持されていなくてもよい。例えば、異常が発生していないと判定されたログ情報が、次回以降の異常判定で、異常が発生していない時のデータの分布を示すリファレンスモデルとして用いられてもよい。また、異常検知サーバに保持されているリファレンスモデルが、車載ネットワークログを用いて更新されてもよい。
【0140】
（５）上記の実施の形態では、異常検知サーバの形態を特に例示していないが、ローカル、つまり上記の実施の形態でいえば、車両に近いエッジサーバとして用意したサーバで実行するようにしてもよい。このようにすることで、異常検知処理をクラウドサーバに担わせるよりもネットワーク遅延の影響が少なくなる。例えばエッジサーバは路側機であって、路側機がネットワークでクラウドサーバと接続されており、車両は路側機に車載ネットワークログをアップロードする。路側機は受信した車載ネットワークログに対して異常検知処理を実行し、その結果を車両に返し、また、クラウドサーバにアップロードもしてもよい。
【0141】
（６）上記の実施の形態では、車両又はサーバで異常が検知された場合にアラートを通知する情報の提供先として車載ネットワーク監視システムの管理者又はセキュリティアナリストを設定しているが、それに限定されない。例えば、カーメーカやＥＣＵサプライヤ、又は運転者若しくは所有者等の車両のユーザが使用している情報端末に情報を提供してもよい。また、複数のカーメーカ間で共通で利用可能なセキュリティプロバイダに情報が提供されてもよい。
【0142】
（７）上記の実施の形態では、異常検知サーバへは、ＴＣＵに接続されるＥＣＵが受信したデータフレームのログが、このＴＣＵからアップロードされているが、データフレームの車両から異常検知サーバへのアップロードの形態はこれに限らない。例えば、車載ネットワークシステム内でより広範囲からデータフレームを受信するゲートウェイが受信したデータフレームのログが、異常検知サーバにアップロードされてもよい。また、このログ情報は、ゲートウェイから異常検知サーバにアップロードされてもよい。
【0143】
（８）上記の実施の形態では、ＥＣＵが車載ネットワークのデータフレームのログを定期的にアップロードしていたが、アップロードの機会又は頻度はこれに限定されない。車載ネットワークログは、例えば、異常検知サーバからの要求に応じてアップロードされてもよいし、車内に設置されたＩＤＳ（Intrusion Detection System）により異常が検知された場合のみアップロードされてもよい。ネットワークの混雑及び異常検知サーバの過負荷は、異常検知処理の遅滞を招き、その結果に基づく対応の遅延に繋がる。しかし、これにより、ネットワークの通信量の抑制及び異常検知サーバの処理負荷の抑制につながり、対応の遅延発生が抑制される。
【0144】
（９）上記の実施の形態では、異常検知サーバは、車両からアップロードされた車載ネットワークログが示すすべてのデータフレームを異常検知処理の対象としている、一部のデータフレームが対象であってもよい。例えば、特定のＩＤのデータフレームのみを異常検知処理の対象としてもよい。これにより、異常検知サーバでの処理負荷が抑制される。また、対象となるデータフレームのＩＤは、動的に切り替えられてもよい。これにより、異常検知サーバでの異常検知処理の負荷を抑制させつつ、すべてのＩＤのデータフレームに対し異常検知処理を実施することができ、安全性の維持と異常への対応の遅延回避とを、バランスを取りながら両立させることができる。
【0145】
（１０）上記の実施の形態では、車載ネットワークログをアップロードするＥＣＵは、所定の期間に受信したすべてのデータフレームのペイロード情報に基づくログ情報をアップロードしている、異常検知サーバにアップロードするログ情報をすべてのデータフレームのペイロード情報に基づくものでなくてもよい。アップロードされるログ情報は、例えば特定のＩＤのデータフレームのペイロード情報に基づくものであってもよい。これによりネットワークの通信量の抑制及び異常検知サーバの処理負荷の抑制につながる。また、アップロード対象となるデータフレームのＩＤは動的に切り替えられてもよい。これにより、異常検知サーバでの異常検知処理の負荷を抑制させつつ、すべてのＩＤのデータフレームに対して異常検知処理を実施することができ、安全性の維持と異常への対応の遅延回避とを、バランスを取りながら両立させることができる。
【0146】
（１１）上記の実施の形態では、異常検知サーバは、データフレームのペイロード値に対応する多次元の特徴量の全てを入力とした異常検知処理を行っていたが、入力する特徴量の次元を削減してもよい。例えば、ペイロードに含まれるカウンタ又はチェックサムのサブフィールドが既知の場合は、これらのサブフィールドに対応する特徴量を異常検知処理の入力から除外してもよい。これにより、不正な制御に直接的に影響のない部分を異常検知処理の対象から除外して計算量を削減し、かつ、適切に異常検知を実行することができる。
【0147】
（１２）上記の実施の形態では、異常検知サーバでは、攻撃種類がセンサ値偽装、状態値偽装、及びトライアル攻撃の３種類に分類している、攻撃の分類はこれらに限らない。例えば、同一データフレーム内に上記の複合的な攻撃が含まれるような分類が用いられてもよい。また、上記の実施の形態において、攻撃その他の異常種類の判定に用いられているペイロードの異常部分長の値は例であり、これに限定されない。なお、センサ値の異常の場合に異常部分長が取り得る範囲を第一範囲、状態値の異常の場合に異常部分長が取り得る範囲を第二範囲、トライアル攻撃による異常の場合に異常部分長が取り得る範囲を第三範囲とすると、第一範囲、第二範囲、第三範囲の順により長くなりやすいと考えられ、上記の例はこの考えを反映している。また、第一範囲、第二範囲及び第三範囲どうしは、必ずしも連続していなくてもよい。例えば第一範囲の上限は４ビットである場合に、第二範囲の下限は５ビットでなくてもよく、例えば８ビットであってもよい。これらの各範囲の上限および下限は、車載ネットワークシステムの設計、仕様又は準拠する規格等に基づいて導かれる取り得る値に定め得る。また、上記のような複合的な攻撃の発生を示すような異常部分長の範囲が用いられてもよい。
【0148】
（１３）上記の実施の形態では、異常検知サーバは、攻撃レベルを低、中、高と分類したが、分類方法はこれに限られない。例えば、より多段階のスコアが用いられてもよい。攻撃レベルのスコアは、例えば異常であると判定されたフレームのＩＤ、異常であると判定されたフレームのＩＤの個数（つまりデータフレームの種類数）、攻撃種類、又は異常部分長、ペイロードにおける異常部分の位置にそれぞれ基づくパラメータを含む所定の計算式を用いて算出されてもよい。これにより、発生した異常に対し、より細分化した危険度に応じて対応することが可能になり、解析の優先度付けをより的確に行うことができる。
【0149】
（１４）上記の実施の形態では、異常検知サーバは異常部分、すなわちペイロードの異常に寄与した部分の、ビット長に基づいて攻撃種類を判定しているが、攻撃種類の判定方法はこれに限らない。例えば、異常寄与度をさらに用いて攻撃種類を判定してもよい。また、異常寄与度を学習させた攻撃種類の分類器に、異常検知処理対象のデータフレームのペイロードについて算出した異常寄与度を入力して、攻撃種類を判定してもよい。また、ペイロードのサブフィールド情報を表したデータベースを保持しておき、異常部分とこのデータベースとを照らし合わせることで、攻撃種類を判定してもよい。
【0150】
（１５）上記の実施の形態では、使用されているリファレンスモデルは１つである例を示したがこれに限られない。例えば車両であれば、車種、年式、オプション構成、車載ネットワークシステムの構成等に応じた異なる正常モデルが用いられてもよい。
【0151】
（１６）上記の実施の形態では、リファレンスモデルは車両の正常走行時のデータの分布を示すモデルであるが、リファレンスモデルが示すのはこれに限らない。例えば、異常が発生していると既知の通信ネットワークシステムから収集されたデータに基づく、異常発生時のデータの分布を示すモデルであってもよい。
【0152】
（１７）上記の実施の形態では、異常検知サーバは、異常と判断されたデータフレームのＩＤの種類数、判定された攻撃種類、ペイロードにおける異常部分の位置に関する条件の組み合わせに基づいて攻撃レベルを判定していたが、これらすべての条件を用いずに攻撃レベルを判定してもよい。例えば、異常と判断されたＩＤの種類数が１つの場合は、常に攻撃レベルを中と判定してもよい。これにより、より柔軟に攻撃レベルの算出が可能となる。
【0153】
（１８）上記の実施の形態では、異常検知サーバは、密度比が所定の閾値を超えた場合に対応するフレームを異常であると判断するとしたが、所定の閾値は、リファレンスモデルの特徴量において密度比が最大となった時の値としてもよい。これにより、正常なフレームを誤って異常と判定する可能性が低くなり、解析コストの低減につながる。
【0154】
（１９）上記の実施の形態では、異常検知サーバはＩＤごとにペイロード値の分布をリファレンスモデルとして保持しているが、ＩＤごとに分けずにペイロード値の分布を保持していてもよい。これにより、リファレンスモデルのデータサイズを効果的に削減することができる。
【0155】
（２０）上記の実施の形態では、異常検知サーバに通知する車両ログは、ＣＡＮのフレームにかかわる情報であったが、異常検知サーバに通知する車両ログはこれに限らない。例えばＥｔｈｅｒｎｅｔのフレーム、ＣＡＮ－ＦＤフレーム、ＦｌｅｘＲａｙフレームであってもよいし、車載ネットワークフレームでなくてもよい。例えば、車両の現在位置を表すＧＰＳ情報、オーディオヘッドユニットへのアクセスログ、動作プロセスに関するログ、ファームウェアのバージョン情報等といった情報であってもよい。
【0156】
（２１）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭ又はハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【0157】
（２２）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【0158】
また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部又はすべてを含むように１チップ化されてもよい。
【0159】
また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
【0160】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0161】
（２３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【0162】
（２４）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。
【0163】
また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
【0164】
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【0165】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
【0166】
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号をネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【0167】
（２５）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
【産業上の利用可能性】
【0168】
本開示は、車載ネットワークシステム等の通信ネットワークシステムにおいて、例えば外れ値を含まない不正なフレームが攻撃者によって送信された場合も、当該フレームが異常であるか否か判定することができる。さらに、異常なフレームのペイロードのおける異常部分を算出し、この異常部分に基づいて、異常の種類及び以上のレベルといった内容を迅速に把握し、対処することができ、安全性の向上に効果的である。
【符号の説明】
【0169】
１０ 車両
２０ ネットワーク
６０ 異常検知サーバ
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１ 電子制御ユニット（ＥＣＵ）
１１０ エンジン
１１１ トランスミッション
２１０ ブレーキ
２１１ ステアリング
３１０ カメラ
３１１ カーナビゲーションシステム
３１２ テレマティクス制御ユニット（ＴＣＵ）
３３０、９１０ フレーム送受信部
３４０、９２０ フレーム解釈部
３５０ 外部機器制御部
３６０、９４０ フレーム生成部
３７０ 受信履歴保持部
３８０ サーバ通信部
４１０ ドア
４１１ ライト
５１０ 診断ポート
６１０ 通信部
６２０ 異常検知部
６３０ 異常部分特定部
６４０ 攻撃種類判定部
６５０ 攻撃レベル判定部
６６０ 結果出力部
６７０ リファレンスモデル保持部
６８０ 攻撃種類判定テーブル
６９０ 攻撃レベル判定テーブル
９００ ゲートウェイ
９３０ 転送制御部
９５０ 転送ルール保持部
１０００、２０００、３０００、４０００、５０００ バス
２０ ネットワーク
６０ 異常検知サーバ
１００、１０１、２００、２０１、３００、３０１、３０２、４００、４０１ 電子制御ユニット（ＥＣＵ）
１１０ エンジン
１１１ トランスミッション
２１０ ブレーキ
２１１ ステアリング
３１０ カメラ
３１１ カーナビゲーションシステム
３１２ テレマティクス制御ユニット（ＴＣＵ）
３３０、９１０ フレーム送受信部
３４０、９２０ フレーム解釈部
３５０ 外部機器制御部
３６０、９４０ フレーム生成部
３７０ 受信履歴保持部
３８０ サーバ通信部
４１０ ドア
４１１ ライト
５１０ 診断ポート
６１０ 通信部
６２０ 異常検知部
６３０ 異常部分特定部
６４０ 攻撃種類判定部
６５０ 攻撃レベル判定部
６６０ 結果出力部
６７０ リファレンスモデル保持部
６８０ 攻撃種類判定テーブル
６９０ 攻撃レベル判定テーブル
９００ ゲートウェイ
９３０ 転送制御部
９５０ 転送ルール保持部
１０００、２０００、３０００、４０００、５０００ バス
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】