JP7354137B2 - 脅威分析装置、脅威分析方法、および、プログラム - Google Patents

Description

本発明は、脅威分析装置、脅威分析方法、および、プログラムに関する。

車両などに対してなされるサイバー攻撃の分析の効率化のために、標準化されたフォーマットであるSTIX（Structured Threat Information eXpression）を活用する技術がある（特許文献１参照）。

特開２０１８－３２３５４号公報

しかしながら、車両などに対する新たな脅威が出現した場合に、新たな脅威を分析するまでに時間を要するという問題がある。なお、この問題は、車両に限らず、広くＩｏＴ（Internet of Things）デバイスにおいて起こり得る。

そこで、本発明は、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮する脅威分析装置を提供する。

本発明の一態様に係る脅威分析装置は、ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理部と、サイバー攻撃の脅威情報を格納する脅威情報管理部と、前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理部と、前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理部と、前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新部と、前記関連脅威情報管理部が管理する前記関連脅威情報を出力する出力部と、を備える。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明の脅威分析装置は、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

図１は、実施の形態１における脅威分析システムの構成を示す模式図である。 図２は、実施の形態１におけるＳＴＩＸで記述した脅威情報の一例を示す説明図である。 図３は、実施の形態１における脅威情報の交換手順を示すシーケンス図である。 図４は、実施の形態１における脅威情報分析サーバーの構成を示す説明図である。 図５は、実施の形態１におけるリスクレベル管理部が保持する機能別リスクレベルテーブルの一例を示す説明図である。 図６は、実施の形態１におけるリスクレベル管理部が保持する関連ＥＣＵ別リスクレベルテーブルの一例を示す説明図である。 図７は、実施の形態１におけるリスクレベル管理部が保持するアプリケーション権限別リスクレベルテーブルの一例を示す説明図である。 図８は、実施の形態１における脅威情報管理部が保持する脅威情報データベースの一例を示す説明図である。 図９は、実施の形態１における関連脅威情報管理部が保持するモデル別関連脅威情報データベースの一例を示す説明図である。 図１０は、実施の形態１における更新により機能追加された後のモデル別関連脅威情報データベースの一例を示す説明図である。 図１１は、実施の形態１における、機能追加の際の車種別の関連脅威情報が更新される処理を示すシーケンス図である。 図１２は、実施の形態１における、機能追加の際の関連脅威情報が更新される処理を示すシーケンス図である。 図１３は、実施の形態１における機能追加される更新前の関連脅威情報出力画面の一例を示す説明図である。 図１４は、実施の形態１における機能追加された更新後の関連脅威情報出力画面の一例を示す説明図である。 図１５は、実施の形態２における更新により機能追加される場合の車両別の関連脅威情報が更新される処理を示すシーケンス図である。 図１６は、実施の形態２における車両別の関連脅威情報データベースの一例を示す説明図である。 図１７は、実施の形態２における車両別の関連脅威情報出力画面の一例を示す説明図である。

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、サイバー攻撃に関し、以下の問題が生じることを見出した。

近年、ネットワークに接続された自動車であるコネクテッドカーの分野において、自動車に搭載されたソフトウェアを無線で更新するOTA(Over the Air)機能が搭載され始めている。このようなOTAを活用することで、自動車メーカーは、リコール費用を大幅に削減できる利点がある。また、自動車メーカーは、サイバー攻撃に関する対応時間を短縮し、品質の運用効率を向上させるだけでなく、出荷後に車両性能の機能を強化することが可能となっている。

一方で、自動車がインターネットに接続されると、パソコン等と同様に自動車へのサイバー攻撃のリスクが高まる。特に、車載システムにLinux（登録商標）を始めとするオープンソースソフトウェアが採用されたり、電動化又は高機能化に伴いソフトウェア規模が拡大されたりすることにより、出荷前に脆弱性を完全になくすことが難しく、出荷後に脆弱性をついてサイバー攻撃されることが問題となっている。

脆弱性が発見されても、その対策を車両に反映させるためには時間がかかる。対策が反映されるまでの間は、サイバー攻撃を受ける可能性があるので、対策が反映されるまでの時間を短縮することが重要となる。

新たに発見されるサイバー攻撃であっても、既知の脆弱性又は攻撃手法を利用されることがあるので、攻撃の分析には、過去の攻撃事例又は対策案を参照することが有効である。こうしたことから、サイバー攻撃の分析を効率化するために、過去のサイバー攻撃の活動を、標準化されたフォーマットであるSTIX（Structured Threat Information eXpression）で記述し、脅威情報を交換する仕様が規定されている。

STIXを活用して、類似するサイバー攻撃を提供して、攻撃を分析する方法がある（特許文献１）。しかしながら、特許文献１では、OTAにより車両の機能が更新された際に、更新された機能に関して脅威情報を迅速に提示することができない。

一方、コネクテッドカーにおけるソフトウェア更新機能により、出荷後に強化される機能は、注目されやすく、攻撃の対象になりやすい。また、攻撃は、過去の脆弱性や攻撃手法を利用するケースも多い。

そこで、本発明では、ソフトウェア更新により追加された新機能に関連する過去の脅威情報を関連付けて、脅威分析を行うセキュリティ分析官に迅速に提示する。このようにすることで、ソフトウェア更新により追加された新機能へのサイバー攻撃を検知した場合に、新機能に関連づけられた脅威情報を参照して攻撃分析することで、分析の効率化を図り、攻撃発見から対策までの時間を短縮することを目的とする。

本発明の一実施態様に係る脅威分析装置は、ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理部と、サイバー攻撃の脅威情報を格納する脅威情報管理部と、前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理部と、前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理部と、前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新部と、前記関連脅威情報管理部が管理する前記関連脅威情報を出力する出力部と、を備える。

上記態様によれば、脅威分析装置は、ＩｏＴデバイスのソフトウェア更新により追加された機能に関連した脅威情報を、過去の脅威情報を検索して関連付けて出力する。分析官は、出力された、追加された機能に関連した脅威情報と、それに関連付けられた過去の脅威情報とに基づく分析をすることができる。このように、ソフトウェア更新により追加された機能がサイバー攻撃の対象となった際に、攻撃の分析を効率化し、サイバー攻撃の発生からその対策を講じるまでの時間を大幅に削減することが可能となる。よって、脅威分析装置は、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。また、上記時間を短縮することができれば、脅威分析装置が稼働するための電力を削減する効果も得られる。

例えば、前記ＩｏＴデバイスは、モビリティデバイスであり、前記脅威分析装置は、さらに、前記脅威情報を交換する脅威情報交換処理部を備えてもよい。

上記態様によれば、脅威分析装置は、ＩｏＴデバイスとして、コネクテッドカーを始めとする自動車、建機、または農機などのモビリティデバイスのソフトウェア更新に関して、新たな脅威の分析に要する時間を短縮できる。

例えば、前記リスクレベルは、モビリティ制御に関連する機能ごとに定義されていてもよい。

上記態様によれば、脅威分析装置は、走る、曲がる、止まるといった車両の制御ごとにリスクレベルを定義でき、自動運転レベルに合わせたリスクレベルも設定可能となる。よって、脅威分析装置は、車両の制御ごとに定義したリスクレベルを用いてより容易に、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記リスクレベルは、モビリティ制御メッセージを送受信する電子制御ユニットの関係に基づいて定義されていてもよい。

