JP2007058514A - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Abstract

【課題】 多数の脆弱性情報の中から調査対象とすべき脆弱性情報を効果的に選択できるようにする。
【解決手段】 製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２に脆弱性の特性を示すキーワードを複数記憶させておき、キーワード抽出部１５２が、脆弱性関連情報収集部１５１が収集した脆弱性情報から、製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２に蓄積されているキーワードに合致するキーワードを抽出し、優先度判定部１５３が、優先度判定ＤＢ１１４の内容に従い、キーワード抽出結果に基づいて脆弱性情報の優先度を判定し、出力部２０１が、優先度の判定結果を出力する。
【選択図】 図２

Description

本発明は、コンピュータシステム等のセキュリティの脆弱性を示す脆弱性情報、攻撃コードの検知を行うシグネチャ等を管理する装置、方法、プログラムに関する。

近年、ソフトウェアの脆弱性を悪用したコンピュータシステムへの不正アクセスが増加している。シグネチャベースのＮＩＤＳ（Ｎｅｔｗｏｒｋ ｂａｓｅｄ Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）は有効な対策の一つであるが、次々と発見される脆弱性を悪用する攻撃に対応するため、品質の良いシグネチャの収集及び開発が重要である。

特開２００４−５４７０６号公報では、脆弱性情報とシグネチャの収集・配布に関する機能において以下が示されている。

情報収集オペレータは脆弱性情報をインターネットの情報配信サイトやメーリングリストから収集し、専門家が脆弱性情報は日本語に翻訳し、必要かつ有用な情報を付加してセキュリティ脆弱性情報マスターデータベースに登録する。

同オペレータは不正アクセスシグネチャをインターネットの情報配信サイトやメーリングリストから収集し、内容を確認して不正アクセスシグネチャマスターデータベースに登録する。

これらの情報には定量的なランクを付与し判断の参考にする。

セキュリティ脆弱性情報マスターデータベースと不正アクセスシグネチャマスターデータベースのエントリで関連があるものは同じＩＤで結びつける。また、ＩＤとして可能であれば業界の標準になりつつあるＣＶＥ（Ｃｏｍｍｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ ａｎｄ Ｅｘｐｏｓｕｒｅｓ）のＩＤを付与する。

上記サーバは、脆弱性情報とシグネチャをエンドユーザのサイトへ、タイムリーに配布する。
特開２００４−５４７０６号公報

しかしながら、特開２００４−５４７０６号公報では、脆弱性情報の複数ソースからの効率的な収集には触れていない。収集した情報の効果的な蓄積方法については具体的な例示が無く、セキュリティ専門家が人手で行うことが前提であるように示唆されている。また、１つの脆弱性情報ソースからの情報だけでは適切な情報の解析は行えないことが多いため、同じ脆弱性情報について複数ソースから情報を効率よく収集する方法が必要である。

また、特開２００４−５４７０６号公報では、一度公開された脆弱性情報における更新情報の効果的な収集方法についても触れられていない。情報が公開されてから危険度が上昇したり、影響を受けるソフトウェア製品が増えたりすることがあり、情報は更新されうるので、更新情報の効果的なフォローが必要である。

また、特開２００４−５４７０６号公報では、収集したシグネチャの品質を確認する具体的な方法について触れられていない。また、収集した脆弱性情報からシグネチャを開発する方法について触れられていない。公開されている脆弱性情報全てに対してシグネチャが公開されているとは限らず、また、品質も保証されているとは限らないため、脆弱性情報からシグネチャを新規に開発する方法と、効果的な品質確認方法が必要である。

次に、ＩＤＳ（Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）用のシグネチャ開発における問題点を説明する。

先ず、ＩＤＳ用のシグネチャの開発手順の例を図３４に示す。

まず、脆弱性情報の収集（Ｓ３）において、脆弱性情報を収集する。Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００から、一般に公開されている参照可能な脆弱性情報を収集する。Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００の具体的な例としては、ＣＥＲＴ（Ｃｏｍｐｕｔｅｒ Ｅｍｅｒｇｅｎｃｙ Ｒｅｓｐｏｎｓｅ Ｔｅａｍ）などがある。或いは、有料情報などから収集しても良いが、何れの場合でも情報ソースにおける使用条件に従うことを前提とする。或いは、シグネチャの開発者自身が発見した脆弱性でも良い。

また、攻撃コードの収集（Ｓ８）において、脆弱性情報を悪用した攻撃に関して、攻撃コードを収集する。攻撃コードは必ずしも公開されておらず収集が不可能であることもある。

また、シグネチャの収集（Ｓ９）において、脆弱性情報を悪用した攻撃に対応したシグネチャを収集する。既知の脆弱性への攻撃に対応するためのシグネチャが、インターネット上で公開され利用できる場合があるからである。しかし、脆弱性情報によっては、シグネチャが公開されておらず収集が不可能であることもある。なお、公開されているシグネチャを利用する場合も、公開元における使用条件に従うことを前提とする。

次に、脆弱性情報の調査（Ｓ４）において、収集した脆弱性情報について、以下の分析を行う。
（Ａ）脆弱性の原因は何か（ソフトウェアのどのような不具合か）
（Ｂ）攻撃を受けた場合にどのような不都合が発生するか
（Ｃ）脆弱性の存在する製品は何か、存在しない製品は何か
（Ｄ）攻撃コードの構成／作用
（Ｅ）派生の攻撃の可能性
（Ｆ）脆弱性情報の通り実際に攻撃が再現するか
（Ｇ）対処策は何か
次に、シグネチャの開発（Ｓ５）において、脆弱性情報の分析結果を元に、攻撃の手法を判断し、攻撃を検知できるシグネチャを開発する。このとき、既にインターネット上で公開されているシグネチャを参考にすることも考えられる。

次に、シグネチャの検査（Ｓ６）において、開発したシグネチャが攻撃を検知できるか、実際に使用するＩＤＳに組み込み、攻撃コードをＩＤＳに流して検査する。

最後に、脆弱性調査結果／シグネチャの公開（Ｓ７）において、脆弱性情報の分析結果やエンドユーザ向けにヘルプファイル化した情報とＩＤＳに組み込むためのシグネチャをリリースする。

以上が、ＩＤＳ用のシグネチャの開発手順であるが、以下の課題が存在する。
（１）脆弱性情報の収集に関する課題
インターネット上で報告されている脆弱性情報は非常に数が多く、様々な製品に対し、様々な危険度の情報が報告され、かつ情報の信頼性も様々である。この様に、公開されている脆弱性情報を収集し対応すべき脆弱性情報を効率よく選択することが困難であるという課題が存在する。

また、１つの脆弱性情報ソースからの情報だけでは適切な情報の解析は行えないことが多いため、同じ脆弱性情報について複数ソースから情報を効率よく収集する必要がある。

また、情報が公開されてから危険度が上昇したり、影響を受けるソフトウェア製品が増えたりすることがあり、情報は更新されうるので、更新情報の効果的なフォローを行う必要がある。
（２）シグネチャの開発に関する課題
公開されている脆弱性情報全てに対して利用可能なシグネチャが公開されているとは限らないため、脆弱性情報からシグネチャを新規に効率よく開発することが必要である。

また、シグネチャの開発においては開発者のノウハウに依存することが多く、過去に開発したシグネチャを再利用しシグネチャの開発効率を上げることが必要である。
（３）シグネチャの検証に関する課題
１つの攻撃を複数のシグネチャで検知してしまう場合があり、攻撃とシグネチャの対応が１対１とならない場合は、ＩＤＳにおいて受けた攻撃に対応した警告が通知されず対処を誤る可能性がある。

また、公開されている利用可能なシグネチャを使用したり流用する場合でも、品質が保証されているとは限らないため、効果的な品質確認が必要である。

本発明は、上記の課題を解決することを主な目的としており、脆弱性情報の効率の良い収集・選別・優先度付け、効率の良いシグネチャ開発の支援、シグネチャの品質確認を実現することを主な目的としている。

本発明に係る情報処理装置は、
脆弱性の特性を示すキーワードが一つ以上含まれる脆弱性情報を取得する脆弱性情報取得部と、
脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
前記脆弱性情報取得部により取得された脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出部と、
前記キーワード抽出部によるキーワード抽出結果に基づいて、前記脆弱性情報取得部により取得された脆弱性情報に対する優先度を判定する優先度判定部とを有することを特徴とする。

本発明によれば、脆弱性情報に含まれるキーワードを抽出し、キーワード抽出結果に基づいて脆弱性情報の優先度を設定するため、重要な情報が含まれた脆弱性情報の優先度を高く設定することができ、このため、多数の脆弱性情報の中から調査対象とすべき脆弱性情報を効果的に提示することができる。

実施の形態１．
本実施の形態は、上記の（１）脆弱性情報の収集に関する課題を解決することを主な目的としている。

図１は、本実施の形態に係るシグネチャ開発支援装置（情報処理装置）１の構成例を示する図である。

シグネチャ開発支援装置１は、脆弱性関連情報収集部１５１と、脆弱性情報処理部２００と、シグネチャ・攻撃コード処理部３００から構成される。

脆弱性関連情報収集部１５１は、Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００から脆弱性情報、シグネチャ、攻撃コードなどを収集する。本実施の形態では、脆弱性関連情報収集部１５１は脆弱性情報取得部の例である。

脆弱性情報処理部２００は、脆弱性関連情報収集部１５１により収集された脆弱性情報に対する処理を行う。

シグネチャ・攻撃コード処理部３００は、脆弱性関連情報収集部１５１により収集されたシグネチャや攻撃コードに対する処理を行う。なお、本実施の形態に示す動作を実現するには、シグネチャ・攻撃コード処理部３００は必ずしも必要なく、シグネチャ・攻撃コード処理部３００は、別装置としてもよい。なお、本実施の形態では、シグネチャ・攻撃コード処理部３００の説明は行わず、後の実施の形態において説明する。

次に、図２を参照して、脆弱性情報処理部２００の内部構成例を説明する。

図２において、製品データベース（ＤＢ）１１１は、調査対象の製品情報を蓄積する。脆弱性キーワードデータベース（ＤＢ）１１２は、脆弱性の性質を特定するキーワードを蓄積する。

製品ＤＢ１１１は、ＯＳ＿Ａ（オペレーティングシステムＡ）、 ＯＳ＿Ｂ（オペレーティングシステムＢ）、ＷＥＢサーバＡ、ＷｅｂサーバＢ、 ｌｉｂｒａｒｙ＿ｘｘ、ＤＢサーバＡ、ＤＢサーバＢ・・・といった製品に関する情報が蓄積されている。

脆弱性キーワードＤＢ１１２には、脆弱性の特徴（メモリリーク、無限ループ、異常終了、無応答、バイパス、判定ミス、不整合、ＡＳＮ．１、ＰＫＩ、証明書、暗号、署名、エンコード、デコード、画像、テキスト、サーバ、クライアント・・・）、攻撃種別（バッファオーバフロー、不正なプログラムの実行、権限の取得、権限の昇格、ＤｏＳ、ＸＳＳ、システム情報の漏洩・・・）、通信プロトコル（ＨＴＴＰ、ＳＭＢ、ＦＴＰ・・・）、セキュリティ技術（ＳＳＬ、ＳＳＨ、ＶＰＮ・・・）、プログラム分類（Ｗｅｂサーバ、ブラウザ、ライブラリ、データベース、ＯＳ）といった脆弱性の情報が蓄積されている。

なお、製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２に記憶されている情報は、脆弱性の特性を示すキーワードの例である。このキーワードは多くの脆弱性情報に共通で含まれるものを予め選択する。そして、これらキーワードを複数記憶している製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２は、キーワードデータベースの例である。

次に、脆弱性情報ＤＢ１１３は、脆弱性関連情報収集部１５１により収集された公開されている脆弱性情報１２１を蓄積する。

脆弱性情報には、製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２で蓄積されているキーワードのいずれか一つ以上が含まれている。また、脆弱性情報ＤＢ１１３のエントリには調査結果などを反映することが可能である。脆弱性情報ＤＢ１１３ＤＢのエントリは例えば以下の通りである。

脆弱性情報ＩＤ、脆弱性の内容、危険度、攻撃の種類、対象製品（影響を受ける製品）、非対象製品（影響を受けない製品）、パッチ情報、見解
キーワード抽出部１５２は、脆弱性情報から脆弱性キーワードＤＢ１１２の登録キーワード及び製品ＤＢ１１２の登録キーワード（製品名）に合致するキーワードを抽出する。

優先度判定ＤＢ１１４は、脆弱性情報の優先度を決定するための情報を保持する。

優先度判定部１５３は、収集した脆弱性情報に対して優先度判定ＤＢ１１４を利用し、キーワードの抽出結果に基づいて、調査の優先度を設定する。

出力部２０１は、優先度判定部１５３により判定された優先度を出力（表示）する。

次に、図３を参照して、具体的な動作について説明する。

まず、ステップＳ３０１において、脆弱性関連情報収集部１５１を用いて公開されている脆弱性情報１２１を収集し（脆弱性情報取得ステップ）、ステップＳ３０２において、脆弱性情報ＤＢに一次蓄積する（複数可能）。ここで、脆弱性関連情報収集部１５１は、Ｉｎｔｅｒｎｅｔ上の脆弱性情報を公開しているＷｅｂサイトや、メーリングリストから脆弱性情報を収集する。

Ｗｅｂサイトからの収集については、ＨＴＴＰクライアントツールを利用し専用のＨＴＴＰクライアントプログラムを開発・運用してＷｅｂサイトから定期的・自動的に情報を収集し、さらに、収集した脆弱性情報から必要な項目を取り出すプログラムを開発・運用すれば、定期的・自動的に情報を収集することが可能である。収集の周期は１日、１週間など、ユーザが設定できる機能を備えてよい。また、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を備え、自動ではなくマニュアル操作で収集するように実装しても良い。

メーリングリストからの収集については、情報収集用メールアカウントをメーリングリストに登録し、メーリングリストから得られたメールのデータから、必要な脆弱性情報の項目を取り出すプログラムを開発・運用すれば定期的・自動的に情報を収集することが可能である。収集の周期は１日、１週間など、ユーザが設定できる機能を備えてよい。また、ＧＵＩを備え、自動ではなくマニュアル操作で収集するように実装しても良い。

つまり、脆弱性関連情報収集部１５１は、Ｗｅｂサイトやメーリングリストから収集するための上記プログラム等により収集の機能を実装するようにしてもよい。

また、脆弱性関連情報収集部１５１は、Ｗｅｂサイトやメーリングリストから収集したデータを脆弱性情報ＤＢに蓄積するため、脆弱性情報ＤＢに対応したデータフォーマット変換を行う機能とＤＢアクセス機能を具備するものとする。

次に、ステップＳ３０３において、キーワード抽出部１５２を用い、収集した公開されている脆弱性情報１２１の１つから、脆弱性を特定するキーワードと製品に関するキーワードを抽出する（キーワード抽出ステップ）。前述したように、脆弱性情報には、脆弱性キーワードＤＢ１１２及び製品ＤＢ１１１に蓄積されているキーワードに一致するキーワードが含まれているので、キーワード抽出部１５２は、脆弱性情報からキーワードを抽出することができる。

この結果、脆弱性キーワードＤＢ１１２に登録されているキーワードに一致する特徴や製品ＤＢ１１１に登録されている製品名（バージョン）が抽出され、脆弱性の特徴１２２ａ、攻撃の種類１２２ｂ、対象製品１２２ｃ等が特定される。

なお、脆弱性情報が英文で提供される場合は、上記のキーワード、製品情報について同等の英単語で登録しておく。

次に、ステップＳ３０４において、優先度判定部１５３がこれらのキーワードから調査対象とする脆弱性情報の優先度を判定する（優先度判定ステップ）。優先度判定の例を以下に記述する。
（１）ポイント付与による優先度決定方法
例えば、優先度判定ＤＢ１１４には上記情報に対してあらかじめ定めたポイントを記録しておく。

具体的には、以下のようなポイント設定が考えられる。

攻撃種別：不正なプログラムの実行（５点）、権限の昇格（４点）、ＤｏＳ（３点）、ＸＳＳ（２点）、システム情報の漏洩（１点）
通信プロトコル：ＨＴＴＰ（５点）、ＳＭＢ（４点）、ＦＴＰ（３点）
セキュリティ技術：ＳＳＬ（５点）、ＶＰＮ（４点）
製品：ＯＳ＿Ａ（５点）、ＯＳ＿Ｂ（５点）、ＷｅｂサーバＡ（４点）、ＷｅｂサーバＢ（４点）、ＤＢサーバＡ（３点）、ＤＢサーバＢ（２点）
脆弱性情報から抽出したキーワードが、“不正なプログラムの実行、ＨＴＴＰ、ＳＳＬ、ＷｅｂサーバＡ”であった場合、優先度判定ＤＢにおけるそれぞれの情報に対するポイントを加算し総合ポイントを算出する（この場合は、５＋５＋５＋４＝１９点）。このように、収集した脆弱性情報全てに対して総合ポイントの付与を行うことで自動的に脆弱性情報の優先度づけを行うことが可能である。

毎回収集される脆弱性情報を、逐次、脆弱性情報ＤＢ１１３に蓄積し、優先度付けを常に行うことで、蓄積された全ての脆弱性情報において、その時点で常に優先度の自動付与が可能である。
（２）相対比較による優先度決定方法
また、優先度の判定を総合ポイントによる比較ではなく、キーワードを複数のカテゴリに分類し、各カテゴリにおける優先順位で脆弱性情報の優先度をソートし、全てのカテゴリにおいて上位に含まれる脆弱性情報を絞り込み優先順位付けする方法でもよい。この場合、優先度判定ＤＢ１１４においては各カテゴリ別に優先順位を決めておく。

具体的な優先順位付けは、例えば、以下のとおりである。

