JP2007323349A - ソフトウェア更新要否判定方法 - Google Patents

Abstract

【課題】ネットワークシステムの信頼性を考慮しつつ、ソフトウェアの更新要否を適切に判定可能なソフトウェア更新要否判定方法を提供することを目的とする。
【解決手段】ネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するソフトウェア更新要否判定方法であって、コンピュータ１６が、機器に搭載されたソフトウェアに関する情報およびソフトウェアの脆弱性に関する情報を取得し、機器に搭載されたソフトウェアに関する情報およびソフトウェアの脆弱性に関する情報に基づき、機器に搭載されたソフトウェアのうち脆弱性のあるものを選択し、選択されたソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定することにより上記課題を解決する。
【選択図】図２

Description

本発明は、ソフトウェア更新要否判定方法に係り、特に所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するソフトウェア更新要否判定方法に関する。

例えばネットワークシステムでは、ネットワーク機器に搭載されたソフトウェアの不具合の修正などのためにアップデート（更新）が行われる。アップデートは、ネットワーク機器提供ベンダ等が配布するアップデートの為のアップデートファイルをインストールすることにより行われている。

図１はネットワークシステムの一例のシステム構成図である。図１のネットワークシステムはセンターに設置されたサーバ１ａ，１ｂ及びルータＲ１と、営業店に設置されたクライアント２及びルータＲ２と、広域イーサーネット（登録商標）３と、ＩＮＳ網４とを含むように構成されている。

従来のネットワークシステムでは、既存のネットワークシステムがセキュアな構成かの確認を次のように行っていた。まず、ユーザは例えばネットワーク機器提供ベンダ等がインターネット上で公開しているＯＳ脆弱性情報ＷＥＢを参照する。ユーザは個々のネットワーク機器のＯＳバージョンとＯＳ脆弱性情報とを比較することで、ネットワーク機器の脆弱性を確認する。ユーザはネットワーク機器の脆弱性の有無により、既存のネットワークシステムがセキュアな構成かの確認を行っていた。

例えば特許文献１には、ネット上で公開されているソフトアップデート情報と管理対象システムの構成とを比較して、合致するものにつきアップデートを行う技術が記載されている。
特開２００２−２６８９８５号公報

しかしながら、ソフトウェアの中には、他のソフトウェアとの組み合わせや整合性をとる必要があるものなどがある。そのようなソフトウェアに対して安易にアップデートを行ってしまうと、ネットワークシステムは不整合を起こし、システムダウンしてしまう危険性があるという問題があった。

例えば信頼性を重視する基幹系システムでは、絶対にシステムダウンを避けなければならない。したがって、ネットワーク機器提供ベンダ等が配布する全てのアップデートファイルを無条件にインストールすることは望ましくない場合もあった。特開平１１−１６１４８２号公報は、このような場合に対処しようとしたものである。

特開平１１−１６１４８２号公報には、障害を起こしたソフトウェアに関する情報を蓄積しておき、アップデートファイルが障害を起こしたソフトウェアに関連する場合にアップデートを行うことが記載されている。つまり、基幹系システムが動作しているホストなどで障害を起こしていないソフトウェアのアップデートを行わないことで、必要以上にソフトウェアをアップデートしないようにしている。

しかしながら、特開平１１−１６１４８２号公報に記載されている内容では、障害を起こしていないソフトウェアのアップデートを行わないため、本来行うべきアップデートが行われない可能性があるという問題があった。

本発明は、上記の点に鑑みなされたもので、ネットワークシステムの信頼性を考慮しつつ、ソフトウェアの更新要否を適切に判定可能なソフトウェア更新要否判定方法を提供することを目的とする。

上記の課題を解決するため、本発明は、所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するコンピュータのソフトウェア更新要否判定方法であって、前記コンピュータが、前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報を取得して記憶装置に格納する格納ステップと、前記コンピュータが、前記記憶装置に格納されている前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報に基づき、前記機器に搭載されたソフトウェアのうち脆弱性のあるものを選択する選択ステップと、選択された前記ソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定する判定ステップとを有することを特徴とする。

前記判定ステップは、選択された前記ソフトウェアのうち最後に利用されてから所定期間以上経過したものを更新が不要と判定することを特徴としてもよい。

前記機器に搭載されたソフトウェアに関する情報は、前記ソフトウェアの識別情報および利用履歴情報を含むことを特徴としてもよい。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

上述の如く、本発明によれば、ネットワークシステムの信頼性を考慮しつつ、ソフトウェアの更新要否を適切に判定可能なソフトウェア更新要否判定方法を提供できる。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。まず、本発明の理解を容易とする為、図２のネットワークシステムを構成する機器のうち、ルータＲ１，Ｒ２に搭載されたソフトウェアの更新要否を判定する例を中心に説明する。図２のネットワークシステムは、セキュアな構成かの確認を行い、その確認結果を顧客に通知することにより、セキュアなネットワークシステムの運用を実現するものである。