上記態様によれば、モビリティデバイスの制御を司る電子制御ユニット（ＥＣＵ）ごとにリスクレベルを設定することが可能となる。例えば複数の制御を司るＥＣＵのリスクレベルを高く設定することも可能となる。また、ＥＣＵが採用しているハードウェアセキュリティモジュールのレベルごとに設定が可能となる。また、ＥＣＵサプライヤごとにリスクレベルも設定可能となる。よって、脅威分析装置は、ＥＣＵごとに定義したリスクレベルを用いてより容易に、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記リスクレベルは、モビリティ制御を行うアプリケーションに対応した権限の個数に応じて定義されていてもよい。

上記態様によれば、サービスオリエンテッドアーキテクチャにおけるアプリケーションごとにリスクレベルが可能となる。特に、車載向けＯＳのアプリケーションでは、機能をサービスとして提供し、それぞれのアプリケーションがどのサービスを利用するかはマニフェストファイルに定義されるため、アプリケーションに付与されるマニフェストファイルごとにリスクレベルを定義することが可能となる。よって、脅威分析装置は、アプリケーションに対応した権限の個数ごとに定義したリスクレベルを用いてより容易に、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記関連脅威情報は、車種ごとに管理されていてもよい。

上記態様によれば、車種ごとに関連する脅威情報を提示することが可能となり、セキュリティ分析も効率化される。よって、脅威分析装置は、車種ごとに管理されている関連脅威情報を用いて、より容易に、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記関連脅威情報は、車両ごとに管理されていてもよい。

上記態様によれば、同一車種（モデル）においても、更新タイミングが異なる車両においても、個別の車両の更新状況に応じた関連脅威情報の提示が可能となり、より柔軟で効率的なセキュリティ分析が可能となる。よって、脅威分析装置は、車両ごとに管理されている関連脅威情報を用いて、より容易に、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記リスクレベル更新部は、前記ＩｏＴデバイスの前記機能追加の完了前に、前記関連脅威情報を更新してもよい。

上記態様によれば、ＩｏＴデバイスによるソフトウェア更新の直後から、更新される機能に関連する脅威情報を提示することが可能となり、更新直後に、新機能に対してサイバー攻撃が発生したとしても効率的に攻撃分析が可能となる。よって、脅威分析装置は、ＩｏＴデバイスによるソフトウェア更新の直後から、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、前記リスクレベル更新部は、所定の台数の前記ＩｏＴデバイスの前記機能追加の完了後に、前記関連脅威情報を更新してもよい。

上記態様によれば、新機能に対する脅威情報の提示のタイミングを柔軟に設定することが可能となる。具体的には、所定の台数の車両でソフトウェアの動作の試行のあとに、新機能に対する脅威情報の提示をすることが可能となる。よって、柔軟に設定したタイミングを利用して、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮することができる。

例えば、さらに、前記リスクレベル更新部によって前記関連脅威情報が更新された場合に、更新後の前記関連脅威情報に基づいて車両に制御信号を送信する車両制御部を備えてもよい。

上記態様によれば、更新したあとの関連脅威情報を用いて車両を制御することができる。よって、脅威分析装置は、新たな脅威からの攻撃が発見されてから新たな脅威を分析するとともに車両を制御するまでに要する時間を短縮することができる。

また、本発明の一実施態様に係る脅威分析方法は、ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理ステップと、サイバー攻撃の脅威情報を格納する脅威情報管理ステップと、前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理ステップと、前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理ステップと、前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新ステップと、前記関連脅威情報管理ステップで管理する前記関連脅威情報を出力する出力ステップと、を含む。

これにより、上記脅威分析装置と同様の効果を奏する。

また、本発明の一実施態様に係るプログラムは、上記の脅威分析方法をコンピュータに実行させるためのプログラムである。

これにより、上記脅威分析装置と同様の効果を奏する。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
本実施の形態において、新たな脅威からの攻撃が発見されてから新たな脅威を分析するまでに要する時間を短縮する脅威情報分析システムについて説明する。脅威情報分析システムは、脅威分析装置に相当する。

本実施の形態では、ソフトウェア更新機能により、車両に機能が追加された場合に、予め決められたリスクレベルに基づき、車両ごとに追加された機能に関連する脅威情報を表示する例について、以下図面を用いて説明をする。

なお、車両は、モビリティデバイスの一例であり、また、ＩｏＴデバイスの一例である。

＜脅威情報分析システムの構成＞
図１は、本実施の形態における脅威情報分析システム１の構成を示す模式図である。

図１に示されるように、脅威情報分析システム１は、脅威情報分析サーバー１０と、脅威情報管理サーバー２０と、更新サーバー３０と、車両５０ａ、５０ｂ、５０ｃ、５０ｄ、５０ｅおよび５０ｆとを備える。上記装置および車両のそれぞれは、ネットワーク４０を介して接続される。

脅威情報管理サーバー２０は、脅威情報１００を管理しているサーバーである。

脅威情報分析サーバー１０は、車両５０ａ～車両５０ｆへのセキュリティ監視を行うセキュリティオペレーションセンターのサーバーとして機能する。車両５０ａ～車両５０ｆに異常が検出されると、車両５０ａ～車両５０ｆは、脅威情報分析サーバー１０に異常を通知し、さらには定期的もしくはイベント的に車両のセキュリティ状態を通知する。

脅威情報管理サーバー２０は、車両５０ａ～車両５０ｆから受信した情報を用いて車両５０ａ～車両５０ｆへのサイバー攻撃を分析するＳＩＥＭ（Ｓｅｃｕｒｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｅｖｅｎｔ Ｍａｎａｇｅｍｅｎｔ）機能を備える。脅威情報分析サーバー１０は、新たに発生したサイバー攻撃を分析するために、過去の脆弱性又は攻撃手順などが記録された脅威情報１００を参照する。脅威情報１００は、脅威情報分析サーバー１０が、脅威情報管理サーバー２０から受信する。

更新サーバー３０は、出荷後の車両５０ａ～車両５０ｆのセキュリティレベルを維持するための脆弱性を修正したソフトウェアを配信する機能、および、車両５０ａ～車両５０ｆの機能追加または性能向上のためのソフトウェアを配信する機能を備える。

ネットワーク４０は、Ｗｉ－Ｆｉ等を含むローカルエリアネットワーク、携帯電話のキャリアネットワーク、およびインターネットなどを含むネットワークである。

＜脅威情報＞
図２は、本実施の形態におけるＳＴＩＸで記述した脅威情報の一例である脅威情報１００を示す説明図である。図２に示される脅威情報１００は、脅威情報管理サーバー２０が管理する脅威情報を示している。ＳＴＩＸで記述した脅威情報は、ＳＴＩＸ＿Ｐａｃｋａｇｅともよばれる。

サイバー攻撃活動の分析には、攻撃者（つまり、サイバー攻撃に関与している人または組織）、攻撃者の行動または手口、狙っている脆弱性などのように、攻撃者側の側面から状況をまとめる必要がある。また、サイバー攻撃活動の分析には、サイバー攻撃を検知するための兆候、サイバー攻撃によって引き起こされる問題、または、サイバー攻撃に対処するためにとるべき措置などのように、防護側の側面から状況をまとめる必要がある。

脅威情報１００は、これらの関連する情報を標準化された方法で記述し、サイバー空間における脅威やサイバー攻撃の分析、サイバー攻撃を特徴づける事象の特定、サイバー攻撃活動の管理、サイバー攻撃に関する情報を共有するために開発されたＳＴＩＸ（Structured Threat Information eXpression）で記述される。図２は、ＳＴＩＸのバージョン１のフォーマットで脅威情報１００が記述されたものである。