攻撃種別：不正なプログラムの実行＞権限の昇格＞ＤｏＳ＞ＸＳＳ＞システム情報の漏洩
通信プロトコル：ＨＴＴＰ＞ＳＭＢ＞Ｓａｍｂａ、ＦＴＰ
セキュリティ技術：ＳＳＬ＞ＳＳＨ＞ＶＰＮ
製品：ＯＳ＿Ａ、 ＯＳ＿Ｂ＞ＷＥＢサーバＡ、ＷｅｂサーバＢ＞ＤＢサーバＡ＞ＤＢサーバＢ
ここでは、脆弱性情報について上位２つを選出する例を挙げる。例として、脆弱性情報Ａ、Ｂ、Ｃ、Ｄ、Ｅについて脆弱性キーワードＤＢ１１２等にマッチするキーワードを抽出した結果、図４のように整理されたとする。

次に各カテゴリについて、優先度判定ＤＢ１１４で定義された優先順位に基づき、図５に示すように、優先度の順位をつける。

最後に各カテゴリにおいて上位２位内に登場した回数を計上する。

この結果、図６に示すように、Ｂ、Ｃの順番に優先度が高いものが２つ選出された。

なお、図６のＤ、Ｅのように同順位の脆弱性情報が存在する場合は、同順位の脆弱性情報同士を比較する場合の、カテゴリ同士の優先順位を決めておき、優先度を決定してもよい。例えば、図６の結果において同順位の脆弱性情報同士を比較する場合に限り、攻撃種別の優先順位が高い＞製品の優先順位が高いとあらかじめ定義しておけば、攻撃種別の優先順位が高い（Ｄ）＞製品の優先順位が高い（Ｅ）であり、攻撃種別においてはＤの方が優先度が高いのでＤの優先度を高くする。この結果、Ｂ、Ｃ、Ｄ、Ｅ、Ａという順位が得られる。

最後に、ステップＳ３０５において、優先度の判定結果は、優先度付与結果として出力部２０１から出力される。当結果は、脆弱性情報ＤＢのエントリに優先度順位として記録されてもよいし、別表で出力しても良い。

このように、優先度判定ＤＢ１１４において事前に優先度付けのルール付けを決め、収集される脆弱性情報を、随時、脆弱性情報ＤＢ１１３に蓄積する。あるタイミングで、前回の調査対象に漏れた情報と、新規に追加蓄積された情報を、全て併せて優先度付けのルールを適用することで、常に優先度の高い脆弱性情報を自動的に選出することが可能である。

例えば、毎週、調査対象の件数が決まっている場合に、過去の脆弱性情報から最新の脆弱性情報まで併せて、常に優先度の高い脆弱性情報を自動的に調査対象に選定することが可能となる。

調査対象にならなかった脆弱性情報において、次回の選定時に優先的に調査を行いたい場合は、その脆弱性情報に対して最優先であるフラグを付与しておき、次回の選定時に最優先として選択すればよい。

以上の処理により優先度が判定された後は、シグネチャの開発者が、優先度付与結果に基づき、優先度の高い脆弱性情報の詳細調査を行う。

例えば、１週間に３件の脆弱性情報を調査する場合は、脆弱性情報ＤＢ１１３で優先度順位付けがされた上位３つの情報を選択すればよい。

その後、脆弱性情報の詳細調査の結果を、脆弱性情報ＤＢの該当エントリに修正反映する。当作業はＧＵＩを利用した手作業である。

例えば、脆弱性情報ＤＢには以下のデータが保存される。

タイトル（日付：ＹＹＹＹ／ＭＭ／ＤＤ）、脆弱性情報ＩＤ、件名、要約、攻撃の分類、危険度、リモートからの攻撃か否か、攻撃コードの有無、影響を受ける製品、影響を受けない製品、詳細、原因の分類、対策、検証方法、検証結果、参考文献
また、必要があれば、日本語に翻訳する。

詳細には、脆弱性の原因、攻撃の手法など調査した結果を記述する。

対策には、パッチの適用やＩＤＳによる検知などを記述する。

また、脆弱性情報ＤＢ１１３への反映結果に基づき、シグネチャの開発者が、脆弱性を悪用した攻撃を検出するＩＤＳ用のシグネチャを開発するようにしてもよい。開発した結果は、シグネチャ・攻撃コード処理部３００のシグネチャデータベース（ＤＢ）（後述）に登録する。シグネチャＤＢには以下のデータが保存される。

シグネチャＩＤ、概要、検知条件、シグネチャ、シグネチャの動作条件、誤検知、取りこぼし、参考文献、脆弱性情報ＩＤ、攻撃コードＩＤ
脆弱性情報ＩＤは、シグネチャが検出する攻撃に対応した脆弱性情報のＩＤであり、脆弱性情報ＤＢ１１３の該当エントリを指すものである。

攻撃コードＩＤは、攻撃に利用されるコードがインターネット上から入手されることがあり、攻撃コードＤＢ（後述）に蓄積している場合の該当エントリを指すものである。シグネチャが検出する攻撃コードを攻撃コードＤＢ上のエントリで指す場合に指定する。

このように、脆弱性情報ＤＢ１１３とシグネチャＤＢと攻撃コードＤＢのエントリ間のリンクを指定するために、各々、脆弱性情報ＩＤ、シグネチャＩＤ、攻撃コードＩＤをエントリに含めてもよい。

以上が、収集した脆弱性情報を自動的に優先度付与／選定し、シグネチャを開発するまでの実施の形態であるが、ここでは、派生的な、脆弱性情報の優先度判定の効率化の例を挙げる。

優先度判定部１５３は、調査対象の脆弱性情報の選定を効率化するために、過去１年間以内に生成された脆弱性情報以外は調査対象外とするなど、生成日からの経過時間で選定対象から足きりしても良い。

この場合は、脆弱性情報に、脆弱性情報の生成日（あるいは公開日）に関するキーワードを含ませ、脆弱性キーワードＤＢ１１３にも生成日に関するキーワードを含ませることで、キーワード抽出部１５２が、生成日に関するキーワードを抽出し、優先度判定部１５３は、生成日に基づいて、脆弱性情報が生成されてからの経過時間を算出し、算出した経過時間が一定レベル（例えば、１年）を超過している場合は、優先度付与の対象としないことで、調査対象外とすることができる。

また、同様に選定を効率化するために、キーワードの検出の結果、製品ＤＢ１１１に存在しない製品は、調査対象外とし、選定対象から足きりしても良い。或いは、製品ＤＢ１１１において選定対象外の製品をリストで保持し、検出されたキーワードが一致したら、選定対象から足きりしても良い。

また、同様に選定を効率化するために、Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００において判断された危険度情報がある場合は、キーワード抽出部１５２が、当該危険情報をキーワードとして抽出し、例えば５段階評価（大変危険、危険、中程度、それほど危険ではない、危険ではない）であれば下位２つを選定対象から足きりする、という方法でも良い。

また、優先度判定の精密化のために、優先度判定部１５３は、脆弱性が報告されてからの経過時間を優先度の判定の際に考慮するようにしてもよい。

この場合は、前述したように、脆弱性情報に、脆弱性情報の生成日（あるいは公開日）に関するキーワードを含ませ、脆弱性キーワードＤＢ１１３にも生成日に関するキーワードを含ませることで、キーワード抽出部１５２が、生成日に関するキーワードを抽出し、優先度判定部１５３は、生成日に基づいて、脆弱性情報が生成されてからの経過時間を算出する。

そして、ポイント付与による優先度決定方法においては、例えば、以下のように経過時間が長くなるほど数値が低くなるポイントを決めておいて、優先度を判定するようにする。

最近２週間以内（５点）、最近４週間以内（４点）、最近２ヶ月以内（３点）、最近３ヶ月以内（４点）、最近半年以内（１点）、半年以上（０点）
また、これとは逆に、経過時間が長くなるほど数値が高くなるポイントを決めておいて、優先度を判定するようにしてもよい。

また、相対比較による優先度決定方法においては、例えば、以下のように経過時間が長くなるほど順位が低くなる優先順位を決めておいて、優先度を判定するようにする。

最近２週間以内＞最近４週間以内＞最近２ヶ月以内＞最近３ヶ月以内＞最近半年以内＞半年以上
また、これとは逆に、経過時間が長くなるほど順位が高くなる優先順位を決めておいて、優先度を判定するようにしてもよい。

また、優先度判定部１５３は、脆弱性情報のソースにおいて判断された危険度情報を用いて優先度を判定してもよい。

この場合は、前述のように、キーワード抽出部１５２が、脆弱性情報から、当該危険情報をキーワードとして抽出し、優先度判定部１５３は、ポイント付与による優先度決定方法においては、例えば、以下のように危険度が大きくなるほど数値が大きくなるポイントを決めておいて、優先度を判定するようにする。

大変危険（５点）、危険（４点）、中程度（３点）、それほど危険ではない（２点）、危険ではない（１点）
また、相対比較による優先度決定方法においては、例えば、以下のように危険度が大きくなるほど順位が高くなる優先順位を決めておいて、優先度を判定するようにする。

大変危険＞危険＞中程度＞それほど危険ではない＞危険ではない
以上のように、本実施の形態では、製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２に脆弱性の特性を示すキーワードを複数記憶させておき、キーワード抽出部１５２が、脆弱性関連情報収集部１５１が収集した脆弱性情報から、製品ＤＢ１１１及び脆弱性キーワードＤＢ１１２に蓄積されているキーワードに合致するキーワードを抽出し、優先度判定部１５３が、優先度判定ＤＢ１１４の内容に従い、キーワード抽出結果に基づいて脆弱性情報の優先度を判定し、出力部２０１が、優先度の判定結果を出力する。

本実施の形態によれば、脆弱性情報に含まれるキーワードを抽出し、キーワード抽出結果に基づいて脆弱性情報の優先度を設定するため、重要な情報が含まれた脆弱性情報の優先度を高く設定することができ、このため、多数の脆弱性情報の中から調査対象とすべき脆弱性情報を効果的に提示することができる。

実施の形態２．
実施の形態１は、収集した脆弱性情報の優先度の判定を自動化することにより、調査対象の選定の効率化を実現するものであった。

本実施の形態では、脆弱性情報の調査にあたり、複数の情報ソースから効率的に脆弱性情報を充実化するものである。

脆弱性情報の提供ソースごとに、提供する情報に特徴がある。例えば、一般的に広く利用されているソフトウェア製品について網羅性が高く一早く情報を提供しているソースや、脆弱性の存在する製品についてバージョン、エディション、サービスパックなどきめ細かに情報を提供しているソースなどである。

つまり、脆弱性情報を単一のソースから収集するよりも、同じ脆弱性情報について複数のソースから収集して情報をマージした方がより情報が充実する（実際に、あるソースでは、攻撃手法の情報が詳細であるが、脆弱性の存在する製品の情報が不足しているなど、複数ソースからの情報をマージする必要がある、という事態は起きている）。

そこで、本実施の形態においては、脆弱性関連情報収集部１５１において、提供情報に特徴のあるソースを複数指定・収集し、不足する情報を相互補完することで脆弱性情報の信頼性を高め収集効率を上げる方法を記述する。

図７は、本実施の形態に係るシグネチャ開発支援装置１の一部の機能を抜粋したものである。

図７において、脆弱性情報リンク部２５１が追加されている。脆弱性情報リンク部２５１は、複数の情報ソースから収集された複数の脆弱性情報のうち、キーワード抽出結果において共通関係にある二以上の脆弱性情報を相互に対応付ける機能を有する。脆弱性情報リンク部２５１は、脆弱性情報対応付け部の例である。

また、本実施の形態では、脆弱性関連情報収集部１５１は、ソースＡ、ソースＢ、ソースＣから情報を収集する。各ソースは次の特徴を持つと仮定する。

ソースＡからの情報１２１ａ：重要な製品の情報の網羅性が高い
ソースＢからの情報１２１ｂ：脆弱性の存在する／しない製品についての情報がきめ細かい
ソースＣからの情報１２１ｃ：参照情報が豊富である
なお、これらのソースから入手される情報の一部は、重複している場合が多い。

次に、図９を参照して、動作を説明する。

まず、ステップＳ９０１において、脆弱性関連情報収集部１５１を用いて公開されている脆弱性情報１２１を収集し（脆弱性情報取得ステップ）、ステップＳ３０２において、脆弱性情報ＤＢに一次蓄積する。ここで、図７に示すように、脆弱性関連情報収集部１５１は、公開されている複数の脆弱性情報１２１ａ、１２１ｂ、１２１ｃを取得する。

脆弱性情報１２１ａ、１２１ｂ、１２１ｃはそれぞれ以下の情報構成とする。

脆弱性情報１２１ａ：Ａ−１、Ａ−２、Ａ−３
脆弱性情報１２１ｂ：Ｂ−１、Ｂ−２
脆弱性情報１２１ｃ：Ｃ−１、Ｃ−２
ここで、Ａ−１、Ａ−２、Ａ−３はそれぞれソースＡで報告された３つの脆弱性情報を表す。Ｂ−１、Ｂ−２はそれぞれソースＢで報告された２つの脆弱性情報を表す。Ｃ−１、Ｃ−２はそれぞれソースＣで報告された２つの脆弱性情報を表す。
次に、ステップＳ９０３において、キーワード抽出部１５２を用い、収集した公開されている脆弱性情報のそれぞれから、脆弱性を特定するキーワードと製品に関するキーワードを抽出する（キーワード抽出ステップ）。この結果、各情報を識別するための特徴的な情報が抽出される。抽出された結果は、脆弱性情報ＤＢ１１３のエントリの１要素として記録する。

ここで、それぞれの脆弱性情報のキーワード抽出結果を図８に示すとおりとする。

ソースＡからの脆弱性情報のキーワード抽出結果３１１ａ：Ａ−１ｓ、Ａ−２ｓ、Ａ−３ｓ
ソースＢからの脆弱性情報のキーワード抽出結果３１１ｂ：Ｂ−１ｓ、Ｂ−２ｓ
ソースＣからの脆弱性情報のキーワード抽出結果３１１ｃ：Ｃ−１ｓ、Ｃ−２ｓ
図８の３０１はソースＡからの脆弱性情報１２１ａの内、Ａ−１の元情報を保持しており、脆弱性情報ＤＢ１１３のエントリである。これに対して、３１１ａのＡ−１ｓは、キーワード抽出部１５２にＡ−１の元情報を適用した結果である。Ａ−１ｓを脆弱性情報ＤＢ１１３で管理できるように、３０１の情報の一部として追記しておく。

次に、ステップＳ９０４において、脆弱性情報リンク部２５１が、キーワードの共通性に基づいて、各脆弱性情報をリンクする（脆弱性情報対応付けステップ）。具体的なリンク手順は、後で説明する。

次に、ステップＳ９０５において、優先度設定部１５３が、脆弱性情報リンク部２５１によるリンク結果を考慮しながら優先度を設定し、ステップＳ９０６において、出力部２０１が、優先度を出力する。

次に、脆弱性情報リンク部２５１による脆弱性情報のリンク手順の詳細を説明する。

例えば、Ａ−３に、“アプリケーションＡＰ＿ｘにおける脆弱性で、ＣＧＩに不具合があり、ＸＳＳの脆弱性が存在する。共通ＩＤはＩＤ００００２である。”という内容の情報がテキストで示されていた場合に、キーワード抽出部１５２において、以下の特徴が抽出される。

Ａ−３ｓ．ＣＧＩ、境界値チェック／ＸＳＳ／ＡＰ＿ｘ／０５／０１／０６／ＩＤ０００２
同様に、Ｂ−２、Ｃ−２の特徴が以下の様に抽出されたとする。

Ｂ−２ｓ．ＣＧＩ、境界値チェック／ＸＳＳ／ＡＰ＿ｘ１．０、１．１、１．２／０５／０１／０６／ＩＤ０００２
Ｃ−２ｓ．ＣＧＩ、境界値チェック／ＸＳＳ／ＡＰ＿ｘ／０５／０１／０６／ＩＤ０００２
これらの情報には、脆弱性情報を識別する共通ＩＤが付与されており、ＩＤ０００２である。例えば、ＣＶＥなどで付与されるＩＤが該当する。

これらの結果が脆弱性情報リンク部２５１入力される。脆弱性情報リンク部２５１は、Ａ−３ｓ、Ｂ−２ｓ、Ｃ−２ｓの抽出された特徴（キーワード）から、共通ＩＤの一致を確認し、一致した場合は、それぞれの脆弱性情報をリンクする。

この場合は、ＩＤ０００２がＡ−３ｓ、Ｂ−２ｓ、Ｃ−２ｓ全てに含まれるので、同内容の情報と判定し、それぞれの脆弱性情報をリンクする。

なお、全てのソースに同じ共通ＩＤが付与される必要はない。例えば、以下の例では、ソースＡからのＡ−１０ｓ、ソースＢからのＢ−９ｓ、ソースＣからのＣ−５１ｓは、それぞれ同じ脆弱性情報を示している。また、Ａ−１０ｓは参照情報のＩＤとしてＢ−９ｓを参照している。Ｂ−９ｓは参照情報のＩＤとしてＣＶＥ０００１とＣ−５１ｓを参照している。Ｃ−５１ｓには参照するＩＤは無い。

Ａ−１０ｓ ・・・ Ｂ−９ｓ・・・
Ｂ−９ｓ ・・・ ＣＶＥ００００１、Ｃ−５１・・・
Ｃ−５１ｓ ・・・ ＩＤ無し・・・
例えば、ソースＡが参照サイトとしてソースＢを参照していたり、ソースＢが参照サイトとしてソースＣを参照している場合は、上記の様な情報が提供される。Ａ−１０とＣ−５１は直接お互いに参照していないが、Ｂ−９の参照を介して同じ情報であると判断できる。

この様に、各々に含まれる参照している情報のＩＤを辿ることで、それぞれ同じ情報を示していると判断でき、リンクすることが可能である。なお、ＩＤの情報は参考文献に示されるＵＲＬ内に含まれることもある。