図２は本発明によるネットワークシステムの一実施例の構成図である。図２に示すネットワークは、業務サーバ１０ａ，１０ｂと、クライアント１１と、ルータＲ１，Ｒ２，１９及び２０と、広域イーサーネット（登録商標）１４と、ＩＮＳ網１５と、セキュリティクライアント１６と、ルータＲ１の脆弱情報１７と、ルータＲ２の脆弱情報１８と、インターネット２１とを含むように構成されている。

図２のネットワークシステムでは、センター側に業務サーバ１０ａ，１０ｂと、ルータＲ１，１９と、セキュリティクライアント１６とが設置されている。営業店側には、クライアント１１とルータＲ２とが設置されている。また、ルータＲ１，Ｒ２を提供するベンダ側にはＷｅｂサイト（ベンダサイトＷＥＢ）を実現する為の各種サーバ（図示せず）及びルータ２０が設置されている。ベンダサイトＷＥＢには、ルータＲ１の脆弱情報１７およびルータＲ２の脆弱情報１８が参照可能に登録されている。セキュリティクライアント１６は、ベンダサイトＷＥＢ（ＯＳ脆弱性情報ＷＥＢ）を参照し、ルータＲ１，Ｒ２にＯＳ脆弱性が発生した場合に以下の処理を行う。

まず、セキュリティクライアント１６はルータＲ１，Ｒ２に対してＯＳバージョン取得用パトロールパケットを送信する。ＯＳバージョン取得用パトロールパケットは後述するような既存の情報取得コマンドを利用することで実現できる。

次に、セキュリティクライアント１６はＯＳバージョン取得用パトロールパケットにより取得したＯＳバージョンを後述するネットワークシステムマップに設定する。このネットワークシステムマップは、ネットワークシステムを構成する機器毎に、その機器に搭載されたソフトウェアの更新要否を判定する為の各種情報（ＯＳバージョン，アクセス日時など）が設定されている。

セキュリティクライアント１６はＯＳ脆弱性情報ＷＥＢに登録されているルータＲ１の脆弱情報１７およびルータＲ２の脆弱情報１８の脆弱性ＯＳバージョンと、ネットワークシステムマップに設定されているルータＲ１およびルータＲ２のＯＳバージョンとを比較して、脆弱性対応がされているか否かを判定する。

ルータＲ１およびルータＲ２の少なくとも一方が脆弱性対応されていなければ、セキュリティクライアント１６は更に、ネットワークシステムマップに設定されているルータＲ１およびルータＲ２のアクセス日時を参照し、利用実績がある場合に、ＯＳ脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行う。なお、セキュリティクライアント１６は、設定されているアクセス日時から所定期間が経過していなければ、利用実績があるソフトウェアと見なす。また、セキュリティクライアント１６は、アクセス日時が設定されていないか又は設定されているアクセス日時から所定期間が経過していれば、利用実績がないソフトウェアと見なす。

ＯＳ脆弱性未対応メッセージ／推奨バージョン通知は、脆弱性対応されていない機器を識別する為の情報と、その機器の脆弱性対応が成されたＯＳバージョンを表す推奨バージョンとを含む。このように、図２のネットワークシステムでは、脆弱性対応がされていないソフトウェアのうち、所定期間の間に利用実績のあるソフトウェアだけＯＳ脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行うことができる。

つまり、図２のネットワークシステムでは、脆弱性対応がされていないソフトウェアであっても、利用実績がないと見なしたソフトウェアのＯＳ脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行わないことにより、必要以上にソフトウェアの脆弱性対応を行うことを避けている。この結果、図２のネットワークシステムではネットワークシステムの信頼性を考慮しつつ、ソフトウェアの更新要否を適切に判定できる。

次に、セキュリティクライアント１６のハードウェア構成について、図３を参照しつつ説明する。図３は、セキュリティクライアントの一例のハードウェア構成図である。セキュリティクライアント１６は、それぞれバスＢで相互に接続されている入力装置３１，出力装置３２，ドライブ装置３３，補助記憶装置３４，メモリ装置３５，演算処理装置３６およびインターフェース装置３７を含むように構成される。

入力装置３１はキーボードやマウスなどで構成され、各種信号を入力するために用いられる。出力装置３２はディスプレイ装置などで構成され、各種ウインドウやデータ等を表示するために用いられる。インターフェース装置３７は、モデム，ルータ，ＬＡＮカードなどで構成されており、各種ネットワークに接続する為に用いられる。

