(57)【要約】【課題】複数の異なる製品に実装されるソフトウェアの脆弱性について、迅速かつ的確に対応し、実際の製品に対する影響調査や関係者等への報告等も効率的に行う。【解決手段】対象製品に実装されたソフトウェアについての脆弱性を管理する脆弱性システム１が、対象製品の所定の構成情報を収集して構成情報ＤＢ２１に記憶させる構成情報収集部１１と、公開又は発見された所定の脆弱性情報を収集して脆弱性ＤＢに記憶させる脆弱性情報収集部１２と、構成情報及び前記脆弱性情報に基づいて、脆弱性の影響調査を行うべき対象製品を抽出する対象製品洗い出し部１３と、対象製品洗い出し部１３により抽出された対象製品に実装されたソフトウェアの脆弱性についての影響調査を実行する影響調査部１４と、影響調査の結果を示すレポート情報を生成し、所定のタイミングで所定の送信先に送信する結果レポート部１５を備える。【選択図】図２
2020021309.tif 000002
【特許請求の範囲】
【請求項１】
対象製品に実装されたソフトウェアについての脆弱性を管理するシステムであって、
前記対象製品の所定の構成情報を収集して構成情報データベースに記憶させる構成情報収集部と、
公開又は発見された所定の脆弱性情報を収集して脆弱性データベースに記憶させる脆弱性情報収集部と、
前記構成情報及び前記脆弱性情報に基づいて、脆弱性の影響調査を行うべき対象製品を抽出する対象製品洗い出し部と、
前記対象製品洗い出し部により抽出された対象製品に実装されたソフトウェアの脆弱性についての影響調査を実行する影響調査部を備える
ことを特徴とする脆弱性管理システム。
【請求項２】
前記影響調査部で実行された影響調査の結果を示すレポート情報を生成し、当該レポート情報をレポートデータベースに記憶させるとともに、所定のタイミングで所定の送信先に送信する結果レポート部を備える
ことを特徴とする請求項１に記載の脆弱性管理システム。
【請求項３】
前記結果レポート部でレポート情報が生成された対象製品についての所定の対応状況情報を生成して対応状況データベースに記憶させるとともに、前記レポートデータベース及び対応状況データベースに記憶された情報を参照可能に出力させる製品対応判断ワークフロー記録部を備える
ことを特徴とする請求項２に記載の脆弱性管理システム。
【請求項４】
前記影響調査部は、
前記構成情報中に、前記脆弱性情報に対応する情報が含まれる場合に脆弱性が再現されると判定する第一の影響調査を実行するとともに、
前記構成情報による影響調査で脆弱性が再現されると判定された場合に、当該脆弱性の概念実証情報を前記対象製品に実装されたソフトウェアに適用して脆弱性の再現を実行させる第二の影響調査を実行する
ことを特徴とする請求項１乃至３のいずれか一項に記載の脆弱性管理システム。
【請求項５】
対象製品に実装されたソフトウェアについての脆弱性を管理するシステムを構成する情報処理装置を、
前記対象製品の所定の構成情報を収集して構成情報データベースに記憶させる構成情報収集手段、
公開又は発見された所定の脆弱性情報を収集して脆弱性データベースに記憶させる脆弱性情報収集手段、
前記構成情報及び前記脆弱性情報に基づいて、脆弱性の影響調査を行うべき対象製品を抽出する対象製品洗い出し手段、
前記対象製品洗い出し手段により抽出された対象製品に実装されたソフトウェアの脆弱性についての影響調査を実行する影響調査手段、として機能させる
ことを特徴とする脆弱性管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットなどのネットワークに接続可能な製品に実装されるソフトウェアの脆弱性を管理するための支援技術に関し、特に、脆弱性情報の収集や影響調査等を効率的に行えるようにする脆弱性管理システム及びプログラムに関する。
【背景技術】
【０００２】
ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）の進展に伴い、これまでインターネットなどのネットワークに接続されることが想定されていなかった製品についてもネットワーク接続が可能となり、それらの製品に実装されるソフトウェアの脆弱性の管理が重要となっている。
これまで、ネットワーク接続を前提とするＰＣやＷｅｂサーバ，ＯＡ機器などのＩＴ製品・情報システムの分野では、ソフトウェアの脆弱性管理は、国・企業・団体を含めて整備が進んでおり、例えば企業単位でのＣＳＩＲＴ（Ｃｏｍｐｕｔｅｒ  Ｓｅｃｕｒｉｔｙ  Ｉｎｃｉｄｅｎｔ  Ｒｅｓｐｏｎｓｅ  Ｔｅａｍ）による確立された脆弱性管理が行われている。
【０００３】
一方、これまでネットワーク接続を前提としていなかった製品、例えば自動車，カーナビ，家電製品などの組込み系の製品・デバイス等についても、ＩｏＴ製品としてネットワークに接続されるようになり、そのような製品に実装されるソフトウェアの脆弱性管理の重要性・必要性が高まっている。
このため、ＣＳＩＲＴの製品版に相当するＰＳＩＲＴ（Ｐｒｏｄｕｃｔ  Ｓｅｃｕｒｉｔｙ  Ｉｎｃｉｄｅｎｔ  Ｒｅｓｐｏｎｓｅ  Ｔｅａｍ）による脆弱性管理の整備が検討されている。
【０００４】
特に、ＩｏＴの対象となる製品では、コスト低減などの観点から既製のソフトウェアやＯＳＳ（Ｏｐｅｎ  Ｓｏｕｒｃｅ  Ｓｏｆｔｗａｒｅ）が使用されることも多く、脆弱性情報も例えば年間１〜２万件が報告・公開等され、それらの情報が日々更新されている。
このため、ＩｏＴ製品についての効率的かつ迅速・的確な脆弱性の管理体制の構築・整備は喫緊の課題となってきている。
【０００５】
一般に、ソフトウェアの脆弱性の管理としては、例えばＯＳＳ等のソースファイルについては、脆弱性情報を格納しているデータベースが存在しており、ソフトウェアエンジニアが開発時にそのような脆弱性ＤＢを参照して、開発対象ソフトウェアに脆弱性がないかどうかを確認することで行われている。
この種のソフトウェアの脆弱性の管理・分析等に関する技術としては、例えば特許文献１に提案されている「脆弱性分析のための自律型推論システム」などがある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１６−１６７２６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に開示されている技術を含めて、これまでのソフトウェアの脆弱性管理は、対象となる製品・ソフトウェアについて、個々に脆弱性の有無や検証・影響調査などを行っているため、効率が悪く、特にＩｏＴ製品のように多種多様な異なる製品に実装される多数の既成のソフトウェアやＯＳＳの脆弱性について、迅速・的確に対応することは、現実には困難乃至不可能であった。
ＣＳＩＲＴが対象とするＩＴ製品・情報システムの分野では、対象となるＰＣやサーバＯＡ機器などの情報機器やソフトウェアはある程度限られており、例えば情報システムを利用・提供する企業や業種等が異なっても、統一的・画一的な脆弱性の管理体制で対応することが可能であった。
【０００８】
これに対して、ＩｏＴ製品では、対象となるのは種々異なる多数の製品であり、実装されるソフトウェアもそれぞれ異なり、既製のソフトウェアやＯＳＳが実装されることも少なくない。このため、管理対象となるソフトウェアやそれらの脆弱性は膨大な数になることもあり、また、日々刻一刻と脆弱性が発見・報告されることもある。
また、対象製品のソフトウェアに脆弱性が見つかれば、製品の提供者・製造者のみならず、製品の使用者・一般ユーザなど多くの利害関係者に影響を及ぼすおそれがある。
このため、特にＩｏＴ製品のソフトウェアの脆弱性については、効率的な管理と、迅速かつ的確な対応が求められることになるところ、現在まで有効な解決手段や技術は提供されていない。
【０００９】
本発明は、上記のような課題を解決するために提案されたものであり、複数の異なる製品に実装されるソフトウェアの脆弱性について、迅速かつ的確な対応を可能とし、実際の製品に対する影響調査や関係者等への報告等も効率的に行うことができる、ＩｏＴ製品を対象とするＰＳＩＲＴに好適な脆弱性管理システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明は、対象製品に実装されたソフトウェアについての脆弱性を管理するシステムであって、前記対象製品の所定の構成情報を収集して構成情報データベースに記憶させる構成情報収集部と、公開又は発見された所定の脆弱性情報を収集して脆弱性データベースに記憶させる脆弱性情報収集部と、前記構成情報及び前記脆弱性情報に基づいて、脆弱性の影響調査を行うべき対象製品を抽出する対象製品洗い出し部と、前記対象製品洗い出し部により抽出された対象製品に実装されたソフトウェアの脆弱性についての影響調査を実行する影響調査部を備える構成としてある。
【００１１】
また、本発明は、上記のような本発明に係る脆弱性管理システムで実行されるプログラムとして構成することができる。
さらに、本発明は、上記のような本発明に係る脆弱性管理システム及びプログラムによって実施可能な方法として実施することもできる。
【発明の効果】
【００１２】
本発明によれば、複数の異なる製品に実装されるソフトウェアの脆弱性について、迅速かつ的確な対応が可能となり、実際の製品に対する影響調査や関係者等への報告等も効率的に行うことが可能となる。
このため、特にＩｏＴ製品を対象とするＰＳＩＲＴに好適な脆弱性管理システムを実現することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態に係る脆弱性管理システムの全体構成を模式的に示す説明図である。
【図２】脆弱性管理システムにおける各装置の構成を示す機能ブロック図である。
【図３】脆弱性管理システムの動作の全体を示すフローチャートである。
【図４】脆弱性管理システムにおける、（ａ）は構成情報の収集、（ｂ）は脆弱性情報の収集の各動作を示すフローチャートである。
【図５】脆弱性管理システムにおける、（ａ）は対象製品の洗い出し、（ｂ）は影響調査の各動作を示すフローチャートである。
【図６】脆弱性管理システムの影響調査における、（ａ）は構成情報と脆弱性再現フローを示す説明図、（ｂ）は脆弱性再現手法の実行を模式的に示す説明図である。
【図７】脆弱性管理システムにおける、（ａ）は結果レポート、（ｂ）は製品対応の判断ＷＦ記録、（ｃ）は監査処理の各動作を示すフローチャートである。
【図８】脆弱性管理システムにおける脆弱性管理サーバ又はユーザ端末又は脆弱性情報源サーバのハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【００１４】
以下、本発明に係る脆弱性管理システム及びプログラムの実施形態について、図面を参照しつつ説明する。
ここで、以下に示す本発明の脆弱性管理システムは、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理，手段，機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段，機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。
【００１５】
なお、プログラムの全部又は一部は、例えば、磁気ディスク，光ディスク，半導体メモリ，その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
また、本システムは、単一の情報処理装置（例えば一台のパーソナルコンピュータ等）で構成することもでき、複数の情報処理装置（例えば複数台のサーバコンピュータ群等）で構成することもできる。
【００１６】
［システム構成］
図１に示すように、本発明の一実施形態に係る脆弱性管理システム１（以下「本システム１」という）は、脆弱性管理サーバ１０と、一又は二以上のユーザ端末３０（３０ａ〜３０ｎ）と、一又は二以上の脆弱性情報原サーバ４０（４０ａ〜４０ｎ）とを備えて構成されている。
そして、これら脆弱性管理サーバ１０・ユーザ端末３０・脆弱性情報原サーバ４０は、ＬＡＮ・ＷＡＮ等を含むインターネット１００を介して接続され、それぞれ相互にネットワーク通信が可能となっている。
【００１７】
ここで、脆弱性管理サーバ１０とユーザ端末３０は、例えば同一の組織・企業等に設置される情報処理装置によって構成することができる。この場合には、脆弱性情報源サーバ４０は本システム１に接続される外部装置として機能し、本システム１は脆弱性管理サーバ１０及びユーザ端末３０によって構成されることになり、本システム１を、例えば同一の組織・企業単位で設置されるＰＳＩＲＴやＣＳＩＲＴ等のシステムとして機能させことができる。
【００１８】
また、脆弱性管理サーバ１０とユーザ端末３０は、それぞれ異なる組織・企業等に設置される情報処理装置によって構成することができ、例えば、脆弱性管理サーバ１０は、本システム１をＰＳＩＲＴサービスとして提供する企業に設置される情報処理装置、ユーザ端末３０は、管理対象となる対象製品を製造・販売等する製造業者・ベンダー等に設置される情報処理装置によって構成することもできる。この場合には、ユーザ端末３０及び脆弱性情報源サーバ４０が本システム１に接続される外部装置として機能することになり、本システム１は脆弱性管理サーバ１０のみによって構成されることになる。
【００１９】
［脆弱性管理サーバ］
脆弱性管理サーバ１０は、管理対象となる対象製品に実装されたソフトウェアについての脆弱性を管理する本システム１の中核となる情報処理装置であり、本発明の脆弱性管理システムを構成している。
この脆弱性管理サーバ１０は、例えば、１又は２以上のサーバコンピュータやパーソナルコンピュータ、クラウドコンピューティングサービス上に構築された１又は２以上の仮想サーバからなるサーバシステム等、所定のプログラム（ソフトウェア）が実装された情報処理装置によって構成することができる。
【００２０】
そして、本実施形態に係る脆弱性管理サーバ１０は、図２に示すように、構成情報収集部１１，脆弱性情報収集部１２，対象製品洗い出し部１３，影響調査部１４，結果レポート部１５，製品対応判断ＷＦ（ワークフロー）記録部１６，監査処理部１７の各部として機能するように構成される。
また、脆弱性管理サーバ１０には、所定の記憶手段によって構成される複数のデータベース（ＤＢ）が構築されており、具体的には、構成情報ＤＢ２１，脆弱性ＤＢ２２，影響調査ＤＢ２４，レポート結果ＤＢ２５，ユーザＤＢ２６，対応状況ＤＢ２７の各ＤＢ（データベース）が備えられており、それぞれ所定のデータがデータベースとして管理されるようになっている。
【００２１】
［構成情報収集部］
構成情報収集部１１は、本システム１においてソフトウェアの脆弱性の管理対象となる対象製品についての所定の構成情報を収集して構成情報ＤＢ２１に記憶させる。
具体的には、構成情報収集部１１は、対象製品（例えば自動車，カーナビ，家電製品などの組込み系の製品・デバイス等）に実装されているソフトウェアのソースコードから、対象製品やソフトウェアを特定するための構成情報（静的情報）を直接読み出して抽出・収集することができる。例えば、対象製品に実装されているＯＳ（オペレーティングシステム）のコマンド機能（例えばＬｉｎｕｘＯＳのｌｄｄコマンド等）を用いることにより、必要な情報を読み出すことができる。
この場合、脆弱性管理サーバ１０の近傍に用意された対象製品（図１参照）と脆弱性管理サーバ１０とをケーブル・外部接続ポート等を介して接続することにより、構成情報収集部１１が対象製品のソフトウェアに直接アクセスして、必要な構成情報を読み出すことができる。
【００２２】
また、構成情報収集部１１は、対象製品の構成情報として、例えば当該対象製品の製造業者・ベンダー等において予め記録・管理されている情報を、脆弱性管理サーバ１０で受信・入力することにより、所定の構成情報を収集・取得することもできる。
この場合には、構成情報収集部１１は、例えばメール受信や入力手段による入力操作を介して構成情報を示すデータ（例えばＣＳＶファイル形式のデータ）を受信・入力して、所定の構成情報を収集・取得することができる。
【００２３】
以上のような構成情報収集部１１による構成情報の収集は、例えば、対象製品の本システム１への新規登録時や、製品のＵｐｄａｔｅ時のタイミングで実施される。
また、対象となるＯＳ情報や実行ファイル情報が新規の場合（新規性あり）にも、構成情報の収集が実行される。
構成情報収集部１１で収集された構成情報は、構成情報ＤＢ２１に記憶されてデータベースとして管理され、以後の処理において随時読み出され、また、更新される。
構成情報収集部１１における構成情報収集の具体的な処理・動作については、図４（ａ）を参照しつつ後述する。
【００２４】
ここで、構成情報収集部１１で収集され構成情報ＤＢ２１に格納される所定の構成情報は、管理対象となる各対象製品及び実装されるソフトウェア等を特定するための情報であり、具体的には例えば以下のような情報（静的情報）がある。
なお、以下に示す構成情報は、本システム１に適用可能な情報の一例であって、特に以下の情報のみに限定されるものではなく、本システム１として必要な情報を追加・削除等することができる。
【００２５】
［構成情報ＤＢ］
・製品ＩＤ
・製品名，バージョン
・登録日付
・システム基盤情報
−Ｆｉｒｅｗａｌｌの有無
−ＷＡＦの有無
・ＯＳ情報
−ＯＳ名，バージョン
−カーネル名，カーネルバージョン
−ＯＳ攻撃緩和策の有無
・ＡＳＬＲ
・ＮＸ  ｂｉｔ（No  eXecute  bit）
−ホスト型Ｆｉｒｅｗａｌｌの有無
−ローカルアクセス方法の有無
−外部ＩＦの一覧
・実行ファイル情報
−ソフト名、バージョン
−ファイルパス
−外部呼出し情報
・ライブラリ名、バージョン
・ライブラリのファイルパス
・関数名
−攻撃緩和策の有無
・Ｃａｎａｒｙ
・ＲＥＬＲＯ
・ＰＩＥ
−設定値
・機能ＯＮ/ＯＦＦ
・設定パラメータ
【００２６】
［脆弱性情報収集部］
脆弱性情報収集部１２は、公開又は発見された所定の脆弱性情報を収集して脆弱性ＤＢ２２に記憶させる。
具体的には、脆弱性情報収集部１２は、後述するＣＶＥ，ＪＶＮなどの脆弱性情報源サーバ４０にインターネット１００を介してアクセスし、各脆弱性情報源サーバ４０で公開・提供されている脆弱性情報を受信・収集することができる。
この脆弱性情報収集部１２による脆弱性情報の収集は、所定のタイミングで実行することができ、例えば１日１回所定の時刻に実行したり、新たな脆弱性情報や脆弱性再現手法が報告・公開されたタイミングで実行することができる。
脆弱性情報収集部１２で収集された脆弱性情報は、脆弱性ＤＢ２２に記憶されてデータベースとして管理され、以後の処理において随時読み出され、また、更新される。
脆弱性情報収集部１２における脆弱性情報収集の具体的な処理・動作については、図４（ｂ）を参照しつつ後述する。
【００２７】
ここで、脆弱性情報収集部１２で収集され脆弱性ＤＢ２２に格納される所定の脆弱性情報は、脆弱性が公開／発見されたソフトウェア及び該当する脆弱性等を特定するための情報であり、具体的には以下のような脆弱性情報がある。
なお、以下に示す脆弱性情報は、本システム１に適用可能な情報の一例であって、特に以下の情報のみに限定されるものではなく、本システム１として必要な情報を追加・削除等することができる。
【００２８】
［脆弱性ＤＢ］
・脆弱性ＩＤ
・脆弱性深刻度(ＣＶＳＳ（Common  Vulnerability  Scoring  System：共通脆弱性評価システム）値)
・登録日付
・対象ソフト名，対象バージョン範囲
・脆弱性再現手法
【００２９】
［対象製品洗い出し部］
対象製品洗い出し部１３は、構成情報ＤＢ２１に記憶された構成情報、及び脆弱性ＤＢ２２に記憶された脆弱性情報に基づいて、脆弱性の影響調査を行うべき対象製品を抽出する。
具体的には、対象製品洗い出し部１３は、各対象製品について、構成情報・脆弱性情報に基づき、脆弱性情報中に当該対象製品に実装されているソフトウェアのソフト名及びバージョンと一致するものがあるか否かを判定し、一致するソフトウェアがある場合には、脆弱性情報に示されるＣＶＳＳ値が所定の閾値以上のものについて、脆弱性の影響調査を行うべき対象製品を抽出する。
【００３０】
この対象製品洗い出し部１３による対象製品の抽出・洗い出しは、所定のタイミングで実行することができ、例えば構成情報ＤＢ２１や脆弱性ＤＢ２２が更新されたタイミングで実行することができる。
そして、対象製品洗い出し部１３では、抽出された影響調査を行うべき対象製品についての所定の影響調査情報を、影響調査ＤＢ２４に記憶させる。
影響調査ＤＢ２４に記憶された影響調査情報は、データベースとして管理され、以後の処理において随時読み出され、また、更新される。
対象製品洗い出し部１３における製品洗い出しの具体的な処理・動作については、図５（ａ）を参照しつつ後述する。
【００３１】
ここで、影響調査ＤＢ２４に記憶される情報としては、例えば以下のような情報がある。
なお、以下に示す影響調査情報は、本システム１に適用可能な情報の一例であって、特に以下の情報のみに限定されるものではなく、本システム１として必要な情報を追加・削除等することができる。
［影響調査ＤＢ］
・影響調査ＩＤ
・登録日
・関連する構成情報ＩＤ
・関連する脆弱性ＩＤ
・関連するＯＳソフト情報
・影響調査結果
−判定結果
−判定結果根拠
【００３２】
［影響調査部］
影響調査部１４は、対象製品洗い出し部１３により抽出された対象製品に実装されたソフトウェアの脆弱性についての影響調査を実行する。
具体的には、影響調査部１４は、影響調査ＤＢ２４に記憶された影響調査情報に基づいて、対象製品の構成情報中に、脆弱性情報に対応する情報が含まれる場合に脆弱性が再現されると判定する一次調査（第一の影響調査）を実行する。
また、影響調査部１４は、一次調査の結果、構成情報による影響調査で脆弱性が再現されると判定された対象製品について、当該脆弱性の概念実証情報となる再現手法を、対象製品に実装されたソフトウェアに適用して脆弱性の再現を実行させる二次調査（第二の影響調査）を実行する。
【００３３】
すなわち、本システム１における影響調査は、実行ファイル（アプリ本体，ライブラリ，ＯＳカーネル，ドライバ，ＢＩＯＳ等）における、静的情報（実行ファイル構造，呼出しライブラリと関数・設定情報，ＯＳ設定，ＦＷやＷＡＦ等のネットワーク構成と設定による情報）と、動的情報（実行時のメモリ情報，呼出し動的ライブラリと関数，スレッド状態，正常時動作，脆弱性再現手法による動作への影響による情報）に基づいて、（１）構成情報による影響調査（一次調査）と、（２）再現手法による影響調査（二次調査)の二段階の調査により、脆弱性を分析し、その影響を調査するようになっている。
提供調査部１４による一次調査・二次調査の調査結果は、影響調査情報として影響業差ＤＢ２４に記憶され、結果レポート部１５によるレポート生成の基礎情報として用いられる。
影響調査部１４における影響調査の処理の詳細については、図５（ｂ）及び図６を参照しつつ後述する。
【００３４】
［結果レポート部］
結果レポート部１５は、影響調査部１４で実行された影響調査の結果を示すレポート情報を生成する。
そして、結果レポート部１５は、生成されたレポート情報を、レポートＤＢ２５に記憶させるとともに、所定のタイミングで所定の送信先に送信する。
具体的には、結果レポート部１５は、ユーザＤＢ２６に記憶されている所定のユーザ情報に基づいて、該当する対象製品を製造・販売等するユーザ側に設置されたユーザ端末３０に、レポート情報を送信する。
【００３５】
レポート情報は、所定のフォーマット・項目で構成され、影響調査の結果をユーザに通知するために必要な所定の情報が含まれるように生成される。
例えば、レポート情報は、レポートＩＤ，対象製品／バージョン，サマリー情報（深刻度別の件数など），検知ＩＤ，深刻度，製品内で影響を受けるソフトウェア名／バージョン情報，脆弱性ＩＤ（ＣＶＥ番号など情報源のＩＤ），脆弱性タイトル，脆弱性のあるソフトウェアバージョン，ＣＶＳＳ値，深刻度の判定理由、などから構成される。
結果レポート部１５におけるレポート処理の詳細については、図７（ａ）を参照しつつ後述する。
【００３６】
［製品対応判断ＷＦ記録部］
製品対応判断ＷＦ記録部１６は、影響調査部１４及び結果レポート部１５で生成される影響調査のレポート結果を、ワークフロー情報として生成・記録して、本システム１の担当者や開発上長などの関係者が随時参照できるように出力・表示させる。
製品対応判断ＷＦ記録部１６で生成・出力されるワークフロー情報は、脆弱性管理サーバ１０に接続された端末装置などの出力手段（ディスプレイ・プリンタ等）を介して出力・表示され、関係者が参照・確認等することができ、また、入力手段（キーボード・マウス等）を介してワークフロー情報に対して必要な情報を入力・更新等することができる。
また、製品対応判断ＷＦ記録部１６で生成・出力されるワークフロー情報は、ユーザ端末３０において出力・表示させることもできる。
【００３７】
具体的には、製品対応判断ＷＦ記録部１６は、レポートＤＢ２５に記憶されたレポート情報に基づいて、結果レポート部１５でレポート情報が生成された対象製品についての所定の対応状況情報を生成して対応状況ＤＢ２７に記憶させる。
そして、製品対応判断ＷＦ記録部１６は、レポートＤＢ２５及び対応状況ＤＢ２７に記憶された情報を参照可能に出力させる所定のワークフロー情報の生成処理を実行する。
【００３８】
ワークフロー情報は、所定のフォーマット・項目で構成され、担当者や開発上長などの各関係者が参照・確認・承認等を行うために必要な所定の情報が含まれるように生成される。
例えば、ワークフロー情報は、レポートＩＤ，製品ＩＤ，検知ＩＤ，承認者ＩＤ，承認時刻，対策担当者ＩＤ，対策実施完了時刻，監査者ＩＤ，監査完了時刻，コメント欄，添付ファイル追加欄、などから構成される。
製品対応判断ＷＦ記録部１６におけるワークフロー処理の詳細については、図７（ｂ）を参照しつつ後述する。
【００３９】
［監査処理部］
監査処理部１７は、対応状況ＤＢ２７に記憶された各対象製品の対応状況に対して、所定の監査処理を実行する。
具体的には、監査処理部１７は、製品対応判断ＷＦ記録部１６のワークフロー処理によって記録・更新・承認等された対応状況ＤＢ２７の格納情報から、監査対象となる所定情報を抽出し、例えば開発上長や責任者などの監査担当者による監査が行えるように、監査対象情報を出力・表示させ、また、監査が行われたことを示す監査結果情報を生成して、対応状況ＤＢ２７に記憶・更新させる。
【００４０】
監査処理部１７で抽出・出力される監査対象情報は、脆弱性管理サーバ１０に接続された端末装置などの出力手段（ディスプレイ・プリンタ等）を介して出力・表示され、監査担当者が参照・確認等することができ、また、入力手段（キーボード・マウス等）を介して監査対象情報に対して必要な情報を入力・記録等することができる。
また、監査処理部１７で生成・出力される監査情報（監査対象情報・監査結果情報）は、ユーザ端末３０において出力・表示させることもできる。
【００４１】
監査情報（監査対象情報・監査結果情報）は、所定のフォーマット・項目で構成され、監査担当者が参照・確認・承認等を行うために必要な所定の情報が含まれるように生成される。
例えば、監査情報（監査対象情報・監査結果情報）は、全体監査サマリー，レポートＩＤ，レポート別監査サマリー，製品ＩＤ，検知ＩＤ，ワークフローＩＤ，監査結果情報、などから構成される。
監査処理部１７における監査処理の詳細については、図７（ｃ）を参照しつつ後述する。
【００４２】
［ユーザ端末］
ユーザ端末３０（３０ａ〜３０ｎ）は、インターネット１００を介して脆弱性管理サーバ１０に接続された、例えばＰＣ、タブレット端末、スマートフォン等で構成される、管理対象となる対象製品を製造・販売等する製造業者・ベンダー等に設置される情報処理装置によって構成することができる。
このようなユーザ端末３０を備えることにより、ユーザ端末３０を使用するユーザは、インターネット１００を介して、脆弱性管理サーバ１０から対象製品の影響調査のレポート情報をユーザ端末３０により受信することができ、また、脆弱性管理サーバ１０に対象製品の所定の構成情報をユーザ端末３０から送信・入力するｌことができるようになる。
【００４３】
［脆弱性情報源サーバ］
脆弱性情報源サーバ４０（４０ａ〜４０ｎ）は、インターネット１００を介して脆弱性管理サーバ１０に接続された、脆弱性情報を提供する事業者等のデータセンタやオフィスなどに設置されるＰＣやサーバ群等によって構成される情報処理装置であり、脆弱性管理サーバ１０に対して、発見・公開等されている脆弱性情報を送信・提供する手段として機能する。脆弱性情報源サーバ４０から送信・提供された脆弱性情報は、脆弱性情報収集部１２によって脆弱性ＤＢ２２に格納される。
このような脆弱性情報源サーバ４０としては、例えば、ＮＶＤ（National  Vulnerability  Database）が管理を行っているＣＶＥ（Common  Vulnerabilities  and  Exposures），ＪＰＣＥＲＴ／ＣＣ及びＩＰＡ（Information-technology  Promotion  Agency,）が管理を行っているＪＶＮ（Japan  Vulnerability  Notes）など、インターネット上で脆弱性情報を公開・提供しているＷｅｂサーバなどが該当する。
【００４４】
［動作］
次に、以上のような本システム１における具体的な処理・動作（脆弱性管理方法の実施）について、図３〜図７を参照して説明する。
本システム１では、図３に示す一連の処理動作を自動実行することにより、公開/発見された脆弱性再現手法に対する脆弱性管理業務を効率化することができる。
具体的には、図３に示すように、本システム１は、製品の構成情報の収集（Ｓ３０１）→脆弱性情報の収集（Ｓ３０２）→対象製品の洗い出し（Ｓ３０３）→影響調査（Ｓ３０４）→結果レポート（Ｓ３０５）→製品対応の判断ＷＦ記録（Ｓ３０６）→監査（Ｓ３０７）の各処理を実行する。
以下、各処理の詳細を順次説明する。
【００４５】
［構成情報の収集］
製品の構成情報の収集（図３：Ｓ３０１）は、図４（ａ）に示すように、構成情報収集部１１により、静的情報の収集（Ｓ４０１）と、通常動作時の動的情報の収集（Ｓ４０２）が行われる。
構成情報の収集は、対象製品に実装されているソフトウェアから直接的に、又は、対象製品の製造者・ベンダー等から間接的に、必要な情報が収集・取得される。
構成情報の静的情報としては、上述のとおり、対象製品とソフトウェアを特定するための製品名やソフト名，識別情報，バージョン情報，実行ファイル情報などがある。
構成情報の動的情報としては、実行時のメモリ情報，呼出し動的ライブラリと関数，スレッド状態，正常時動作，脆弱性再現手法による動作への影響による情報などがある。
【００４６】
構成情報の収集は、対象製品の本システム１への新規登録時と、製品のＵｐｄａｔｅ時に実施され、また、対象製品に実装されるＯＳ情報や実行ファイル情報が新規性ありの場合に実施される。
収集された構成情報は、構成情報ＤＢ２１に格納され、各製品単位の情報としてデータベース管理される。
【００４７】
［脆弱性情報の収集］
脆弱性情報の収集（図３：Ｓ３０２）は、図４（ｂ）に示すように、脆弱性情報収集部１２により、脆弱性情報の収集（Ｓ４０３）が行われる。
脆弱性情報の収集は、ＣＶＥ，ＪＶＮなどの脆弱性情報源サーバ４０にインターネット１００を介してアクセスすることにより、必要な情報が収集・取得される。
脆弱性情報としては、上述のとおり、対象とソフトウェアを特定するためのソフト名，バージョン情報，脆弱性の識別情報（ＩＤ），脆弱性の深刻度を示す情報（ＣＶＳＳ値），脆弱性再現手法などがある。
静寂性情報の収集は、定期的（例えば１日１回所定の時刻）に実施され、また、新たな脆弱性情報や脆弱性再現手法が報告・公開される都度実施される。
収集された脆弱性情報は、脆弱性ＤＢ２２に格納され、各脆弱性単位の情報としてデータベース管理される。
【００４８】
［対象製品の洗い出し］
対象製品の洗い出し（図３：Ｓ３０３）は、図５（ａ）に示すように、対象製品洗い出し部１３により、構成情報ＤＢ２１及び脆弱性ＤＢ２２の格納情報に基づく項目の抽出（Ｓ５０１）が行われる。この項目の抽出処理は、構成情報ＤＢ２１や脆弱性ＤＢ２２が更新される都度実施される。
具体的には、項目の抽出処理（Ｓ５０１）は、まず、構成情報・脆弱性情報に基づき、脆弱性情報中に当該対象製品に実装されているソフトウェアのソフト名及びバージョンと一致するものがあるか否かの判定が行われる（Ｓ５０２）。一致するものがなければ処理は終了し、全ての脆弱性について同様の処理が繰り返される。
【００４９】
次に、脆弱性情報中に、対象製品とソフトウェア名及びバージョンが一致する情報がある場合には、該当する脆弱性情報に示されるＣＶＳＳ値についての判定が行われ（Ｓ５０３）、ＣＶＳＳ値が所定の閾値（例えばＣＶＳＳ値４．０）以上であるか否かが判定される。ＣＶＳＳ値が閾値以下の場合には、脆弱性としての危険度が低く対象製品への影響がないものと判断でき、処理は終了し、全ての脆弱性について同様の処理が繰り返される。
ＣＶＳＳ値が所定の閾値を超える場合には、当該脆弱性についての影響調査を行う必要があるとして、影響調査ＤＢ２４に所定の影響調査情報が記録され（Ｓ５０４）、次処理の影響調査（図３：Ｓ３０４）が実行される。
【００５０】
以上の処理が、構成情報ＤＢ２１及び脆弱性ＤＢ２２に登録されている全対象製品及び全脆弱性について繰り返し実行される。
影響調査ＤＢ２４に記録される影響調査情報としては、上述のとおり、実行される影響調査と対象製品・ソフトウェアを特定するための識別情報があり、また、影響調査が実行されると、その影響調査の結果を示す情報も、対応する影響調査情報に対応付けて記録される（図５：Ｓ５０９）。
【００５１】
［影響調査］
影響調査（図３：Ｓ３０４）は、影響調査部１４により実行され、図５（ｂ）に示すように、影響調査ＤＢ２４の格納情報に基づく影響調査対象項目の抽出（Ｓ５０５）が行われる。この対象項目の抽出処理は、上述した対象製品洗い出し処理において影響調査ＤＢ２４が更新される都度実施される。
具体的には、項目の抽出処理（Ｓ５０５）は、まず、構成情報による影響調査（Ｓ５０６）が実行される。
【００５２】
［構成情報による影響調査］
図６（ａ）に、構成情報による影響調査における構成情報と脆弱性再現フローの一例を示す。
同図中、矢印が「×」印の箇所に到達する場合に、脆弱性が再現する（影響ありと判定される）ことを表現している。
また、矢印は脆弱性再現の流れを表しており、この矢印が通過する各構成要素が一つでも存在しない/ブロックしている場合には、脆弱性は再現しないと判定することができる。
構成情報による影響調査では、これら各構成要素の存在の有無、及び設定情報による活性／非活性状態を確認することにより、脆弱性が再現するかを根拠付けて確認・判定が実行される。
【００５３】
以下の表１に、構成情報による影響調査における調査方法と影響があると判定される条件をします。表中の（１）〜（７）は、図６（ａ）に示す（１）〜（７）に対応している。
【表１】
2020021309.tif 000003
【００５４】
上記のような構成情報による影響調査により「影響あり」と判定された脆弱性については、再現手法が存在するか否かが判断される（Ｓ５０７）。
そして、該当する再現手法が存在する場合には、その再現手法による影響調査（Ｓ５０８）が実行される。
【００５５】
［再現手法による影響調査］
図６（ｂ）に、脆弱性再現手法による影響調査の実行を模式的に示す。
同図に示すように、再現手法による影響調査では、脆弱性の概念実証（脆弱性ＰｏＣ：Ｐｒｏｏｆ  ｏｆ  Ｃｏｎｃｅｐｔ)プログラムを用いて、脆弱性が再現するか否かが確認・判定される。
脆弱性ＰｏＣは、一般的にセキュリティ研究者が公開しているものや、脆弱性の技術情報などから独自でプログラムを作成したものがあり、これらの脆弱性ＰｏＣを再現手法による影響調査に用いることができる。なお、このような脆弱性ＰｏＣは、脆弱性情報源サーバ４０から取得され、脆弱性ＤＢ２２に記憶されている。
【００５６】
なお、脆弱性ＰｏＣは、特定環境向け（例えば特定ＶｅｒｓｉｏｎのライブラリやＯＳのバイナリ構造/ＩＰ/ポート番号向け等）に作られていることがほとんどである。
これらの特定環境向けの脆弱性ＰｏＣを各対象製品別に手動によりカスタマイズするのは時間がかかり非効率となる。
そこで、本システム１では、そのような特定環境向けの脆弱性ＰｏＣを自動的に調整できるようにしている。
具体的には、予め用意したバイナリ情報/ＩＰ/ポート番号向けの情報を自動反映できるようにしておく。これによって。新たな脆弱性ＰｏＣが得られた際の脆弱性の再現を効率的に行うことができる。
【００５７】
以上のような脆弱性再現手法(プログラム化された脆弱性ＰｏＣ)は、対象製品に対してリモート／ローカルから適用・実行し、その結果、影響があると判断できるエラーが出力された場合や、通常の動作と異なる動きが発生した場合に、脆弱性の影響があると判定される。
ここで、影響があると判定される場合としては、例えば以下のような事象がる。
・アプリやサービスが停止する(ＯＳのＳＩＧＮＡＬによる強制停止等)。
・ＯＳが停止する(Ｋｅｒｎｅｌ  ｐａｎｉｃ等)。
・ハードウェアが動かなくなる／再起動する。
そして、以上の再現手法による影響調査の終了後は、影響調査結果が影響調査ＤＢ２４に記録され（Ｓ５０９）、処理は終了となる。
【００５８】
［結果レポート］
結果レポート（図３：Ｓ３０５）は、図７（ａ）に示すように、結果レポート部１５により実行され、まず、影響調査ＤＢ２４の格納情報が参照・検索され、上述した影響調査が行われた結果、「影響あり」の項目がある新規の影響調査情報の抽出が実行される（Ｓ７０１）。
次に、抽出された影響調査情報に基づいて、上述した所定のフォーマット・項目で構成されたレポート情報が生成される（Ｓ７０２）。生成されたレポート情報は、レポートＤＢ２５に格納される。
【００５９】
次いで、レポートＤＢ２５に格納されたレポート情報が、ユーザＤＢ２６に記憶されている所定のユーザ情報に基づいて、該当するユーザ端末３０に送信される（Ｓ７０３）。
このレポート情報の送信は、週次や月次等の定期的なスケジュールで送信されるようにすることができるが、新規の「影響あり」項目が抽出される都度送信されることが望ましく、特に影響度が深刻なものについては、日次や随時送信することが好ましい。
【００６０】
［製品対応の判断ＷＦ記録］
製品対応の判断ＷＦ記録（図３：Ｓ３０６）は、図７（ｂ）に示すように、製品対応判断ＷＦ記録部１６により実行され、所定のワークフロー情報が、担当者や開発上長などの関係者の端末装置で表示・確認・承認等されることにより必要な処理が行われる。
具体的には、まず、開発担当者によるレポート結果の確認（Ｓ７０４）が行われる。開発担当者は、自己が操作する端末装置等を介してワークフロー情報を表示させ、そこからレポートＤＢ２５に格納されているレポート情報にアクセスし、関連するレポート結果を表示・確認することができる。
次に、レポート結果を確認した開発担当者は、自己が操作する端末装置等を介しワークフロー情報を表示させ、そこから対応状況ＤＢ２７にアクセスして、該当するレポート結果に対する対応有無と判断理由を入力・記載することができる（Ｓ７０５）。記載された入力情報は、影響調査に対する対応状況を示す情報として、対応状況ＤＢ２７に記憶・格納される。
【００６１】
また、対応状況ＤＢ２７に格納された対応状況については、開発上長による承認が行われる（Ｓ７０６）。開発上長は、自己が操作する端末装置等を介してワークフロー情報を表示させ、そこから対応状況ＤＢ２７に格納されている対応状況情報にアクセスし、対応状況の内容を表示・確認し、承認を行うことができる。承認の有無や内容、対応の要否等を示す情報は、ワークフロー情報画面から入力され、対応する対応状況情報とともに対応状況ＤＢ２７に記録・更新される。
ここで、開発上長による承認の結果、対応が必要である認定・入力された場合には（Ｓ７０７）、必要な対応が実施され（Ｓ７０８）、対応結果が対応状況ＤＢ２７に記録された後（Ｓ７０９）、再度開発上長による承認を経ることにより（Ｓ７１０）、処理が完了となる。
【００６２】
［監査］
監査（図３：Ｓ３０７）は、図７（ｃ）に示すように、監査処理部１７により実行され、所定のワークフロー情報が、担当者や開発上長などの関係者の端末装置で表示・確認・承認等されることにより必要な処理が行われる。
まず、対応状況ＤＢが参照され、監査対象となる項目が抽出され（Ｓ７１１）、監査担当者による監査が行えるように、所定の端末装置等を介して監査対象情報が出力・表示される。
【００６３】
そして、抽出・出力された監査対象情報は、端末装置等を介して出力・表示され、監査担当者による各種確認等が行われ、監査対象情報に対して必要な情報が入力されると、それらの情報が監査結果情報として対応状況ＤＢ２７に記録される（Ｓ７１２）。
これによって、脆弱性の影響調査・対応状況などの結果が、責任のある監査担当者によって監査・承認されたことが記録され、必要な関係者が対応状況ＤＢ２７を参照することによって随時確認等することができるようになる。
【００６４】
以上説明したように、本システム１によれば、公開/発見された脆弱性再現手法に対する脆弱性管理業務（製品の構成情報の収集，脆弱性情報の収集，対象製品の洗い出し，影響調査，結果レポート，製品対応の判断ＷＦ記録，監査）を効率化することができる。
また、公開/発見されている脆弱性再現手法（脆弱性ＰｏＣや再現手順）を用いて、対象製品の実行ファイルに対する影響調査（影響有無の調査と根拠付けを導く調査）を新たな手法によって自動化することができる。
これによって、複数の異なる製品に実装されるソフトウェアの脆弱性について、迅速かつ的確な対応が可能となり、実際の製品に対する影響調査や関係者等への報告等も効率的に行うことが可能となる。このため、特にＩｏＴ製品を対象とするＰＳＩＲＴに好適な脆弱性管理システムを実現することができる。
【００６５】
なお、以上のような本実施形態に係る本システム１を構成する脆弱性管理サーバ１０やユーザ端末３０のハードウェア構成の一例は図８に示すとおりであり、ＣＰＵ１０１，ＲＡＭ１０２，ＲＯＭ１０３，ＨＤＤ１０４，入力装置１０５及び表示装置１０６を含む情報処理装置によって構成される。これらの構成要素はシステムバスで接続され、システムバスを介してデータのやり取りが行われる。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、中央処理装置ともいい、コンピュータの中心的な処理を行う部位であり、各装置の制御やデータの計算／加工を行う。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２は、メモリ装置の一種で、データの消去・書き換えが可能なものであり、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３は、半導体などを用いたメモリ装置の一種で、データ書き込みは製造時１回のみで、利用時には記録されたデータの読み出しのみできるものである。ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４は、磁性体の性質を利用し、情報を記録し読み出す補助記憶装置である。入力装置１０５は、ユーザがコンピュータに対して操作指示を行うため、あるいは、文字等を入力するために使用され、具体的には、キーボード，マウス等で構成される。表示装置１０６は、例えば液晶ディスプレイ等で構成され、タッチパネル機能を有するものであってもよい。この他、図示しない通信機能も有し、この通信機能により他の端末との通信が可能となる。
【００６６】
以上、本発明について好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態では、本発明が対象とする対象製品として、ＰＳＩＲＴが対象とする例えば自動車，カーナビ，家電製品などの組込み系の製品・デバイス等のＩｏＴ製品を例にとって説明したが、本発明を適用可能な対象製品としては、脆弱性の管理が必要となるソフトウェアが実装される製品であれば、特に限定されるものではない。
したがって、例えばＣＳＩＲＴが対象とするＰＣやＷｅｂサーバ，ＯＡ機器などについても、本発明を適用してソフトウェアの脆弱性管理を実施することができる。
【産業上の利用可能性】
【００６７】
本発明は、例えばインターネットなどのネットワークに接続可能な製品に実装されるソフトウェアの脆弱性を管理するためのＰＳＩＲＴやＣＳＩＲＴなどの脆弱性管理システムとして好適に利用可能である。
【符号の説明】
【００６８】
１  脆弱性管理システム
１０  脆弱性管理サーバ
１１  構成情報収集部
１２  脆弱性情報収集部
１３  対象製品洗い出し部
１４  影響調査部
１５  結果レポート部
１６  製品対応判断ＷＦ記録部
１７  監査処理部
２１  構成情報ＤＢ
２２  脆弱性ＤＢ
２４  影響調査ＤＢ
２５  レポートＤＢ
２６  ユーザＤＢ
２７  対応状況ＤＢ
３０  ユーザ端末
４０  脆弱性情報源サーバ
【図１】
2020021309.tif 000004
【図２】
2020021309.tif 000005
【図３】
2020021309.tif 000006
【図４】
2020021309.tif 000007
【図５】
2020021309.tif 000008
【図６】
2020021309.tif 000009
【図７】
2020021309.tif 000010
【図８】
2020021309.tif 000011