脅威情報１００は、サイバー攻撃活動(Campaigns)、攻撃者(Threat_Actors)、攻撃手口(TTPs)、検知指標(Indicators)、観測事象(Observables)、インシデント(Incidents)、対処措置(Courses_Of_Action)、および、攻撃対象(Exploit_Targets)の８つの情報群を含んで構成されている。図２では、例として、サイバー攻撃活動(Campaigns)のフィールドからリンク可能な各情報フィールドを矢印で表している。

脅威情報１００は、ＳＴＩＸ＿Ｈｅａｄｅｒのフィールド１０１と、Ｒｅｌａｔｅｄ＿Ｐａｃｋａｇｅｓの付属情報についてのフィールド１１０と、上記のサイバー攻撃活動に関連する各項目の情報についてのフィールド１０２～１０９とを有する。

例として、サイバー攻撃活動（Campaigns）のフィールド１０８は、各項目のフィールド（１０３、１０４、１０６、１０９および１１０）にリンクされている。

サイバー攻撃活動（Campaigns）のフィールド１０８には、該当するサイバー攻撃活動における意図または攻撃活動の状態などが記述される。具体的には、フィールド１０８には、サイバー攻撃活動または攻撃者の意図（Intended_Effect）の情報が個別に記述される。また、フィールド１０８には、攻撃活動状態（campaign:Status）が個別に記述される。

攻撃者（Threat_Actors）のフィールド１０９には、サイバー攻撃の攻撃者のタイプ、攻撃者の動機、攻撃者の熟練度、または、攻撃者の意図などの視点からサイバー攻撃に寄与している人もしくは組織についての情報が個別に記述される。例えば、フィールド１０９には、不正アクセス元（言い換えれば送信元）のＩＰアドレス、またはメールアドレス、ソーシャルネットワークサービスのアカウントの情報が記述される。

攻撃手口（TTPs）のフィールド１０４には、攻撃のパターン、攻撃者が用いたマルウェアまたはツールなどのリソース、攻撃者の攻撃基盤、もしくは攻撃対象についての情報が個別に記述される。なお、攻撃のパターン（ttp:Attack_Pattern）は、ＣＡＰＥＣ（Common Attack Pattern Enumeration and Classification：共通攻撃パターン一覧）を使用して記述される。例えば、フィールド１０４には、サイバー攻撃に関与した情報処理装置に割り当てられたＩＰアドレス、情報処理装置からのアクセス先の少なくともいずれかの情報が記述される。

検知指標（Indicators）のフィールド１０３には、サイバー攻撃イベントを特徴づける指標を示す情報が個別に記述される。例えば、フィールド１０３では、検知指標のタイプ、検知指標に関連する観測事象、攻撃段階フェーズ、痕跡などから検知指標を作成するために使用したツールと共に、サイバー攻撃を特徴づける指標について記述される。

観測事象（Observables）のフィールド１０２には、サイバー攻撃イベントによって観測された動作に関わる事象を示す情報が個別に記述される。例えば、フィールド１０２には、サイバー攻撃によって観測された事象として、ファイル名、ハッシュ値もしくはファイルサイズ、レジストリの値、稼働中のサービス、または、ＨＴＴＰ要求などが記述される。また、記述には、サイバー攻撃の観測事象を記述するための仕様であるＣｙｂＯＸ（Cyber Observable eXpression）が使用される。

インシデント（Incidents）のフィールド１０６には、どのようなインシデントなのかという分類、インシデントの関与者（具体的には報告者、対応者、調整者または被害者）、インシデントによる被害を受けた資産（具体的には所有者、管理者または場所）、インシデントによる直接的または間接的な影響、インシデント対処の状況などの視点から、サイバー攻撃によって発生した事案の情報が個別に記述される。例えば、フィールド１０６には、サイバー攻撃の攻撃者により被害を受けた資産の所有者または管理者、資産の場所の情報が個別に記述される。

対処措置（Courses_Of_Action）のフィールド１０７には、対処措置の状況、対処措置のタイプ、対処措置の目的、影響、費用または有効性などの視点から、サイバー攻撃イベントによる脅威に対処するための処置を示す情報が個別に記述される。

攻撃対象（Exploit_Targets）のフィールド１０５には、脆弱性、脆弱性の種類、設定や構成などの視点から、攻撃の対象となりうるソフトウェアやシステムの弱点など、サイバー攻撃イベントにおいて攻撃の対象となる資産の弱点を示す情報が個別に記述される。例えば、フィールド１０５では、脆弱性を記述するためにＣＶＥ（Common Vulnerability and Exposures：共通脆弱性識別子）を使用する。また、フィールド１０５では、脆弱性の種類を記述するためにＣＷＥ（Common Weakness Enumeration：共通脆弱性タイプ一覧）を使用する。また、フィールド１０５では、設定上のセキュリティ問題を記述するためにＣＣＥ（Common Configuration Enumeration：共通セキュリティ設定一覧）を使用する。

本実施の形態の脅威情報１００はＳＴＩＸのフォーマットで説明をしたが、ＳＴＩＸのフォーマットに限定される必要はなく、他のフォーマットを利用してもよい。

＜脅威情報１００交換シーケンス＞
図３は、本実施の形態における脅威情報の交換手順を示すシーケンス図である。図３には、脅威情報分析サーバー１０が、脅威情報管理サーバー２０から脅威情報１００を収集するときの手順が示されている。

ステップＳ１０１において、脅威情報分析サーバー１０は、脅威情報管理サーバー２０にアクセスする。具体的には、脅威情報分析サーバー１０は、脅威情報リクエストを脅威情報管理サーバー２０に送信する。脅威情報管理サーバー２０は、送信された脅威情報リクエストを受信する。

ステップＳ１０２において、脅威情報管理サーバー２０は、ステップＳ１０１で脅威情報リクエストを受信したことに応じて、脅威情報１００を脅威情報分析サーバー１０に送信する。脅威情報分析サーバー１０は、送信された脅威情報１００を受信する。

ステップＳ１０３において、脅威情報分析サーバー１０は、ステップＳ１０２で受信した脅威情報１００を脅威情報管理部４００に保存する。

ここで、ステップＳ１０１及びＳ１０２において、例えば、脅威情報の交換手順として規定されているＴＡＸＩＩ（Trusted Automated eXchange of Indicator Information）プロトコルに従って脅威情報が交換される。この交換シーケンスは、定期的に行われてもよいし、脅威情報が新たに登録されたときに行われるようにしてもよい。本実施の形態の脅威情報の交換手順は、ＴＡＸＩＩを用いるとして説明するが、ＴＡＸＩＩプロトコルに限定される必要はなく、他の通信プロトコルを用いてもよい。

＜脅威情報分析サーバー１０＞
図４は、脅威情報分析サーバー１０の構成を示す説明図である。

図４に示されるように、脅威情報分析サーバー１０は、脅威情報交換処理部２００、更新管理部２１０、リスクレベル更新部２２０、出力部２３０、車両制御部２４０、リスクレベル管理部３００、脅威情報管理部４００、および関連脅威情報管理部５００を含んで構成される。

脅威情報交換処理部２００は、脅威情報を交換する処理部である。具体的には、脅威情報交換処理部２００は、図３で示したＴＡＸＩＩプロトコルに従って、脅威情報管理サーバー２０から脅威情報１００を取得する。