本発明によるソフトウェア更新要否判定プログラムは、セキュリティクライアント１６を制御する各種プログラムの少なくとも一部である。ソフトウェア更新要否判定プログラムは例えば記録媒体３８の配布や各種ネットワークからのダウンロードなどによって提供される。

ソフトウェア更新要否判定プログラムを記録した記録媒体３８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。

また、ソフトウェア更新要否判定プログラムを記録した記録媒体３８がドライブ装置３３にセットされると、ソフトウェア更新要否判定プログラムは記録媒体３８からドライブ装置３３を介して補助記憶装置３４にインストールされる。各種ネットワークからダウンロードされたソフトウェア更新要否判定プログラムは、インターフェース装置３７を介して補助記憶装置３４にインストールされる。

セキュリティクライアント１６は、インストールされたソフトウェア更新要否判定プログラムを格納すると共に、必要なファイル，データ等を格納する。メモリ装置３５は、コンピュータの起動時に補助記憶装置３４からソフトウェア更新要否判定プログラムを読み出して格納する。そして、演算処理装置３６はメモリ装置３５に格納されたソフトウェア更新要否判定プログラムに従って、後述するような各種処理を実現している。

次に、セキュリティクライアント１６のソフトウェア構成図について、図４を参照しつつ説明する。図４は、セキュリティクライアントの一例のソフトウェア構成図である。

図４のセキュリティクライアント１６は、構成／脆弱性確認ツール４１，稼動情報取得ツール４２，脆弱性確認ツール４３，提案テンプレートＤＢ４４，脆弱性情報開発元ＤＢ４５，ネットワークシステムマップＤＢ４６，脆弱性情報ＤＢ４７を含むように構成されている。ここでは、構成／脆弱性確認ツール４１，稼動情報取得ツール４２，脆弱性確認ツール４３の処理について図面を参照しつつ説明する。

図５は、構成／脆弱性確認ツールの処理を説明する為の図である。まず、図２に示すネットワークシステムの概要提案構成を決定し、各機器の見積りを生成する。見積り５１はルータＲ１の見積りの一例である。例えば見積り５１は、機種名，モジュール，バージョン，使用コマンド，メモリサイズおよび価格／Ｃｏｓｔから構成される。

ステップＳ１に進み、構成／脆弱性確認ツール４１は各機器の見積り、提案テンプレートＤＢ４４及び脆弱性情報開発元ＤＢ４５に基づき、ネットワークシステムの最適な該当組合せを検索する。提案テンプレートＤＢ４４は、事前検証済みのネットワークシステムの構成を表しているものである。脆弱性情報開発元ＤＢ４５は、ＯＳバージョン毎の脆弱性／ＢＵＧ情報，使用コマンドを表しているものである。

ステップＳ２に進み、構成／脆弱性確認ツール４１は該当組合せの製品詳細情報を入手して、ネットワークシステムの機器の構成と、各機器に搭載されるソフトウェアとを表したネットワークシステム構成マップを作成する。ステップＳ３では、ネットワークシステム構成マップに基づいて、各機器へのソフトウェアのインストールと、情報取得コマンドの設定とを行う。

ステップＳ１〜Ｓ３の処理結果に基づき、図６のようなネットワークシステムマップＤＢ４６が作成される。図６はネットワークシステムマップＤＢの一例の構成図である。図６のネットワークシステムマップＤＢ４６は、機種名／ｉｐアドレス，バージョン，インストール日時，起動日時，アクセス日時，機能，使用コマンド，情報取得コマンドから構成されている。図６のネットワークシステムマップＤＢ４６はインストール直後で、各機器が未使用である例を表したものである。未使用である場合、アクセス日時には「００００／００／００／００」が設定されている。

図７は、稼動情報取得ツールの処理を説明する為の図である。稼動情報取得ツール４２はネットワークシステムマップＤＢ４６に設定されている各機器のＩＰアドレスの取得および情報取得コマンドの読込を行い、情報取得コマンドを各機器に発行することで各機器のアクセス日時を取得し、そのアクセス日時をネットワークシステムマップＤＢ４６に設定する。図７のネットワークシステムマップＤＢ４６では使用された機器のアクセス日時が設定されている。

図８は、脆弱性確認ツールの処理を説明する為の図である。脆弱性確認ツール４３はステップＳ２１に進み、ネットワークシステムマップＤＢ４６と、各機器の脆弱情報が登録されている脆弱性情報ＤＢ４７とを比較する。ここでは、ルータＲ１，ルータＲ２を例に説明する。脆弱性情報ＤＢ４７には、機器および使用コマンド毎に脆弱性バージョン範囲および推奨バージョンが設定されている。

