特開 2024-160595 ソフトウェア更新装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024160595

(43)【公開日】2024-11-14

(54)【発明の名称】ソフトウェア更新装置及び方法

(51)【国際特許分類】

   G06F 21/57 20130101AFI20241107BHJP

【ＦＩ】

G06F21/57 320

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2023075766

(22)【出願日】2023-05-01

(71)【出願人】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】森田 伸義

(72)【発明者】

【氏名】山▲崎▼ 裕紀

(57)【要約】

【課題】車両等に搭載された対象装置のソフトウェアを更新する際に、その更新内容がリスク許容範囲内のものであるかどうか否か判定可能なソフトウェア更新装置及び方法を提供する。
【解決手段】本発明の一実施例に係るソフトウェア更新装置は、対象装置の脆弱性情報と脆弱性情報におけるリスクの許容条件とを管理するリスク管理部と、対象装置のソフトウェア更新がされる場合、更新内容が許容条件を満たさないと判定されたときにソフトウェア更新を禁止するソフトウェア更新制御部と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

対象装置の脆弱性情報と前記脆弱性情報におけるリスクの許容条件とを管理するリスク管理部と、
前記対象装置のソフトウェア更新がされる場合、更新内容が前記許容条件を満たさないと判定されたときに前記ソフトウェア更新を禁止するソフトウェア更新制御部と、を備える、
ことを特徴とするソフトウェア更新装置。

【請求項2】

請求項１に記載のソフトウェア更新装置であって、
前記ソフトウェア更新がされるときに前記更新内容が前記許容条件を満たすか否かを検証するリスク検証部をさらに備える、
ことを特徴とするソフトウェア更新装置。

【請求項3】

請求項１に記載のソフトウェア更新装置であって、
前記許容条件の更新情報に基づき前記許容条件を更新するリスク更新部をさらに備える、
ことを特徴とするソフトウェア更新装置。

【請求項4】

請求項３に記載のソフトウェア更新装置であって、
前記許容条件の更新情報および前記ソフトウェア更新に用いる更新プログラムを取得する更新情報取得部と、
前記許容条件の更新または前記ソフトウェア更新のどちらを実行するかを判定する更新内容判定部と、をさらに備える、
ことを特徴とするソフトウェア更新装置。

【請求項5】

対象装置の脆弱性情報と前記脆弱性情報におけるリスクの許容条件とを取得し、
前記対象装置のソフトウェア更新がされる場合、更新内容が前記許容条件を満たさないと判定したときに前記ソフトウェア更新を禁止する、
ことを特徴とするソフトウェア更新方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、対象装置のソフトウェア更新を管理するソフトウェア更新装置及び方法に関する。

【背景技術】

【0002】

車両等に搭載される電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）においては、自動運転技術の向上やＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ）等の通信技術の台頭により、そのサイバーセキュリティ上の安全性の確保が近年ますます要求されている。

【0003】

特に、製品に何らかの脆弱性が発見された場合には、その脆弱性を狙ったサイバー攻撃によって数万台の車両に影響が及ぶ危険性があり、迅速に対処する必要がある。

【0004】

車両の製造元（ＯＥＭ：Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ）にはＰＳＩＲＴ（Ｐｒｏｄｕｃｔ Ｓｅｃｕｒｉｔｙ Ｉｎｃｉｄｅｎｔ Ｒｅｓｐｏｎｓｅ Ｔｅａｍ）という組織が設置される。ＰＳＩＲＴは各業界団体から公開脆弱性情報及び業界脆弱性情報を取得し、ＯＥＭ内の各部門と連携しつつ取得した脆弱性に該当する製品がサプライヤにあるか否かの調査を行う。

【0005】

脆弱性に該当する製品があった場合、ＰＳＩＲＴはそのリスク評価や再現試験といった各種の評価試験を実施し、その脆弱性に関する影響度がどの程度大きいのかを調査する。そして、その影響度が非常に大きいと判断された場合には、製品の仕様書を更新するために開発プロジェクトへのフィードバックが実行される。最後に、すでに市場に出回っている製品に対応するために例えばＯＴＡを利用したソフトウェアのリプログラミングが行われ、出荷品が修正される。

【0006】

しかしながら上述の処理は現実的には非常に困難であり、製品出荷後に脆弱性が発見されたとしても、その脆弱性を克服するためのソフトウェア更新は容易に実施することはできない。ソフトウェア変更に伴う影響の調査に数か月単位の時間を要するためである。

【0007】

また上述したサイバーセキュリティの安全性向上要求は関連法規の施行によるものでもあるが、この法規は発見された脆弱性の除去をただちに要求するものではなく、その脆弱性によるリスク評価結果に基づく説明責任を果たすことを求めている。

【0008】

一方、車両は通常２０年近くに亘る長期運用が想定されるものであり、脆弱性が発見された当初はそのリスクを許容可能であると判定されていた条件が、その後の運用でリスク許容範囲を逸脱してしまうような可能性も想定される。

【0009】

このようなリスク管理に管理する技術として特許文献１が挙げられる。該文献には、更新情報に基づいて、脅威情報とＩｏＴデバイスのリスクレベルとの関連づけを行い、関連脅威情報を更新するリスクレベル更新部と、関連脅威情報管理部が管理する関連脅威情報を出力する出力部を備える脅威情報分析サーバに関する発明が記載されている。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】国際公開２０２０／０８０２２２号

【発明の概要】

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

【0011】

しかしながら特許文献１に記載の技術を用いたとしても、上述したような、期間経過に伴って変化するリスク許容範囲に対応した判定をすることはできない。

【0012】

本発明は、以上の問題に鑑みなされたものであり、車両等に搭載された対象装置のソフトウェアを更新する際に、その更新内容がリスク許容範囲内のものであるかどうか否か判定可能なソフトウェア更新装置を提供することを目的とする。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

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

【0013】

上記課題を解決するために、本発明の一実施例に係るソフトウェア更新装置は、対象装置の脆弱性情報と脆弱性情報におけるリスクの許容条件とを管理するリスク管理部と、対象装置のソフトウェア更新がされる場合、更新内容が許容条件を満たさないと判定されたときにソフトウェア更新を禁止するソフトウェア更新制御部と、を備える。

【発明の効果】

【0014】

本発明によれば、車両等に搭載された対象装置のソフトウェアを更新する際に、その更新内容がリスク許容範囲内のものであるかどうか否か判定することが可能になる。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0015】

【図1】本発明の一実施例に係るソフトウェア更新装置の機能構成及び外部組織との関係性を示すブロック図。

【図2】脆弱性が発見された後に想定される処理（事象）を説明する図。

【図3】ソフトウェア更新の際に実行される処理を示すフローチャート。

【図4】脆弱性発見後、リスク管理情報を更新する処理を示す図。

【図5】リスク管理情報の更新内容を説明する図。

【図6】ソフトウェアを更新する処理を示す図。

【図7】ソフトウェア更新の際に参照されるリスク許容条件を示す図。

【図8】ソフトウェア更新の際に実行されるリスク許容条件の検証処理を示すフローチャート。

【図9】脆弱性修正パッチを適用する処理を示す図。

【図10】脆弱性修正パッチの適用内容を示す図。

【図11】リスク管理情報の更新内容を説明する図。

【図12】本発明の変形例に係るソフトウェア更新装置の機能構成及び外部組織との関係性を示すブロック図。

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

【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】

１２ リスク管理部、１３ ソフトウェア更新制御部、１４ リスク検証部、１５ リスク更新部、１６ 更新情報取得部、１７ 更新内容判定部、１００ ソフトウェア更新装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】