更新管理部２１０は、更新サーバー３０から、出荷後の車両５０ａ～車両５０ｆのセキュリティレベルを維持するための脆弱性を修正したソフトウェアを受信する。また更新管理部２１０は、車両５０ａ～車両５０ｆの機能追加又は性能向上のためのソフトウェアの配信の状況、更新したソフトウェア、および車両機能の情報を受信する。また、更新管理部２１０は、更新サーバー３０から受信した情報を、リスクレベル管理部３００へ提供する。

リスクレベル更新部２２０は、更新情報に基づいて、脅威情報と車両のリスクレベルとの関連づけを行い、関連脅威情報を更新する処理部である。リスクレベル更新部２２０は、具体的には、更新管理部２１０から受信した情報に基づき、リスクレベル管理部３００に保存されているリスクレベルテーブル３１０を更新する。また、リスクレベル更新部２２０は、更新管理部２１０から受信した更新内容に関連する脅威情報１００が、脅威情報管理部４００で管理されている脅威情報データベース４１０に含まれているか否かを判定する。リスクレベル更新部２２０は、更新内容に関連する脅威情報１００が脅威情報データベース４１０に含まれていると判定した場合、リスクレベルテーブル３１０に基づき、関連脅威情報管理部５００が保持するモデル別関連脅威情報データベース５１０を更新する。詳細シーケンスは、後述する。

リスクレベル管理部３００は、車両のリスクレベルが定義されたリスクレベルテーブルを管理する。リスクレベルテーブルは、車両のモビリティ制御に関連する機能ごとに定義されてもよいし、モビリティ制御メッセージを送受信するＥＣＵ（Electronic Control Unit、電子制御ユニット）ごとに定義されてもよいし、モビリティ制御を行うアプリケーションに対応した権限の個数に応じて定義されてもよい。上記のように定義されたリスクレベルテーブルについては、あとで詳しく説明する。なお、リスクレベルテーブルは、ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報の一例である。

脅威情報管理部４００は、脅威情報データベース４１０を保持する。脅威情報データベース４１０は、サイバー攻撃の脅威情報に相当する。

関連脅威情報管理部５００は、脅威情報と、車両にリスクレベルを関連づけた関連脅威情報とを管理する。関連脅威情報管理部５００は、具体的には、モデル別関連脅威情報データベース５１０を保持し管理する。

出力部２３０は、モデル別関連脅威情報データベース５１０の内容を出力することによって、脅威情報分析サーバー１０を使ってサイバー攻撃を分析するセキュリティ分析官に提示する。例えば、出力部２３０は、表示画面を備え、車種モデルごとに関連する脅威情報をわかりやすく表示することによって、モデル別関連脅威情報データベース５１０の内容をセキュリティ分析官に提示する。

車両制御部２４０は、関連脅威情報に基づいて車両に制御信号を送信する処理部である。より具体的には、車両制御部２４０は、リスクレベル更新部２２０によって関連脅威情報が更新された場合に、更新後の関連脅威情報に基づいて車両に制御信号を送信する。制御方信号は、例えば、脅威によって攻撃され得るソフトウェアを車両において稼働させない制御、又は、脅威によって攻撃され得るソフトウェアであることを示すメッセージを車両のドライバに提示する制御などに係る制御信号である。

＜機能別リスクレベルテーブル＞
図５は、本実施の形態におけるリスクレベル管理部３００が保持する機能別リスクレベルテーブルの一例を示す説明図である。

図５は、リスクレベルテーブル３１０の一例であり、車両が備える機能別にリスクレベルを定義した機能別リスクレベルテーブル３１１である。

機能別リスクレベルテーブル３１１は、自動運転レベル、車両が備える機能、その機能についてのリスクレベルを含んで構成される。ここで、自動運転レベルとは、車両の自動化の程度（レベル）を示す一般の指標である。

図５では、自動運転レベルそれぞれに対応して定められる、車両が備える機能ごとにリスクレベルが定義されている。

自動運転レベル０に対応する機能は、例えば、死角検知機能を含む。なお、自動運転レベルが０である車両は、ドライバーが常時全ての運転操作を行い、自動運転システムが車両の制御に介入することはない。

自動運転レベル１に対応する機能は、例えば、アダプティブクルーズコントロール（ＡＣＣ）、車線逸脱防止、自動ブレーキなどの機能を含む。なお、自動運転レベル１は、ステアリング操作と加減速とのいずれかを自動運転システムがサポートする自動運転レベルである。

自動運転レベル２に対応する機能は、例えば、渋滞追従、駐車支援、自動車線変更、割り込み減速、車線中央維持などの機能を含む。なお、自動運転レベル２は、ステアリング操作と加減速との両方を自動運転システムがサポートする自動運転レベルである。

自動運転レベル３に対応する機能は、例えば、高速追従、追い越し、合流・分岐、急カーブ自動走行、本線離脱、緊急路肩退避、または、自動駐車などの機能を備える。なお、自動運転レベル３は、特定の場所で全ての操作が自動運転システムによって自動化される自動運転レベルである。ただし緊急時はドライバーによる操作が要求される。

自動運転レベル４に対応する機能は、例えば、信号停止・発進、歩行者・自転車回避、障害物回避、必要に応じた徐行、交差点の右左折・停止・進入、標識に従った走行、対向車両の回避、大型車両識別判断、または、狭路走行などの機能を含む。なお、自動運転レベル４は、特定の場所で全ての操作が自動運転システムによって自動化される自動運転レベルである。緊急時の対応も自動化される。

自動運転レベル５に対応する機能は、例えば、信号停止・発進、歩行者・自転車回避、障害物回避、必要に応じた徐行、交差点の右左折・停止・進入、標識に従った走行、対向車両の回避、大型車両識別判断、または、狭路走行などの機能を含む。なお、自動運転レベル５は、あらゆる状況下において操作が自動運転システムによって自動化される自動運転レベルである。

なお、車両は、当該車両の自動運転レベル以下の自動運転レベルに対応する機能も有する。言い換えれば、自動運転レベルがＮ（ただしＮ＝０～５）である車両は、自動運転レベルＮ以下に対応する機能を有する。

このように、自動運転のレベルが上がるほど、自動運転システムによって制御される範囲が広がり、つまり、車両が備える機能が増える。そのため、自動運転レベルが高いほど、リスクレベルが高く設定されている。

図５では、自動運転レベル０に対応する機能がリスクレベル１と設定され、自動運転レベル１に対応する機能がリスクレベル２と設定され、自動運転レベル２に対応する機能がリスクレベル３と設定され、自動運転レベル３に対応する機能がリスクレベル４と設定され、自動運転レベル４に対応する機能がリスクレベル５と設定され、自動運転レベル５に対応する機能がリスクレベル６と設定されている。

なお、自動運転レベルが同じものは、同じリスクレベルを設定しているが、同じレベル内であっても機能ごとにリスクレベルを変えてもよい。

＜関連ＥＣＵ別リスクレベルテーブル＞
図６は、本実施の形態におけるリスクレベル管理部３００が保持する関連ＥＣＵ別リスクレベルテーブルの一例を示す説明図である。

図６は、リスクレベルテーブル３１０の一例であり、車載ネットワークシステムに搭載されるＥＣＵ別にリスクレベルを定義した関連ＥＣＵ別リスクレベルテーブル３１２である。

関連ＥＣＵ別リスクレベルテーブル３１２は、ＥＣＵメーカー、ＥＣＵ識別情報、ＥＣＵのソフトウェアバージョン、メッセージを送受信する関係にあるＥＣＵの情報、カメラ／センサー／カメラの利用可否状況、ＥＣＵごとのリスクレベルが定義される。なお、メッセージを送受信する関係にあるＥＣＵを、「関連するＥＣＵ」とも表現する。