ステップＳ２２に進み、脆弱性確認ツール４３はネットワークシステムマップＤＢ４６と脆弱性情報ＤＢ４７との比較結果に基づき、ルータＲ１，ルータＲ２に搭載されているソフトウェアに脆弱性対応がされていないバージョンのソフトウェアが含まれるか否かを判定する。

具体的に、脆弱性確認ツール４３はルータＲ１，ルータＲ２に搭載されているソフトウェアのバージョンが、脆弱性情報ＤＢ４７の脆弱性バージョン範囲に含まれている場合に脆弱性対応がされていないバージョンのソフトウェアが含まれると判定し、脆弱性情報ＤＢ４７の推奨バージョンに含まれている場合に脆弱性対応がされているバージョンのソフトウェアが含まれていると判定する。

脆弱性確認ツール４３はルータＲ１，ルータＲ２に搭載されているソフトウェアに脆弱性対応がされていないバージョンのソフトウェアが含まれると判定すると、ステップＳ２３に進み、脆弱性対応がされていないバージョンのソフトウェアの使用コマンドが一致しているか否かを判定する。

脆弱性確認ツール４３は脆弱性対応がされていないバージョンのソフトウェアの使用コマンドが一致していると判定すると、ステップＳ２４に進み、脆弱性対応がされていないバージョンのソフトウェアのアクセス日時がネットワークシステムマップＤＢ４６に設定されているか否かを判定する。

脆弱性確認ツール４３は脆弱性対応がされていないバージョンのソフトウェアのアクセス日時がネットワークシステムマップＤＢ４６に設定されていると判定すると、ステップＳ２５に進み、脆弱性対応がされていないバージョンのソフトウェアのアクセス日時に応じて所定期間（例えば２年間）アクセスなしか否かを判定する。

脆弱性確認ツール４３は脆弱性対応がされていないバージョンのソフトウェアが２年間アクセスなしではないと判定すると、ステップＳ２６に進み、脆弱性情報ＤＢ４７の推奨バージョンをダウンロードする。そして、ステップＳ２７に進み、脆弱性確認ツール４３は顧客に脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行う。

なお、ステップＳ２２でルータＲ１，ルータＲ２に脆弱性対応がされていないバージョンのソフトウェアが含まれていないと判定した場合、ステップＳ２３で脆弱性対応がされていないバージョンのソフトウェアの使用コマンドが一致していないと判定した場合、ステップＳ２４で脆弱性対応がされていないバージョンのソフトウェアのアクセス日時がネットワークシステムマップＤＢ４６に設定されていない判定した場合、ステップＳ２５で脆弱性対応がされていないバージョンのソフトウェアが２年間アクセスなしである場合は脆弱性対応がされていないバージョンのソフトウェアが無いことを表す該当無し通知を顧客に対して行う。

このように、脆弱性確認ツール４３は脆弱性対応されていない機器のアクセス日時をネットワークシステムマップＤＢ４６から取得し、脆弱性対応されていない機器のうち利用実績がある機器を選択して、前述したような脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行うことができる。

例えば図８のネットワークシステムマップＤＢ４６及び脆弱性情報ＤＢ４７の場合、脆弱性確認ツール４３はステップＳ２１〜Ｓ２７の処理により、機器「ルータＲ１，ルータＲ２」及び使用コマンド「ＩＰｖ６／ＲＩＰ」に対応する脆弱性未対応メッセージ／推奨バージョン通知を顧客に対して行うことができる。

以下、本発明によるネットワークシステムの他の構成を説明する。図９はベンダ側で脆弱情報を登録する処理を示したフロー図である。ベンダ側には、脆弱性情報登録クライアント１００，ＷＥＢサーバ１０１，ＡＰサーバ１０２，ＤＢサーバ１０３が設置されている。

ステップＳ１００では脆弱性情報登録クライアント１００がルータＲ１の脆弱性登録依頼を行う。ステップＳ１０１に進み、ＷＥＢサーバ１０１はルータＲ１の脆弱性登録依頼に基づきサーブレット（振り分け）を行い、ルータＲ１の機種Ｃａｌｌを行う。ステップＳ１０２に進み、ＡＰサーバ１０２はルータＲ１の機種 Ｃａｌｌに基づきルータＲ１の脆弱性検索依頼を行う。

ステップＳ１０３に進み、ＤＢサーバ１０３はルータＲ１の脆弱情報を脆弱性情報ＤＢ１０４から検索する。ステップＳ１０４〜Ｓ１０７に進み、ＤＢサーバ１０３から脆弱性情報登録クライアント１００に検索結果が通知される。脆弱性情報登録クライアント１００は、検索結果に基づき脆弱性情報更新画面を出力する。