次に、お互いをリンクするためのＩＤ情報が記載されていない場合の重複の判断方法を示す。

まず、これらの脆弱性情報をキーワード検出部１５２に適用する。この結果、各情報を識別するための特徴的な情報が抽出される。

例えば、Ａ−１は、“ＯＳ＿ｘにおける脆弱性で、画像（ＪＰＥＧ）ファイルを取り扱う機能に不具合があり、特定の画像ファイルを読み込むとメモリリークを発生する。原因は画像の大きさを判断する境界の判断に不具合があるからである。”という内容の情報を示している。Ａ−１の脆弱性情報をキーワード検出部１５２に適用した結果、以下の情報が抽出されたとする。

Ａ−１ｓ：メモリリーク、ＪＰＥＧ、境界／ＤｏＳ／ＯＳ＿ｘ／０５／０１／０５／ＩＤ無し
同様に、Ｂ−１は同じ内容を示しているが、脆弱性情報をキーワード検出部１５２に適用した結果は、以下のキーワードが抽出されたとする。ここで、Ａ−１のキーワード抽出結果とは、影響を受ける製品の情報が細かい点と、共通ＩＤが付与されている点が異なる。

Ｂ−１ｓ：メモリリーク、ＪＰＥＧ／ＤｏＳ／ＯＳ＿ｘ、ＯＳ＿ｙ、ＯＳ＿ｚ／０５／０１／０５／ＩＤ０００１
これらの結果は、脆弱性情報リンク部２５１に入力される。脆弱性情報リンク部２５１は、Ａ−１、Ｂ−１から抽出された特徴（キーワード）であるＡ−１ｓ／Ｂ−１ｓから、Ａ−１とＢ−１が同じ内容を示しているか判断するために、予め設定してある「情報の一致を判定するための比較基準」と照合する。例えば、「脆弱性の特徴＋攻撃の種類＋報告日」を比較し一致すれば重複する情報と判定する。

ここで、Ａ−１ｓとＢ−１ｓは、
特徴：メモリリーク、ＪＰＥＧ
攻撃の種類：ＤｏＳ
報告日：０５／０１／０５
が一致するため、Ａ−１、Ｂ−１は同じ内容として判断され、リンクされる。

なお、Ｂ−１において特徴に“境界”が含まれておりＡ−１では含まれていないが、キーワードの一致率が何パーセントを超えたら一致とみなすという基準は別途設けておけばよい。

「情報の一致を判定するための比較基準」は、単一でも良いし、複数の基準の組み合わせでも良い。例えば、脆弱性の特徴のみでも良いし、脆弱性の特徴と攻撃の種類の２つを組み合わせても良い。

報告日（脆弱性情報の生成日）による比較についても、報告日に幅を持たせて比較しても良い。例えば、Ａ−１の場合、０５／０１／０５が報告日であるが、他のソースにおいて報告日がずれることがある。例えば、「Ａの報告日の前後３日以内に一致するもの」という比較でも良い。

また、上記の例では、「ある一定の期間において収集した各ソースの情報を比較する」ことにしているが、リンク可能な情報の検索範囲は、１週間内に収集した情報でも良いし、脆弱性情報ＤＢに蓄積済みのものを過去１年に遡って検索しても良い。

このように、複数のソースから得られた脆弱性情報において同じ情報についてのリンクを行う。同じ情報であることの判定方法は２種類あり、ＩＤによる判定と、キーワード抽出による類似度判定による判定であった。

次にリンクの具体的な例を図１０に示す。

Ａ−１とＢ−１をリンクする場合、Ａ−１ｓが格納されているＤＢエントリ４０１（Ａ−１の元情報も格納されている）に対して、Ｂ−１ｓのＤＢエントリ４０３（Ｂ−１の元情報も格納されている）の中の「影響を受ける／受けない製品」の情報を抽出して反映（上書きなど）する。

同様に、Ａ−３、Ｂ−２、Ｃ−２をリンクする場合、Ａ−３ｓのＤＢエントリ４０２（Ａ−３の元情報も格納されている）に対して、Ｂ−２ｓのＤＢエントリ４０４（Ｂ−２の元情報も格納されている）の中の「影響を受ける／受けない製品」の情報を抽出して反映（上書きなど）する。さらに、Ｃ−２ｓのＤＢエントリ４０５（Ｃ−２の元情報も格納されている）の中の参照情報を抽出して反映（上書きなど）する。

或いは、図５の５０１のように、Ａ−１の情報とリンクするＢ−１の情報を並列に記述、Ａ−３の情報に対してＢ−２、Ｃ−２の情報を並列に記述し、グループ化しても良い。

この方法の場合、ソースＡには存在するがソースＢ、Ｃには存在しない項目がある場合が考えられる。この場合、並列に記述すると、Ａについては記述できるが、Ｂ、Ｃについてはブランクになる項目が存在してしまう。しかし、より多くの情報を一覧できるため、その後の脆弱性情報の調査においては有用である。

このように、複数のソースからの脆弱性情報をお互いにリンクさせ、不足している情報を補完することにより効率よく詳細な脆弱性情報を取得することが可能である。

当実施の形態では、当リンク処理の後、優先度判定部１５３を適用し、脆弱性情報の優先度付けを行う。ここで、複数のソースから同じ脆弱性が取れた場合は、優先度判定における優先度をアップさせるようにしてもよい。

このように、本実施の形態によれば、キーワード抽出結果において共通関係を有する二以上の脆弱性情報を対応付けることができるので、複数ソースからの脆弱性情報を対応付けることができ、それぞれ個々のソースからの情報では不足している情報を相互に補完することができ、効率よく詳細な脆弱性情報を取得することが可能である。

実施の形態３．
実施の形態２では、複数のソースから収集した脆弱性情報をキーワード抽出部１５２に入力し、抽出されたキーワードを脆弱性情報リンク部２５１に入力することにより、複数ソースの脆弱性情報のリンクを行う。そして、その後、優先度判定部１５３を適用し、脆弱性情報の優先度付けを行う。

当実施の形態では、脆弱性情報のリンクの異なるタイミングによる実施の形態を記述する。

図１２は、シグネチャ開発支援装置１の一部の機能を抜粋したものである。

図１２では、図７の場合と異なり、予め決められた１つのソースからの脆弱性情報に対して、優先度判定部１５３を適用することで、調査対象の優先度付けを先に行う。この後、脆弱性情報リンク部２５１を利用して、脆弱性情報のリンクを行う。

リンクを行う対象は、収集した対象全てに対して、一度に行う必要は無い。例えば、Ａ１、Ａ２、Ａ３、Ａ４、Ａ５という５つの脆弱性情報がソースＡから収集されたとする。

優先度判定部１５３により、調査対象がＡ１とＡ２に絞られた場合、その時点ではＡ１、Ａ２に対してのみリンクを行えば良く、Ａ３、Ａ４、Ａ５がその後も調査対象として浮上してきた場合にリンク作業を行えばよい。

このように、当実施の形態では、優先度判定部１５３を脆弱性情報リンク部２５１よりも先に適用することで、リンク作業の省略化が実現可能である。

実施の形態４．
既に収集した脆弱性情報において、その情報の内容が更新されることがある。例えば、攻撃コードが無かったものが発見された、危険度が上がった、パッチが提供された、派生の攻撃が発見された、というものである。内容によっては、エンドユーザに脆弱性情報の分析結果を更新して通知したりシグネチャを変更して再配布する必要がある。

更新情報の提供形態はソースにより異なり、例えば、若干でも情報の更新が発生した場合に随時更新情報を掲載するソースや、１週間ごとに区切って掲載するソースや、複数の脆弱性情報に更新が発生した場合にまとめて掲載するソースなど様々である。

本実施の形態では、実施の形態２又は実施の形態３において、複数のソースをリンクした場合に、情報の更新を扱いやすいソースを情報の更新のフォローのために利用し、情報の更新を確実にフォローする方法を記述する。

図１３は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す。

図１３では、脆弱性情報検索部１５４が追加されている以外は、図２の構成と同じである。

脆弱性情報検索部１５４は、脆弱性情報を、キーワードに基づいて脆弱性情報ＤＢ１１３から検索する。

次に、動作について説明する。

図１４は、脆弱性情報が更新された状態を示す図である。図１４では、図８の状態に対してソースＤからの脆弱性情報が追加されただけである。

例えば、ソースＤでは、随時更新情報を公開する方針であったとする。実施の形態２又は実施の形態３と同様の方法で、ソースＤからの脆弱性情報に対してキーワード抽出を行い、ソースＤからの情報もキーワード抽出結果が共通する他ソースからの情報にリンクし、（Ａ−１、Ｂ−１、Ｄ−１）、（Ａ−３、Ｂ−２、Ｃ−２、Ｄ−３）という関係付けを行う。

その後、脆弱性情報に関しての更新のフォローは、それぞれＤ−１、Ｄ−３に対して行う。

例えば、（Ａ−１、Ｂ−１、Ｄ−１）の情報の更新をフォローするためには、図１５において、ソースＤからの脆弱性情報１２１ｄを収集し、キーワード抽出部１５２でキーワード７０１を抽出した後、脆弱性情報検索部１５４に対してキーワド７０１を検索キーとして入力する。

脆弱性情報検索部１５４はキーワード７０１に該当する脆弱性情報を脆弱性情報ＤＢ１１３から検索して提示する。脆弱性情報の共通ＩＤが明確であれば、ＩＤで一意に検索できるし、ＩＤが明確でなくとも、実施の形態２におけるＩＤを用いないリンク方法と同じ要領で、該当する脆弱性情報を検索する。つまり、キーワードから脆弱性情報ＤＢ１１３内に格納されている類似の脆弱性情報を絞り込み、出力する。

次に、出力された「既に格納されている脆弱性情報」について、更新が発生していることをＧＵＩ等でユーザに通知する（７０４）。

通知の方法は、単に、（Ａ−１、Ｂ−１、Ｄ−１）の脆弱性情報が更新されていることのみを伝えてもよいし、危険度の上昇等、特定の項目の更新が発生した場合は、緊急の通知としても良い（７０５）。

この際、更新情報を、（Ａ−１、Ｂ−１、Ｄ−１）に自動反映してもよい。前回のＤ−１からの情報をキーワード抽出部１５２に適用した結果をＤＢのエントリに記録していれば、毎回差分を自動的にチェックすることが可能である。

ユーザはこの更新の通知を受けて、再度（Ａ−１、Ｂ−１、Ｄ−１）について追加調査を行い、ＩＤＳのエンドユーザに対して脆弱性情報の分析結果を更新配布したり、ヘルプ情報を更新配布したり、シグネチャを更新配布する。

このように、更新情報を扱い易いソースＤをリンク対象に含め、ソースＤのみを定期的にチェックすることで効率よく脆弱性情報の更新の発生をフォローすることが可能である。

当実施の形態によれば、調査対象の脆弱性情報について、更新を通知するソースからの情報を収集・追加リンクすることにより、ユーザに脆弱性情報の更新を効率よく通知することが可能となる。

実施の形態５．
従来のシグネチャの開発方法では、シグネチャの開発はセキュリティの専門家が脆弱性情報の内容を調査し、攻撃コードが存在する場合はその特徴を調査し、特徴を捕捉・検出するためのシグネチャを開発する。また、脆弱性情報が報告されても攻撃コードは公開されなかったり公開されても一部のみであったり情報が不十分である場合がある。

熟練したセキュリティ専門家であれば脆弱性情報のみから攻撃コードや攻撃手法を考案しシグネチャを開発することは可能であろうが、そのような専門家は一部であり、シグネチャの開発は特定の個人に負担のかかる作業であった。

そこで、本実施の形態では、シグネチャの開発を支援するシグネチャ開発支援装置を説明する。

図１６は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す図である。

シグネチャ・攻撃コード処理部３００において、シグネチャデータベース（ＤＢ）１１５は、脆弱性関連情報収集部１５１で収集されたインターネット上で公開されているシグネチャや過去に開発されたシグネチャを蓄積する。ＤＢのエントリは以下である。そして、これらはシグネチャ情報１２６を構成する。

シグネチャＩＤ、対応する攻撃コードＩＤ、概要、検知条件、シグネチャ、シグネチャが動作する条件
シグネチャ検索部１５５は、シグネチャ情報１２６をシグネチャＤＢ１１５から検索する。

本実施の形態においては、脆弱性情報処理部２００の構成要素は図２及び図１３に示したものと同様である。但し、脆弱性情報ＤＢ１１３には、それぞれに対応するシグネチャが生成済みの脆弱性情報が含まれている。そして、シグネチャ生成済みの脆弱性情報については、脆弱性情報ＤＢ１１３には、例えば１１３ａに示されるエントリのように以下の情報が含まれている。

脆弱性情報ＩＤ、脆弱性の内容、危険度、攻撃の種類、対象製品、非対象製品、パッチ情報、見解、シグネチャＩＤ
また、脆弱性情報ＤＢ１１３には、それぞれの脆弱性情報に対してキーワード抽出部１５２により抽出されたキーワード抽出結果も記憶されている。

シグネチャは脆弱性を悪用した攻撃を検出するものであるから、シグネチャの開発に先立ち脆弱性情報を分析・把握することが重要である。

本実施の形態では、過去に調査した脆弱性情報と対応したシグネチャにおいて、現在調査したい脆弱性情報に類似のものを参考情報として表示し、シグネチャの開発を効率化する方法を記述する。

次に、図１７を参照して、具体的な動作を説明する。

先ず、図３において説明した、ステップＳ３０１〜Ｓ３０５を行って、脆弱性情報についてキーワード抽出を行って、脆弱性情報のキーワード抽出結果を脆弱性情報ＤＢ１１３に蓄積しておく。更に、脆弱性情報に対する優先度設定を行う（ステップＳ１７０１）。

次に、ステップＳ１７０２において、調査対象の脆弱性情報を決定する。シグネチャ開発者は、ステップＳ３０５において、優先度を付与された脆弱性情報が参照可能なので、優先度に基づいて調査対象の脆弱性情報を１つ決定する。例えば最も優先度の高い脆弱性情報を選択する。

次に、脆弱性情報検索部１５４が、調査対象の脆弱性情報の特徴を表すキーワード抽出結果を得る。ステップＳ３０３において調査対象の脆弱性情報に対するキーワード抽出が行われているので、調査対象の脆弱性情報の脆弱性の特徴１２２ａ、攻撃の種類１２２ｂ、影響を受ける製品１２２ｃなどの脆弱性情報の特性を示すキーワードは既に抽出済みであり、脆弱性情報ＤＢ１１３に格納されている。

次に、脆弱性情報検索部１５４は、当該調査対象の脆弱性情報のキーワード抽出結果を検索キーとして脆弱性情報ＤＢ１１３を検索し、共通するキーワード抽出結果の脆弱性情報を抽出する（脆弱性情報検索ステップ）。

検索結果として脆弱性情報１２３が得られる。

検索された脆弱性情報１２３は、例えば１１３ａに示される脆弱性情報ＤＢ１１３のエントリのように以下の情報を含んでいる。

脆弱性情報ＩＤ、脆弱性の内容、危険度、攻撃の種類、対象製品、非対象製品、パッチ情報、見解、シグネチャＩＤ
検索された脆弱性情報にはソフトウェアの何のモジュールにどのような脆弱性があり、どのような攻撃手法により攻撃されるかが示されているため、調査対象の脆弱性情報の解析のヒントになる。

次に、脆弱性情報検索部１５４が、シグネチャ検索部１５５に、抽出した脆弱性情報１２３のシグネチャＩＤを渡し、シグネチャ検索部１５５が、ステップＳ１７０５において、当該シグネチャＩＤに基づいて、シグネチャＤＢ１１５を検索し、シグネチャＩＤで識別されるシグネチャを抽出する（シグネチャ検索ステップ）。

そして、ステップＳ１７０６において、出力部２０１が、ステップＳ１７０４で抽出された脆弱性情報と、ステップＳ１７０５で検索されたシグネチャを含むシグネチャ情報１２６を出力する。

検索されたシグネチャ情報１２６に含まれるシグネチャは、調査対象の脆弱性情報と類似すると推測される脆弱性情報に対応したシグネチャなので、当シグネチャを調査対象の脆弱性情報向けのシグネチャの参考情報として参照することが可能である。

従って、検索結果を参考情報として開発者に表示することでシグネチャ開発の効率化が可能となる。

類似シグネチャ情報には（類似の）攻撃コードの何の特徴をシグネチャで捉えるか検知条件として記述されており、シグネチャ開発の参考となる。

また、類似シグネチャ自体を表示することも参考となる。

また、類似シグネチャにおいて、検知条件に該当する箇所を視覚的にわかりやすく示すＧＵＩを備えてもよい。

また、検索された脆弱性情報には、調査対象の脆弱性情報と類似の脆弱性が示されている可能性があるので、検索された脆弱性情報を、これから調査しようとする脆弱性情報の分析の参考にすることができる。

このように、本実施の形態によれば、調査対象の脆弱性情報のキーワード抽出結果と共通関係を有するシグネチャ生成済みの脆弱性情報を検索し、更に、検索したシグネチャ脆弱性情報に対応させたシグネチャを検索するため、調査対象の脆弱性情報と関連性が強いと考えられる脆弱性情報及びシグネチャを提示することが可能であり、これによりシグネチャの開発の効率を向上させることができる。

実施の形態６．
図１８は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す図である。

図１８において、各構成要素は、図１６のものと同様である。但し、シグネチャＤＢ１１５に既に開発済みのシグネチャを蓄積する場合、そのエントリの“概要”情報において、脆弱性キーワードＤＢ１１２に登録されているキーワードで検索が可能なキーワードを記録しておく。つまり、シグネチャの開発の際に利用された脆弱性情報から抽出されたキーワード抽出結果を記録しておく。

また、本実施の形態では、シグネチャＤＢ１１５ａには、それぞれのシグネチャに対応する脆弱性情報の識別子（ＩＤ）を記憶している。ここで、シグネチャに対応する脆弱性情報とは、当該シグネチャを生成する際に、利用した脆弱性情報である。