例えば、図６ではＥＣＵメーカーＡのＥＣＵ＿Ａ１は、ＡＣＣソフトウェアのバージョンが１．０であり、ＥＣＵ＿Ｂ１とメッセージを送受信する関係にあり、機能実現のためにカメラとレーダーの情報を使うことを示している。

また、ＥＣＵ＿Ａ３については、２つのバージョンそれぞれについてリスクレベルが定義される。具体的には、ＥＣＵ＿Ａ３のソフトウェアバージョン１．０では、ＥＣＵ＿Ａ２とメッセージを送受信する関係にあり、車両は、駐車支援機能を有する。ＥＣＵ＿Ａ３のソフトウェアバージョン２．０では、ＥＣＵ＿Ａ１ともメッセージを送受信する関係にあり、車両は、駐車支援機能に加えて自動駐車機能を有する。

機能が追加されれば、メッセージを送受信するＥＣＵ、つまり、関連するＥＣＵが増えることになる。メッセージ送受信するＥＣＵの増加は、１つのＥＣＵの脆弱性が、送受信を行うＥＣＵにもリスクを与える危険性があることになる。そのため、関連するＥＣＵが多いほど、リスクレベルが高く設定されている。

＜アプリケーション権限別リスクレベルテーブル＞
図７は、本実施の形態におけるリスクレベル管理部３００が保持するアプリケーション権限別リスクレベルテーブルの一例を示す説明図である。

図７は、リスクレベルテーブル３１０を車両に実装されるアプリケーションの権限別にリスクレベルを定義したアプリケーション権限別リスクレベルテーブル３１３である。アプリケーション権限別リスクレベルテーブル３１３は、アプリケーションサプライヤ名、アプリケーションＩＤ、ソフトウェアバージョン、アプリケーションが備える機能、アプリケーションが保有する機能又はデバイスに対するアクセス権限情報、および、リスクレベルを含んで構成される。

例えば、図７ではサプライヤＡのアプリＡ３のソフトウェアバージョン１．０は、ステアリング操作、アクセル操作、カメラ、レーザーへのアクセス権限情報を保持しており、また、駐車支援機能をサポートしている。

また、アプリＡ３のソフトウェアバージョン２．０は、駐車支援機能だけでなく、ブレーキ操作の権限情報を保持しており、自動駐車機能が追加されたことを示している。

アプリケーションの、機能又はデバイスに対するアクセス権限が追加されれば、車両の制御範囲が広がることになる。アプリケーションのアクセス権限の増加は、１つのアプリケーションの脆弱性が、車両制御へ与えるリスクを広げることになるので、アクセス権限の個数が多いほど、リスクレベルが高く設定されている。

＜脅威情報データベース４１０＞
図８は、本実施の形態における脅威情報管理部４００が保持する脅威情報データベースの一例としての脅威情報データベース４１０を示した説明図である。

脅威情報管理部４００は、脅威情報交換処理部２００で取得した脅威情報１００を保存する。

脅威情報データベース４１０は、脅威情報１００に示される各脅威情報が、車両が備える機能、ＥＣＵまたはアプリケーションに関連した脅威であるか否かを示すテーブルである。例えば、ＥＣＵ＿Ａ３およびアプリＡ３は、脅威情報ＩＤ００３、０１０および０２０に関連することが示されている。ＥＣＵ＿Ａ３およびアプリＡ３は、駐車支援と自動駐車支援機能とを有するからである。

＜モデル別関連脅威情報データベース（更新前）＞
図９は、関連脅威情報管理部５００が保持するモデル別関連脅威情報データベースの一例として、モデル別関連脅威情報データベース５１０を示す説明図である。

モデル別関連脅威情報データベース５１０は、車種モデル別に脅威情報とそのリスクレベルを管理しているテーブルである。

具体的には、モデル別関連脅威情報データベース５１０は、カーメーカー、車種情報、機能情報、その機能を制御するＥＣＵ ＩＤ、リスクレベル、ＥＣＵに関連する脅威情報のＩＤを含んで構成される。

図９は、図６の関連ＥＣＵ別リスクレベルテーブル３１２に基づいて、車両ごとにリスクレベルを設定された例を示している。例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ１は、ＡＣＣ機能を有しており、ＡＣＣ機能のリスクレベルは２であり、ＡＣＣもしくはＥＣＵ＿Ａ１に関連する脅威情報は、脅威情報００１であることを示している。

また、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３は駐車支援機能を有しており、駐車支援機能のリスクレベルは３であり、駐車支援機能もしくはＥＣＵ＿Ａ３に関連する脅威情報は、脅威情報００３であることを示している。

＜モデル別関連脅威情報データベース（更新後）＞
図１０は、本実施の形態における更新により機能追加された後のモデル別関連脅威情報データベースの一例として、モデル別関連脅威情報データベース５１０Ａを示す説明図である。

車両の機能が追加され、追加された機能に関連する機能が存在する場合は、追加機能に関する脅威情報がモデル別関連脅威情報データベース５１０に追加されて、モデル別関連脅威情報データベース５１０Ａとなる。

図１０は、カーメーカーＯＥＭ＿Ａの車種モデルＡ１の駐車支援機能を有しているＥＣＵ＿Ａ３に、ソフトウェア更新により、新たに自動駐車機能が追加された場合におけるモデル別関連脅威情報データベース５１０Ａを示している。ＥＣＵ＿Ａ３の自動駐車機能のリスクレベルが４であり、ＥＣＵ＿Ａ３あるいは自動駐車機能に関連する脅威情報として、新たに脅威情報０１０と０２０とが追加されたことを示している。

＜更新シーケンス＞
図１１と図１２は、車両５０ａ～車両５０ｆに搭載されるソフトウェアをＯＴＡで更新し、機能を追加する際のシーケンスを示す説明図である。ここでは、カーメーカーＯＥＭ＿ＡのモデルＡ１車種のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加されるケースを例として説明する。

より具体的には、図１１は、本実施の形態における、機能追加の際の車種別の関連脅威情報が更新される処理を示すシーケンス図である。図１２は、本実施の形態における、機能追加の際の関連脅威情報が更新される処理を示すシーケンス図である。

図１１に示されるように、ステップＳ２０１において、更新サーバー３０に、更新すべき対象ソフトおよび更新機能に関する情報が登録される。例えば、ＥＣＵ＿Ａ３の新しいソフトウェアが登録される。その際、更新機能情報として、配信先対象となるカーメーカーの情報、車種情報、追加機能情報、更新対象となるＥＣＵ情報（ＥＣＵのＩＤ、ハードウェアバージョン情報、又はＥＣＵのソフトウェアのバージョン情報）およびリスクレベルが登録される。

ステップＳ２０２において、更新サーバー３０は、ステップＳ２０１で登録された更新機能情報を脅威情報分析サーバー１０の更新管理部２１０に送信する。

ステップＳ２０３において、更新管理部２１０は、リスクレベル更新部２２０へ更新機能情報を送信する。

ステップＳ２０４において、リスクレベル更新部２２０は、ステップＳ２０３で受信した更新機能情報が、リスクレベルテーブル３１０に登録されているかを判定する。更新機能情報がリスクレベルテーブル３１０に登録されていると判定した場合（ステップＳ２０４でＹｅｓ）にはステップＳ２０６へ処理を移し、そうでない場合（ステップＳ２０４でＮｏ）にはステップＳ２０５へ処理を移す。