ステップＳ１０８では、脆弱性情報登録クライアント１００に脆弱性バージョン範囲や推奨バージョン，使用（機能）コマンドが設定される。ステップＳ１０９に進み、ＷＥＢサーバ１０１は脆弱性情報更新ＡＰＬ Ｃａｌｌを行う。ステップＳ１１０に進み、ＡＰサーバ１０２は脆弱性情報更新ＡＰＬ Ｃａｌｌに基づき脆弱性情報ＤＢ１０４の更新依頼を行う。ステップＳ１１１に進み、ＤＢサーバ１０３は脆弱性情報ＤＢ１０４の更新依頼に基づいて脆弱性情報ＤＢ１０４を更新する。

ステップＳ１１２〜Ｓ１１５に進み、ＤＢサーバ１０３から脆弱性情報登録クライアント１００に更新結果が通知される。脆弱性情報登録クライアント１００は、更新結果を表示する。図９に示すように、ベンダ側では機器の脆弱情報を脆弱性情報ＤＢ１０４に登録できる。

図１０は、ベンダ側からセンター側に脆弱性情報を通知する処理を示したフロー図である。ベンダ側には、ＷＥＢサーバ１０１，ＡＰサーバ１０２，ＤＢサーバ１０３，脆弱性情報通知クライアント１１０が設置されている。

ステップＳ２００では脆弱性情報通知クライアント１１０がルータＲ１を使用しているユーザへの脆弱性通知確認依頼を行う。ステップＳ２０１に進み、ＷＥＢサーバ１０１はルータＲ１を使用しているユーザへの脆弱性通知確認依頼に基づきサーブレット（振り分け）を行い、ルータＲ１のＵｓｅｒ Ｃａｌｌを行う。

ステップＳ２０２に進み、ＡＰサーバ１０２は、ルータＲ１のＵｓｅｒ Ｃａｌｌに基づきルータＲ１を使用しているユーザの検索依頼を行う。ステップＳ２０３に進み、ＤＢサーバ１０３は図１１に示すＲ１ユーザＤＢ１１１を検索する。

図１１はＲ１ユーザＤＢの一例の構成図である。Ｒ１ユーザＤＢ１１１はルータＲ１を使用しているユーザのユーザ名，そのユーザへの通知方式，ｅ−ｍａｉｌ ａｄｄｒｅｓｓ，Ｗｅｂ ａｄｄｒｅｓｓから構成されている。ＤＢサーバ１０３は、Ｒ１ユーザＤＢ１１１からユーザ名，通知方式，ｅ−ｍａｉｌ ａｄｄｒｅｓｓ，Ｗｅｂ ａｄｄｒｅｓｓを検索する。

ステップＳ２０４〜Ｓ２０７に進み、ＤＢサーバ１０３から脆弱性情報通知クライアント１１０に検索結果が通知される。脆弱性情報通知クライアント１１０は、検索結果に基づき通知ユーザ確認画面を出力する。

ステップＳ２０８では、脆弱性情報通知クライアント１１０がルータＲ１を使用しているユーザへの脆弱性情報通知依頼を行う。ステップＳ２０９に進み、ＷＥＢサーバ１０１はユーザ名「Ｔｓｕｄａ」を指定して、通知ＡＰＬ Ｃａｌｌを行う。

ステップＳ２１０に進み、ＡＰサーバ１０２は通知ＡＰＬ Ｃａｌｌに基づき脆弱性情報検索依頼を行う。ステップＳ２１１に進み、ＤＢサーバ１０３は脆弱性情報ＤＢ１０４からルータＲ１の脆弱性情報を検索する。ステップＳ２１２に進み、ＤＢサーバ１０３は検索結果をＡＰサーバ１０２に通知する。

ステップＳ２１３に進み、ＡＰサーバ１０２は、検索結果のルータＲ１の脆弱性情報をｅ−ｍａｉｌに設定し、Ｒ１ユーザＤＢ１１１から検索したｅ−ｍａｉｌ ａｄｄｒｅｓｓを宛先に設定する。ステップＳ２１４に進み、ＡＰサーバ１０２はｅ−ｍａｉｌを発信する。ステップＳ２１５〜Ｓ２１７に進み、ＡＰサーバ１０２から脆弱性情報通知クライアント１１０に結果が通知される。脆弱性情報通知クライアント１１０は、脆弱性通知結果を表示する。

また、ＷＥＢサーバ１０１はステップＳ２１６に続いてステップＳ２１８に進み、次のユーザ名「Ｏｏｔａ」を指定して、通知ＡＰＬ Ｃａｌｌを行う。ステップＳ２１９に進み、ＡＰサーバ１０２は、Ｒ１ユーザＤＢ１１１から検索したＷｅｂ ａｄｄｒｅｓｓをｅ−ｍａｉｌに設定し、Ｒ１ユーザＤＢ１１１から検索したｅ−ｍａｉｌ ａｄｄｒｅｓｓを宛先に設定する。