一方、本実施の形態では、脆弱性情報ＤＢ１１３には、実施の形態５では記憶されていた、シグネチャＩＤは記憶されていない。

次に、図１９を参照して動作を説明する。

先ず、図３において説明した、ステップＳ３０１〜Ｓ３０５を行って、脆弱性情報についてキーワード抽出を行って、脆弱性情報のキーワード抽出結果を脆弱性情報ＤＢ１１３に蓄積しておく。更に、脆弱性情報に対する優先度設定を行う（ステップＳ１９０１）。

次に、ステップＳ１９０２において、調査対象の脆弱性情報を決定する。シグネチャ開発者は、ステップＳ３０５において、優先度を付与された脆弱性情報が参照可能なので、優先度に基づいて調査対象の脆弱性情報を１つ決定する。例えば最も優先度の高い脆弱性情報を選択する。

次に、シグネチャ検索部１５５が、調査対象の脆弱性情報の特徴を表すキーワード抽出結果を得る。ステップＳ３０３において調査対象の脆弱性情報に対するキーワード抽出が行われているので、調査対象の脆弱性情報の脆弱性の特徴１２２ａ、攻撃の種類１２２ｂ、影響を受ける製品１２２ｃなどの脆弱性情報の特性を示すキーワードは既に抽出済みであり、脆弱性情報ＤＢ１１３に格納されている。

次に、シグネチャ検索部１５５は、当該調査対象の脆弱性情報のキーワード抽出結果を検索キーとしてシグネチャＤＢ１１５を検索し、共通するキーワード抽出結果のシグネチャを抽出する（シグネチャ検索ステップ）。ここで、シグネチャＤＢ１１５に対し、“概要”情報においてキーワードを含むエントリを検索することになる。

当該シグネチャは、調査対象の脆弱性情報に類似すると推測される脆弱性情報に対応したシグネチャなので、当シグネチャを調査対象の脆弱性情報向けのシグネチャの参考情報として参照することが可能である。従って、検索結果を参考情報として開発者に表示することでシグネチャ開発の効率化が可能となる。

次に、シグネチャ検索部１５５が、脆弱性情報検索部１５４に、抽出したシグネチャ情報１２６に含まれる脆弱性情報ＩＤを渡し、脆弱性情報検索部１５４が、ステップＳ１９０５において、当該脆弱性情報ＩＤに基づいて、脆弱性情報ＤＢ１１３を検索し、脆弱性情報ＩＤ１２３ｂで識別される脆弱性情報を抽出する（脆弱性情報検索ステップ）。脆弱性情報ＤＢ１１３では、１１３ａに示される様に、脆弱性情報ＩＤが記録されているため、シグネチャ検索部１５５から通知のあった脆弱性情報ＩＤに基づいて対応する脆弱性情報１２３を検索可能である。

そして、ステップＳ１９０６において、出力部２０１が、ステップＳ１９０４で抽出されたシグネチャを含むシグネチャ情報１２６と、ステップＳ１９０５で検索された脆弱性情報を出力する。

当実施の形態によれば、脆弱性情報のキーワードを利用し、シグネチャＤＢから類似のシグネチャを検索し、かつ、脆弱性情報ＤＢからも、該当する脆弱性情報を検索可能なので、これらの情報を表示することで、シグネチャの開発者は、調査対象の脆弱性情報の解析と、シグネチャ開発の参考とすることが可能である。

つまり、本実施の形態によれば、調査対象の脆弱性情報のキーワード抽出結果と共通関係を有するシグネチャを検索し、更に、検索したシグネチャに対応させた脆弱性情報を検索するため、調査対象の脆弱性情報と関連性が強いと考えられる脆弱性情報及びシグネチャを提示することが可能であり、これによりシグネチャの開発の効率を向上させることができる。

実施の形態７．
既知の脆弱性への攻撃に対応するためのシグネチャが、インターネット上で公開され自由に利用可能な場合がある。脆弱性関連情報収集部１５１は、このような公開されているシグネチャ及びその脆弱性情報も収集する。

本実施の形態では、収集されたシグネチャについて、信頼できるか確認し、検知方法などを参考にするために、以下を実行する。

脆弱性関連情報収集部１５１は、インターネットからシグネチャ及び当該シグネチャに対応する脆弱性情報を取得する。その後、実施の形態５又は実施の形態６に示す操作が行なわれ、インターネットから収集した脆弱性情報のキーワードと共通するキーワードを有するシグネチャと脆弱性情報を検索し、検索したシグネチャと脆弱性情報と、インターネットから収集したシグネチャと脆弱性情報とを表示する。

シグネチャ開発者は、表示された２組のシグネチャと脆弱性情報の組を比較して、収集されたシグネチャが信頼できるか確認し、検知方法などを参考にすることができる。つまり、インターネットから収集されたシグネチャにおける検知条件と、実施の形態５又は６の操作の結果、検索された類似のシグネチャの検知条件を比較し、妥当性を判定することができる。

なお、脆弱性情報を表示せずに、シグネチャのみを表示するようにしてもよい。また、シグネチャ全体の表示とせずに、シグネチャの検知条件の部分のみを表示するようにしてもよい。また、表示方法は、シグネチャの検知条件を並べて表示するようにしてもよい。

また、公開されているシグネチャは定められたフォーマットに基づいて記述されているため、シグネチャから検知条件を日本語の記述に変換することが可能であり、日本語変換された検知条件を表示し、一方で検索されたシグネチャの検知条件を並べて表示しても良い。

このように、本実施の形態によれば、インターネットなどから収集された利用可能なシグネチャについて、信頼できるか確認し、検知方法などを参考にすることができ、この結果、シグネチャの開発の効率を向上させることができる。

実施の形態８．
本実施の形態は、脆弱性関連情報収集部で収集した攻撃コードを、シグネチャＤＢに格納されている開発済みのシグネチャに適用し、開発済みのシグネチャで検知可能か調べる場合について説明する。

図２０は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す図である。

図２０において、攻撃コードＤＢ１１６は、過去に開発した攻撃コードを蓄積する。また、脆弱性関連情報収集部１５１で収集されたインターネット上で公開されている攻撃コードを蓄積する。ＤＢのエントリは以下である。

攻撃コードＩＤ、対応するシグネチャＩＤ、対応する脆弱性情報ＩＤ、概要、攻撃コードの実体
攻撃コード検索部１５６は、攻撃コード情報１２７を攻撃コードＤＢ１１６から検索する。

品質管理用ＩＤＳ８５２は、脆弱性関連情報収集部で収集した攻撃コードを、シグネチャＤＢに格納されている開発済みのシグネチャに適用し、開発済みのどのシグネチャで検知可能か調べる。品質管理用ＩＤＳ８５２は、攻撃検知性判断部の例である。なお、図２０では、品質管理用ＩＤＳ８５２は、シグネチャ・攻撃コード処理部３００内に配置されているが、品質管理用ＩＤＳ８５２をシグネチャ開発支援装置外に配置してもよい。

なお、図２０における他の構成要素は、既に説明したものと同様である。但し、本実施の形態では、脆弱性関連情報収集部１５１は、脆弱性情報、シグネチャのほかに、攻撃コードも収集するものとする。このため、本実施の形態では、脆弱性関連情報収集部１５１は、攻撃コード取得部の例である。

例えば、図２１では、シグネチャＤＢ１１５に保存されている開発済みシグネチャ８０２を品質管理用ＩＤＳ８５２に取り込み、攻撃コード８０１を適用し、検知するか調査する。

検知に成功した場合、検知した開発済みシグネチャ８０２のシグネチャＩＤ８０３を検索キーとして、シグネチャ検索部１５５により該当するシグネチャ情報８０４をシグネチャＤＢ１１５から取得する。なお、このシグネチャ情報８０４は、実施の形態６において説明したシグネチャ情報と同様である。また、シグネチャ情報８０４には、シグネチャの属性が示されており、シグネチャ属性情報に相当する。

また、同時に、検索されたシグネチャ情報８０４において記載される脆弱性情報ＩＤ８０５を検索キーとして、脆弱性情報検索部１５４により該当する脆弱性情報８０６を脆弱性情報ＤＢ１１３より取得する。

本実施の形態に係る動作を、図２２を参照して説明する。

先ず、ステップＳ２２０１において、脆弱性関連情報収集部１５１が、インターネット上の脆弱性情報のソースから攻撃コードを取得する（攻撃コード取得ステップ）。

次に、ステップＳ２２０２において、品質管理用ＩＤＳ８５２が、シグネチャＤＢ１１５に蓄積されている開発済みのシグネチャのそれぞれを適用して、取得された攻撃コードを検知できるシグネチャを特定する（攻撃検知性判断ステップ）。

次に、ステップＳ２２０３において、シグネチャ検索部１５５が、特定されたシグネチャのシグネチャ情報をシグネチャＤＢ１１５から取得し、更に、ステップＳ２２０４において、脆弱性情報検索部１５４が、シグネチャ情報内の脆弱性情報ＩＤに基づいて脆弱性情報ＤＢ１１３を検索して、該当する脆弱性情報を抽出する。

最後に、出力部２０１が、抽出されたシグネチャと脆弱性情報を出力する（出力ステップ）。

図２１には、出力部２０１による表示例が示されている。検索されたシグネチャ情報８０４と脆弱性情報８０６をＧＵＩ８５３表示することで、シグネチャの開発参考情報として示しシグネチャ開発を効率化する。

例えば、ＧＵＩ８５３では、以下の開発済みの２つのシグネチャが攻撃コード８０１を検知した場合の表示例である。脆弱性情報Ａに示される脆弱性を悪用した攻撃Ａを検知するシグネチャと、脆弱性情報Ｂに示される脆弱性を悪用した攻撃Ｂを検知するシグネチャが表示されている。

８５３ａでは、シグネチャ情報から抜粋したシグネチャに関する情報を表示する。８５３ａ’では対応する脆弱性情報Ａの内容を表示する。

８５３ｂでは、シグネチャ情報から抜粋したシグネチャに関する情報を表示する。８５３ｂ’では対応する脆弱性情報Ｂの内容を表示する。

ＧＵＩに表示するシグネチャの情報と対応する脆弱性情報は、１つでも複数でも良い。

このように本実施の形態によれば、開発済みのシグネチャのうち、取得した攻撃コードを検知可能なシグネチャを判断し、当該シグネチャの属性情報及び当該シグネチャに対応する脆弱性情報を表示するため、シグネチャの開発の効率を向上させることができる。

実施の形態９．
図２３は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す図である。

図２３において、テンプレート生成部８６０は、品質管理用ＩＤＳ８５２において特定されたシグネチャからテンプレートを生成する。

また、シグネチャＤＢ連携部８７０（シグネチャデータベース更新部）は、品質管理用ＩＤＳ８５２において特定されたシグネチャのシグネチャ情報に、脆弱性関連情報収集部１５１で収集された攻撃コードを検知可能であるとの記述を追加して、シグネチャＤＢ１１５を更新する。

なお、他の構成要素は、図２０と同様である。

テンプレート生成部８６０は、攻撃コードの検出に成功した既存のシグネチャをテンプレートとして生成する。

例えば、図２４の例では、８５４は、外部ネットワークからＷｅｂサーバへの通信において、文字列“ａｂｃ”を含み“ｘｙｚ”を含まないデータを攻撃として捕捉しており、その場合は、警告時に表示するメッセージとして“ＤｏＳ ａｔｔａｃｋ ｈａｓ ｄｅｔｅｃｔｅｄ！”を表示するためのシグネチャである。シグネチャのＩＤは１２３４、攻撃の種別としてＤｏＳ、シグネチャのバージョンは１．０を表している。そこで、検知した既存のシグネチャ８５４を利用し、検知に直接関係の無い情報（攻撃の種別、シグネチャのＩＤ、シグネチャのバージョン、警告時に表示するメッセージ）を空白として省略し、テンプレート８５５として生成する。図２４では、破線で囲んだ部分を空白に変更してテンプレートとしている。

また、脆弱性関連情報収集部１５１で収集された攻撃コードは既存のシグネチャで検出が可能であるため、シグネチャを兼用するという方針の場合は、シグネチャＤＢ連携部８７０は、検索された既存のシグネチャ情報に、“攻撃コードＸＸＸも検出可能”という付加情報を記述する。ＸＸＸの部分には本来そのシグネチャが検出する攻撃コード以外の攻撃コードを示す情報が入る。そして、このような付加情報をシグネチャ開発者に表示することにより、当該攻撃コードに対しては新たにシグネチャを開発する必要がないことをシグネチャ開発者に通知することができる。

このように、本実施の形態では、シグネチャの内容を変更して、シグネチャのテンプレートを生成することができ、また、特定のシグネチャが、本来の検知対象以外の攻撃コードを検知可能であることを示す情報を追加することができるので、シグネチャの開発の効率を向上させることができる。

実施の形態１０．
例えば、攻撃コードによっては、ある位置に空白等を挿入された亜種が存在する場合がある。この場合、元の攻撃コードを検知するシグネチャでは検知できない（すり抜け／回避）ことがある。

本実施の形態では、亜種の攻撃コードを検知する派生シグネチャを自動生成する方法を記述する。

例えば、元の攻撃コードが、“ＸＸＸＸＡＢＣＸＸＸＸ”である場合に、元の攻撃コードを検出するためのシグネチャは、“ＡＢＣ”が存在するデータを攻撃コードとみなす。

ここで、“ＸＸＸＸＡＢ△△ＣＸＸＸＸ”又は“ＸＸＸＸＡ△△ＢＣＸＸＸＸ”（△は空白を示す）などの空白の挿入された亜種の攻撃コード（ＡＢＣの文字間に空白が挿入されているが攻撃コードとして動作する）の場合、上記のシグネチャは、間に空白のない“ＡＢＣ”が含まれるデータを攻撃データとみなすので、亜種の攻撃コードの様に、“ＡＢＣ”の文字間に１つ以上の空白や文字を挿入されるとＩＤＳの検知を回避されてしまう。

従って、亜種の攻撃に対抗するために、予め派生のシグネチャを自動生成することで亜種に対抗する必要がある。本実施の形態は、このような亜種の攻撃コードに対応する派生コードの生成に関する。

図２５は、本実施の形態に係るシグネチャ開発支援装置の構成例を示す図である。

ＧＵＩ部８８０は、図２６に示すような派生シグネチャ生成画面を表示し、派生シグネチャ生成画面を通じて、派生シグネチャを生成するための派生シグネチャ生成条件を入力する。また、派生シグネチャ生成画面を通じて、派生シグネチャの元となるシグネチャを入力することもできる。ＧＵＩ部８８０は、派生シグネチャ生成条件入力部の例である。また、シグネチャを入力する場合は、シグネチャ取得部としても機能する。

派生シグネチャ生成部８９０は、派生シグネチャ生成条件に従って、派生シグネチャの元となるシグネチャの内容を変更して、派生シグネチャを生成する。

また、本実施の形態では、派生シグネチャの元となるシグネチャは、脆弱性情報関連情報収集部１５１が、Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００から取得してもよいし、またシグネチャ検索部１５５が、シグネチャＤＢ１１５から取得してもよい。これらの場合には、脆弱性情報関連情報収集部１５１又はシグネチャ検索部１５５がシグネチャ取得部の例となる。

次に、図２７を参照して、本実施の形態に係る動作を説明する。

先ず、ステップＳ２７０１において、ＧＵＩ部８８０が、シグネチャ開発者から派生シグネチャ生成リクエストを入力する。

次に、ステップＳ２７０２において、ＧＵＩ部８８０は、図２６に示すような派生シグネチャ生成画面を表示する。

次に、ステップＳ２７０３において、シグネチャ開発者の指示に従って、派生シグネチャの生成元となるシグネチャを取得する（シグネチャ取得ステップ）。当該シグネチャの取得方法は、前述したように、ＧＵＩ部８８０が、派生シグネチャ生成画面を通じて、派生シグネチャの元となるシグネチャを入力してもよいし、脆弱性情報関連情報収集部１５１が、Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース１００から取得してもよいし、またシグネチャ検索部１５５が、シグネチャＤＢ１１５から取得してもよい。

次に、ステップＳ２７０４において、ＧＵＩ部８８０は、派生シグネチャ生成画面を通じて派生シグネチャ生成条件を入力する（派生シグネチャ生成条件入力ステップ）。

次に、ステップＳ２７０５において、派生シグネチャ生成部８９０が、派生シグネチャ生成条件に従って、派生シグネチャの元となるシグネチャの内容を変更して、派生シグネチャを生成する（派生シグネチャ生成ステップ）。

最後に、ステップＳ２７０６において、ＧＵＩ部８８０が、派生シグネチャ生成画面上に、派生シグネチャを表示する。

次に、図２６の派生シグネチャ生成画面を用いて具体的な派生シグネチャ生成手法を説明する。

図２６の派生シグネチャ生成画面９００において、検知条件９０１には、派生シグネチャの生成元のシグネチャが攻撃コードを検知するための検知条件が表示されている。

また、シグネチャ９０２には、派生シグネチャの生成元となるシグネチャが表示されている。文字列“ＡＢＣ”を含むＷｅｂサーバへのメッセージを捕捉するシグネチャである。

派生シグネチャ生成条件９０３では、シグネチャ開発者が指定する派生シグネチャ生成条件が表示される。図２７では、発生パターンが発生する箇所として“ＡＢＣ”が、派生パターンとして空白が、派生パターンの挿入数として空白が３つ挿入されることが、プロトコルとしてＨＴＴＰが、製品としてＷｅｂサーバＢ２．Ｘが派生シグネチャ生成条件として指定されている。

このように、派生シグネチャ生成条件として、予め、予想される挿入される空白の個数を３個と決定しておくことで、自動的に派生の攻撃コードの特徴を生成する。図２７の例では、以下のような空白３個の適用パターンを自動生成する。
具体的には、以下のパターンである（以下の例において、△は空白を示す）。