ステップＳ２０５において、リスクレベル更新部２２０は、リスクレベルテーブル３１０を更新する。具体的には、機能別にリスクレベルが定義されている場合は、図５で示した機能別リスクレベルテーブル３１１を更新する。ＥＣＵ別にリスクレベルが定義されている場合は、図６で示した関連ＥＣＵ別リスクレベルテーブル３１２を更新する。アプリケーション別リスクレベルが定義されている場合は、図７で示したアプリケーション権限別リスクレベルテーブル３１３を更新する。なお、機能別リスクレベルテーブル３１１と、関連ＥＣＵ別リスクレベルテーブル３１２と、アプリケーション権限別リスクレベルテーブル３１３とを組み合わせてリスクレベルを判定してもよい。

ステップＳ２０６において、リスクレベル更新部２２０は、更新管理部２１０へリスクレベルテーブルの更新が完了した旨を通知する。

ステップＳ２０７において、更新管理部２１０は、更新サーバー３０へ、リスクレベルテーブルの更新が完了した旨を通知する。

図１２に移り、ステップＳ２０８において、更新サーバー３０は、車両５０ａ～車両５０ｆへ新しいソフトウェアを配信する。例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアを、自動駐車機能（リスクレベル４）に対応したソフトウェアに更新する場合は、更新サーバー３０は、更新ソフトウェアを更新対象車両である車両５０ａと車両５０ｂとに配信する。

ステップＳ２０９において、更新対象車両は、ステップＳ２０８で受信したソフトウェアに更新する。ここでは詳細は記載しないが、更新処理においては、ソフトウェアにデジタル署名が付与されて配布され、車両内でソフトウェアの署名検証が行われることが望ましい。

ステップＳ２１０において、更新対象車両は、更新処理が終わると、ソフトウェアの更新が完了した旨の通知である更新完了通知を更新サーバー３０へ送信する。

ステップＳ２１１において、更新サーバー３０は、更新された機能に関する情報である更新機能情報を脅威情報分析サーバー１０へ送信する。

ステップＳ２１２において、脅威情報分析サーバー１０の更新管理部２１０は、更新機能情報をリスクレベル更新部２２０へ送信する。

ステップＳ２１３において、リスクレベル更新部２２０は、更新機能に関連した脅威情報が脅威情報管理部４００にある脅威情報データベース４１０に含まれているか否かを判定する。更新機能に関連した脅威情報がないと判定した場合（ステップＳ２１３でＮｏ）、ステップＳ２１７へ処理を移す。一方、更新機能に関連した脅威情報があると判定した場合（ステップＳ２１３でＹｅｓ）、ステップＳ２１４へ処理を移す。

ステップＳ２１４において、リスクレベル更新部２２０は、リスクレベル管理部３００の機能別リスクレベルテーブル３１１で更新機能のリスクレベルを参照する。

ステップＳ２１５において、リスクレベル更新部２２０は、関連脅威情報管理部５００のモデル別関連脅威情報データベース５１０に、更新機能情報を追加し、更新機能に関連する脅威情報とリスクレベルとを追加して、モデル別関連脅威情報データベース５１０を更新する。

例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアを、自動駐車機能（リスクレベル４）に対応したソフトウェアに更新する場合、ステップＳ２１５の更新前のモデル別関連脅威情報データベース５１０は、図９のように機能・脅威情報・リスクレベルが登録されているが、ステップＳ２１５の処理の後は、図１０に示すように自動駐車機能に関する脅威情報・リスクレベルが追加される。

ステップＳ２１６において、リスクレベル更新部２２０は、モデル別関連脅威情報データベースの更新を完了した旨の通知である関連脅威情報更新完了通知を出力部２３０に送信する。

ステップＳ２１７において、出力部２３０は、モデル別関連脅威情報データベースに登録された情報を、セキュリティ分析官が解釈しやすいユーザーインターフェースで表示画面に表示する。

以上のように、リスクレベル更新部２２０は、車両の機能追加の完了前に、関連脅威情報を更新する。これにより、脅威情報分析サーバー１０は、ソフトウェア更新の直後から、更新される機能に関連する脅威情報を提示することが可能となり、更新直後に、新機能に対してサイバー攻撃が発生したとしても効率的に攻撃分析が可能となる。

なお、リスクレベル更新部２２０は、所定の台数の車両の機能追加の完了後に、関連脅威情報を更新してもよい。これにより、脅威情報分析サーバー１０は、新機能に対する脅威情報の提示のタイミングを柔軟に設定することが可能となる。具体的には、所定の台数の車両でソフトウェアの動作の試行のあとに、新機能に対する脅威情報の提示をすることが可能となる。

＜機能追加前の出力画面イメージ＞
図１３は、本実施の形態における機能追加される更新前の関連脅威情報出力画面の一例を示す説明図である。図１３は、図９のモデル別関連脅威情報データベースの表示の一例を示している。

図１３において、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加される前の状態の表示例である、関連脅威情報出力画面８００である。

図１３に示される関連脅威情報出力画面８００では、カーメーカーＯＥＭ＿Ａの車種モデルＡ１が備える機能それぞれについて、当該機能が関連するＥＣＵ、当該機能のリスクランク、および当該機能が関連する脅威情報が示されている。

分析官は、図１３に示される出力画面を見て機能ごとのリスクレベルを知り、ログの分析に役立てることが想定される。分析官は、車両５０ａ等から脅威情報分析サーバー１０にアップロードされたログを分析することによって当該車両５０ａが新たな脅威、又は、既知の脅威による攻撃を受けていないかを監視している。このとき、分析官は、図１３に示される出力画面において、リスクレベルの高い脅威ほど、より優先的に着目して、車両５０ａ等からアップロードされたログを分析する。これは、リスクレベルの高い脅威が発見されてからその脅威を分析するまでに要する時間を短縮する効果につながる。

なお、図１３では、リスクレベルが、低、中および高の３段階に丸めて表示されているが、リスクレベル管理部３００が保持するリスクレベルテーブルに基づき、リスクレベルを表示してもよい。

＜機能追加後の出力画面イメージ＞
図１４は、本実施の形態における機能追加された更新後の関連脅威情報出力画面の一例を示す説明図である。図１４は、図１０のモデル別関連脅威情報データベースの表示の一例を示している。

カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加された後の状態の表示例である、関連脅威情報出力画面８１０である。

図１４に示される関連脅威情報出力画面８１０では、関連脅威情報出力画面８００（図１３参照）に加えて、機能追加された自動駐車機能について、新たな機能であることを示す印８１１が付されている。また、新たな機能である自動駐車機能のリスクレベルが「高」であることから注意を要することを示す印８１２が表示されている。

＜実施の形態１の効果＞
実施の形態１に示したように、例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加される場合、新たな機能である自動運転機能に関連する脅威情報を優先的に表示し、それに関わるリスクレベルも高いことが分かるように関連脅威情報出力画面８１０を表示することが可能となる。分析官は、関連脅威情報出力画面８１０を視認し、印８１１及び８１２が付されていることに基づいて、直感的に自動駐車機能に注目して、分析をすることができる。

そのため、もし、リスクの高い自動駐車機能がサイバー攻撃された場合、セキュリティ分析官による攻撃分析が効率化され、自動駐車機能のソフトウェアの脆弱性を修正したソフトウェアを配信するまでの時間を大幅に短縮することが可能となる。攻撃発生から、対応ソフトの配信までの時間短縮化は、被害の拡大を防止することになるのでセキュリティ効果としては非常に高い。