ステップＳ２２０に進み、ＡＰサーバ１０２はｅ−ｍａｉｌを発信する。ステップＳ２２１〜Ｓ２２３に進み、ＡＰサーバ１０２から脆弱性情報通知クライアント１１０に結果が通知される。脆弱性情報通知クライアント１１０は、脆弱性通知結果を表示する。図１０に示すように、ベンダ側ではルータＲ１を利用しているユーザに、Ｐｕｓｈメール方式やＷＥＢダウンロード方式、タイマー型ＷＥＢダウンロード方式でルータＲ１等の機器の脆弱性情報を通知できる。

図１２は、ＯＳバージョン取得用パトロールパケットによりルータＲ１，ルータＲ２に搭載されているソフトウェアのバージョンを取得する処理を示したフロー図である。セキュリティクライアント１６，ＷＥＢサーバ１２０，ＡＰサーバ１２１，ＤＢサーバ１２２はセンター側に設置されている。

ステップＳ３００ではセキュリティクライアント１６がネットワークシステムマップ作成依頼を行う。ステップＳ３０１に進み、ＷＥＢサーバ１２０はネットワークシステムマップ作成依頼に基づきサーブレット（振り分け）を行い、全ｎｅｔｗｏｒｋ ａｃｃｅｓｓのＡＰＬを起動する。

ステップＳ３０２に進み、ＡＰサーバ１２１はｓｎｍｐコマンドでネットワークシステムに含まれる各機器のＩＰアドレスを取得する。ステップＳ３０３に進み、ＡＰサーバ１２１は取得したＩＰアドレスを元にｓｎｍｐコマンドでルータＲ１，ルータＲ２等の各機器のバージョンを取得する。ステップＳ３０４に進み、ＡＰサーバ１２１は取得した各機器のバージョンをＤＢサーバ１２２に通知し、ネットワークシステムマップＤＢ更新依頼を行う。

ステップＳ３０５に進み、ＤＢサーバ１２２はＡＰサーバ１２１から受信した各機器のバージョンに基づき、ネットワークシステムマップＤＢ４６を更新する。ステップＳ３０６〜Ｓ３０８に進み、ＤＢサーバ１２２からＷＥＢサーバ１２０にネットワークシステムマップＤＢ４６の更新結果が通知される。ＷＥＢサーバ１２０はネットワークシステムマップ作成完了通知をセキュリティクライアント１６に対して行う。そして、ステップＳ３０９では、セキュリティクライアント１６がネットワークシステムマップ作成完了通知を受信する。図１２に示すように、ネットワークシステムを構成する機器毎に、その機器に搭載されたソフトウェアのバージョンを取得できる。

図１３は、脆弱性情報を取得する処理を示したフロー図である。セキュリティクライアント１６には、前述したようにＰｕｓｈメール方式やＷＥＢダウンロード方式のｅ−ｍａｉｌを各ベンダサイトＷＥＢから受信する。Ｐｕｓｈメール方式である場合、セキュリティクライアント１６はステップＳ４００〜Ｓ４０８の処理を行う。ＷＥＢダウンロード方式である場合、セキュリティクライアント１６は、ステップＳ４１０〜Ｓ４１８の処理を行う。

ステップＳ４００でＰｕｓｈメール方式であると判定すると、セキュリティクライアント１６は脆弱性情報更新依頼を行う。ステップＳ４０１に進み、ＷＥＢサーバ１２０は脆弱性情報更新依頼に基づきサーブレット（振り分け）を行い、Ｐｕｓｈ型のＡＰＬを起動する。

ステップＳ４０２に進み、ＡＰサーバ１２１はｅ−ｍａｉｌのＤＡＴＡ部の脆弱性情報を取得する。ステップＳ４０３に進み、ＡＰサーバ１２１は、取得した脆弱性情報をＤＢサーバ１２２に通知し、脆弱性情報ＤＢ更新依頼を行う。ステップＳ４０４に進み、ＤＢサーバ１２２はＡＰサーバ１２１から受信した各機器の脆弱性情報に基づき、脆弱性情報ＤＢ４７を更新する。ステップＳ４０５〜Ｓ４０８に進み、ＤＢサーバ１２２からＷＥＢサーバ１２０に脆弱性情報ＤＢ４７の更新結果が通知される。ＷＥＢサーバ１２０は脆弱性情報ＤＢ４７の更新完了をセキュリティクライアント１６に通知する。