Ａ△ＢＣ
ＡＢ△Ｃ
Ａ△△ＢＣ
ＡＢ△△Ｃ
Ａ△△△ＢＣ
ＡＢ△△△Ｃ
・・・（中略）・・・Ａ△△△Ｂ△△△Ｃ
次にこれらの全てのパターンを検出するシグネチャを生成する。

シグネチャの検知条件は例えば以下になる。

Ａから後方０〜３以内離れた位置にＢがある。かつ、Ｂから後方０〜３以内離れた位置にＣがある。

或いは、各攻撃パターン１つ１つに対応したシグネチャを生成しても良い。

或いは、各攻撃パターン１つ１つに対応したシグネチャを生成するのではなく、
（１）Ａから後方０〜３文字以内離れた位置に“ＢＣ”がある（“ＢＣ”から前方０個〜３文字以内離れた位
置にＡがある）
（２）Ａから後方０〜３文字以内離れた位置に“Ｂ△Ｃ”がある（“Ｂ△Ｃ”から前方０個〜３文字以内離れた位置にＡがある）
（３）Ａから後方０〜３文字以内離れた位置に“Ｂ△△Ｃ”がある（“Ｂ△△Ｃ”から前方０個〜３文字以内離れた位置にＡがある）
というように、幾つかの特徴単位で検知条件をまとめても良い。

図２６に示す派生シグネチャ生成画面において、検知したい元々の攻撃コードを検知する検知条件９０１と派生シグネチャの生成元となるシグネチャ９０２を開発用ＧＵＩ９００において入力（作成）する。例では、シグネチャ９０２は、データ“ＡＢＣ”を検知する。

次に、派生シグネチャ生成条件９０３の画面において、派生パターンが発生するデータ列を９０３ａで指摘する。当例では、“ＡＢＣ”に空白が挿入される派生パターンを想定する。よって、９０３ａには“ＡＢＣ”を入力する。

次に、９０３ｂには空白を表す‘ ’を入力する。

次に、派生パターンの挿入数を９０４で指定する。上限を３つと想定しているので、９０４には３を入力する。

最後に、９０５の派生グネチャの生成ボタンを押すと、派生シグネチャ生成部８９０は、以下の攻撃パターンを検出可能な派生シグネチャを生成する。

Ａ△ＢＣ
ＡＢ△Ｃ
Ａ△△ＢＣ
ＡＢ△△Ｃ
Ａ△△△ＢＣ
ＡＢ△△△Ｃ
・・・（中略）・・・Ａ△△△Ｂ△△△Ｃ
また、派生シグネチャ生成部８９０が派生シグネチャを生成した後、派生シグネチャ生成画面９００の別エリアに、派生シグネチャ９２２ａ、９２２ｂ（その他派生数分表示）を表示して、シグネチャ開発者が派生シグネチャの内容を確認可能な構成にしても良い。

また、図２６には図示していないが、画面上の派生シグネチャ９２２ａ、９２２ｂなどを選択して取消／編集する機能があっても良い。

また、派生パターンとして、空白が文字列中だけでなく文字列の前後に含まれることを指定する入力欄を設けてもよい。

また、派生パターンが、空白のみでなく、その他の文字や文字列、バイナリデータが挿入されることが想定される場合は、９０３ｃ、９０３ｄの入力欄で追加指定しても良い。

このように、本実施の形態によれば、亜種の攻撃コードを検知可能な派生シグネチャを生成可能であるため、シグネチャの開発の効率を向上させることができるとともに、亜種の攻撃に対するセキュリティを向上させることができる。

実施の形態１１．
実施の形態１０では、派生シグネチャを作成する場合、亜種の攻撃コードのとりうるパターン数を予め想定した。パターン数の上限を想定できる場合では実施の形態１０は有効な手段である。

しかし、必ずしも上限について想定ができない場合がある。

実施の形態１０では、例えば、空白が１から３個を想定したが、１から１００まで挿入されても攻撃コードとして成り立つのであれば、その組み合わせ分の亜種が考えられることになる。

この場合、Ａから後方０〜１００以内離れた位置にＢがある。かつ、Ｂから後方０〜１００以内離れた位置にＣがあるデータ列を捕捉する、というシグネチャを記述可能であればシグネチャは１つでよい。しかし、ＩＤＳの製品やバージョンによっては記述できないこともあり、各パターン別に用意することになり数が膨大になる。

また、必ずしも１つのシグネチャで記述したからといって高速な処理が実現できるわけではない。

一方、シグネチャを複数用意せざるを得ないという前提では、攻撃コードの亜種が理論上は「１０１の２乗パターン（ＡとＢの間で０〜１００個の空白×ＢとＣの間で０〜１００個の空白）」発生しえても、実際には１０１の２乗パターンも適用することは性能的に不可能なことがある。

このような場合は、効果的な上限数を決め、シグネチャ数を減らすことが必要となる。

しかし、このような場合のシグネチャの削減は、経験に基づく判断になってしまったり、或いは取りこぼしを懸念して判断が付かない場合もあり、断定的に決定することは困難である。

そこで、実施の形態１０では、予想される挿入される空白の個数を開発者が指定していたが、本実施の形態では自動的に亜種のパターンの上限を決定する方法を記述する。

本実施の形態の特徴は、普及している製品の送受信データのフォーマットの特徴を製品ＤＢに蓄積しておき、派生コード生成部８９０が、該製品がとりうるデータフォーマットの許容の範囲内で亜種の攻撃コードの上限を検討する点にある。

例えば、ブラウザ製品のＨＴＴＰリクエストの特徴を製品ＤＢに保持しておき、シグネチャ開発時に空白の挿入パターンの許容範囲をチェックすることで、派生パターンを余計に作成しなくても良いようにする。

データフォーマット違反の送受信データに関しては、そもそも製品間の通信が成り立たないため正常に送受信されず、攻撃コードが攻撃対象装置で活動する以前に、通信プロトコルのチェックで破棄され、機能しない可能性がある。

すなわち、派生シグネチャの生成においては、正常に製品が動作するデータフォーマットの範囲内で亜種を検討すれば良い。

例えば、ある検知対象となる項目において、フォーマットとして空白が２つまで許されるのであれば、亜種の攻撃は２つとり得るのでシグネチャも２種類追加すればよい。空白が３つ以上の亜種は存在したとしても製品自体のフォーマットチェックで機能しない可能性があるため、対応するシグネチャを作成する必要が無い。

以下のようなプロトコルのリクエストデータが存在した場合に、規約上は、リクエストとパラメータ１の間に１つ以上空白が許されている場合を想定する。

リクエスト（空白）パラメータ１（空白）パラメータ２
以下の３つのリクエストは、規約上はプロトコルデータとして有効である。なお、“ＡＢＣ”は攻撃コードとする。
（Ａ）リクエスト（空白）○○ＡＢＣ○○（空白）パラメータ２
（Ｂ）リクエスト（空白）（空白）○○ＡＢＣ○○（空白）パラメータ２
（Ｃ）リクエスト（空白）○○ＡＢＣ○○（空白）（空白）パラメータ２
しかし、実際に使用している製品が送信するリクエストフォーマットが（Ａ）のみであれば、（Ａ）のフォーマットに限定して、第一パラメータ内の“ＡＢＣ”を補足すればよい。（Ｂ）、（Ｃ）のフォーマットで送信された攻撃コードは受信側のプロトコルフォーマットチェックでエラーとなる可能性があり、攻撃コードが有効とならない可能性があるため、（Ｂ）、（Ｃ）のフォーマットを前提とした亜種を想定しなくてもよいことになる。

すなわち、予め、攻撃対象となる製品について、送受信されるデータフォーマットを調べておき、そのフォーマットの範囲内で起こりうる亜種を検討することで、派生のシグネチャ数を削減可能である。

本実施の形態に係るシグネチャ開発支援装置の構成は、図２５に示すものと同様である。

また、動作も、実施の形態１０に示したものとほぼ同様である。

具体的には、図２６に示す様に、検知したい元々の攻撃コードを検知する検知条件９０１とシグネチャ９０２を派生シグネチャ生成画面９００において入力する（作成する）。例では、シグネチャ９０２は、データ“ＡＢＣ”を検知する。

次に、派生シグネチャ生成条件９０３において、派生パターンが発生するデータ列を９０３ａで指摘する。当例では、“ＡＢＣ”に空白が挿入される派生パターンを想定する。よって、９０３ａには“ＡＢＣ”を入力する。

次に、９０３ｂには空白を表す‘ ’を入力する。

次に、プロトコル９０６と製品９０７を指定し派生シグネチャの生成９０５ボタンを押すと、派生シグネチャ生成部８９０は、製品ＤＢ１１１に問い合わせを行い、製品９０７で指定された製品が実際に使用するプロトコル９０６の実装の特徴の情報を通知される。

実装の特徴とは、具体的には、規約に対するデータフォーマットの実装範囲である。

次に、派生シグネチャ生成部８９０は、製品ＤＢ１１１から通知された実装の特徴に基づき、派生シグネチャを生成し、派生シグネチャ９２２ａを出力する。

また、派生シグネチャ生成部８９０が派生シグネチャを生成した後、派生シグネチャ生成画面９００の別エリアに、派生シグネチャ９２２ａ、９２２ｂ（その他派生数分表示）を表示して、シグネチャ開発者が派生シグネチャの内容を確認可能な構成にしても良い。

また、図２６には図示していないが、画面上の派生シグネチャ９２２ａ、９２２ｂなどを選択して取消／編集する機能があっても良い。

このように、攻撃コードの攻撃対象が有するデータフォーマットに基づいて、派生シグネチャを生成するので、不要な派生シグネチャを生成することを回避することができ、シグネチャの開発の効率を向上させることができる。

実施の形態１２．
攻撃コード毎に対応するシグネチャを用意し、対応したシグネチャのみが１つの攻撃コード（攻撃）を検知するという設計に基づきシグネチャを開発することがあるが、開発したシグネチャにおいて、１つのシグネチャが他の攻撃コードも検知してしまうことがある。

この状況を、シグネチャの競合と呼ぶことにする。

これは、１つのシグネチャの検知条件の設定が、本来検知対象とする攻撃コードの特徴以外に、他の攻撃コードの特徴を捉えてしまうことが原因である。

例えば、図２９に示すように、シグネチャＢは攻撃コードＢのみ検知するように設計したはずであるが、実際にＩＤＳに組み込んで動作させると、図３０のように攻撃コードＤも検知してしまうことが判明するといった例である。

ここで、１つの攻撃Ｘに対して１つのシグネチャＸで対応し、検知した場合は、「攻撃Ｘを検知したので、攻撃Ｘの被害を受けないために、Ｘ用の以下の対処を行ってください」というヘルプ情報を管理者に表示する運用の場合に問題となる。

図２９及び図３０の例では、攻撃Ｄが行われていたとしても、シグネチャＤではなくシグネチャＢが検知してしまう可能性があり、その場合管理者は、「攻撃Ｂを検知したので、攻撃Ｂの被害を受けないために、Ｂ用の以下の対処を行ってください」というヘルプ情報を参照することになる。

しかし、実際は攻撃Ｄが行われている。攻撃Ｄへの対処と攻撃Ｂへの対処が異なる場合、本来とは異なる対処が（攻撃Ｂへの対処）が行われるため、適切な対処が行われないことになる。

例えば、攻撃Ｄへの対処は回線切断であるが、攻撃Ｂへの対処は監視強化である場合、攻撃Ｂの対処をとると、回線は切断されないため、攻撃Ｄによる被害が広まってしまう危険性がある。

つまり、シグネチャ１つについて１つのヘルプ情報を表示する運用の場合、シグネチャの競合は攻撃検出時に誤った判断を促す可能性があるということである。

本実施の形態では、このようなシグネチャの競合に関する問題を回避するための方法を記述する。

図２８は、本実施の形態に係るシグネチャ開発支援装置の構成の抜粋を示す。

本実施の形態では、シグネチャ開発支援装置に、攻撃コードによる攻撃を模擬する攻撃装置１００２を接続するとともに、攻撃装置１００２と攻撃コードＤＢ１１６とを連携させる攻撃ＤＢ連携部１００１を設ける。

攻撃装置１００２は、攻撃ＤＢ連携部１００１を経由して、攻撃コードＩＤを指定して単数又は複数の攻撃コード情報（攻撃コード及び攻撃コードＩＤを含む）を取り出し、攻撃コードと攻撃コードＩＤを読み込み、品質管理用ＩＤＳへ送信する機能を有する。

攻撃ＤＢ連携部１００１は、攻撃コードＤＢ１１６から攻撃コード情報を抽出し、攻撃装置１００２に対して攻撃コード情報を供給する。

品質管理用ＩＤＳ８５２は、実施の形態８で示したものと同様であり、本実施の形態では、シグネチャＤＢ連携部８７０を経由して、シグネチャＤＢ１１５からシグネチャ情報を検索し、検索されたエントリに対して攻撃コードに関する情報の追記を命じる機能を有する。

また、シグネチャＤＢ連携部８７０を経由して、シグネチャＩＤを指定しシグネチャＤＢから該当するシグネチャ情報を取り出し、シグネチャを読み込む機能を有する。

本実施の形態では、シグネチャＤＢ１１５、シグネチャＤＢ連携部８７０、品質管理用ＩＤＳ８５２、攻撃コードＤＢ１１６、攻撃ＤＢ連携部１００１をシグネチャ開発支援装置内に配置し、攻撃装置１００２をシグネチャ開発支援装置外に配置することを想定しているが、攻撃装置１００２をシグネチャ開発支援装置内に配置してもよいし、品質管理用ＩＤＳ８５２をシグネチャ開発支援装置外に配置してもよい。

次に、図３１を参照して具体的な動作例を示す。

シグネチャの競合を調べる場合、まず、ステップＳ３１０１において、品質管理用ＩＤＳ８５４内にシグネチャが存在すれば、存在するシグネチャを全て削除した後、品質管理用ＩＤＳ８５４が、シグネチャＤＢ連携部８７０を経由して、シグネチャＤＢ１１５にシグネチャＩＤ１０２４を１つ指定してシグネチャの読み込み命令を送信する。

次に、ステップＳ３１０２において、品質管理用ＩＤＳ８５４は、シグネチャＤＢ１１５から該当するシグネチャ情報１０２６を受信し、シグネチャを品質管理用ＩＤＳ８５４に取り込む。なお、当処理は、品質管理用ＩＤＳ８５４に操作用のＧＵＩを設けて処理を指示しても良い。

次に、攻撃装置１００２は、攻撃ＤＢ連携部１００１を経由して、攻撃コードＤＢ１１６に攻撃コードＩＤ１０２１を１つ指定して攻撃コードの読み込み命令を送信し、ステップＳ３１０３において、攻撃コードＤＢ１１６から攻撃ＤＢ連携部１００１を経由して該当する攻撃コード情報１０２２を攻撃装置１００２に送信し、攻撃コードと攻撃コードＩＤを攻撃装置１００２に取り込む。なお、当処理は、攻撃装置１００２に操作用のＧＵＩを設けて処理を指示しても良い。

次に、ステップＳ３１０４において、攻撃装置１００２は品質管理用ＩＤＳ８５４に対して、攻撃コードＩＤと攻撃コード１０２３を送信する。

次に、ステップＳ３１０５において、品質管理用ＩＤＳ８５４がステップＳ３１０２で取得したシグネチャで当該攻撃コードを検知したかを判定する（攻撃検知性判断ステップ）。

次に、品質管理用ＩＤＳ８５４が当該攻撃コードを検知した場合に、ステップＳ３１０６において、攻撃コードが一致するかを判断する（攻撃検知性判断ステップ）。つまり、ステップＳ３１０５においてシグネチャにより検知した攻撃コードと、当該シグネチャが本来的に検知対象としている攻撃コードが一致するかを判断する。

具体的には、品質管理用ＩＤＳ８５４は、シグネチャＤＢ１１５から供給されたシグネチャ情報に含まれたシグネチャＩＤにより、攻撃コードを検知したシグネチャのシグネチャＩＤを認識し、このシグネチャＩＤを指定して、シグネチャＤＢ１１５に攻撃コードＩＤの読み出し命令を送信する。この結果、品質管理用ＩＤＳ８５４は、シグネチャＤＢ連携部８７０を経由して、シグネチャが本来、検知対象としている攻撃コードの攻撃コードＩＤをシグネチャＤＢ１１５から得る。そして、シグネチャＤＢ１１５から得た攻撃コードＩＤと、攻撃装置から受信した攻撃コードＩＤが一致するかどうかを判断する。

ステップＳ３１０６において攻撃コードが一致する場合は、本来の検知対象である攻撃コードを検知したのみであり、シグネチャの競合は発生していないので、ステップＳ３１０７において、試行していない攻撃コードがあるかどうかを判断し、試行していない攻撃コードが存在する場合は、ステップＳ３１０３に戻って、未試行の攻撃コードにて同様の処理を繰り返す。全ての攻撃コードを試行している場合は、ステップＳ３１１１に進む。

一方、ステップＳ３１０６において攻撃コードが一致しない場合は、本来の検知対象である攻撃コード以外の他の攻撃コードを検知した状態であり、シグネチャの競合が発生している。このため、ステップＳ３１０８において、品質管理用ＩＤＳ８５４は、シグネチャＤＢ連携部８７０に対して、当該シグネチャが検知可能な他の攻撃コードの攻撃コードＩＤ（ステップＳ３１０５で検知した攻撃コードのＩＤ）をシグネチャ情報に追記するよう命じる追記命令１０２５を送信する。

次に、ステップＳ３１０９において、シグネチャＤＢ連携部８７０が、当該攻撃コードＩＤを示す情報を生成し、シグネチャＤＢの該当するシグネチャ情報にこのシグネチャで検知可能な攻撃コードとして追加し、シグネチャＤＢに格納する（シグネチャＤＢ更新ステップ）。