（実施の形態２）
実施の形態１では、ＯＴＡによる更新内容に基づき、モデル別に関連する脅威情報を表示していた。しかしながら、同一モデルであっても個車ごとに更新タイミングは異なる。実施の形態２では、モデル別ではなく、個車ごとの更新状況に合わせた脅威情報の提示である。実施の形態１と構成が同じ部分が多いため、差異がある部分のみ説明する。

関連脅威情報管理部５００は、実施の形態１におけるモデル別関連脅威情報データベース５１０に代えて、車両別関連脅威情報データベース５２０を保持する。

＜更新シーケンス＞
図１５は、本実施の形態における、更新により機能追加される場合の車両別の関連脅威情報が更新される処理を示すシーケンス図である。実施の形態１の図１１のステップＳ２０１からＳ２０７までの処理は、実施の形態１と同じであるため説明を省略する。図１５に示されるステップＳ３０８からＳ３１７までの処理は、実施の形態１の図１２のステップＳ２０８からＳ２１７までの処理に対応している。以降では、実施の形態１と異なる部分を説明する。

また、ここでは、カーメーカーＯＥＭ＿Ａの車種モデルＡ１の車両ＩＤが「ＶＩＤ＿Ａ１」と「ＶＩＤ＿Ａ２」とである車両のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加されるケースを例として説明する。

ステップＳ３０８において、更新サーバー３０は、車両５０ａ～車両５０ｆへ新しいソフトウェアを配信する。例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアを、自動駐車機能（リスクレベル４）に対応したソフトウェアに更新する場合は、更新サーバー３０は、更新ソフトを車両ＩＤが「ＶＩＤ＿Ａ１」と「ＶＩＤ＿Ａ２」とである車両に配信する。

ステップＳ３０９において、更新対象車両（ＶＩＤ＿Ａ１とＶＩＤ＿Ａ２）は、ステップＳ３０８で受信したソフトウェアに更新する。ここでは詳細は記載しないが、更新処理においては、ソフトウェアにデジタル署名が付与されて配布され、車両内でソフトウェアの署名検証が行われることが望ましい。

ステップＳ３１０において、更新対象車両（ＶＩＤ＿Ａ１とＶＩＤ＿Ａ２）は、更新処理が終わると、車両ＩＤと共に、ソフトウェアの更新が完了した旨の通知である更新完了通知を更新サーバー３０へ送信する。

ステップＳ３１１において、更新サーバー３０は、更新された機能に関する情報である更新機能情報を脅威情報分析サーバー１０へ送信する。

ステップＳ３１２において、脅威情報分析サーバー１０の更新管理部２１０は、更新機能情報をリスクレベル更新部２２０へ送信する。

ステップＳ３１３において、リスクレベル更新部２２０は、更新機能に関連した脅威情報が脅威情報管理部４００にある脅威情報データベース４１０に含まれているかを判定する。更新機能に関連した脅威情報がないと判定した場合（ステップＳ３１３でＮｏ）、ステップＳ３１７へ処理を移す。一方、更新機能に関連した脅威情報があると判定した場合（ステップＳ３１３でＹｅｓ）、ステップＳ３１４へ処理を移す。

ステップＳ３１４において、リスクレベル更新部２２０は、リスクレベル管理部３００の機能別リスクレベルテーブル３１１で更新機能のリスクレベルを参照する。

ステップＳ３１５において、リスクレベル更新部２２０は、関連脅威情報管理部５００の車両別関連脅威情報データベースに、更新機能情報を追加し、更新機能に関連する脅威情報とリスクレベルとを追加し、さらには車両別の更新状況を記録して、車両別関連脅威情報データベースを更新する。

例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１の車両ＶＩＤ＿Ａ１と車両ＶＩＤ＿Ａ２とのＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェアを、自動駐車機能（リスクレベル４）に対応したソフトウェアに更新する場合、車両ごとの更新状況が記録される。車両別関連脅威情報データベースは図１６を用いて後述する。

ステップＳ３１６において、リスクレベル更新部２２０は、車両別関連脅威情報データベースの更新を完了した旨の通知である関連脅威情報更新完了通知を出力部２３０に送信する。

ステップＳ３１７において、出力部２３０は、車両別関連脅威情報データベースに登録された情報を、セキュリティ分析官が解釈しやすいユーザーインターフェースで表示画面に表示する。

＜車両別関連脅威情報データベース＞
図１６は、本実施の形態における車両別の関連脅威情報データベースの一例として、車両別関連脅威情報データベース５２０を示す説明図である。

車両別関連脅威情報データベース５２０は、カーメーカー、車種情報、車両ＩＤ、機能情報、その機能を制御するＥＣＵ ＩＤ、ＥＣＵソフトのバージョン、ＥＣＵソフトの更新状況、リスクレベル、ＥＣＵに関連する脅威情報のＩＤを含んで構成される。

例えば、カーメーカーＯＥＭ＿Ａの車種モデルＡ１の車両ＶＩＤ＿Ａ１と車両ＶＩＤ＿Ａ２のＥＣＵ＿Ａ３の駐車支援機能（リスクレベル３）のソフトウェア（Ｖｅｒｓｉｏｎ１．０）を、自動駐車機能（リスクレベル４）に対応したソフトウェア（Ｖｅｒｓｉｏｎ２．０）へ更新する例で、図１６は、車両ＶＩＤ＿Ａ１が未更新であり、車両ＶＩＤ＿Ａ２が更新済みであることを示している。

＜車両別関連脅威情報の表示＞
図１７は、図１６の車両別関連脅威情報データベースを表示した一例を示している。

カーメーカーＯＥＭ＿Ａの車種モデルＡ１のＥＣＵ＿Ａ３の駐車支援機能のソフトウェアが、自動駐車機能（リスクレベル４）に対応したソフトウェアへ更新し機能追加された後の状態の表示例である関連脅威情報出力画面９００である。関連脅威情報出力画面９００は、車両ＶＩＤ＿Ａ１についてはＥＣＵ＿Ａ３の駐車支援機能のソフトウェアが未更新であり、車両ＶＩＤ＿Ａ２については上記ソフトウェアが更新済みであることを示している。

図１７に示される関連脅威情報出力画面９００では、図１４と同様、機能追加された自動駐車機能および駐車支援機能について、新たな機能であることを示す印８１１が付されている。また、車両ＶＩＤ＿Ａ１については、上記ソフトウェアが未更新であることから、注意を要することを示す印８１２が表示されている。なお、この場合における印８１２は、ソフトウェアが未更新であることを分析官に示すための印であるともいえるし、ソフトウェアを更新する必要があることを分析官に示すための印であるともいえる。また、車両ＶＩＤ＿Ａ２については、新たな機能である自動駐車機能のリスクレベルが高いことから注意を要することを分析官に示す印８１２が表示されている。

＜実施の形態２の効果＞
同一モデルであっても個車ごとに更新タイミングは異なる。実施の形態２では、モデル別ではなく、個車ごとの更新状況に合わせた脅威情報が可能となり、車両ごとの更新状況に合わせたセキュリティ分析が可能となる。

＜その他変形例＞
なお、本発明を上記各実施の形態に基づいて説明してきたが、本発明は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