ステップＳ４１０でＷＥＢダウンロード方式であると判定すると、セキュリティクライアント１６は脆弱性情報更新依頼を行う。ステップＳ４１１に進み、ＷＥＢサーバ１２０は脆弱性情報更新依頼に基づきサーブレット（振り分け）を行い、ｗｅｂ型又はｔｉｍｅｒ型のＡＰＬを起動する。

ステップＳ４１２に進み、ＡＰサーバ１２１はｅ−ｍａｉｌのＤＡＴＡ部のｗｅｂアドレス内の脆弱性情報又は図１４に示すようなベンダｗｅｂアドレスＤＢ１３０に事前登録されているベンダｗｅｂアドレス内の脆弱性情報をダウンロードする。図１４はベンダｗｅｂアドレスＤＢの一例の構成図である。

ベンダｗｅｂアドレスＤＢ１３０は、機器毎に脆弱性バージョン範囲のダウンロード先である脆弱性Ｗｅｂ ａｄｄｒｅｓｓと、推奨バージョンのダウンロード先である推奨ＯＳ Ｗｅｂ ａｄｄｒｅｓｓとが事前登録されている。なお、ステップＳ４１３〜Ｓ４１８の処理はステップＳ４０３〜Ｓ４０８の処理と同様であるため、説明を省略する。図１３に示すように、ネットワークシステムを構成する機器毎に、その機器の脆弱性情報を取得できる。

図１５は、脆弱性情報を確認する処理を示したフロー図である。セキュリティクライアント１６には、前述したようにＰｕｓｈメール方式やＷＥＢダウンロード方式のｅ−ｍａｉｌを各ベンダサイトＷＥＢから受信する。すると、図１３を用いて前述したようなＰｕｓｈメール方式またはｗｅｂダウンロード方式の処理を行ったあと、ステップＳ５００に進む。

ステップＳ５００では、セキュリティクライアント１６が、脆弱性確認依頼を行う。ステップＳ５０１に進み、ＷＥＢサーバ１２０は脆弱性確認依頼に基づきサーブレット（振り分け）を行い、脆弱性確認のＡＰＬを起動する。

ステップＳ５０２に進み、ＡＰサーバ１２１は脆弱性情報ＤＢ検索依頼を行う。ステップＳ５０３に進み、ＤＢサーバ１２２はＡＰサーバ１２１から受信した各機器の脆弱性情報ＤＢ検索依頼に基づき、脆弱性情報ＤＢ４７を検索する。ステップＳ５０４〜Ｓ５０５に進み、ＤＢサーバ１２２からＡＰサーバ１２１に脆弱性情報ＤＢ４７の検索結果が通知される。

ステップＳ５０６に進み、ＡＰサーバ１２１はネットワークシステムマップＤＢ検索依頼を行う。ステップＳ５０７に進み、ＤＢサーバ１２２はＡＰサーバ１２１から受信したネットワークシステムマップＤＢ検索依頼に基づき、ネットワークシステムマップＤＢ４６を検索する。ステップＳ５０８〜Ｓ５０９に進み、ＤＢサーバ１２２からＡＰサーバ１２１にネットワークシステムマップＤＢ４６の検索結果が通知される。

ステップＳ５１０に進み、ＡＰサーバ１２１はＤＢサーバ１２２から通知された脆弱性情報ＤＢ４７の検索結果およびネットワークシステムマップＤＢ４６の検索結果を比較する。そして、ステップＳ５１１に進み、ＡＰサーバ１２１はルータＲ１，Ｒ２に搭載されているソフトウェアの更新要否を判定すると共に、推奨バージョンを取得し、比較結果を設定する。

ステップＳ５１２〜Ｓ５１４に進み、ＡＰサーバ１２１からセキュリティクライアント１６に比較結果が通知される。セキュリティクライアント１６は通知された比較結果に基づいて、図１５に示すような完了メッセージを表示する。図１５に示すように、脆弱性情報ＤＢ４７およびネットワークシステムマップＤＢ４６を比較し、ルータＲ１，Ｒ２に搭載されているソフトウェアの更新要否を判定できる。なお、前述の図８のステップＳ２１からステップＳ２５の処理はステップＳ５１０に、図８のステップＳ２７はステップＳ５１２からステップＳ５１４に相当する。