次に、ステップＳ３１１０において、試行していない攻撃コードが存在するかどうかを判断し、試行していない攻撃コードが存在する場合は、ステップＳ３１０３に戻って、未試行の攻撃コードにて同様の処理を繰り返す。全ての攻撃コードを試行している場合は、ステップＳ３１１１に進む。

ステップＳ３１１１では、試行していないシグネチャが存在するかどうかを判断し、試行していないシグネチャが存在する場合は、ステップＳ３１０１に戻って、未試行のシグネチャについて同様の処理を繰り返す。全てのシグネチャについて試行している場合は、処理を終了する。

上記手順のステップＳ３１０３〜Ｓ３１０９を全ての攻撃コードについて実施すると、１つのシグネチャが検知する攻撃コード全てが把握でき、該当するシグネチャ情報には本来検知すべき攻撃コード以外に検知可能な攻撃コードについて、競合情報として自動的に登録することが可能である。

また、ステップＳ３１１１において最後のシグネチャでなければ、ステップＳ３１０１に戻り、シグネチャを別のシグネチャ１つに変更し、ステップＳ３１０２〜Ｓ３１０９を実施すれば、そのシグネチャについても同様に競合情報を調べることが可能である。

競合情報は、シグネチャＤＢのエントリに記録される場合、例えば以下のような実装例がある。

（上記例の様に）検知する攻撃コードＩＤのエントリに競合情報として追加
シグネチャ内のメッセージ表示用フィールドに具体的な文字列として含む
例） 「攻撃Ｂの他に攻撃Ｄも検知します」という意味を表す文字列
よって、上記を全てのシグネチャについて実施することで、自動的に、各シグネチャが本来の攻撃コード以外にどの攻撃コードを検知するのか把握し、シグネチャＤＢ１１５に反映することが可能である。

また、実施の形態８の様に、攻撃コードＤＢ１１６の攻撃コード情報に、該当する脆弱性情報ＩＤが記録されている場合は、攻撃コード情報から得られた該当する脆弱性情報ＩＤを、１０２３ａにおいて、攻撃コードＩＤと攻撃コードと共に、品質管理用ＩＤＳに送信してもよい。

この場合、ステップＳ３１０８及びＳ３１０９において、脆弱性情報ＩＤも攻撃コードＩＤと共に、シグネチャＤＢ１１５に追記しても良い。

また、実施の形態８の様に、攻撃コードＤＢ１１６の攻撃コード情報に、該当するシグネチャＩＤが記録されている場合は、攻撃コード情報から得られた該当するシグネチャＩＤを、１０２３ｂにおいて、攻撃コードＩＤと攻撃コードと共に、品質管理用ＩＤＳに送信してもよい。

この場合、ステップＳ３１０８及びＳ３１０９において、１０２３ｂで送信されるシグネチャＩＤも攻撃コードＩＤと共に、シグネチャＤＢ１１５に追記しても良い。この場合、現在品質管理用ＩＤＳに読み込まれているシグネチャで検知した攻撃コード（１０２３ｂの攻撃コードＩＤで識別）は、１０２３ｂのシグネチャＩＤで識別されるシグネチャでも検知されることを記録することになる。

また、１０２３ａの様に、攻撃コードＩＤと攻撃コードと共に、該脆弱性情報ＩＤを品質管理用ＩＤＳに送信する場合で、本来検知する攻撃コード以外の攻撃コードを検知した場合、品質管理用ＩＤＳは、シグネチャＤＢ連携部８７０を介し該脆弱性情報ＩＤを利用して脆弱性情報ＤＢ１１３を検索する。そして、検索されたエントリに記載されている対応するシグネチャＩＤに、現在品質管理用ＩＤＳにおいて検知したシグネチャＩＤを追記しても良い。

つまり、該脆弱性情報のＤＢエントリにおいて、該脆弱性情報を検知するための元々のシグネチャの他に、検知可能なシグネチャを追記し、シグネチャの競合状態を示すことが可能である。

また、１０２３において、攻撃コードＩＤと攻撃コードを品質管理用ＩＤＳに送信する場合で、本来検知する攻撃コード以外の攻撃コードを検知した場合、品質管理用ＩＤＳは、攻撃ＤＢ連携部１１０１を介して、攻撃コードＤＢに対し、攻撃コードＩＤを利用し攻撃コード情報１０２２を検索する。そして、検索されたエントリに記載されている対応するシグネチャＩＤに、現在品質管理用ＩＤＳにおいて検知したシグネチャＩＤを追記しても良い。

つまり、攻撃コードＤＢ１１６のエントリにおいて、該攻撃コードを検知するための元々のシグネチャの他に、検知可能なシグネチャを追記し、シグネチャの競合状態を示すことが可能である。

シグネチャＤＢ、脆弱性情報ＤＢ、攻撃コードＤＢで競合情報を管理することができるため、ＩＤＳのエンドユーザに特定のシグネチャが本来の検知対象の攻撃コード以外の攻撃コードを検知可能である旨を通知する通知メッセージを生成する通知メッセージ生成部を設け、この通知メッセージを例えばＧＵＩ部８８０から出力するようにしてもよい。また、当該通知メッセージをヘルプ情報に含めてもよいし、Ｗｅｂサイトに掲載てしも良いし、ＩＤＳがＩＤＳエンドユーザ向けに発する警告情報に含めても良い。

ここで、通知メッセージの例は、以下のようなものが考えられる。

「シグネチャＢは、攻撃Ｂの他に攻撃Ｄも検知します」→ヘルプ情報の公開
「攻撃Ｂもしくは攻撃Ｄが検知された」→ＩＤＳが管理者に送信する警告メッセージ
本実施の形態によれば、シグネチャが本来検知対象としている攻撃コード以外の攻撃コードを検知可能であることを通知可能であるので、実際にシグネチャにより攻撃が検知された場合に、本来の検知対象の攻撃以外の攻撃が検知されたことがユーザに通知される、ユーザは当該攻撃の可能性も含めて対処を検討可能となる。

実施の形態１３．
実施の形態１２では、品質管理用ＩＤＳへ取り込むシグネチャは１つづつであった。ＩＤＳの機能によってはシグネチャの取り込み順番により検出するシグネチャの優先度が変化することがあり、シグネチャ１つづつ取り込んで競合を検査しただけでは、十分な検査とは言えない場合がある。

本実施の形態では、そのようなＩＤＳの機能を考慮し、十分な検査を達成可能な実現方法を示す。

まず、ＩＤＳに全てのシグネチャを取り込む。ここでシグネチャの順序（シグネチャ試行順序）を、Ａ→Ｂ→Ｃ→Ｄ→Ｅとする。
この状態で、以下を実施する。

（あ）１つの攻撃コードに対して図３１に示したＳ３１０３〜Ｓ３１０９を実施する。

（い）終了したら攻撃コードを変更してＳ３１０３〜Ｓ３１０９の実施を繰り返す。全ての攻撃コードについて実施する。

次に、シグネチャの試行順序を変更する。例えば以下にする
Ｂ→Ｃ→Ｄ→Ｅ→Ａ
この状態で、上記（あ）、（い）を実施する。

以降、全ての順列について（あ）、（い）を実施することで、全てのシグネチャの取り込み順番について競合の状態を確認することが可能である。

実施の形態１４．
実施の形態１２の、競合情報の記述において、利用者に攻撃Ｂ、攻撃Ｄのどちらの対処を行うか判断させるのではなく、攻撃Ｂと攻撃Ｄの対処の優先度を比較して優先度の高い方に合わせた対処を推奨するメッセージを表示しても良い。

つまり、本実施の形態では、品質管理用ＩＤＳによりいずれかのシグネチャについて他の攻撃コードが存在すると判断された場合に、当該シグネチャが本来検知対象としている攻撃コード及び品質管理用ＩＤＳにより判断された他の攻撃コードに対して優先度を設定する攻撃コード優先度設定部を追加し、実施の形態１２で説明した通知メッセージ生成部は、攻撃コード優先度設定部により優先度が高く設定された攻撃コードに対する措置を優先的に講じるよう通知する通知メッセージを生成し、ＧＵＩ部８８０は、このような通知メッセージを表示する。

優先度の判定は、例えば、実施の形態１における脆弱性情報の選択の優先度判定の基準を元に、予め優先度付けを行った情報を競合情報に含めればよい。そして、ＧＵＩ部８８０から通知される通知メッセージは例えば以下のようなものが考えられる。

例）“攻撃Ｂもしくは攻撃Ｄが検知された。攻撃Ｄはシステムの情報が一部漏洩するだけであるが、攻撃Ｂの場合は不正なプログラムが実行される恐れがあるため、攻撃Ｂに対するパッチが適用されているか優先的に確認してください”
また、攻撃Ｄであれば切断、攻撃Ｂであれば警告のみ、という対処を行っている場合、競合情報において対処の優先度の高い攻撃の情報を示すルールを定めておき、ＩＤＳのプログラムに自動的に判断させても良い。

例えば、シグネチャ内に警告時に表示する文字列を記述できる場合は、文字列において、“ａｔｔａｃｋ Ｄ ＞ ａｔｔａｃｋ Ｂ”と記述する。この場合はメッセージとしては、ａｔｔａｃｋ Ｄ（攻撃Ｄ）かａｔｔａｃｋ Ｂが行われているという警告を示すが、ａｔｔａｃｋ Ｄ の方が優先度が高い（＞）ことを示しており、ＩＤＳの対処としては、ａｔｔａｃｋ Ｄに対する対処を自動的に行うことができる。

例えば９０２への適用を示すと以下になる。
・ プロトコル種別 ： ｔｃｐ
・ 送信元情報、送信先情報 ： 任意の外部ネットワークからＷｅｂサーバのＨＴＴＰポートへ
・ 攻撃の種別 ： ＢＯＦ
・ シグネチャのＩＤ ： １０
・ シグネチャのバージョン ： ｖｅｒ １．０
・ 警告時に表示するメッセージ ：“ａｔｔａｃｋ Ｄ ＞ ａｔｔａｃｋ Ｂ”
・ 捕捉するデータ ： “ＡＢＣ”を含む
このように、いずれかのシグネチャについて他の攻撃コードが存在すると判断された場合に、当該シグネチャが本来検知対象としている攻撃コード及び他の攻撃コードに対して優先度を設定し、いずれか優先度が高く設定された攻撃コードに対する措置を優先的に講じるよう通知する通知メッセージを生成するため、攻撃を検知した際の対策の優先度付けが明確になる。

実施の形態１５．
実施の形態１２、１３、１４では、複数の攻撃コードを検知するシグネチャについて、競合情報を提示することにより、複数ありうる攻撃を示し、ＩＤＳに対し対処の選択権を与えている。

本実施の形態は、複数の攻撃コードを検知するシグネチャにおいて、実際に攻撃コードが検知された場合にいずれの攻撃コードが検知されたのかを判別するための攻撃コード判別情報を生成する攻撃コード判別情報生成部を設け、攻撃コード判別情報に基づいてどのような攻撃を受けたのかを判別する場合について述べる。

実施の形態１２、１３、１４では、ＩＤＳではシグネチャＢが攻撃を検知した場合、それだけでは攻撃Ｂを検知したのか攻撃Ｄを検知したのか断定できない。

しかし、攻撃Ｂと攻撃Ｄのいずれかの攻撃コードの特徴的なパターン本体を含む攻撃コード判別情報を用意しておき、実際に攻撃コードを検知した際には、当該攻撃コード判別情報に基づき、受信したデータパケット内に、特徴的なパターンが含まれるかを検索できれば、含まれている方の特徴で攻撃Ｂか攻撃Ｄか確定できる。

本実施の形態では、攻撃コード判別情報生成部が、検知しうる攻撃コードの特徴的なパターン本体をシグネチャの競合情報と共にＩＤＳのエンドユーザへ提供することで、より確実な検知を実現する。

図３２の例では、シグネチャＢ１１０１は競合情報１１０２において攻撃コードＢと攻撃コードＤを検知することが判明している。

攻撃コードＢ１１０４と攻撃コードＤ１１０５の特徴は以下である。

両方とも、文字列ＸＹＺを含む
攻撃コードＢのみ、文字列ＢＢを含む
攻撃コードＤのみ、文字列ＤＤを含む
このような差異に基づき、攻撃コードＢと攻撃コードＤとを判別するために、ＢＢが含まれていたら攻撃コードＢであり、ＤＤが含まれていたら攻撃コードＤであることを示す攻撃コード判別情報を競合情報１１０２に含ませる。

今、シグネチャＢが受信データ１１０３において攻撃を検知したとする。

しかし、それだけでは、攻撃コードＢか攻撃コードＤか分らないため、競合情報内の攻撃コード判別情報を参照し、受信データ１１０３内に「ＢＢ」が含まれないか検索する。含まれない場合は「ＤＤ」を検索する。

例では、「ＤＤ」が検索されるため、攻撃Ｄであることが確定される。

このように、攻撃コードＢと攻撃コードＤにおいて、シグネチャ本体で検知する条件（「ＸＹＺ」の検知）以外の有意な差分（「ＢＢ」と「ＤＤ」）を攻撃コード判別情報として競合情報に付加することにより、ＩＤＳは競合情報の参照によって攻撃を確定可能である。

また、攻撃を検知した場合にのみ競合情報を参照すればよく、シグネチャを攻撃コードＢ用と攻撃コードＤ用を兼用することも可能となる。

ＩＤＳによっては、攻撃コード全てをバイナリ検索するルールを記述可能なことがある。しかし、この方法では処理効率が悪いことがあり、その場合は、送信元／送信先、及び、「攻撃コードの一部の特徴」を捉えるルールを記述することが検討される。

この方法は、逆に他の攻撃コードも検知してしまう原因でもある。

しかし、本実施の形態によれば、衝突が発生するシグネチャで検知が発生した場合のみ、スキャンデータに攻撃コードの特徴が含まれているかを予備的に検査することで攻撃を確定するため、受信データに対して最初から攻撃コード全体との比較を行うことが無いため処理効率は良く、かつ攻撃を特定できる。

実施の形態１６．
実施の形態１５において、シグネチャの開発者が、競合情報に攻撃コード判別情報を含める場合に、該当する複数の攻撃コードをＧＵＩ上に比較表示し、共通部分と差分部分を分けて表示する。

例えば、図３２の攻撃コードＢ１１０４と攻撃コードＤ１１０５をＧＵＩ表示する場合、ＸＹＺは同じ黒で表示し、差であるＢＢとＤＤを赤で表示する。

単純に２つのデータの差分を表示する既存のツールを適用しても良く、２つの攻撃コードの差分が視覚的に明らかになることで、競合情報の生成が容易になる。

攻撃コード全体ではなく差異部分を切り出して競合情報として提供することにより、シグネチャの開発者は、当表示を元に、競合情報の情報量を縮小でき、スキャンデータにおける攻撃コードの検索も効率化が可能である。

実施の形態１７．
実施の形態１２〜１６は、競合情報を利用することにより、ユーザに判断の材料を多く与え適切な処置を促したり、或いは危険度の高い攻撃への対処を優先させたりすることに着目したものであるが、本実施の形態は、そもそも、競合しないシグネチャを開発する場合の方法である。

本実施の形態では、図２８の品質管理用ＩＤＳ８５４とシグネチャＤＢ１１５を連動させることにより、衝突が判明したシグネチャ間で、検知条件同士、及び、シグネチャ同士をＧＵＩで比較表示する。

具体的には、例えば、図２８の環境で、品質管理用ＩＤＳ８５４において、シグネチャＢが攻撃Ｄを検知した場合、図３３に示すように、実施の形態１２で説明した通知メッセージ生成部がシグネチャＢのシグネチャ情報１２０１を生成し、ＧＵＩ部８８０がこれを表示する。

さらに、品質管理用ＩＤＳ８５４は、攻撃ＤＢ連携部１１０１を介して、攻撃Ｄの攻撃コードＩＤで、攻撃コードＤＢ１１６を検索し、検索された攻撃コード情報に記載のシグネチャＩＤでシグネチャＤＢ連携部８７０を介してシグネチャＤＢ１１５を検索し、シグネチャ情報を得る。この場合は、通知メッセージ生成部が図３３のようなシグネチャＤのシグネチャ情報１２０２を生成し、ＧＵＩ部８８０がこれを表示する
或いは、図２８の１０２３ｂの様に攻撃コードと共に当攻撃コードを元々検知するシグネチャＩＤが送信されている場合は、１０２３ｂ内のシグネチャＩＤを利用してシグネチャＤＢ１１５を検索し、同様にシグネチャ情報を表示する。

シグネチャＢのシグネチャ情報１２０１と検索されたシグネチャＤのシグネチャ情報１２０２を並べて表示する。

検知条件やシグネチャにおける両者の差を色づけして表示してもよい。例えば、検知条件が同じ箇所はハイライト表示するか、グレーアウト表示することによりシグネチャの差分を明確に表示してもよい。当機能によりシグネチャの修正の判断を容易にする。

シグネチャ情報の表示は、シグネチャの競合が発見されるごとに表示されても良い。例えば、１つの攻撃コードを３つ以上のシグネチャで検知した場合は、３つのシグネチャ情報が表示されても良い。

このように、本実施の形態では、検知可能な他の攻撃コードが存在すると判断されたシグネチャ（シグネチャＢ）について、当該シグネチャのシグネチャ属性情報と、当該他の攻撃コードを本来の検知対象としているシグネチャ（シグネチャＤ）のシグネチャ属性情報とを通知する通知メッセージを生成し、当該シグネチャ属性情報を通知する通知メッセージを出力する。

以上のように、本実施の形態によれば、競合関係にある複数のシグネチャを並べて提示することにより、競合しないシグネチャの開発を促すことができる。

実施の形態１８．
開発したシグネチャが攻撃ではない通常のデータを攻撃として検知してしまうことを誤検知という。当実施の形態は誤検知の少ないシグネチャを作成するための方法である。