（１）上記の実施の形態では、脅威情報を活用した自動車へのサイバー攻撃分析として説明したが、適用範囲はこれに限られない。自動車に限らず、建機、農機、船舶、鉄道、飛行機などのモビリティにも適用してもよい。また、工場やビルなどの産業制御システムで利用される通信ネットワーク、又は、組込みデバイスを制御するための通信ネットワークに適用してもよい。また、より広く、ＩｏＴデバイスであってもよい。ＩｏＴデバイスとは、上記のモビリティのほか、家電製品を含む概念であり、通信インタフェースを有している一方、計算処理などに使用するリソースが比較的小さいデバイスを指す概念である。なお、ＩｏＴデバイスの概念には、パーソナルコンピュータ、又はマートフォンなどの情報処理装置は含まれない。

（２）上記の実施の形態では、リスクレベル管理部３００が、機能別、アプリケーション権限別、又は、ＥＣＵ別でリスクレベルを定義していたが、これに限定されない。例えば、採用するＯＳ別、又は、ＥＣＵがサポートしている通信プロトコル別（例えばＣＡＮ（Controller Area Network）、ＣＡＮ－ＦＤ（Controller Area Network with Flexible Data Rate）、Ｅｔｈｅｒｎｅｔ、ＬＩＮ（Local Interconnect Network）、Ｆｌｅｘｒａｙ）であってもよいし、それぞれを組み合わせたものでリスクレベルを定義してもよい。

（３）上記の実施の形態では、各機能に対して１つの脅威情報しか関連づけしていないが、関連する脅威情報を複数関連づけしてもよい。これにより、複数の攻撃手法を組み合わせた高度な攻撃も分析可能となる。また、複数の脅威情報を関連付ける場合は、出力部２３０は、攻撃手順に従った順序で関連する脅威情報を並べ変えて出力してもよい。これにより、攻撃手順を追った分析が可能となり、対応までの時間を短縮することが可能となる。

（４）上記の実施の形態では、関連脅威情報を表形式で表示していたが、関連する機能と脅威情報をツリー形式で表示してもよい。これにより、関連する脅威情報が多い機能やＥＣＵからの枝が密になるので、攻撃されやすいポイントをわかりやすく提示することが可能となる。

（５）上記の実施の形態では、ソフトウェア更新により追加される機能に関連した脅威情報を、過去の脅威情報を検索して関連づけしていたが、過去の脅威情報にない場合は、その時点では脅威情報がないことが分かる形で関連脅威情報として登録しておいてもよい。関連する過去の脅威情報がないが、新たな脅威情報を関連脅威情報に関連づけして登録してもよい。

（６）上記の実施の形態では、ソフトウェア更新時に、更新される機能に対する脅威情報を検索していたが、この検索処理は、定期的に行っても良い。これにより、常に最新の脅威情報を関連づけることが可能となる。

（７）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。

また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

（８）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（９）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。

また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。

また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（１０）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の脅威分析装置などを実現するソフトウェアは、次のようなプログラムである。

すなわち、このプログラムは、コンピュータに、ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理ステップと、サイバー攻撃の脅威情報を格納する脅威情報管理ステップと、前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理ステップと、前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理ステップと、前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新ステップと、前記関連脅威情報管理ステップで管理する前記関連脅威情報を出力する出力ステップと、を含む脅威分析方法を実行させるプログラムである。

以上、一つまたは複数の態様に係る脅威分析装置などについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本発明は、車両などに対してなされるサイバー攻撃を分析する分析装置に適用可能である。

１ 脅威情報分析システム
１０ 脅威情報分析サーバー
２０ 脅威情報管理サーバー
３０ 更新サーバー
４０ ネットワーク
５０ａ、５０ｂ、５０ｃ、５０ｄ、５０ｅ、５０ｆ 車両
１００ 脅威情報
１０１、１０２、１０３、１０４、１０５、１０６、１０７、１０８、１０９、１１０ フィールド
２００ 脅威情報交換処理部
２１０ 更新管理部
２２０ リスクレベル更新部
２３０ 出力部
２４０ 車両制御部
３００ リスクレベル管理部
３１０ リスクレベルテーブル
３１１ 機能別リスクレベルテーブル
３１２ 関連ＥＣＵ別リスクレベルテーブル
３１３ アプリケーション権限別リスクレベルテーブル
４００ 脅威情報管理部
４１０ 脅威情報データベース
５００ 関連脅威情報管理部
５１０、５１０Ａ モデル別関連脅威情報データベース
５２０ 車両別関連脅威情報データベース
８００、８１０、９００ 関連脅威情報出力画面
８１１、８１２ 印

Claims (12)

1. ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理部と、
   サイバー攻撃の脅威情報を格納する脅威情報管理部と、
   前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理部と、
   前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理部と、
   前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新部と、
   前記関連脅威情報管理部が管理する前記関連脅威情報を出力する出力部と、
   を備える脅威分析装置。
2. 前記ＩｏＴデバイスは、モビリティデバイスであり、
   前記脅威分析装置は、さらに、
   前記脅威情報を交換する脅威情報交換処理部を備える
   請求項１に記載の脅威分析装置。
3. 前記リスクレベルは、モビリティ制御に関連する機能ごとに定義されている
   請求項２に記載の脅威分析装置。
4. 前記リスクレベルは、モビリティ制御メッセージを送受信する電子制御ユニットの関係に基づいて定義されている
   請求項２又は３に記載の脅威分析装置。
5. 前記リスクレベルは、モビリティ制御を行うアプリケーションに対応した権限の個数に応じて定義されている
   請求項２～４のいずれか１項に記載の脅威分析装置。
6. 前記関連脅威情報は、車種ごとに管理されている
   請求項２～５のいずれか１項に記載の脅威分析装置。
7. 前記関連脅威情報は、車両ごとに管理されている
   請求項２～６のいずれか１項に記載の脅威分析装置。
8. 前記リスクレベル更新部は、前記ＩｏＴデバイスの前記機能追加の完了前に、前記関連脅威情報を更新する
   請求項１～７のいずれか１項に記載の脅威分析装置。
9. 前記リスクレベル更新部は、所定の台数の前記ＩｏＴデバイスの前記機能追加の完了後に、前記関連脅威情報を更新する
   請求項１～８のいずれか１項に記載の脅威分析装置。
10. さらに、
    前記リスクレベル更新部によって前記関連脅威情報が更新された場合に、更新後の前記関連脅威情報に基づいて車両に制御信号を送信する車両制御部を備える
    請求項１～９のいずれか１項に記載の脅威分析装置。
11. コンピュータが実行する脅威分析方法であって、
    コンピュータが、ＩｏＴデバイスの機能追加がなされたことを示す更新情報を管理する更新管理ステップと、
    コンピュータが、サイバー攻撃の脅威情報を格納する脅威情報管理ステップと、
    コンピュータが、前記ＩｏＴデバイスのリスクレベルが定義されたリスクレベル情報を管理するリスクレベル管理ステップと、
    コンピュータが、前記脅威情報と、前記ＩｏＴデバイスに前記リスクレベルを関連づけた関連脅威情報とを管理する関連脅威情報管理ステップと、
    コンピュータが、前記更新情報に基づいて、前記脅威情報と前記ＩｏＴデバイスの前記リスクレベルとの関連づけを行い、前記関連脅威情報を更新するリスクレベル更新ステップと、
    コンピュータが、前記関連脅威情報管理ステップで管理する前記関連脅威情報を出力する出力ステップと、
    を含む
    脅威分析方法。
12. 請求項１１に記載の脅威分析方法をコンピュータに実行させるためのプログラム。

Images