本発明は、以下に記載する付記のような構成が考えられる。
（付記１）
所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するコンピュータのソフトウェア更新要否判定方法であって、
前記コンピュータが、前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報を取得して記憶装置に格納する格納ステップと、
前記コンピュータが、前記記憶装置に格納されている前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報に基づき、前記機器に搭載されたソフトウェアのうち脆弱性のあるものを選択する選択ステップと、
選択された前記ソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定する判定ステップと
を有することを特徴とするソフトウェア更新要否判定方法。
（付記２）
前記判定ステップは、選択された前記ソフトウェアのうち最後に利用されてから所定期間以上経過したものを更新が不要と判定することを特徴とする付記１記載のソフトウェア更新要否判定方法。
（付記３）
前記機器に搭載されたソフトウェアに関する情報は、前記ソフトウェアの識別情報および利用履歴情報を含むことを特徴とする付記１又は２記載のソフトウェア更新要否判定方法。
（付記４）
前記判定ステップによる判定結果をユーザに通知する通知ステップを更に有することを特徴とする付記１乃至３何れか一項記載のソフトウェア更新要否判定方法。
（付記５）
所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するコンピュータにおいて実行されるソフトウェア更新要否判定プログラムであって、
前記コンピュータは、記憶装置，演算処理装置を含み、
前記演算処理装置に、前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報を取得させて前記記憶装置に格納させる格納ステップと、
前記記憶装置に格納されている前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報に基づき、前記機器に搭載されたソフトウェアのうち脆弱性のあるものを選択させる選択ステップと、
選択された前記ソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定させる判定ステップと
を実行させるソフトウェア更新要否判定プログラム。
（付記６）
所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するソフトウェア更新要否判定装置であって、
前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報を取得して記憶装置に格納する情報取得格納手段と、
前記記憶装置に格納されている前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報に基づき、前記機器に搭載されたソフトウェアのうち脆弱性のあるものを選択するソフトウェア選択手段と、
選択された前記ソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定する更新判定手段と
を有することを特徴とするソフトウェア更新要否判定装置。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

ネットワークシステムの一例のシステム構成図である。 本発明によるネットワークシステムの一実施例の構成図である。 セキュリティクライアントの一例のハードウェア構成図である。 セキュリティクライアントの一例のソフトウェア構成図である。 構成／脆弱性確認ツールの処理を説明する為の図である。 ネットワークシステムマップＤＢの一例の構成図である。 稼動情報取得ツールの処理を説明する為の図である。 脆弱性確認ツールの処理を説明する為の図である。 ベンダ側で脆弱情報を登録する処理を示したフロー図である。 ベンダ側からセンター側に脆弱性情報を通知する処理を示したフロー図である。 Ｒ１ユーザＤＢの一例の構成図である。 ＯＳバージョン取得用パトロールパケットによりルータＲ１，ルータＲ２に搭載されているソフトウェアのバージョンを取得する処理を示したフロー図である。 脆弱性情報を取得する処理を示したフロー図である。 ベンダｗｅｂアドレスＤＢの一例の構成図である。 脆弱性情報を確認する処理を示したフロー図である。

符号の説明

１ａ，１ｂ サーバ
２，１１ クライアント
３，１４ 広域イーサーネット（登録商標）
４，１５ ＩＮＳ網
１０ａ，１０ｂ 業務サーバ
１６ セキュリティクライアント
１７，１８ 脆弱性情報
１９，２０，Ｒ１，Ｒ２ ルータ
２１ インターネット
３１ 入力装置
３２ 出力装置
３３ ドライブ装置
３４ 補助記憶装置
３５ メモリ装置
３６ 演算処理装置
３７ インターフェース装置
３８ 記録媒体
４１ 構成／脆弱性確認ツール
４２ 稼動情報取得ツール
４３ 脆弱性確認ツール
４４ 提案テンプレート
４５ 脆弱性情報開発元ＤＢ
４６ ネットワークシステムマップＤＢ
４７ 脆弱性情報ＤＢ

Claims (3)

1. 所定のネットワークシステムを構成する機器に搭載されたソフトウェアの更新要否を判定するコンピュータのソフトウェア更新要否判定方法であって、
   前記コンピュータが、前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報を取得して記憶装置に格納する格納ステップと、
   前記コンピュータが、前記記憶装置に格納されている前記機器に搭載されたソフトウェアに関する情報および前記ソフトウェアの脆弱性に関する情報に基づき、前記機器に搭載されたソフトウェアのうち脆弱性のあるものを選択する選択ステップと、
   選択された前記ソフトウェアのうち利用実績のあるソフトウェアを更新が必要と判定する判定ステップと
   を有することを特徴とするソフトウェア更新要否判定方法。
2. 前記判定ステップは、選択された前記ソフトウェアのうち最後に利用されてから所定期間以上経過したものを更新が不要と判定することを特徴とする請求項１記載のソフトウェア更新要否判定方法。
3. 前記機器に搭載されたソフトウェアに関する情報は、前記ソフトウェアの識別情報および利用履歴情報を含むことを特徴とする請求項１又は２記載のソフトウェア更新要否判定方法。

Images