ＨＴＴＰプロトコルにおける内容を検知するシグネチャにおいては、攻撃用に特殊に加工されたＨＴＭＬタグを、検知するように作成することがある。

その場合、その特殊に加工されたＨＴＭＬタグが通常に運用されているホームページ上に存在するか、その頻度はどれくらいなのかを調べる必要がある。何故ならば、通常に運用されているホームページ上に存在した場合、そのサイトにユーザがアクセスしても、ＩＤＳが検知してしまう恐れが有るからである。この場合は攻撃ではないので、誤検知である。

そこで、シグネチャを作成する段階で、検知するデータの候補が決まった段階で、検索サービスで、そのデータを含むホームページが有るか検索する。

全くヒットしなければ、そのデータを検知するようにシグネチャを決定すればよいし、相当数のヒットが起こった場合は、検知するデータを見直す、という判断が可能となる。

具体的な実装例としては、図２６に類するシグネチャ開発画面において、「誤検知の確認」というボタンを儲け、これを押すと、ＧＵＩからＨＴＴＰクライアントが起動され検知するデータをキーワードとしてインターネット上の検索エンジンに対して検索をかける。その結果を自動的に解析しヒットした件数を画面上に表示することで、その検知するデータの条件を採用するか、変更するか判断することが可能である。このような機能はＧＵＩが呼び出すプログラムで実現可能である。

また、データとしてＨＴＭＬタグだけとは限らず、通常の検知するＨＴＭＬタグ以外のデータ列を検索にかけても良い。

また、開発したシグネチャから、攻撃コードを生成するツール等を利用して攻撃コードを生成し、その攻撃コードを同脆弱性に対応している異なるＩＤＳ製品に流す。検知に成功した場合は少なくともその攻撃コードは別製品においても攻撃コードであるとみなされていることになり、品質確認の１つの指標となる。

また、当発明では、脆弱性情報の収集、シグネチャ情報の収集、攻撃コードの収集、及びこれらの情報の利用に関して述べているが、実際の作業においては、Ｗｅｂサイトやメーリングリストなどの各情報ソースにおける、使用条件に従った作業を行うことになる。

前述した各実施の形態で、シグネチャ開発支援装置は、コンピュータで実現できるものである。

図示していないが、シグネチャ開発支援装置は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。

例えば、ＣＰＵは、バスを介して、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリ、通信ボード、表示装置、Ｋ／Ｂ（キーボード）、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、ＣＤＤ（コンパクトディスクドライブ）、磁気ディスク装置、光ディスク装置、プリンタ装置、スキャナ装置等と接続可能である。

ＲＡＭは、揮発性メモリの一例である。ＲＯＭ、フラッシュメモリ、ＦＤＤ、ＣＤＤ、磁気ディスク装置、光ディスク装置は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。

前述した各実施の形態のシグネチャ開発支援装置が扱うデータや情報は、記憶装置あるいは記憶部に保存され、シグネチャ開発支援装置の各部により、記録され読み出されるものである。

また、通信ボードは、例えば、ＬＡＮ、インターネット、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されている。

磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群（データベース）が記憶されている。

プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。

上記シグネチャ開発支援装置の各部は、一部或いはすべてコンピュータで動作可能なプログラムにより構成しても構わない。或いは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。

上記プログラム群には、実施の形態の説明において「〜部」として説明した処理をＣＰＵに実行させるプログラムが記憶される。これらのプログラムは、例えば、Ｃ言語やＨＴＭＬやＳＧＭＬやＸＭＬなどのコンピュータ言語により作成される。

また、上記プログラムは、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体に記憶され、ＣＰＵにより読み出され実行される。

実施の形態１〜１９に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態１に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態１に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態１に係るシグネチャ開発支援装置におけるキーワード抽出結果の例を示す図。 実施の形態１に係るシグネチャ開発支援装置におけるキーワード抽出結果に基づくカテゴリーごとの順位の例を示す図。 実施の形態１に係るシグネチャ開発支援装置におけるキーワード抽出結果に基づく順位の上位２位以内に登場した例を示す図。 実施の形態２に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態２に係るシグネチャ開発支援装置におけるリンクの例を示す図。 実施の形態２に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態２に係るシグネチャ開発支援装置におけるリンクの例を示す図。 実施の形態２に係るシグネチャ開発支援装置におけるリンクの例を示す図。 実施の形態３に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態４に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態４に係るシグネチャ開発支援装置におけるリンクの例を示す図。 実施の形態４に係るシグネチャ開発支援装置におけるリンクの例を示す図。 実施の形態５に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態５に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態６に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態６に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態８に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態８に係るシグネチャ開発支援装置の動作例を示す図。 実施の形態８に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態９に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態９に係るシグネチャ開発支援装置のテンプレートの例を示す図。 実施の形態１０に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態１０に係るシグネチャ開発支援装置の派生シグネチャ生成画面の例を示す図。 実施の形態１０に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態１２に係るシグネチャ開発支援装置の構成例を示す図。 実施の形態１２に係るシグネチャの競合の例を説明する図。 実施の形態１２に係るシグネチャの競合の例を説明する図。 実施の形態１２に係るシグネチャ開発支援装置の動作例を示すフローチャート図。 実施の形態１５に係るシグネチャ開発支援装置の競合情報の例を示す図。 実施の形態１７に係るシグネチャ開発支援装置のシグネチャの表示例を示す図。 シグネチャの開発フローの例を示す図。

符号の説明

１ シグネチャ開発支援装置、１００ Ｉｎｔｅｒｎｅｔ上の脆弱性情報のソース、１１１ 製品データベース、１１２ 脆弱性キーワードデータベース、１１３ 脆弱性情報データベース、１１４ 優先度判定データベース、１１５ シグネチャデータベース、１１６ 攻撃コードデータベース、１５１ 脆弱性関連情報収集部、１５２ キーワード抽出部、１５３ 優先度判定部、１５４ 脆弱性情報検索部、１５５ シグネチャ検索部、１５６ 攻撃コード検索部、２００ 脆弱性情報処理部、２０１ 出力部、２５１ 脆弱性情報リンク部、３００ シグネチャ・攻撃コード処理部、８５２ 品質管理用ＩＤＳ、８６０ テンプレート生成部、８７０ シグネチャデータベース連携部、１００１ 攻撃データベース連携部、１００２ 攻撃装置。

Claims (46)

1. 脆弱性の特性を示すキーワードが一つ以上含まれる脆弱性情報を取得する脆弱性情報取得部と、
   脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
   前記脆弱性情報取得部により取得された脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出部と、
   前記キーワード抽出部によるキーワード抽出結果に基づいて、前記脆弱性情報取得部により取得された脆弱性情報に対する優先度を判定する優先度判定部とを有することを特徴とする情報処理装置。
2. 前記優先度判定部は、
   前記キーワードデータベースに記憶されている複数のキーワードについてキーワードごとのポイントを設定しておき、前記キーワード抽出部によって抽出されたキーワードごとにポイントを計上し、キーワードのポイントの合計値に基づいて、前記特定の脆弱性情報に対する優先度を判定することを特徴とする請求項１に記載の情報処理装置。
3. 前記優先度判定部は、
   前記キーワードデータベースに記憶されている複数のキーワードを複数のカテゴリーに分類し、カテゴリーごとにキーワードの優先順位を設定しておき、前記キーワード抽出部によって抽出されたキーワードごとにカテゴリー内の優先順位を判断して、前記特定の脆弱性情報に対する優先度を判定することを特徴とする請求項１に記載の情報処理装置。
4. 前記脆弱性情報取得部は、
   脆弱性情報の生成日を示すキーワードが含まれる脆弱性情報を取得し、
   前記キーワード抽出部は、
   前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性情報の生成日を示すキーワードを抽出し、
   前記優先度判定部は、
   脆弱性情報の生成日から時間が経過するほど数値が低くなるポイントを設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性情報の生成日に基づき脆弱性情報の生成日からの経過時間を算出し、算出した経過時間に基づいてポイントを計上することを特徴とする請求項２に記載の情報処理装置。
5. 前記脆弱性情報取得部は、
   脆弱性情報の生成日を示すキーワードが含まれる脆弱性情報を取得し、
   前記キーワード抽出部は、
   前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性情報の生成日を示すキーワードを抽出し、
   前記優先度判定部は、
   脆弱性情報の生成日からの経過時間に関するカテゴリーを設け、脆弱性情報の生成日からの時間が経過するほど順位が低くなる優先順位を設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性情報の生成日に基づき脆弱性情報の生成日からの経過時間を算出し、算出した経過時間に基づいて優先順位を判断することを特徴とする請求項３に記載の情報処理装置。
6. 前記脆弱性情報取得部は、
   脆弱性情報に示されている脆弱性の危険度の大きさを示すキーワードが含まれる脆弱性情報を取得し、
   前記キーワード抽出部は、
   前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性の危険度の大きさを示すキーワードを抽出し、
   前記優先度判定部は、
   脆弱性の危険度が大きくなるほど数値が大きくなるポイントを設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性の危険度の大きさに基づいてポイントを計上することを特徴とする請求項２に記載の情報処理装置。
7. 前記脆弱性情報取得部は、
   脆弱性情報に示されている脆弱性の危険度の大きさを示すキーワードが含まれる脆弱性情報を取得し、
   前記キーワード抽出部は、
   前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性の危険度の大きさを示すキーワードを抽出し、
   前記優先度判定部は、
   脆弱性の危険度に関するカテゴリーを設け、脆弱性の危険度が大きくなるほど順位が高くなる優先順位を設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性の危険度の大きさに基づいて優先順位を判断することを特徴とする請求項３に記載の情報処理装置。
8. 前記優先度判定部は、
   脆弱性情報の生成日からの経過時間が一定レベルを超えている脆弱性情報に対しては優先度を判定しないことを特徴とする請求項４又は５に記載の情報処理装置。
9. 前記優先度判定部は、
   脆弱性の危険度が一定レベル以下の脆弱性情報に対しては優先度を判定しないことを特徴とする請求項６又は７に記載の情報処理装置。
10. 脆弱性の特性を示すキーワードが一つ以上含まれる複数の脆弱性情報を取得する脆弱性情報取得部と
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    前記脆弱性情報取得部により取得された複数の脆弱性情報に対して、それぞれの脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出部と、
    前記キーワード抽出部によるキーワード抽出結果を比較し、キーワード抽出結果において所定の共通関係を有する二以上の脆弱性情報を相互に対応づける脆弱性情報対応付け部とを有することを特徴とする情報処理装置。
11. 前記脆弱性情報取得部は、
    複数のソースから、複数の脆弱性情報を取得することを特徴とする請求項１０に記載の情報処理装置。
12. 前記情報処理装置は、更に、
    前記キーワード抽出部によるキーワード抽出結果と、前記脆弱性情報対応付け部による対応付けの有無とに基づいて、前記キーワード抽出部によりキーワードの抽出が行われた脆弱性情報に対する優先度を判定する優先度判定部を有することを特徴とする請求項１０に記載の情報処理装置。
13. 前記優先度判定部は、
    前記脆弱性情報対応付け部により他の脆弱性情報との対応付けが行われた脆弱性情報の優先度を、前記脆弱性情報対応付け部により対応付けが行われていない脆弱性情報の優先度よりも高く判定することを特徴とする請求項１２に記載の情報処理装置。
14. 前記情報処理装置は、更に
    前記キーワード抽出部によるキーワード抽出結果に基づいて、キーワードの抽出が行われた脆弱性情報に対する優先度を判定する優先度判定部を有し、
    前記脆弱性情報対応付け部は、
    前記優先度判定部により判定された優先度に基づいて前記複数の脆弱性情報の中から選択された脆弱性情報とキーワード抽出結果において所定の共通関係を有する脆弱性情報を、当該選択された脆弱性情報に対応付けることを特徴とする請求項１０に記載の情報処理装置。
15. 前記情報処理装置は、更に、
    前記キーワード抽出部によるキーワード抽出結果とともに、脆弱性情報を記憶する脆弱性情報データベースを有し、
    前記脆弱性情報取得部は、
    前記脆弱性情報データベースに記憶されているいずれかの脆弱性情報の更新情報である更新脆弱性情報を受信する場合があり、
    前記キーワード抽出部は、
    前記脆弱性情報取得部により取得された更新脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出し、
    前記脆弱性情報対応付け部は、
    前記キーワード抽出部による更新脆弱性情報のキーワード抽出結果と前記脆弱性情報データベースに記憶されているキーワード抽出結果とを比較し、前記脆弱性情報データベースに記憶されている脆弱性情報のうち、更新脆弱性情報とキーワード抽出結果において所定の共通関係を有する脆弱性情報を選択し、選択した脆弱性情報と更新脆弱性情報とを相互に対応づけることを特徴とする請求項１０に記載の情報処理装置。
16. 複数のシグネチャを記憶するシグネチャデータベースと、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索部と、
    脆弱性の特性を示すキーワードが一つ以上含まれた複数のシグネチャ生成済みの脆弱性情報を、それぞれのシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子と、それぞれのシグネチャ生成済みの脆弱性情報に含まれるキーワードの抽出結果とともに記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶されたシグネチャ生成済みの脆弱性情報の中から特定の条件に合致するシグネチャ生成済みの脆弱性情報を検索する脆弱性情報検索部と、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出部とを有し、
    前記脆弱性情報検索部は、
    前記キーワード抽出部による前記特定の脆弱性情報のキーワード抽出結果と、前記脆弱性情報データベースに記憶されている複数のシグネチャ生成済みの脆弱性情報のキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャ生成済みの脆弱性情報を前記脆弱性情報データベースから検索し、検索したシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子を抽出し、
    前記シグネチャ検索部は、
    前記脆弱性情報検索部により抽出されたシグネチャ識別子に一致するシグネチャを前記シグネチャデータベースから検索することを特徴とする情報処理装置。
17. 前記情報処理装置は、
    脆弱性の特性を示すキーワードが一つ以上含まれた脆弱性情報と、当該脆弱性情報と対応関係にあるシグネチャを取得する脆弱性情報取得部と、
    シグネチャの内容の少なくとも一部を出力する出力部とを有し、
    前記キーワード抽出部は、
    前記脆弱性情報取得部により取得された取得脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出し、
    前記脆弱性情報検索部は、
    前記キーワード抽出部による前記取得脆弱性情報のキーワード抽出結果と、前記脆弱性情報データベースに記憶されている複数のシグネチャ生成済みの脆弱性情報のキーワード抽出結果とを比較し、前記取得脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャ生成済みの脆弱性情報を前記脆弱性情報データベースから検索し、検索したシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子を抽出し、
    前記シグネチャ検索部は、
    前記脆弱性情報検索部により抽出されたシグネチャ識別子に一致するシグネチャを前記シグネチャデータベースから検索し、
    前記出力部は、
    前記シグネチャ検索部により検索されたシグネチャの内容の少なくとも一部と、前記脆弱性情報取得部により取得されたシグネチャの内容の少なくとも一部とを出力することを特徴とする請求項１６に記載の情報処理装置。
18. 脆弱性の特性を示すキーワードが一つ以上含まれた複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索部と、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャと対応関係にある脆弱性情報に含まれるキーワードの抽出結果とともに記憶するシグネチャデータベースと、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索部と、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出部とを有し、
    前記シグネチャ検索部は、
    前記キーワード抽出部による前記特定の脆弱性情報のキーワード抽出結果と、シグネチャデータベースに記憶されている複数のシグネチャに関するキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャを前記シグネチャデータベースから検索し、検索したシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子を抽出し、
    前記脆弱性情報検索部は、
    前記シグネチャ検索部により抽出された脆弱性情報識別子に一致する脆弱性情報を前記脆弱性情報データベースから検索することを特徴とする情報処理装置。
19. 前記情報処理装置は、
    脆弱性の特性を示すキーワードが一つ以上含まれた脆弱性情報と、当該脆弱性情報と対応関係にあるシグネチャを取得する脆弱性情報取得部と、
    シグネチャの内容の少なくとも一部を出力する出力部とを有し、
    前記キーワード抽出部は、
    前記脆弱性情報取得部により取得された取得脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出し、
    前記シグネチャ検索部は、
    前記キーワード抽出部による前記取得脆弱性情報のキーワード抽出結果と、シグネチャデータベースに記憶されている複数のシグネチャに関するキーワード抽出結果とを比較し、前記取得脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャを前記シグネチャデータベースから検索し、
    前記出力部は、
    前記シグネチャ検索部により検索されたシグネチャの内容の少なくとも一部と、前記脆弱性情報取得部により取得されたシグネチャの内容の少なくとも一部とを出力することを特徴とする請求項１８に記載の情報処理装置。
20. 複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索部と、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャの属性を示すシグネチャ属性情報とともに記憶するシグネチャデータベースと、
    攻撃コードを取得する攻撃コード取得部と、
    前記シグネチャデータベースに記憶されている複数のシグネチャのうち、前記攻撃コード取得部により取得された取得攻撃コードを検知可能なシグネチャを判断する攻撃検知性判断部と、
    脆弱性情報の内容の少なくとも一部と、シグネチャ属性情報の内容の少なくとも一部を出力する出力部とを有し、
    前記脆弱性情報検索部は、
    前記シグネチャデータベースに記憶されている脆弱性情報識別子に基づいて、前記攻撃検知性判断部により前記取得攻撃コードを検知可能と判断された検知可能シグネチャと対応関係にある脆弱性情報を検索し、
    前記出力部は、
    前記シグネチャデータベースに記憶されている前記検知可能シグネチャのシグネチャ属性情報の内容の少なくとも一部と、前記脆弱性情報検索部により検索された脆弱性情報の内容の少なくとも一部とを出力することを特徴とする情報処理装置。
21. 前記情報処理装置は、更に、
    前記検知可能シグネチャの内容を変更してシグネチャのテンプレートを生成するテンプレート生成部を有することを特徴とする請求項２０に記載の情報処理装置。
22. 前記情報処理装置は、
    前記検知可能シグネチャが前記取得攻撃コードを検知可能である旨の記述を、前記検知可能シグネチャのシグネチャ属性情報に追加して、シグネチャデータベースを更新するシグネチャデータベース更新部を有することを特徴とする請求項２０に記載の情報処理装置。
23. 特定の攻撃コードを検知対象とするシグネチャを取得するシグネチャ取得部と、
    前記シグネチャ取得部により取得されたシグネチャが検知対象としている前記特定の攻撃コードの亜種の攻撃コードを検知対象とする派生シグネチャを生成するための派生シグネチャ生成条件を入力する派生シグネチャ生成条件入力部と、
    前記派生シグネチャ生成条件入力部により入力された派生シグネチャ生成条件に従って、前記シグネチャ取得部により取得されたシグネチャの内容を変更して派生シグネチャを生成する派生シグネチャ生成部とを有することを特徴とする情報処理装置。
24. 前記派生シグネチャ生成部は、
    前記特定の攻撃コードの攻撃対象が有するデータフォーマットを解析し、前記特定の攻撃コードの攻撃対象が有するデータフォーマットに基づいて、派生シグネチャを生成することを特徴とする請求項２３に記載の情報処理装置。
25. それぞれ特定の攻撃コードを検知対象とする複数のシグネチャを記憶するシグネチャデータベースと、
    前記シグネチャデータベースに記憶されたシグネチャごとに、検知対象の攻撃コード以外にそれぞれのシグネチャが検知可能な他の攻撃コードが存在するか否かを判断する攻撃検知性判断部と、
    前記攻撃検知性判断部により検知可能な他の攻撃コードが存在すると判断されたシグネチャについて、前記攻撃検知性判断部により判断された他の攻撃コードを示すシグネチャ属性情報を生成し、生成したシグネチャ属性情報を当該シグネチャに対応付けて前記シグネチャデータベースに格納するシグネチャデータベース更新部とを有することを特徴とする情報処理装置。
26. 前記情報処理装置は、更に、
    前記攻撃検知性判断部により検知可能な他の攻撃コードが存在すると判断されたシグネチャについて、前記攻撃検知性判断部により判断された他の攻撃コードを通知する通知メッセージを生成する通知メッセージ生成部と、
    前記通知メッセージ生成部により生成された通知メッセージを出力する出力部とを有することを特徴とする請求項２５に記載の情報処理装置。
27. 前記攻撃検知性判断部は、
    複数のシグネチャについて特定のシグネチャ試行順序で攻撃コードの検知可否の試行を行うとともに、前記特定のシグネチャ試行順序と異なる試行順序により複数のシグネチャについて攻撃コードの検知可否の試行を行って、それぞれのシグネチャが検知可能な他の攻撃コードが存在するか否かを判断することを特徴とする請求項２５に記載の情報処理装置。
28. 前記情報処理装置は、更に、
    前記攻撃検知性判断部によりいずれかのシグネチャについて他の攻撃コードが存在すると判断された場合に、当該シグネチャが本来検知対象としている攻撃コード及び前記攻撃検知性判断部により判断された他の攻撃コードに対して優先度を設定する攻撃コード優先度設定部を有し、
    前記通知メッセージ生成部は、
    前記攻撃コード優先度設定部により優先度が高く設定された攻撃コードに対する措置を優先的に講じるよう通知する通知メッセージを生成することを特徴とする請求項２６に記載の情報処理装置。
29. 前記情報処理装置は、更に、
    前記攻撃検知性判断部によりいずれかのシグネチャについて他の攻撃コードが存在すると判断された場合に、当該シグネチャが実際にいずれかの攻撃コードを検知した際に当該シグネチャが本来検知対象としている攻撃コード及び前記攻撃検知性判断部により判断された他の攻撃コードのいずれが検知されたのかを判別するための攻撃コード判別情報を生成する攻撃コード判別情報生成部を有することを特徴とする請求項２５に記載の情報処理装置。
30. 前記シグネチャデータベースは、
    複数のシグネチャとともに、それぞれのシグネチャの属性を示すシグネチャ属性情報を記憶しており、
    前記通知メッセージ部は、
    前記前記攻撃検知性判断部により検知可能な他の攻撃コードが存在すると判断されたシグネチャについて、当該シグネチャのシグネチャ属性情報と、他の攻撃コードを本来の検知対象としているシグネチャのシグネチャ属性情報とを通知する通知メッセージを生成し、
    前記出力部は、
    前記通知メッセージ生成部により生成されたシグネチャ属性情報を通知する通知メッセージを出力することを特徴とする請求項２６に記載の情報処理装置。
31. 脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースを用いる情報処理方法であって、
    脆弱性の特性を示すキーワードが一つ以上含まれる脆弱性情報を取得する脆弱性情報取得ステップと、
    前記脆弱性情報取得ステップにより取得された脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出ステップと、
    前記キーワード抽出ステップによるキーワード抽出結果に基づいて、前記脆弱性情報取得ステップにより取得された脆弱性情報に対する優先度を判定する優先度判定ステップとを有することを特徴とする情報処理方法。
32. 脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースを用いる情報処理方法であって、
    脆弱性の特性を示すキーワードが一つ以上含まれる複数の脆弱性情報を取得する脆弱性情報取得ステップと
    前記脆弱性情報取得ステップにより取得された複数の脆弱性情報に対して、それぞれの脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出ステップと、
    前記キーワード抽出ステップによるキーワード抽出結果を比較し、キーワード抽出結果において所定の共通関係を有する二以上の脆弱性情報を相互に対応づける脆弱性情報対応付けステップとを有することを特徴とする情報処理方法。
33. 複数のシグネチャを記憶するシグネチャデータベースと、
    脆弱性の特性を示すキーワードが一つ以上含まれた複数のシグネチャ生成済みの脆弱性情報を、それぞれのシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子と、それぞれのシグネチャ生成済みの脆弱性情報に含まれるキーワードの抽出結果とともに記憶する脆弱性情報データベースと、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    を用いる情報処理方法であって、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索ステップと、
    前記脆弱性情報データベースに記憶されたシグネチャ生成済みの脆弱性情報の中から特定の条件に合致するシグネチャ生成済みの脆弱性情報を検索する脆弱性情報検索ステップと、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出ステップとを有し、
    前記脆弱性情報検索ステップは、
    前記キーワード抽出ステップによる前記特定の脆弱性情報のキーワード抽出結果と、前記脆弱性情報データベースに記憶されている複数のシグネチャ生成済みの脆弱性情報のキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャ生成済みの脆弱性情報を前記脆弱性情報データベースから検索し、検索したシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子を抽出し、
    前記シグネチャ検索ステップは、
    前記脆弱性情報検索ステップにより抽出されたシグネチャ識別子に一致するシグネチャを前記シグネチャデータベースから検索することを特徴とする情報処理方法。
34. 脆弱性の特性を示すキーワードが一つ以上含まれた複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャと対応関係にある脆弱性情報に含まれるキーワードの抽出結果とともに記憶するシグネチャデータベースと、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    を用いる情報処理方法であって、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索ステップと、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索ステップと、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出ステップとを有し、
    前記シグネチャ検索ステップは、
    前記キーワード抽出ステップによる前記特定の脆弱性情報のキーワード抽出結果と、シグネチャデータベースに記憶されている複数のシグネチャに関するキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャを前記シグネチャデータベースから検索し、検索したシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子を抽出し、
    前記脆弱性情報検索ステップは、
    前記シグネチャ検索ステップにより抽出された脆弱性情報識別子に一致する脆弱性情報を前記脆弱性情報データベースから検索することを特徴とする情報処理方法。
35. 複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャの属性を示すシグネチャ属性情報とともに記憶するシグネチャデータベースと、
    を用いる情報処理方法であって、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索ステップと、
    攻撃コードを取得する攻撃コード取得ステップと、
    前記シグネチャデータベースに記憶されている複数のシグネチャのうち、前記攻撃コード取得ステップにより取得された取得攻撃コードを検知可能なシグネチャを判断する攻撃検知性判断ステップと、
    脆弱性情報の内容の少なくとも一部と、シグネチャ属性情報の内容の少なくとも一部を出力する出力ステップとを有し、
    前記脆弱性情報検索ステップは、
    前記シグネチャデータベースに記憶されている脆弱性情報識別子に基づいて、前記攻撃検知性判断ステップにより前記取得攻撃コードを検知可能と判断された検知可能シグネチャと対応関係にある脆弱性情報を検索し、
    前記出力ステップは、
    前記シグネチャデータベースに記憶されている前記検知可能シグネチャのシグネチャ属性情報の内容の少なくとも一部と、前記脆弱性情報検索ステップにより検索された脆弱性情報の内容の少なくとも一部とを出力することを特徴とする情報処理方法。
36. 特定の攻撃コードを検知対象とするシグネチャを取得するシグネチャ取得ステップと、
    前記シグネチャ取得ステップにより取得されたシグネチャが検知対象としている前記特定の攻撃コードの亜種の攻撃コードを検知対象とする派生シグネチャを生成するための派生シグネチャ生成条件を入力する派生シグネチャ生成条件入力ステップと、
    前記派生シグネチャ生成条件入力ステップにより入力された派生シグネチャ生成条件に従って、前記シグネチャ取得ステップにより取得されたシグネチャの内容を変更して派生シグネチャを生成する派生シグネチャ生成ステップとを有することを特徴とする情報処理方法。
37. それぞれ特定の攻撃コードを検知対象とする複数のシグネチャを記憶するシグネチャデータベースを用いる情報処理方法であって、
    前記シグネチャデータベースに記憶されたシグネチャごとに、検知対象の攻撃コード以外にそれぞれのシグネチャが検知可能な他の攻撃コードが存在するか否かを判断する攻撃検知性判断ステップと、
    前記攻撃検知性判断ステップにより検知可能な他の攻撃コードが存在すると判断されたシグネチャについて、前記攻撃検知性判断ステップにより判断された他の攻撃コードを示すシグネチャ属性情報を生成し、生成したシグネチャ属性情報を当該シグネチャに対応付けて前記シグネチャデータベースに格納するシグネチャデータベース更新ステップとを有することを特徴とする情報処理方法。
38. 脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースを用いるプログラムであって、
    脆弱性の特性を示すキーワードが一つ以上含まれる脆弱性情報を取得する脆弱性情報取得処理と、
    前記脆弱性情報取得処理により取得された脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出処理と、
    前記キーワード抽出処理によるキーワード抽出結果に基づいて、前記脆弱性情報取得処理により取得された脆弱性情報に対する優先度を判定する優先度判定処理とをコンピュータに実行させることを特徴とするプログラム。
39. 脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースを用いるプログラムであって、
    脆弱性の特性を示すキーワードが一つ以上含まれる複数の脆弱性情報を取得する脆弱性情報取得処理と
    前記脆弱性情報取得処理により取得された複数の脆弱性情報に対して、それぞれの脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出処理と、
    前記キーワード抽出処理によるキーワード抽出結果を比較し、キーワード抽出結果において所定の共通関係を有する二以上の脆弱性情報を相互に対応づける脆弱性情報対応付け処理とをコンピュータに実行させることを特徴とするプログラム。
40. 複数のシグネチャを記憶するシグネチャデータベースと、
    脆弱性の特性を示すキーワードが一つ以上含まれた複数のシグネチャ生成済みの脆弱性情報を、それぞれのシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子と、それぞれのシグネチャ生成済みの脆弱性情報に含まれるキーワードの抽出結果とともに記憶する脆弱性情報データベースと、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    を用いるプログラムであって、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索処理と、
    前記脆弱性情報データベースに記憶されたシグネチャ生成済みの脆弱性情報の中から特定の条件に合致するシグネチャ生成済みの脆弱性情報を検索する脆弱性情報検索処理と、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出処理とをコンピュータに実行させ、
    前記脆弱性情報検索処理は、
    前記キーワード抽出処理による前記特定の脆弱性情報のキーワード抽出結果と、前記脆弱性情報データベースに記憶されている複数のシグネチャ生成済みの脆弱性情報のキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャ生成済みの脆弱性情報を前記脆弱性情報データベースから検索し、検索したシグネチャ生成済みの脆弱性情報と対応関係にあるシグネチャのシグネチャ識別子を抽出し、
    前記シグネチャ検索処理は、
    前記脆弱性情報検索処理により抽出されたシグネチャ識別子に一致するシグネチャを前記シグネチャデータベースから検索することを特徴とするプログラム。
41. 脆弱性の特性を示すキーワードが一つ以上含まれた複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャと対応関係にある脆弱性情報に含まれるキーワードの抽出結果とともに記憶するシグネチャデータベースと、
    脆弱性の特性を示す複数のキーワードを記憶するキーワードデータベースと、
    を用いるプログラムであって、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索処理と、
    前記シグネチャデータベースに記憶されたシグネチャの中から特定の条件に合致するシグネチャを検索するシグネチャ検索処理と、
    脆弱性の特性を示すキーワードが一つ以上含まれる特定の脆弱性情報から、前記キーワードデータベースに記憶されているキーワードに合致するキーワードを抽出するキーワード抽出処理とをコンピュータに実行させ、
    前記シグネチャ検索処理は、
    前記キーワード抽出処理による前記特定の脆弱性情報のキーワード抽出結果と、シグネチャデータベースに記憶されている複数のシグネチャに関するキーワード抽出結果とを比較し、前記特定の脆弱性情報とキーワード抽出結果において所定の共通関係を有するシグネチャを前記シグネチャデータベースから検索し、検索したシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子を抽出し、
    前記脆弱性情報検索処理は、
    前記シグネチャ検索処理により抽出された脆弱性情報識別子に一致する脆弱性情報を前記脆弱性情報データベースから検索することを特徴とするプログラム。
42. 複数の脆弱性情報を記憶する脆弱性情報データベースと、
    前記脆弱性情報データベースに記憶された複数の脆弱性情報から生成された複数のシグネチャを、それぞれのシグネチャと対応関係にある脆弱性情報の脆弱性情報識別子と、それぞれのシグネチャの属性を示すシグネチャ属性情報とともに記憶するシグネチャデータベースと、
    を用いるプログラムであって、
    前記脆弱性情報データベースに記憶された脆弱性情報の中から特定の条件に合致する脆弱性情報を検索する脆弱性情報検索処理と、
    攻撃コードを取得する攻撃コード取得処理と、
    前記シグネチャデータベースに記憶されている複数のシグネチャのうち、前記攻撃コード取得処理により取得された取得攻撃コードを検知可能なシグネチャを判断する攻撃検知性判断処理と、
    脆弱性情報の内容の少なくとも一部と、シグネチャ属性情報の内容の少なくとも一部を出力する出力処理とをコンピュータに実行させ、
    前記脆弱性情報検索処理は、
    前記シグネチャデータベースに記憶されている脆弱性情報識別子に基づいて、前記攻撃検知性判断処理により前記取得攻撃コードを検知可能と判断された検知可能シグネチャと対応関係にある脆弱性情報を検索し、
    前記出力処理は、
    前記シグネチャデータベースに記憶されている前記検知可能シグネチャのシグネチャ属性情報の内容の少なくとも一部と、前記脆弱性情報検索処理により検索された脆弱性情報の内容の少なくとも一部とを出力することを特徴とするプログラム。
43. 特定の攻撃コードを検知対象とするシグネチャを取得するシグネチャ取得処理と、
    前記シグネチャ取得処理により取得されたシグネチャが検知対象としている前記特定の攻撃コードの亜種の攻撃コードを検知対象とする派生シグネチャを生成するための派生シグネチャ生成条件を入力する派生シグネチャ生成条件入力処理と、
    前記派生シグネチャ生成条件入力処理により入力された派生シグネチャ生成条件に従って、前記シグネチャ取得処理により取得されたシグネチャの内容を変更して派生シグネチャを生成する派生シグネチャ生成処理とをコンピュータに実行させることを特徴とするプログラム。
44. それぞれ特定の攻撃コードを検知対象とする複数のシグネチャを記憶するシグネチャデータベースを用いるプログラムであって、
    前記シグネチャデータベースに記憶されたシグネチャごとに、検知対象の攻撃コード以外にそれぞれのシグネチャが検知可能な他の攻撃コードが存在するか否かを判断する攻撃検知性判断処理と、
    前記攻撃検知性判断処理により検知可能な他の攻撃コードが存在すると判断されたシグネチャについて、前記攻撃検知性判断処理により判断された他の攻撃コードを示すシグネチャ属性情報を生成し、生成したシグネチャ属性情報を当該シグネチャに対応付けて前記シグネチャデータベースに格納するシグネチャデータベース更新処理とをコンピュータに実行させることを特徴とするプログラム。
45. 前記脆弱性情報取得部は、
    脆弱性情報の生成日を示すキーワードが含まれる脆弱性情報を取得し、
    前記キーワード抽出部は、
    前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性情報の生成日を示すキーワードを抽出し、
    前記優先度判定部は、
    脆弱性情報の生成日から時間が経過するほど数値が高くなるポイントを設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性情報の生成日に基づき脆弱性情報の生成日からの経過時間を算出し、算出した経過時間に基づいてポイントを計上することを特徴とする請求項２に記載の情報処理装置。
46. 前記脆弱性情報取得部は、
    脆弱性情報の生成日を示すキーワードが含まれる脆弱性情報を取得し、
    前記キーワード抽出部は、
    前記脆弱性情報取得部により取得された脆弱性情報から、脆弱性情報の生成日を示すキーワードを抽出し、
    前記優先度判定部は、
    脆弱性情報の生成日からの経過時間に関するカテゴリーを設け、脆弱性情報の生成日からの時間が経過するほど順位が高くなる優先順位を設定しておき、前記キーワード抽出部により抽出されたキーワードに示された脆弱性情報の生成日に基づき脆弱性情報の生成日からの経過時間を算出し、算出した経過時間に基づいて優先順位を判断することを特徴とする請求項３に記載の情報処理装置。

Images