JP4458190B2 - 情報表示システムおよび情報表示方法 - Google Patents

Description

本発明は、情報表示システムおよび情報表示方法に関する。

近年、インターネット技術などを用いた情報システムが企業活動のインフラストラクチャとして広く活用されるようになった。これに伴い、情報システムに対する不正アクセスやウィルスによる情報資産への脅威を回避するためのセキュリティシステムの重要性が一段と高まっている。さらに、このようなセキュリティシステムで使用される機器として、様々なベンダの多種多様な機器が提供されてきている。

また、インターネットを活用している企業などでは、セキュリティポリシーを策定する動きが活発になってきている。「セキュリティポリシー」とは、組織内のセキュリティに関する基準（各種脅威を回避するための指針となる基準）をまとめた基準集である。また、セキュリティに関する一つ一つの基準を「ルール」と記すことにする。セキュリティポリシーは、ルールの集合として表される。

セキュリティポリシーには、人間の行動指針を定めたルールが含まれる。このようなルールの例としては、例えばサーバルームへの入退室管理基準や、記録媒体の取り扱い基準等がある。また、セキュリティポリシーには、管理対象システムに対するセキュリティ設定の指針となるルールも含まれる。すなわち、セキュリティに関する各種設定項目の設定内容を如何に定めるかの指針となるルールもセキュリティポリシーに含まれる。システム管理者は、セキュリティ設定の指針となる個々のルールに則って、管理対象システムに適切な設定を行う必要がある。

しかし、ネットワークシステム全体に対して適切な設定を行い、ネットワークシステムを安全かつ有効に運用・管理するためには、通常、高度な専門的知識を持つシステム管理者を要する。さらに、そのようなシステム管理者が存在したとしても、その作業の負荷は著しく大きい。

そのため、システム管理者の負担を軽減するための装置や方法が提案されている（例えば、特許文献１）。特許文献１に記載のシステムは、計算機ネットワークの構成を表すネットワーク構成定義から、診断ポリシーおよび監視ポリシーを作成する。そして、診断結果と監視結果とを分析し、総合分析レポートを出力することで、システム管理者がネットワーク構成の再検討を行えるようにしている。

また、管理対象のネットワークシステムに対し、セキュリティポリシーに則った適切な設定を行うためのシステムが提案されている（例えば、特許文献２）。なお、特許文献２では「ルール」に相当する概念に「ポリシー」という語を用いて説明している。従って、以下に示す特許文献２の説明では「ルール」の代わりに「ポリシー」という語を用いる。

特許文献２に記載のシステムは、情報セキュリティポリシーデータベース、セキュリティ管理・監査プログラムデータベース、ポリシー・設定情報マッピングテーブル、設定情報格納データベース等の各種データベースを備える。情報セキュリティポリシーデータベースは、個々のポリシー毎に、そのポリシーの施策種別、そのポリシーが適用される適用機器および適用ソフトウェア等を対応付けて格納する。ポリシー・設定情報マッピングテーブルには、ポリシー毎に、管理対象となるプログラムで設定を行うべき項目と、その設定項目の推奨される設定値とがあらかじめ記述されている。設定情報格納データベースは、各ソフトウェアの設定内容を格納する。

特許文献２に記載のシステムは、ユーザ（システム管理者）が構築したあるいは構築しようとしている情報システムの構成機器（装置種別、ソフトウェア種別およびプログラム名の組み合わせ）を選択させる画面を表示し、ユーザに構成機器の選択を促す。構成機器が選択されると、選択された構成機器に対して適用可能なポリシーの集合を情報セキュリティポリシーデータベースの中から抽出する。そして、抽出したポリシーの集合を表示して、ユーザに、その中から採用するポリシーの選択を要求する。ポリシーが選択されると、ポリシー・設定情報マッピングテーブルを参照して、選択されたポリシーに対応する設定情報を、設定情報格納データベースに格納する。そして、設定項目に対し、複数のエントリがマッチする場合、設定情報格納データベースに格納した設定値を全てユーザに提示し、設定値の選択をユーザに促す。

また、日々公開されるセキュリティホール情報やセキュリティパッチ情報に追従しネットワークシステムの運用を行うためのセキュリティ運用システムが提案されている（例えば、非特許文献１。）。非特許文献１に記載されたシステムは、新たなセキュリティホールの情報（セキュリティホールへの対処策情報も含む）が投入されると、管理対象の各ホストの機器設定情報（例えば、ＯＳの種別、バージョン情報、ＯＳや各種アプリケーションサーバの設定ファイル等）に基づいて、新たなセキュリティホールに影響を受けるサーバホストを判定する。そして、そのサーバホストに対し、セキュリティホールの対処策情報を送信する。なお、非特許文献２にも、同様のシステムが紹介されている。

特開２００２−９４５０９号公報（段落００４６−００９６、図１−７）

特開２００２−２４７０３３号公報（段落００６２−００６９、図２７−図３１）

佐藤亮介、種茂文之、「セキュアＮＷ動的再構築システムの検討」、社団法人情報処理学会、情報処理学会研究報告Ｖｏｌ．２００２，Ｎｏ．１２、２００２年２月１４日・１５日、ｐ．１６９−１７４

種茂文之、他３名、「脆弱性情報に基づき診断と対処を行うセキュリティ運用システム」、「ＮＴＴ Ｒ＆Ｄ」Ｖｏｌ．５１，Ｎｏ．９、２００２年、ｐ．７３７−７４７

セキュリティポリシーに含まれる各ルールは、必ずしも、管理対象システムに含まれるハードウェアやソフトウェアの名称を指定して、そのソフトウェア等に対してある設定を行わなければならないという詳細な設定内容を示すものではない。そのため、セキュリティポリシーに含まれる各ルールと、各ルールが適用されるハードウェアやソフトウェアとを対応付けて把握することは困難である。その結果、システム管理者が、管理対象システムに対して過不足のあるセキュリティポリシーを策定してしまうことがある。例えば、管理対象システムに含まれる各ハードウェアや各ソフトウェアとは無関係なルールをセキュリティポリシーに含めてしまう場合がある。また、各ハードウェアや各ソフトウェアに適用すべきルールを策定し忘れてしまう場合もある。また、同一のハードウェアやソフトウェアに関して互いに矛盾するルールをセキュリティポリシーに含めてしまう場合がある。

特に、ハードウェアやソフトウェアに適用すべきルールを策定し忘れてしまうと、そのハードウェアやソフトウェアはセキュリティーホールになるおそれがある。すなわち、あるハードウェアやソフトウェアは、所定の設定にすればセキュリティに関する機能を発揮できるにも関わらず、そのような設定を導くルールがシステム管理者によって策定されないと、デフォルト設定で運用されてしまう。その結果、そのソフトウェア等は、セキュリティに関する機能を発揮できず、セキュリティホールになってしまう。このように、システム管理者は本来ハードウェアやソフトウェアの機能を発揮させることを意図しているにも関わらず、ルールを策定し忘れてしまい、結果的にセキュリティホールが発生してしまう場合がある。

特許文献１に記載の発明は、診断ポリシーおよび監視ポリシーを作成して、セキュリティ診断やセキュリティ監視を実行することによって、システム管理者を支援する。しかし、セキュリティポリシーに含まれる各ルールと、ルールが適用されるハードウェアまたはソフトウェアとの対応関係を示すものではない。

また、特許文献２に記載の発明は、システム管理者が選択した構成機器に対して適用可能なポリシー（ルール）の集合を表示して、システム管理者にポリシーの選択を促す。しかし、管理対象システムに対して過不足のないセキュリティポリシーを策定するという点で改善の余地がある。すなわち、一つの設定項目に対して複数の設定値が導かれた場合、各設定値を表示して、システム管理者に設定値の選択を促しているが、設定の抜け落ちが生じる可能性がある。また、特許文献２に記載の発明は、管理対象システムのトポロジーを考慮していない。

また、既に説明したように、セキュリティポリシーに含まれる各ルールは、必ずしも、個々のハードウェアやソフトウェアの詳細な設定内容を示すものではない。従って、従来、システム管理者は、セキュリティポリシーに基づいて各設定項目の内容を判断して、個別に設定を行わなければならなかった。さらに、ハードウェアやソフトウェア毎に設定を行うための命令は異なっているので、システム管理者の設定負担は一層大きいものとなっていた。

また、ネットワークシステムの運用中に新たなセキュリティホール情報を得た場合、セキュリティホールを排除するよう対処しなければならない。非特許文献１，２に記載のシステムでは、新たなセキュリティホールの情報において示される情報に合致する機器設定情報を有するホストに、セキュリティホールの対処策が適用させる。この結果、機器設定情報を同一にする各ホストには、一律にセキュリティホールの対処策が適用されてしまう。しかし、機器設定情報を同一にする複数のホスト全てがセキュリティホールになっているとは限らない。複数のホストに一律にセキュリティホール対処策を適用することにより、本来、対処策を適用する必要のなかったホストに新たな問題が生じてしまう可能性がある。

そこで、本発明は、セキュリティポリシーの適用対象となるネットワークシステムのセキュリティ向上に貢献することができ、また、セキュリティの確保に要するシステム管理者の負荷を軽減することができるセキュリティ管理支援システムに適用される情報表示システムおよび情報表示方法を提供することを目的とする。

本発明による情報表示システムは、ネットワークシステムのセキュリティに関する基準である個々のルールと、前記ネットワークシステムが有する各ハードウェアおよび前記各ハードウェアが搭載する各ソフトウェアとを対応付けるセキュリティ管理支援システムに適用される情報表示システムであって、各ルール、各ハードウェアおよび各ソフトウェアを表示する表示欄を有する画面の情報を記憶する画面情報記憶手段と、画面情報記憶手段が記憶する画面の情報を用いて、前記表示欄の中で、ハードウェアおよびソフトウェアを表示し、ハードウェアおよびソフトウェアを表示する領域の外周にルールを表示し、対応付けられたルールとハードウェアまたはソフトウェアとを結ぶ線を表示する出力画面の情報を作成する出力画面情報作成手段と、前記出力画面の情報に基づいて前記出力画面を出力する出力手段とを備えたことを特徴とする。

出力画面情報作成手段は、一のルールの下位階層のルールとして定められたルールを、前記一のルールの隣に並べるように表示する出力画面の情報を作成することが好ましい。そのような構成によれば、どのルールがどのルールの下位階層であるのかを把握しやすくすることができる。

出力画面情報作成手段は、ソフトウェアと前記ソフトウェアを搭載するハードウェアとを結ぶ線を表示する出力画面の情報を作成することが好ましい。そのような構成によれば、ソフトウェアがどのハードウェアにインストールされているのかを把握しやすくすることができる。

また、本発明による情報表示方法は、ネットワークシステムのセキュリティに関する基準である個々のルールと、前記ネットワークシステムが有する各ハードウェアおよび前記各ハードウェアが搭載する各ソフトウェアとを対応付けるセキュリティ管理支援システムに適用される情報表示方法であって、画面情報記憶手段が、各ルール、各ハードウェアおよび各ソフトウェアを表示する表示欄を有する画面の情報を記憶し、出力画面情報作成手段が、画面情報記憶手段が記憶する画面の情報を用いて、前記表示欄の中で、ハードウェアおよびソフトウェアを表示し、ハードウェアおよびソフトウェアを表示する領域の外周にルールを表示し、対応付けられたルールとハードウェアまたはソフトウェアとを結ぶ線を表示する出力画面の情報を作成し、出力手段が、前記出力画面の情報に基づいて前記出力画面を出力することを特徴とする。

本発明によれば、各ルール、各ハードウェアおよび各ソフトウェアを表示する表示欄を有する画面の情報を記憶する画面情報記憶手段と、画面情報記憶手段が記憶する画面の情報を用いて、前記表示欄の中で、ハードウェアおよびソフトウェアを表示し、ハードウェアおよびソフトウェアを表示する領域の外周にルールを表示し、対応付けられたルールとハードウェアまたはソフトウェアとを結ぶ線を表示する出力画面の情報を作成する出力画面情報作成手段と、前記出力画面の情報に基づいて前記出力画面を出力する出力手段とを備えているので、ルールとハードウェアまたはソフトウェアとの対応関係をシステム管理者に明確に提示することができる。また、「ハードウェアやソフトウェアのセキュリティがルールに守られている」というイメージをシステム管理者に喚起させることができる。

以下、本発明の実施の形態を図面を参照して説明する。
なお、セキュリティポリシーには、サーバルームへの入退室管理基準や記録媒体の取り扱い基準などの人間の行動指針を定めたルールも含まれる。しかし、本発明は、セキュリティポリシーに含まれるルールのうち、管理対象システムに対するセキュリティ設定の指針となるルールを対象とする。

また、以下の説明において、各ハードウェアや各ソフトウェアが実現することができるセキュリティに関する機能をセキュリティ機能と記す。

実施の形態１．
図１は、本発明の第１の実施の形態の例を示すブロック図である。本実施の形態において、セキュリティ管理支援システムは、入力装置１０と、機能マッピング処理手段２０と、ノード知識データベース２１と、出力装置３０とを備える。

入力装置１０は、例えば、キーボードやマウス等の入力デバイスである。入力装置１０は、セキュリティポリシー１と、そのセキュリティポリシー１が適用されるネットワークシステムのトポロジー情報２を入力する。トポロジー情報２は、管理対象のネットワークシステムが有する各ハードウェアとその各ハードウェアが搭載する各ソフトウェアとを示す情報であり、ソフトウェアとそのソフトウェアをインストールしているハードウェアとの対応関係を示している。また、本例において、トポロジー情報は、ネットワークシステムが利用する通信ネットワークの各区分（後述するセグメント）も示し、さらに、その区分と、その区分に属するハードウェアとの対応関係も示している。

ノード知識データベース２１は、ノード知識２２を格納するデータベースである。ノード知識とは、ネットワークシステムにおいてノードとなる各ハードウェアやソフトウェアがどのようなセキュリティ機能を有するかを示す情報である。ノード知識２２は、予めノード知識データベース２１に登録される。なお、本発明において、ノードとは、ネットワークシステムを構成するハードウェアと個々のハードウェアにインストールされるソフトウェアの双方を指す。

機能マッピング処理手段２０は、入力されたセキュリティポリシー１に含まれる各ルールと、トポロジー情報２に記述されるノードとを、セキュリティ機能を介して対応付ける処理を実行する。以下、ルールとセキュリティ機能とノードとの対応関係を示す情報の集合を機能マップと記す。

機能マッピング処理手段２０は、例えば、プログラム（セキュリティ管理支援プログラム）に従って動作するＣＰＵによって実現される。この場合、セキュリティ管理支援システムは、プログラムを記憶する記憶装置（図示せず。）を備える。以下、機能マッピング処理手段２０はＣＰＵによって実現されているものとする。

出力装置３０は、ディスプレイ装置等の情報出力デバイスであり、機能マッピング処理手段２０によって対応付けられたルールとノードの対応関係を出力する。ここでは、ディスプレイ装置を例示したが、プリンタ装置等の他の情報出力デバイスを出力装置３０として用いてもよい。

次に、セキュリティクラスについて説明する。セキュリティクラスとは、ルール、ノード知識およびトポロジー情報を表現するための各項目を表すクラスである。セキュリティクラスには、例えば、ハードウェアの種類を表すクラス、ソフトウェアの種類を表すクラス、セキュリティ機能を表すクラス等がある。セキュリティクラスは、コンピュータが認識できるようにルール、ノード知識およびトポロジー情報を表現する役割を果たす。

図２は、セキュリティクラスによる表現の説明図である。セキュリティクラスによって表現される概念は木構造をなし、木構造のルートは最上位の概念を表す。そして、ルートから離れるにつれ、順次詳細な下位の概念を示すようになる。例えば、図２では、「Ｘ」という概念の下位概念として、「Ａ」，「Ｂ」および「Ｃ」という概念があることを示している。さらに、「Ａ」の下位概念として「ａ１」および「ａ２」があることを示している。セキュリティクラスにおいて、ある概念を示す場合、ルートからその概念までの経路を順に記述する。親子関係にある各概念を結んでいる各アークは、例えば、「．（ドット）」で記述する。例えば、図２に例示する「ｂ２」を表す場合、「Ｘ．Ｂ．ｂ２」と記述される。

図３は、セキュリティクラスに含まれる各クラスの例を示す説明図である。図３に示す「network-type-class」は、セグメント（セグメントについては後述する。）を表すクラスである。例えば、ＤＭＺ（DeMilitarized Zone; 非武装地帯）は、「network-type-class」によって、「network.segment.dmz 」と記述される。また、インターネットとＤＭＺとの境界は、「network.segment-boundary.int-dmz」と記述される。

「hardware-type-class 」は、ハードウェアの種類を表すクラスである。例えば、汎用サーバは、「hardware-type-class 」によって、「hardware.generic.server 」と記述される。また、専用機器であるルータは、「hardware.specific.router」と記述される。「software-type-class 」は、ソフトウェアの種類を表すクラスである。例えば、パケットフィルタリングソフトウェア「ｉｐｃｈａｉｎｓ（商標）」は、「software-type-class 」によって、「software.filtering.packet.ipchains」と記述される。また、ＯＳであるリナックス（商標）のうち、ｒｅｄｈａｔ（商標）は、「software.os.linux.redhat」と記述される。なお、図３では、ルート「software」の子要素である「os」の図示を省略している。

「function-class」は、セキュリティ機能を表すクラスである。例えば、ルーティング機能は、「function-class」によって、「function.router 」と記述される。また、パケットフィルタリング機能は、「function.filtering.packet 」と記述される。また、改ざん防止サービス機能は、「function.service.integrity」と記述される。「account-class 」は、ハードウェアやソフトウェアにおいて使用するユーザアカウントを表すクラスである。例えば、ｒｏｏｔアカウントは、「account-class 」によって、「account.generic.root」と記述される。また、ａｐａｃｈｅアカウントは、「account.specific.apache 」と記述される。なお、図３では、ルート「account 」の子要素である「specific」の図示を省略している。

「file-class」は、ファイルアクセス権の付与状態を表すクラスである。例えば、「ファイル読み込み許可」は、「file-class」によって、「file.acl.readonly 」と記述される。また、「所有者権限での実行許可」は、「file.authorization.setid」と記述される。なお、図３では、ルート「file」の子要素である「authorization 」の図示を省略している。「packet-class」は、パケットの転送やパケットの種類を表すクラスである。例えば、「パケット転送」は、「packet-class」によって、「packet-forward」と記述される。また、ｈｔｔｐパケットは、「packet.tcp.http 」と記述される。「information-class 」は、ハードウェアやソフトウェアからの応答情報を表すクラスである。例えば、システム応答情報は、「information.fingerprinting」と記述される。

セキュリティクラスによる表現は、原則として、具体的に特定されるハードウェアやソフトウェアに依存しない。例えば、ハードウェアやソフトウェアの具体的な製品名やバージョンに依存しない。ただし、具体的なソフトウェアを指し示す場合には、そのソフトウェアに依存した記述になってもよい。また、図３に示した「hardware-type-class 」は、具体的な製品名やバージョンまでを記述するものではないが、「hardware-type-class 」は、製品名やバージョンまで表現できるような木構造であってもよい。具体的なハードウェアやソフトウェアを指し示す記述以外は、ハードウェアやソフトウェアに依存しない記述になる。

図４は、セキュリティ管理支援システムの処理経過の例を示す流れ図である。入力装置１０は、セキュリティポリシー１と、そのセキュリティポリシー１が適用されるネットワークシステムのトポロジー情報２をユーザの操作により入力し、入力された情報を機能マッピング処理手段２０に出力する（ステップＡ１００）。次に、機能マッピング処理手段２０は、ノード知識２２を用いて、セキュリティポリシー１に含まれる各ルールと、トポロジー情報２に記述される各ノードとを対応付けして、機能マップを生成する（ステップＡ２００）。

次に、ステップＡ１００で入力されるセキュリティポリシー１について説明する。セキュリティポリシー１は、例えば、ＧＵＩを介して入力される。そして、ＧＵＩを介して入力されたセキュリティポリシー１は、コンピュータが認識できる書式に変換される。以下、コンピュータが認識できる書式でセキュリティポリシーを記述した情報をポリシー記述と記す。また、ポリシー記述中において個々のルールを示した部分をpolicy要素と記す。一つのpolicy要素は一つのルールに対応し、policy要素は、対応するルールをコンピュータが認識できる書式で示す。図５は、ポリシー記述の例を示す説明図であり、ＸＭＬ(eXtensible Markup Language)と同様の形式でセキュリティポリシーを記述した場合の例を示している。

図５に例示するポリシー記述において、policiesタグに囲まれた範囲７１が、セキュリティポリシー全体を記述している範囲である。また、一組のpolicyタグに囲まれた各範囲７２は、個々のpolicy要素を示している。

ルールは、その意味的なレベルにより階層構造をとってもよい。図５に示すlevel 属性７３は、ルールのレベルを示し、図５では、ルールのレベルを２段階に分けた場合の例を示している。第１レベル（level="1" で表される）のルールは、例えば、「あるノードではあるセキュリティの機能を実現する／しない」というセキュリティ対策の有無を示す。第２レベル（level="2" で表される）のルールは、例えば、「第１レベルで実現すると宣言したセキュリティ機能はこのように設定する」という具体的なセキュリティ施策を規定する。

各policy要素のname属性７４には、個々のルールを一意に決める名前が記述される。policy要素は、comment 要素（個々のルールの説明を自然言語で記述したコメント）７５を含む。comment 要素７５は、comment タグとともに記述される。policy要素は、policy要素に対応するルールが対象とするノードのセキュリティ機能を示すsubject 要素７６を含む。subject 要素７６は、セキュリティクラスを用いて記述される。

なお、subject 要素７６には、ワイルドカード（例えば「* 」）が含まれていてもよい。図５に例示する「packet.forward.*.httpd」において、「* 」はワイルドカードであり、セキュリティクラスにおいて「forward 」を親とし、「httpd 」を子とする情報であれば任意の情報が当てはまることを意味する。

また、policy要素は、subject 要素７６が示すセキュリティ機能を実現するか否かを示すaction要素７７を含む。action要素７７は、actionタグとともに記述される。第１レベルのpolicy要素に含まれるaction要素７７で指定される内容としては、add,delete,change,keep等がある。「add 」は第１レベルのsubject 要素７６が示すセキュリティ機能を発揮させることを意味する。「delete」はそのセキュリティ機能を発揮させないことを意味する。「change」は、セキュリティポリシーを変更して、変更後のセキュリティポリシーに則った設定をネットワークシステムに反映させる際に、セキュリティ機能の発揮状態を従来の状態から変更することを意味する。すなわち、従来セキュリティ機能を発揮する状態だった場合、その機能を発揮しない状態に変更し、従来セキュリティ機能を発揮しない状態だった場合、その機能を発揮する状態に変更することを意味する。「keep」は、変更後のセキュリティポリシーに則った設定をネットワークシステムに反映させる際に、セキュリティ機能の発揮状態を従来の状態のままにすることを意味する。なお、セキュリティ機能を「発揮する」とは、セキュリティ機能を「あらわしだす」ことである。言い換えると、セキュリティ機能を「実現する」ことである。

また、第２レベルのpolicy要素に含まれるaction要素７７で指定される内容としては、authorize,disauthorize等がある。「authorize 」は、第２レベルのsubject 要素７６が示すセキュリティ機能を発揮させることを意味する。「disauthorize」は、そのセキュリティ機能を発揮させないことを意味する。

また、第１レベルのpolicy要素は、セグメントを指定するsegment 要素７８を含む。本実施の形態では、管理対象のネットワークシステムが利用する通信ネットワークを区分けし、区分けされた通信ネットワーク毎にルールとノードとを対応付ける場合を例に説明する。セグメントとは、区分けされた各通信ネットワークのことである。

図６は、セグメントの例を示す説明図である。管理対象のネットワークシステムが利用する通信ネットワークは、例えば、インターネット９１、ＤＭＺ（DeMilitarized Zone; 非武装地帯）９２、イントラネット９３、ＷＡＮ９４などのように、ネットワークの利用形態によって区分される。また、インターネット−ＤＭＺ境界９５、ＤＭＺ−イントラネット境界９６、ＷＡＮ−イントラネット境界９７、インターネット−イントラネット境界９８のように、分類された通信ネットワークの境界部分もセグメントとして分類することができる。このように、通信ネットワークをセグメントに区分けし、セグメント毎にルールとノードと対応付ける場合、ルールとノードとの対応付けを行いやすくなる。

segment 要素７８は、セキュリティクラスを用いて記述される。例えば、ＤＭＺを指定する場合には「network.segment.dmz 」と記述され、インターネットとＤＭＺとの境界を指定する場合には「network.segment-boundary.int-dmz」と記述される（図３に示す「network-type-class」を参照。）。

segment 要素７８は、第１レベルのpolicy要素においてのみ記述される。第２レベルのpolicy要素には、そのpolicy要素の親にあたる第１レベルで記述されたsegment 要素が適用される。なお、segment 要素７８は、segmentタグとともに記述される。

また、policy要素は、親にあたるpolicy要素が存在する場合、parent要素７９を含む。parent要素７９は、親にあたるpolicy要素を特定する情報である。parent要素７９は、例えばname属性を指定することによって、親にあたるpolicy要素を特定する。parent要素７９は、parentタグとともに記述される。

図５に示すpriority要素８０は、各ルールの優先度の高低を示す。図５に示す例では、policy要素（A004-2-2）が、「A004-2-1」を特定するpriority要素８０を含んでいる。このことは、「A004-2-2」のルールの優先度が、「A004-2-1」よりも高いことを表している。ここで、各ルール間の優先度の高低について説明する。複数のルールを組み合わせ、そのルールの適用順に優先度を定めることで、セキュリティに関するある基準を定めることができる。ある事象に、優先順位の高いルールが適用された場合には、より優先順位の低いルールは無視される。ある事象に、優先順位の高いルールが適用されない場合には、より優先順位の低いルールが適用される。例えば、パケットフィルタリング機能に関するルールとして「全てのパケットの通過を禁止する」というルール（図５における「A004-2-1」）と、「ｈｔｔｐパケットを通過させる」というルール（図５における「A004-2-2」）とがあるとする。また、後者の方が優先順位が高いとする。「ｈｔｔｐパケットが到着した」という事象が生じた場合、後者のルールが適用され、前者のルールは無視される。一方、「ｈｔｔｐ以外のパケットが到着した」という事象が生じた場合、このパケットは後者のルール（A004-2-2）の対象ではないので、後者のルールは適用されず、前者のルール（A004-2-1）が適用される。この結果、「ｈｔｔｐ以外のパケットの通過を禁止する」という基準を実現することができる。

セキュリティーポリシー１には、ソフトウェアやハードウェアの製品名やバージョン情報等を特定して、そのソフトウェア等における設定を直接指定するようなルールは含まれない。従って、図５に例示するようなポリシー記述にも、具体定期なソフトウェアやハードウェアに依存する記述は含まれない。

なお、図５は、ポリシー記述の一例を示すものであり、ポリシー記述の記述フォーマットは図５に示すものに限定されない。ポリシー記述は、コンピュータが認識できるようにセキュリティポリシーを記述したものであればよい。例えば、図５では、各要素をタグとともに記述した場合を示しているが、コンピュータが各要素を認識できるのであればタグを用いない記述であってもよい。

次に、ステップＡ１００で入力されるトポロジー情報２について説明する。トポロジー情報２は、例えば、ＧＵＩを介して入力される。そして、ＧＵＩを介して入力されたトポロジー情報２は、コンピュータが認識できる書式に変換される。以下、コンピュータが認識できる書式でトポロジー情報を記述した情報をトポロジー記述と記す。図７は、トポロジー記述の記述フォーマットの例を示す説明図であり、ＸＭＬと同様の形式でトポロジー情報を記述する場合の例を示している。

図７に例示するトポロジー記述において、policiesタグに囲まれた範囲１０１が、トポロジー情報全体を記述している範囲である。また、一組のpolicyタグに囲まれた各範囲７２は、個々のpolicy要素を示している。トポロジー情報は、ネットワーク、ハードウェア、ソフトウェアに分けて記述される。図７において、network タグに囲まれた範囲１０３は、ネットワークに関して記述している範囲である。また、hardwareタグに囲まれた範囲１０４は、ハードウェアに関して記述している範囲である。softwareタグに囲まれた範囲１０５は、ソフトウェアに関して記述している範囲である。

ネットワークに関する記述には、segment 要素１０５が含まれる。segment 要素１０５は、管理対象のネットワークシステムが利用する各セグメントを表す情報である。管理対象のネットワークシステムが複数のセグメントを利用しているのであれば、segment 要素は複数個記述される。

segment 要素１０５のname属性１０６には、個々のセグメントを一意に決める名前が記述される。この名前は、システム管理者によって指定される。segment 要素１０５のtype属性１０７には、セキュリティクラスの「network-type-class」を用いて、セグメントの種類が記述される。例えば、ＤＭＺを表す場合にはtype属性１０７に「network.segment.dmz 」が記述され、イントラネットを表す場合には「network.segment.intra」が記述される。また、インターネットとＤＭＺ境界を表す場合には、「network.segment-boundary.int-dmz」が記述される。segment 要素１０５の子要素であるaddress 要素１０８は、そのセグメントのＩＰアドレス（ネットワークアドレス）を示す。１つのsegment 要素に対して複数のaddress 要素を指定してもよい。ＩＰアドレスの表記方法は例えばxxx.xxx.xxx.xxx/yy（ただし、「すべて」を表す0/0, any/0も可）とする。

ハードウェアに関する記述には、node要素１０９が含まれる。node要素１０９は、管理対象のネットワークシステムに含まれる各ハードウェアを表す情報である。node要素１０９は、各ハードウェア毎に記述される。

node要素１０９のname属性１１０には、個々のハードウェアを一意に決める名前が記述される。この名前は、システム管理者によって指定される。node要素１０９のtype属性１１１には、セキュリティクラスの「hardware-type-class 」を用いて、ハードウェアの種類が記述される。例えば、汎用サーバを表す場合にはtype属性１１０に「hardware.generic.server 」が記述される。また、ルータやファイアウォールを表す場合には、それぞれ「hardware.specific.router」、「hardware.specific.firewall」が記述される。

canonical 要素１１２はハードウェアの製品名などを示す。version 要素１１３はハードウェアのモデル名、バージョン名など、より詳しい名称を示す。これら２つの要素の組み合わせにより、ハードウェアの製品名レベルでの種別を一意に特定する。OS要素１１４は、セキュリティクラスの「hardware-type-class 」を用いて、そのハードウェア上で動作しているＯＳを示す。

nic 要素１１５は、ハードウェアが有するネットワークインタフェース機器（例えば、ＬＡＮカードやＬＡＮボード等）に割り当てられるＩＰアドレスを示す。このアドレスは、例えば、xxx.xxx.xxx.xxxという形式で記述される。nic 要素１１５のname属性１１６は、当該ハードウェア毎に個々のネットワークインタフェース機器を一意に定める名前が記述される。この名前は、システム管理者によって指定される。nic 要素１１５のin属性１１７には、ネットワークインタフェース機器が接続されるセグメントが記述される。in属性１１７は、例えばセグメントのname属性１０６を指定することによってセグメントを特定する。一つのnode要素１０９は、複数のnic 要素１１５を含んでいてもよい。

ソフトウェアに関する記述には、node要素１１８が含まれる。node要素１１８は、ハードウェアにインストールされている各ソフトウェアを表す情報である。node要素１１８は、各ソフトウェア毎に記述される。

node要素１１８のname属性１１９には、個々のソフトウェアを一意に決める名前が記述される。この名前は、システム管理者によって指定される。node要素１１８のtype属性１２０には、セキュリティクラスの「software-type-class 」を用いて、ソフトウェアの種類が記述される。例えば、パケットフィルタリングソフトウェア「ｉｐｃｈａｉｎｓ（商標）」を表す場合には、type属性１２０に「software.filtering.packet.ipchains」が記述される。node要素１１８のon属性１２１には、そのソフトウェアが動作しているハードウェアが記述される。on属性１２１は、例えばハードウェアのname属性１１０を指定することによってハードウェアを特定する。canonical 要素１２２はソフトウェアのアプリケーション名などを示す。version 要素１２３はソフトウェアのバージョン名を示す。これら２つの要素の組み合わせにより、ソフトウェアの製品名レベルでの種別を一意に特定する。

図７に例示した記述フォーマットに従って記述したトポロジー記述の具体例を図８に示す。図７に例示するトポロジー記述によって、セグメントとハードウェアとの対応関係、およびハードウェアとソフトウェアの対応関係を示すトポロジー情報を表現することができる。

トポロジー情報２には、ソフトウェアやハードウェア等を具体的に特定する情報（例えば、製品名やバージョン情報）が含まれる。従って、トポロジー記述にも、個々のソフトウェアやハードウェアに依存する記述が含まれる。

なお、図７は、トポロジー記述の記述フォーマットの一例を示すものであり、トポロジー記述の記述フォーマットは図７に示すものに限定されない。トポロジー記述は、コンピュータが認識できるようにトポロジー情報を記述したものであればよい。

次に、ステップＡ１００におけるセキュリティポリシー１およびトポロジー情報２の入力態様の例を説明する。図９は、ユーザにセキュリティポリシー１の入力を促すためのＧＵＩの例を示す説明図である。セキュリティ管理支援システムは、ステップＡ１００において、ＧＵＩを出力装置３０に表示させる。なお、ＧＵＩの表示制御は、例えば、機能マッピング処理手段２０と共通のＣＰＵが行えばよい。また、ＧＵＩのデータは、記憶装置（図１において図示せず。）に予め記憶しておけばよい。ＧＵＩは、例えば、セグメントを指定するセグメント指定欄１３１と、ルールを指定するルール入力欄１３２を有する。

システム管理者は、セグメント指定欄１３１においてセグメントを指定し、指定したセグメントにおいて採用するルールをルール入力欄１３２に入力する。そして、システム管理者は、セグメント毎にルールを入力していくことにより、セキュリティポリシー全体を入力する。ＣＰＵは、ＯＫボタン１３３をマウスクリックされると、指定されたセグメントにおけるルールの入力を確定する。また、ＣＰＵは、キャンセルボタン１３４をマウスクリックされると、指定されたセグメントにおけるルールの入力を無効とする。

ＣＰＵは、入力装置１０を介して各セグメント毎にルールを入力することによって、セキュリティポリシー１全体の入力を完了する。ＣＰＵは、入力内容に応じてポリシー記述を生成し、そのポリシー記述をファイルとして記憶装置（図示せず。）に記憶させる。なお、ＧＵＩを用いずに直接ポリシー記述を入力してもよい。すなわち、セキュリティ管理支援システムは、エディタ等を介して、ポリシー記述となるテキスト情報を直接入力してもよい。あるいは、セキュリティ管理支援システムは、別のフォーマットで記述されたセキュリティポリシーを入力し、そのセキュリティポリシーをポリシー記述に変換して、記憶装置に記憶させてもよい。

図１０は、ユーザにトポロジー情報２の入力を促すためのＧＵＩの例を示す説明図である。セキュリティ管理支援システムのＣＰＵは、ステップＡ１００において、図１０に例示するＧＵＩも出力装置３０に表示させる。このＧＵＩのデータは、記憶装置（図示せず。）に予め記憶しておけばよい。ＧＵＩは、例えば、ネットワーク情報入力欄１４１と、ハードウェア情報入力欄１４２と、ソフトウェア情報入力欄１４３とを有する。

ネットワーク情報入力欄１４１は、セグメントの名前（name属性１０６の値）、セグメントの種類（type属性１０７の値）およびＩＰアドレス（address 要素１０８）の入力欄を有する。

ハードウェア情報入力欄１４２は、ノードの名前（name属性１１０の値）、ノードの種類（type属性１１１の値）、登録名（canonical 要素１１２）、バージョン（version 要素１１３）およびＯＳ（os要素１１４）の入力欄を有する。また、ネットワークインタフェース機器の名前（name属性１１６の値）、接続セグメント名（in属性１１７の値）およびＩＰアドレス（nic 要素１１５）の入力欄も有する。

ソフトウェア情報入力欄１４３は、ノードの名前（name属性１１９の値）、ノードの種類（type属性１２０の値）、動作ホスト名（on属性１２１の値）、登録名（canonical 要素１２２）およびバージョン（version 要素１２３）の入力欄を有する。

システム管理者は、各入力欄１４１〜１４３に所望の情報を入力する。ＣＰＵは、ＯＫボタン１４４をマウスクリックされると入力を確定し、キャンセルボタン１４５をマウスクリックされると、ＧＵＩ上に記述された内容を無効とする。

ＣＰＵは、入力装置１０を介してトポロジー情報２を入力する。ＣＰＵは、入力内容に応じてトポロジー記述を生成し、そのトポロジー記述をファイルとして記憶装置（図示せず。）に記憶させる。なお、ＧＵＩを用いずに直接トポロジー記述を入力してもよい。すなわち、セキュリティ管理支援システムは、エディタ等を介して、トポロジー記述となるテキスト情報を直接入力してもよい。あるいは、既存のトポロジー情報抽出システムを用いて抽出されたトポロジー情報を入力し、そのトポロジー情報をトポロジー記述に変換して、記憶装置に記憶させてもよい。トポロジー情報を抽出できる既存のシステムとして、例えば、ＳＮＭＰ（Simple Network Management Protocol）やＴＣＰ／ＩＰに従って、各ハードウェアのＩＰアドレス等を収集するネットワーク管理システムがある。

次に、ルールとノードとの対応付け処理（図４に示すステップＡ２００）について説明する。この対応付け処理（以下、機能マッピング処理と記す。）では、セキュリティティポリシー１に含まれる個々のルールと、そのルールに応じたセキュリティの設定を実現できるノードとと対応付ける。セキュリティポリシー１には、ソフトウェアやハードウェアに依存する情報が含まれていないので、ルールとノードとの対応付けはセキュリティ機能を用いて行う。機能マッピング処理の概要を図１１に示す。

図１１に示すように、セキュリティポリシー全体の中に、あるセグメントＳにおけるルールＰａ，Ｐｂが存在し、そのルールＰａ，Ｐｂは、それぞれセキュリティ機能Ｆｘ，Ｆｙによって実現されるとする。同様に、また、トポロジー情報では、セグメントＳ内にノードＮ１，Ｎ２が含まれていることを規定しているとする。また、ノード知識データベース２１内のノード知識２２において、ノードＮ１，Ｎ２は、それぞれセキュリティ機能Ｆｘ，Ｆｚを有することが記述されているとする。このとき、ルールＰａと、ノードＮ１とは、セキュリティ機能Ｆｘを介して対応付けられる。そして、対応付けられたルールＰａ、セキュリティ機能ＦｘおよびノードＮ１の組み合わせは、「ルールＰａは、ノードＮ１が有するセキュリティ機能Ｆｘによって実現される。」ということを意味する。

具体的には、機能マッピング処理手段２０は、機能マッピング処理を、ポリシー記述と、トポロジー記述と、ノード知識２２とを用いて実行する。以下、ノード知識データベース２１が予め記憶しているノード知識２２の記述例を説明した上で、機能マッピング処理の処理経過を説明する。

図１２は、ノード知識２２の記述フォーマットの例を示す説明図である。図１２に示す例において、node_knowledgeタグに囲まれた範囲がノード知識２２全体を記述している範囲である。ノード知識２２は、hardware要素１５２と、software要素１５３とを含む。hardware要素１５２は、ノードとなるハードウェアを具体的に指定し、そのハードウェアがどのようなセキュリティ機能を有しているのかを示す情報である。software要素１５３は、ノードとなるソフトウェアを具体的に指定し、そのソフトウェアがどのようなセキュリティ機能を有しているのかを示す情報である。ノード知識２２内には、ハードウェアやソフトウェアの種類に応じて、複数のhardware要素１５２およびsoftware要素１５３が含まれる。

hardware要素１５２のname属性１５４には、ハードウェアの製品名などが記述される。以下、hardware要素１５２のname属性１５４に記述される値を「hardware-canonical-name 」と記す。hardware要素１５２のversion 属性１５５には、ハードウェアのモデル名、バージョン名など、より詳しい名称が記述される。以下、hardware要素１５２のversion 属性１５５に記述される値を「hardware-canonical-version-name 」と記す。hardware要素１５２のname属性１５４およびversion 属性１５５の組み合わせにより、ハードウェアの製品名レベルでの種別が一意に特定される。図７に例示するトポロジー記述において、ハードウェアを特定するcanonical 要素１１２およびversion 要素１１３は、予めノード知識２２内に含まれているhardware-canonical-name、hardware-canonical-version-nameの中から指定される。

hardware要素１５２の子要素であるfunction要素１５６は、そのハードウェアが有するセキュリティ機能を示す。function要素１５６は、セキュリティクラスの「function-class」を用いて記述される。例えば、ハードウェアがパケットフィルタリング機能を有する場合、「function.filtering.packet 」が記述される。また、ルーティング機能を有する場合、「function.router」が記述される。

software要素１５３のname属性１５７には、ソフトウェアのアプリケーション名などが記述される。以下、software要素１５３のname属性１５７に記述される値を「software-canonical-name 」と記す。software要素１５３のversion 属性１５８には、バージョン名が記述される。以下、software要素１５３のversion 属性１５８に記述される値を「software-canonical-version-name 」と記す。software要素１５３のname属性１５７およびversion 属性１５８の組み合わせにより、ソフトウェアの製品名レベルでの種別が一意に特定される。図７に例示するトポロジー記述において、ソフトウェアを特定するcanonical 要素１２２およびversion 要素１２３は、予めノード知識２２内に含まれているsoftware-canonical-name、software-canonical-version-nameの中から指定される。

software要素１５３の子要素であるfunction要素１５９は、そのソフトウェアが有するセキュリティ機能を示す。function要素１５９は、セキュリティクラスの「function-class」を用いて記述される。

hardware要素１５２およびsoftware要素１５３に含まれるfunction要素は一つだけとは限らない。

また、hardware要素１５２、software要素１５３共に、他のhardware要素１５２やsoftware要素１５３のセキュリティ機能を継承してもよい。図１２に示すinherit 要素１６０は、セキュリティ機能を継承する相手のハードウェアまたはソフトウェアを指定する情報である。図１２に示す例において、inherit 要素１６０は、hardware-canonical-name およびhardware-canonical-version-name の組み合わせ、またはsoftware-canonical-name およびsoftware-canonical-version-name の組み合わせを指定して、継承する相手のノードを特定する。図１３は、セキュリティ機能の継承の具体例を示す説明図である。図１３に示すsoftware要素１５３ｂは、inherit 要素においてsoftware要素１５３ａを指定している。従って、software要素１５３ｂが示すソフトウェアは、software要素１５３ａから３種類のセキュリティ機能を継承し、さらに、software要素１５３ｂ内で直接記述されている２種類のセキュリティ機能を有する。

なお、図１２は、ノード知識２２の記述フォーマットの一例を示すものであり、ノード知識２２の記述フォーマットは図１２に示すものに限定されない。ノード知識２２は、各ハードウェアや各ソフトウェアがどのようなセキュリティ機能を有するのかを、コンピュータが認識できるように記述したものであればよい。

図１４は、機能マッピング処理（ステップＡ２００）の処理経過の例を示す流れ図である。ポリシー記述、トポロジー記述およびノード知識がそれぞれ図５、図７および図１２に例示したフォーマットで記述されている場合を例に説明する。そして、セグメント毎にルールが策定され、個々のpolicy要素は、いずれかのセグメントに対応付けられているものとする。

機能マッピング処理手段２０は、管理対象のネットワークシステム（以下、管理対象システムと記す。）が利用している各セグメントの情報を抽出する（ステップＡ２０１）。機能マッピング処理手段２０は、トポロジー記述に含まれる各segment 要素１０５（図７参照）を抽出することによって、各セグメントの情報を抽出する。

続いて、機能マッピング処理手段２０は、管理対象システムにおいてノードとなる各ハードウェアが、どのセグメントに属しているのかを同定する（ステップＡ２０２）。具体的には、機能マッピング処理手段２０は、トポロジー記述に含まれるハードウェアのノード（node要素１０９）を抽出し、そのノードにおけるnic 要素１１５のin属性１１７を参照する。そして、機能マッピング処理手段２０は、そのin属性１１７と同一のname属性１０６を有するsegment 要素１０５を特定することによって、ハードウェアが属しているセグメントを特定する。機能マッピング処理手段２０は、トポロジー記述に含まれる全てのハードウェアのノードについてこの処理を行う。

次に、機能マッピング処理手段２０は、管理対象システムが用いている各ソフトウェアがどのホスト（ハードウェア）上で動作しているのかを同定する（ステップＡ２０３）。具体的には、機能マッピング処理手段２０は、トポロジー記述に含まれるソフトウェアのノード（node要素１１８)を抽出し、そのノードのon属性１２１を参照する。そして、機能マッピング処理手段２０は、そのon属性１２１と同一のname属性１１０を有するハードウェアのノードを特定することによって、ソフトウェアがインストールされているハードウェアを特定する。機能マッピング処理手段２０は、トポロジー記述に含まれる全てのソフトウェアのノードについてこの処理を行う。ステップＡ２０３までの処理を完了することによって、各ノードは、セグメント毎に分類される。

次に、機能マッピング処理手段２０は、管理対象システムが利用しているセグメントの中から１つのセグメントを選択する（ステップＡ２０４）。機能マッピング処理手段２０は、トポロジー記述に含まれる各segment 要素１０５の中から一つのsegment 要素１０５を選択すればよい。

そして、機能マッピング処理手段２０は、ノード知識データベース２１を検索し、選択したセグメントに属するノードして分類された全てのノード（ハードウェア、ソフトウェアとも）のノード知識を抽出する（ステップＡ２０５）。以下、ステップＡ２０４で選択したセグメントに属するノードのみに関するノード知識をノード知識ビューと記す。ノード知識ビューは、ノード知識データベース２１が記憶するノード知識２２の部分集合である。

具体的には、機能マッピング処理手段２０は、ステップＡ２０４で選択したセグメント（segment 要素１０５）に属すると判定されたノードのcanonical 要素およびversion 要素を参照する。そして、そのcanonical 要素およびversion 要素と合致するhardware-canonical-name およびhardware-canonical-version-name （または、software-canonical-name およびsoftware-canonical-version-name ）を有するhardware要素１５２またはsoftware要素１５３をノード知識データベース２１から抽出する。機能マッピング処理手段２０は、この抽出処理を、選択したセグメントに属すると判定された全てのノードについて行う。抽出されたhardware要素１５２およびsoftware要素１５３の集合がノード知識ビューである。

また、機能マッピング処理手段２０は、hardware要素１５２またはsoftware要素１５３を抽出する際、その要素にinherit 要素が含まれているならば、そのinherit 要素を継承元のノードに記述されているfunction要素に置換（展開）する。図１５は、inherit 要素の展開例を示す説明図である。あるsoftware要素が、図１５（ａ）に示すように、inherit 要素を含んでいるとする。そして、inherit 要素が示すソフトウェアノード（software要素）が、図１５（ｂ）に示す３種類のfunction要素を含んでいるとする。機能マッピング処理手段２０は、図１５（ａ）に示すsoftware要素をノード知識ビューとして抽出する場合、inherit 要素を図１５（ｂ）に示す３種類のfunction要素に置換する。

ノード知識ビュー作成後、機能マッピング処理手段２０は、セキュリティポリシーに含まれるルールの中から、ステップＡ２０４で選択したセグメントに対応付けられたルールを抽出する。そして、そのルールを実現するためのセキュリティ機能を有するノードをノード知識ビューから検索する（ステップＡ２０６）。

ステップＡ２０６において、機能マッピング処理手段２０は、ポリシー記述内のsegment 要素７８（図５）を参照して、選択したセグメントに対応付けられたルール（policy要素）を抽出すればよい。なお、第１レベル以外のpolicy要素には、segment 要素７８は含まれない。しかし、下位レベルのpolicy要素には、第１レベルのsegment 要素７８が適用される。従って、機能マッピング処理手段２０は、全てのpolicy要素について、どのセグメントに対応しているのかを判定できる。

また、選択したセグメントに対応付けられたルール（policy要素）を実現するためのセキュリティ機能を有するノードを検索するときには、subject 要素７６（図５）を参照して、subject 要素７６の内容を含むfunction要素を有するノード（hardware要素１５２またはsoftware要素１５３）を検索すればよい。このとき、function要素がsubject 要素７６の下位概念であるようなノードも検索する。例えば、あるpolicy要素のsubject 要素７６が「function.filtering.packet 」であるとする。この場合、その下位概念（例えば、「function.filtering.packet.tcp.httpd 」等）をfunction要素とするノードも検索対象となる。

機能マッピング処理手段２０は、選択セグメントにおけるルール（policy要素）と、検索したノード（hardware要素１５２またはsoftware要素１５３）とを対応付ける（ステップＡ２０７）。このとき、機能マッピング処理手段２０は、セキュリティ機能も、ルールおよびノードに対応付ける。このセキュリティ機能は、そのルールを実現するためのセキュリティ機能であり、かつ、そのノードが発揮することができるセキュリティ機能である。なお、ステップＡ２０６において、対応するノードが存在しなかった場合には、その旨の情報を記憶する。ステップＡ２０７に続いて、機能マッピング処理手段２０は、ステップＡ２０４で選択したセグメントに対応する全てのルールに対して、ステップＡ２０６，Ａ２０７の処理を行ったか否かを判定する（ステップＡ２０８）。まだ、ステップＡ２０６，Ａ２０７の処理を行っていないルールがあるならば、ステップＡ２０６以降の処理を繰り返す。

機能マッピング処理手段２０は、選択したセグメントに対応する全てのルールに対してステップＡ２０６，Ａ２０７の処理を行ったならば、ポリシー過多（overpolicy）が生じているか否かを判定する（ステップＡ２０９）。ポリシー過多は、入力されたルールを実現するためのセキュリティ機能を有するノードが存在しない状態のことである。ステップＡ２０６で対応するノードを検索できなかったルールが存在する場合、機能マッピング処理手段２０は、ポリシー過多が生じていると判定する。ポリシー過多が生じていると判定した場合、機能マッピング処理手段２０は、ポリシー過多が生じたことを出力装置３０に出力する（ステップＡ２１０）。

ポリシー過多が生じていないと判定した場合、機能マッピング処理手段２０は、ポリシー衝突（collision ）が生じているか否かを判定する（ステップＡ２１１）。ポリシー衝突は、同一のノードに対して、相反する意味を持つ複数のルールが対応付けられている状態のことである。例えば、あるルール（policy要素）のsubject 要素の内容が「function.filtering.packet.tcp.httpd （ｈｔｔｐｄパケットの通過）」であり、かつ、action 要素の内容が「authorize （許可する）」であるとする。このルールは、「ｈｔｔｐｄパケットの通過を許可する。」という内容を表している。また、他の（policy要素）のsubject 要素の内容が「function.filtering.packet.tcp.httpd 」であり、かつ、action 要素の内容が「disauthorize（許可しない）」であるとする。このルールは、「ｈｔｔｐｄパケットの通過を許可しない。」という内容を表している。このような２つのルールが同一のノードに対応付けられていると、互いに矛盾する２つのルールが存在することになり、ポリシー衝突となる。

セキュリティ管理支援システムは、複数のルールの間にポリシー衝突が生じているか否かを、以下のように判断すればよい。例えば、同一のノードに対応付けられた複数のルールのsubject 要素が同一であり、かつaction 要素が異なっていれば、ポリシー衝突が生じていると判定する。また、ポリシー衝突となる状態を示した情報を予め記憶装置（図示せず。）に保持しておき、ルールとセキュリティ機能とルールとの対応関係を示す情報の集合（機能マップ）が、その情報が示す状態に合致する場合に、ポリシー衝突が生じていると判定してもよい。この場合、ポリシー衝突となる状態を示した情報を格納したデータベースを設け、ステップＡ２１１において、そのデータベースを参照してポリシー衝突の有無を判定してもよい。また、セキュリティポリシーに基づいてポリシー記述を生成する際、ポリシー衝突となる状態を示した情報の記述もポリシー記述に追加しておき、そのポリシー記述を参照してポリシー衝突の有無を判定してもよい。

ポリシー衝突となる状態を示した情報として、例えば、一つのノードに対応付けられた場合にポリシー衝突となる複数のルールの組み合わせを予め記憶しておけばよい。このような情報の例として、「ノードＮ１にルールＲ１，Ｒ２が対応付けられた場合、ポリシー衝突である。」などの情報が挙げられる。なお、ポリシー衝突は、同一ノードに対応付けられた複数のルール間においてのみ生じるとは限らない。ポリシー衝突となる状態を示した情報として、異なるノードに対応付けられるルールの組み合わせを予め保持していてもよい。例えば、「ノードＮ１とルールＲ１とが対応付けられ、かつ、ノードＮ２とルールＲ３とが対応付けられた場合、ポリシー衝突である。」などの情報を予め保持していてもよい。

なお、機能マッピング処理手段２０は、priority要素８０（図５参照）によって優先度の高低を定められた複数のルールに関しては、ポリシー衝突は生じていないと判定する。

ポリシー衝突が生じていると判定した場合、機能マッピング処理手段２０は、ポリシー衝突が生じたことを出力装置３０に出力する（ステップＡ２１２）。

ポリシー衝突が生じていないと判定した場合、機能マッピング処理手段２０は、ポリシー過少（underpolicy ）が生じているか否かを判定する（ステップＡ２１３）。ポリシー過少は、どのルールとも対応付けられなかったノードが存在している状態のことである。すなわち、セキュリティ機能を発揮できるハードウェアまたはソフトウェアが管理対象システムに含まれているにも関わらず、そのセキュリティ機能を発揮させるルールが策定されなかった状態のことである。ステップＡ２０４で選択したセグメントに含まれるノードの中に、どのルールとも対応付けられていないノードが存在する場合、機能マッピング処理手段２０は、ポリシー過少が生じていると判定する。その場合、機能マッピング処理手段２０は、ポリシー過少が生じたことを出力装置３０に出力する（ステップＡ２１４）。

ポリシー過多、ポリシー衝突およびポリシー過少が発生していない場合、選択したセグメントにおいてルールとノードとの対応関係は、整合性を保っていることになる。なお、ポリシー過多の判定処理（ステップＡ２０９）、ポリシー衝突の判定処理（ステップＡ２１１）およびポリシー過少判定処理（ステップＡ２１３）は、任意の順序で行ってよい。

ステップＡ２０４からステップＡ２１３までの処理を完了することによって、１つのセグメントにおいて、ルールとノードとの対応付けができたことになる。ステップＡ２１３において、ポリシー過少が生じていないと判定した場合、機能マッピング処理手段２０は、トポロジー記述に含まれる全てのセグメントを選択したか否かを判定する（ステップＡ２１５）。まだ、選択していないセグメントがあれば、そのセグメントを選択し、ステップＡ２０４以降の処理を実行する。全てのセグメントを選択済みであれば、機能マッピング処理を終了する。

ステップＡ２０７において対応付けられるルールとセキュリティ機能とノードとの対応関係を示す情報の集合が機能マップになる。機能マッピング処理手段２０は、全てのセグメントについてステップＡ２１５までの処理を完了することによって、ルールとノードとの間に過不足のない機能マップを生成する。

図１６は、機能マップの例を示す説明図である。図１６に例示するように、対応する一組のルール、セキュリティ機能およびノードが１つのタプルになる。機能マップは、タプルの集合として表される。図１６に例示した１つのタプルは、「Ａ００４−２−２」という名前を有するルール（「ルータではｈｔｔｐｄパケットの通過を許可する」というルール）と、「 ”ｐｆ１”という名前を持つパケットフィルタリングソフトウェアｉｐｃｈａｉｎｓ（商標）」というノードが、セキュリティ機能「function.filtering.packet.tcp.httpd」 を介して対応付けられていることを示している。

機能マッピング処理手段２０は、機能マップを出力装置３０に出力（表示）する。図１７は、機能マップの出力画面の例を示す説明図である。機能マッピング処理手段２０は、例えば、ステップＡ２０８の後に、図１７に例示する画面を出力装置３０に表示させ、システム管理者にルールとノードとの対応関係を提示する。

図１７に例示する画面において、ルール表示欄１７１は、１つのセグメントにおける各ルールを表示する。ルール表示欄１７１において、第２レベルのルールを、親となる第１レベルのルールの下側、かつ親となるルールよりも画面中央よりに表示することが好ましい。このように表示することによってルールの親子関係を把握しやすくなる。ノード表示欄１７２は、１つのセグメントに属する各ノードを表示する。ノード表示欄１７２において、ソフトウェアのノードを、そのソフトウェアがインストールされているハードウェアノードの下側、かつハードウェアノードよりも画面中央よりに表示することが好ましい。このように表示することによって、ソフトウェアがどのハードウェアにインストールされているのかを把握しやすくなる。対応関係表示欄１７３は、対応するルールとノードとを結ぶ線分を表示する。

ルール説明表示欄１７４は、マウスクリック等によって選択されたルールの説明を表示する。ルールの説明として、例えばcomment 要素７５（図５参照）を表示すればよい。ノード情報表示欄１７５は、マウスクリック等によって選択されたノードの説明を表示する。矛盾検証結果表示部１７６は、ポリシー過多、ポリシー衝突またはポリシー過少を検出したときに、検出した内容を表示する欄である。セグメント選択欄１７７は、システム管理者からセグメントの指定を受けるける欄である。機能マッピング処理手段２０は、指定されたセグメントにおけるルールとノードの対応関係を図１７に例示する画面に表示する。

セキュリティ管理支援システムは、ルール表示欄１７１、ノード表示欄１７２、対応関係表示欄１７３、ルール説明表示欄１７４、ノード説明表示欄１７５、矛盾検証結果表示部１７６およびセグメント選択欄１７７を有する画面の情報を予め記憶装置（図１において図示せず。）に記憶する。この画面情報において、対応関係表示欄１７３は、ルール表示欄１７１とノード表示欄１７２との間に配置されるように定められる。機能マッピング処理手段２０は、その画面情報と機能マップとを用いて、出力画面情報を作成し、出力画面情報に基づいて出力画面を出力装置３０に表示する。このとき、機能マッピング処理手段２０は、以下のように出力画面情報を作成する。機能マッピング処理手段２０は、ルール表示欄１７１に各ルールを表示し、ノード表示欄１７２に各ノードを表示し、対応するルールとノードとを結ぶ線分を対応関係表示欄１７３に表示する出力画面情報を作成する。さらに、機能マッピング処理手段２０は、各ルールと対応関係表示欄１７３との距離が各ルールの階層（レベル）に応じた距離になるように各ルールを表示する出力画面情報を作成する。また、機能マッピング処理手段２０は、ハードウェアかソフトウェアかの種別によって対応関係表示欄１７３との距離が異なるように各ノードを表示する出力画面情報を作成する。

図１８は、ポリシー過多を検出した場合の出力画面の例を示す説明図である。図１８に示す例では、ルール「A004-2」、「A004-2-1」および「A004-2-2」に対応するノードが存在せず、ポリシー過多が生じていることを示している。機能マッピング処理手段２０は、矛盾検証結果表示部１７６にその通知を出力する。この通知に基づいて、システム管理者は、余分なルールの削除、あるいは不足しているノードの追加を検討することができる。

図１９は、ポリシー衝突を検出した場合の出力画面の例を示す説明図である。図１９に示す例では、同一のノード（ソフトウェア）に対応付けられたルール「A004-1」と「A004-2」とが矛盾することを示している。機能マッピング処理手段２０は、矛盾検証結果表示部１７６にその通知を出力する。この通知に基づいて、システム管理者は、矛盾を解消するようにセキュリティポリシーを再検討することができる。

図２０は、ポリシー過少を検出した場合の出力画面の例を示す説明図である。図２０に示す例では、どのルールにも対応付けられないノード「pf1 」が存在することを示している。機能マッピング処理手段２０は、矛盾検証結果表示部１７６にその通知を出力する。この通知に基づいて、システム管理者は、不足しているルールの追加、あるいは余分なノードの削除を検討することができる。なお、機能マッピング処理手段２０は、ルールと対応付けられないノードの指定をシステム管理者から受け付けてもよい。この場合、機能マッピング処理手段２０は、ポリシー過少の判定において、その指定されたノードをポリシー過少の判断対象から除外する。そして、形式的に「空のポリシー」と対応付ける。

出力画面は、図１７から図２０に示す画面に限定されない。以下、出力画面の他の例を示す。図２１は、機能マップの出力画面の他の一例を示す説明図である。図２１に例示する画面を出力する場合、セキュリティ管理支援システムは、セグメント選択欄１８１、機能マップ表示欄１８２、ルール説明表示欄１８６、ノード情報表示欄１８７および検出結果表示欄１８８を有する画面の情報を予め記憶装置（図１において図示せず。）に記憶する。機能マッピング処理手段２０は、その画面の情報と機能マップとを用いて、出力画面情報を作成し、出力画面情報に基づいて出力画面を出力装置３０に表示する。図２１に例示する画面において、セグメント選択欄１８１は、システム管理者からセグメントの指定を受け付ける欄である。機能マップ表示欄１８２は、管理者に指定されたセグメントにおけるルールとノードとの対応関係を表示する欄である。機能マップ表示欄１８２には、ハードウェアやソフトウェアを表すノード１８３，１８４を表示する。図２１に示すノード１８３はハードウェア（本例ではファイアウォール）を表し、ノード１８４は、それぞれ「ｔｆ」、「ｎｆ」というソフトウェアを表す。機能マッピング処理手段２０は、ソフトウェアを表すノードと、そのソフトウェアをインストールしているハードウェアを表すノードとを、線分で結んで表示する。また、ハードウェアが他のセグメントに接続している場合、機能マッピング処理手段２０は、他のセグメントとの接続関係を表す線分１８５も表示する。図２１に示す例では、ファイアウォールが３種類のセグメントに接続しているので、他のセグメントとの接続関係を表す線分１８５を３本表示している。

また、機能マッピング処理手段２０は、指定されたセグメントにおける各ノード１８３，１８４の外周にルールを表示する。すなわち、機能マッピング処理手段２０は、各ルールがノード１８３，１８４を囲むように表示する。このとき、機能マッピング処理手段２０は、あるルールの下位のレベルのルールを、上位のレベルのルールの隣から並べるように表示する。図２１に示す例では、「B004-1-1」、「B004-1-9」などのルールを、上位の「B004-1」の隣から並べて表示している。さらに、機能マッピング処理手段２０は、対応しているルールとノードとを矢印で結んで表示する。この結果、システム管理者は、ルールとノードとの対応関係を把握しやすくなる。さらに、各ルールがノードを囲むように表示しているので、「ノードのセキュリティがルールに守られている」というイメージをシステム管理者に喚起させることができる。また、ポリシー衝突を生じさせているルールに関しては、矢印を、他の矢印と区別して表示する（本例では破線の矢印として表示している）。なお、機能マップ表示欄１８２に示すルール「B001-1」は、例えば、「インターネット、ＬＡＮおよびＤＭＺの境界を設ける」というルールであり、ノードとは対応付けられないことを前提にするルールである。従って、「B001-1」に関しては、矢印は表示しない。このように、ノードとは対応付けられないことを前提にするルールが含まれていてもよい。

ルール説明表示欄１８６は、マウスクリック等によって選択されたルールの説明を表示する。機能マッピング処理手段２０は、例えば、選択されたルールのpolicy要素をルール説明表示欄１８６に表示する。ノード情報表示欄１８７は、マウスクリック等によって選択されたノードの説明を表示する。機能マッピング処理手段２０は、例えば、選択されたノードのnode要素をノード情報表示欄１８７に表示する。検出結果表示欄１８８は、ポリシー衝突、ポリシー過多あるいはポリシー過少の検出結果を表示する欄である。システム管理者は検出結果表示欄１８８を確認して、セキュリティポリシーやトポロジー情報の再検討を行うことができる。

機能マッピング処理手段２０は、システム管理者の操作に応じて、再検討結果の入力を促すＧＵＩ１８９を表示する。機能マッピング処理手段２０は、ＧＵＩ１８９の操作に応じて、図２２に例示する再検討結果入力画面を表示し、入力装置１０を介して再検討結果を入力する。例えば、機能マッピング処理手段２０は、図２２（ａ）に例示する画面で追加するルールの指定を受け付け、図２２（ｂ）に例示する画面でルールの追加について確認を促す。機能マッピング処理手段２０は、 ルール追加について確認する旨が入力されたならば、そのルールをポリシー記述に反映させ、その旨を表示する（図２２（ｃ））。図２３は、ルール「B013-1-5」が追加されたことにより、図２１で表示していたポリシー衝突が解消したことを示す出力画面である。

図２４は、ポリシー過多を検出した場合の出力画面の例を示す説明図である。機能マッピング処理手段２０は、いずれのノードとも対応付けられないルールに関しては、矢印を表示しない。図２４において、機能マップ表示欄１８２に表示されたルール「C013-1」については矢印を表示していない。従って、この表示は、ルール「C013-1」がポリシー過多を生じさせていることを意味する。また、機能マッピング処理手段２０は、その説明を検出結果表示欄１８８に表示する。システム管理者は図２４に例示する画面を確認して、セキュリティポリシーやトポロジー情報の再検討を行うことができる。

機能マッピング処理手段２０は、システム管理者の操作に応じて、再検討結果の入力を促すＧＵＩ１８９を表示する。機能マッピング処理手段２０は、ＧＵＩ１８９の操作に応じて、図２５に例示する再検討結果入力画面を表示し、入力装置１０を介して再検討結果を入力する。例えば、機能マッピング処理手段２０は、図２５（ａ）に例示する画面で、ポリシー過多の原因となるルールの削除を促す。機能マッピング処理手段２０は、ルールを削除する指示が入力されたならば、そのルールを削除するようにポリシー記述を変更し、削除した旨を表示する（図２５（ｂ））。機能マッピング処理手段２０は、図２６に例示する画面を表示して、図２４に示すポリシー過多が解消したことを示す。

図２７は、ポリシー過少を検出した場合の出力画面の例を示す説明図である。機能マッピング処理手段２０は、いずれのルールとも対応付けられないノードに関しては、矢印を表示しない。図２７において、機能マップ表示欄１８２に表示されたノード「ｗｕ−ｆｔｐ」については矢印を表示していない。従って、この表示は、ポリシー過少が生じていることを意味する。また、機能マッピング処理手段２０は、その説明を検出結果表示欄１８８に表示する。システム管理者は図２７に例示する画面を確認して、セキュリティポリシーやトポロジー情報の再検討を行うことができる。

機能マッピング処理手段２０は、システム管理者の操作に応じて、再検討結果の入力を促すＧＵＩ１８９を表示する。機能マッピング処理手段２０は、ＧＵＩ１８９の操作に応じて、図２８に例示する再検討結果入力画面を表示し、入力装置１０を介して再検討結果を入力する。例えば、機能マッピング処理手段２０は、図２８（ａ）に例示する画面で、ノードに適用するルールの指定を受け付け、図２８（ｂ）に例示する画面でルールの追加について確認を促す。機能マッピング処理手段２０は、ルール追加について確認する旨が入力されたならば、そのルールをポリシー記述に反映させ、その旨を表示する（図２８（ｃ））。図２９は、ルール「C015-1」が追加されたことにより、図２７で表示していたポリシー過少が解消したことを示す出力画面である。

本実施の形態では、ルールとノードとを、セキュリティ機能を介して対応付け、その処理結果を出力装置３０から出力する。従って、どのポリシーがどのノードに関係していて各ノードがどのようなルールを実現しているか、すなわち、現状のセキュリティがどのようであるかをユーザは容易に把握できる。

本実施の形態では、ルールとノードとを対応づけ、さらに、ポリシー過多、ポリシー衝突およびポリシー過少の判定を行う。従って、入力されたトポロジー情報によって特定されるネットワークシステムではシステム管理者が策定したルールに基づくセキュリティ機能を発揮できないという指摘をすることができる。また、システム管理者が策定したセキュリティポリシーに、相反する意味を持つルールが含まれているという指摘をすることができる。また、システム管理者が策定したセキュリティポリシーは、トポロジー情報によって特定されるネットワークシステムのセキュリティ機能を十分に活用していないという指摘をすることができる。このように、システム管理者がルールとノードとの対応関係を把握しやすくし、ルールとノードとの不整合（過不足）を指摘することができるので、管理対象システムのセキュリティの向上およびシステム管理者の負荷軽減を図ることができる。

実施の形態２．
図３０は、本発明の第２の実施の形態の例を示すブロック図である。なお、第１の実施の形態と同様の構成部については図１と同一の符号で示し、説明を省略する。本実施の形態において、セキュリティ管理支援システムは、入力装置１０と、機能マッピング処理手段２０と、ノード知識データベース２１と、設定パラメータ取得手段４０と、パラメータ取得テンプレートデータベース（以下、パラメータＤＢと記す。）４１と、設定スクリプト生成手段５０と、設定スクリプトテンプレートデータベース（以下、スクリプトＤＢと記す。）５１と、出力装置３０とを備える。

パラメータＤＢ４１は、パラメータ取得テンプレート４２を記憶するデータベースである。パラメータ取得テンプレート４２は、ハードウェアまたはソフトウェアに対してあるセキュリティ機能を設定する際に用いるパラメータと、そのパラメータの具体的な値を抽出する指示とを記述した情報である。本例では、条件式を記述して、条件式に合致するパラメータ値の抽出を指示する場合を例に説明する。パラメータの具体的な値は、例えば、トポロジー記述から抽出される。また、異なるハードウェアやソフトウェアが同一のセキュリティ機能を発揮する場合がある。このような場合、ハードウェアやソフトウェアの製品が異なっていても、そのセキュリティ機能を発揮させる際に設定すべきパラメータは共通である。従って、各セキュリティ機能に応じたパラメータ取得テンプレートは、ハードウェアやソフトウェアに個別に依存した記述にはならない。パラメータＤＢ４１は、例えばテキスト形式で、セキュリティ機能毎にパラメータ取得テンプレート４２を記憶する。

設定パラメータ取得手段４０は、機能マッピング処理手段が生成した機能マップに含まれる各ノードのセキュリティ機能を発揮させるためのパラメータを、トポロジー情報２などから取得する。設定パラメータ取得手段４０は、パラメータ取得テンプレート４２を用いてこの処理を実行する。

スクリプトＤＢ５１は、設定スクリプトテンプレート５２を記憶するデータベースである。設定スクリプトテンプレート５２は、個々のハードウェアまたはソフトウェアの個々のセキュリティ機能毎に、そのセキュリティ機能を発揮させる設定を行うための命令と、その命令において指定すべきパラメータを設定パラメータ取得手段４０による処理結果から抽出する指示とを記述した情報である。異なるハードウェアやソフトウェアが同一のセキュリティ機能を発揮する場合であっても、そのセキュリティ機能を設定するための命令はハードウェアやソフトウェア毎に異なる。従って、セキュリティ機能が同じであっても、ソフトウェアなどが異なれば、設定スクリプトテンプレート５２の記述も異なる。スクリプトＤＢ５１は、例えばテキスト形式で、各ハードウェアおよび各ソフトウェアの各セキュリティ機能毎に設定スクリプトテンプレート５２を記憶する。

設定スクリプト生成手段５０は、設定スクリプトテンプレート５２に、パラメータの具体的な値を追加することによって、その値でのパラメータ設定の命令を記述した設定スクリプトを生成する。

出力装置３０は、例えば、第一の実施の形態と同様の情報出力デバイスであり、設定スクリプト生成手段５０が生成した設定スクリプトを出力（表示出力、印字出力等）する。

設定パラメータ取得手段４０、設定スクリプト生成手段５０は、例えば、プログラム（セキュリティ管理支援プログラム）に従って動作するＣＰＵによって実現される。この場合、セキュリティ管理支援システムは、プログラムを記憶する記憶装置（図示せず。）を備える。以下、機能マッピング処理手段２０、設定パラメータ取得手段４０、設定スクリプト生成手段５０は、共通のＣＰＵによって実現されているものとする。なお、出力装置３０は、設定スクリプトを記憶装置あるいは記憶媒体に記録することにより設定スクリプトを出力するものであってもよい。あるいは、通信ネットワークを介して、パラメータ設定対象となるネットワークシステムに設定スクリプトを送信出力するものであってもよい。この場合、出力装置３０は、このＣＰＵによって実現される。

次に、本実施の形態の動作について説明する。図３１は、本実施の形態の動作の処理経過の例を示す流れ図である。まず、入力装置１０および機能マッピング処理手段２０は、セキュリティポリシー１およびトポロジー情報２を入力し、機能マップを作成する（ステップＢ１００，Ｂ２００）。この処理は、第１の実施の形態におけるステップＡ１００，Ａ２００と同様の処理である。ステップＢ２００の処理によって、機能マッピング処理手段２０は、ルールとセキュリティ機能とノードの対応関係を示す情報を作成する。

図３２は、ステップＢ３００以降の処理の概念を示す説明図である。設定パラメータ取得手段４０は、対応付けられたルール、セキュリティ機能およびノードの組毎に、そのセキュリティ機能に応じたパラメータ取得テンプレート４２を検索する。各パラメータ取得テンプレート４２には、セキュリティ機能を設定する際に用いるパラメータの具体的な値をトポロジー記述から抽出するための条件式が記述されている。設定パラメータ取得手段４０は、各セキュリティ機能に応じたパラメータ取得テンプレート４２を検索したならば、パラメータ取得テンプレート４２内の条件式を用いてトポロジー記述からパラメータの値を抽出する（ステップＢ３００）。

次に、設定スクリプト生成手段５０は、ステップＢ２００で得られた機能マップに含まれる個々のノードの各セキュリティ機能毎に、スクリプトＤＢ５１から設定スクリプトテンプレート５１を検索する。各設定スクリプトテンプレート５２には、セキュリティ機能を発揮させる命令（設定スクリプト）の雛型があらかじめ記述されている。設定スクリプト生成手段５０は、検索した設定スクリプトテンプレート５２に、ステップＢ３００で得られたパラメータを追加することで設定スクリプトを生成する（ステップＢ４００）。続いて、設定スクリプト生成手段５０は、出力装置３０に、設定スクリプトを出力させる（ステップＢ５００）。

次に、ステップＢ３００について詳細に説明する。設定パラメータ取得手段４０は、機能マップ内のセキュリティ機能毎に、このパラメータ取得テンプレート４２を検索する。

既に説明したように、個々のパラメータ取得テンプレート４２には、セキュリティ機能を発揮させるために設定すべきパラメータと、そのパラメータの具体的な値を抽出する条件式とが予め記述される。この記述は、個々のハードウェアやソフトウェアの種類に依存するものではない。セキュリティ機能を発揮させるために設定すべきパラメータの例としては、ＩＰアドレスやnic 要素１１５のname属性１１６（図７参照）等が挙げられる。そして、これらのパラメータの具体的な値は、トポロジー記述に含まれている。

図３３は、パラメータ取得テンプレート４２の具体例を示す説明図である。図３３（ａ）は、「インターネット−ＤＭＺ境界セグメントにおいて、httpdパケットの通過を許可する」というルールのpolicy要素を示す。このルールは、subject 要素が示すセキュリティ機能「function.filtering.packet.tcp.httpd 」を発揮させることで実現される。図３３（ｂ）は、このセキュリティ機能に対応するパラメータ取得テンプレートの具体例である。dataタグに囲まれたdata要素２１１は、このセキュリティ機能を発揮させるために必要な各パラメータおよび、そのパラメータの具体的な値を抽出するための条件式の集合である。param タグに囲まれた１つのparam 要素２１２は、１つのパラメータ取得テンプレートを表す。param 要素２１２は、data要素２１１と、セキュリティ機能を示すfunction要素とを含む。

図３３（ｂ）に示す例では、「<パラメータ名>::<トポロジー記述の要素>[<条件式>];」という書式の集合としてdata要素２１１を記述している。「パラメータ名」は同一のテンプレート中で一意に識別できる名前が指定されている。「トポロジー記述の要素」の部分でトポロジー記述内の子要素を指定する場合、親要素と子要素とをドット（. ）で連結し、親要素から子要素をたどるように記述される。また、ある要素の属性を指定する場合、その要素と属性とを例えば「@ 」で連結して記述する。「条件式」は、「Ａ＝Ｂ」という形式で記述され、「ＡがＢである」という条件を表している。設定パラメータ取得手段４０は、この条件式を用いて、トポロジー記述から条件を満たすような要素の内容や属性値を抽出する。

図３３（ｂ）に示す例では、パラメータ「src-address」の具体的な値を抽出する条件式として[network.segment@type='network.segment.int']を記述している。この条件式は、「トポロジー記述のnetwork 要素の子要素であるsegment要素のtype属性が"network.segment.int" である」という条件を示している。設定パラメータ取得手段４０は、この条件を満たすaddress 要素の内容を抽出して、「src-address」の値とすることを意味する。

また、条件式はネスト構造になっていてもよい。図３４のトポロジー記述を用いて、ネスト構造の条件式に基づいてパラメータ値を抽出する場合の例を示す。例えば、図３３（ｂ）に示すパラメータ「in-interface」の値を抽出する条件式は、ネスト構造になっている。この条件式は、「network 要素の子要素であるsegment 要素のtype属性が"network.segment.int"である。」という条件式を内包している。従って、条件式全体としては、「ハードウェアのnic 要素のin属性が、『network 要素の子要素であるsegment 要素のtype属性が"network.segment.int"であるようなsegment要素のname属性』の値になっている。」という条件を示している。さらに、この条件を満たすnic 要素のname属性の値を抽出して、「in-interface」の値とすることを示している。図３４に示す記述Ａは、「type属性が"network.segment.int"であるようなsegment要素」を示しており、そのname属性は、「int 」である。そして、この「int 」をin属性とするnic 要素が記述Ｂに示されており、記述Ｂは、この条件に合致する。この結果、設定パラメータ取得手段４０は、記述Ｂが示すname属性「eth0」を抽出して、「in-interface」の値とする。

また、パラメータの値が既定値として定まっている場合には、条件式を記述せずに、その既定値を直接記述しておいてもよい。例えば、図３３に示すパラメータ「protocol」の値は、トポロジー記述の内容によらずに「tcp」という既定値として定められる。

設定パラメータ取得手段４０は、パラメータ取得テンプレート４２が示す全てのパラメータについて検索を行い、トポロジー記述から抽出したパラメータの値を、パラメータ取得テンプレート４２に記述する。図３５は、この処理によって値が記述されたパラメータ取得テンプレートの例を示す。 設定パラメータ取得手段４０は、この処理を機能マッピング処理（ステップＢ２００）で得られた全てのタプル、つまり全てセキュリティ機能について行う。

なお、図３３（ｂ）は、パラメータ取得テンプレートの記述フォーマットの一例を示すものである。パラメータ取得テンプレートは、条件に応じた値を抽出できるように記述されていればよい。

ステップＢ３００で取得したパラメータの値は、セキュリティ機能を発揮させるような設定を行うために用いられるパラメータ値である。このパラメータ値そのものは、ハードウェアやソフトウェアの種類には依存しない。一方、このパラメータ値を設定するための命令（設定スクリプト）は、ハードウェアやソフトウェアの種類毎に異なる。ステップＢ４００では、ハードウェアやソフトウェアの種類に応じた設定スクリプトを生成する。以下、ステップＢ４００の処理について説明する。

ステップＢ４００において、設定スクリプト生成手段５０は、機能マップ内のセキュリティ機能とノードとの組み合わせをキーにして、スクリプトＤＢ５１から設定スクリプトテンプレート５２を検索する。設定スクリプトテンプレート５２には、設定スクリプトの雛型が記述されている。ただし、設定すべきパラメータ値は未確定であり、パラメータ値が記述されたパラメータ取得テンプレート（図３５参照）からパラメータ値を抽出する指示が記述されている。設定スクリプト生成手段５０は、検索した設定スクリプトテンプレート５２に基づいて、設定スクリプトを生成する。

図３６は、設定スクリプトテンプレートの例を示す説明図である。図３６に示した例は、「ｈｔｔｐパケットを通過させる」というセキュリティ機能を、パケットフィルタリングソフトウェア「ｉｐｃｈａｉｎｓ（商標）」に設定するためのテンプレートである。図３６に示す例において、パラメータの前に記述された「$ 」は、そのパラメータの値をパラメータ取得テンプレートから抽出し、「$ 」およびパラメータの記述を、抽出したパラメータ値に置換することを意味する。この置換の例を、図３７に示す。例えば、設定スクリプトテンプレートにおいて、「$in-interface 」という記述がある場合、設定スクリプト生成手段５０は、パラメータ取得テンプレートから「in-interface」のパラメータ値（本例では「eth0」）を抽出する。そして、「$in-interface 」を「eth0」に置換する。設定スクリプト生成手段５０は、設定スクリプトテンプレートに従って、この置換を繰り返し、設定スクリプトを生成する。設定スクリプト生成手段５０は、この処理を前記ステップＢ２００の機能マッピングで得られたすべてのタプルについて行う。

なお、図３６は、設定スクリプトテンプレートの記述フォーマットの一例を示すものである。設定スクリプトテンプレートは、各ハードウェアやソフトウェアに応じた設定スクリプトの雛型と、パラメータ値の抽出の指示が記述されたものであればよい。

最後に、設定スクリプト生成手段５０は、出力装置３０に設定スクリプトを出力する（ステップＢ５００）。システム管理者は、出力された設定スクリプトを用いて、各ノードに対し設定を行えばよい。なお、設定スクリプト生成手段５０は、設定スクリプトを記憶装置や記憶媒体にファイルとして記憶させてもよい。また、表示出力や印字出力ではなく、設定スクリプト生成手段５０は、通信ネットワークを介して、管理対象のネットワークシステムの各ノードに設定スクリプトを送信してもよい。この場合、設定スクリプトを受信した各ノードが、その設定スクリプトに基づいて自動的にパラメータの設定を行ってもよい。

図３８は、設定スクリプトを表示出力する出力画面の例である。設定スクリプト生成手段５０は、例えば、図３８に例示するように、セグメント選択欄１８１、機能マップ表示欄１８２、ルール説明表示欄１８６およびノード説明表示欄１８７と同時にスクリプト表示欄５０１を出力すればよい。そして、設定スクリプト生成手段５０は、マウスクリックなどによってルールを選択されたならば、図３９に例示する画面を出力して、設定スクリプトを生成するか否かの確認をシステム管理者に促す。設定スクリプトを生成する指示が入力されたならば、設定スクリプト生成手段５０は、設定スクリプトを生成し、その設定スクリプトをスクリプト表示欄５０１に表示すればよい。

第２の実施の形態では、設定パラメータ取得手段４０が、ハードウェアやソフトウェアに依存せずにセキュリティ機能に応じたパラメータ値を抽出する。そして、設定スクリプト生成手段が、ハードウェアやソフトウェアの種類に応じた設定スクリプトの雛型に対してそのパラメータ値を適用することにより、設定スクリプトを生成する。このように、設定スクリプトが自動的に作成されるので、システム管理者の負担を軽減できる。特に、システム管理者は、各ハードウェアやソフトウェアのセキュリティ機能毎に設定スクリプトを作成する必要がなく、システム管理者の負担軽減の効果が大きい。すなわち、各ハードウェアあるいはソフトウェア固有の設定方法を意識しなくても、策定したセキュリティポリシーに則って適切に設定スクリプトが生成されるので、システム管理者の負担が軽減される。

また、新たなセキュリティ機能が出現した場合には、そのセキュリティ機能に応じたパラメータ取得テンプレートと、設定スクリプトテンプレートをそれぞれ追加すればよい。既存のパラメータ取得テンプレートおよび設定スクリプトテンプレートを修正する必要はないので、セキュリティ機能の増加に対して容易に対処できる。また、既存のセキュリティ機能を持つ新たなノードが出現した場合には、そのノードに応じた設定スクリプトテンプレートを追加すればよく、既存のパラメータ取得テンプレートおよび設定スクリプトテンプレートを修正する必要はない。従って、ハードウェアやソフトウェアの種類の増加にも容易に対処できる。

なお、本実施の形態では、機能マッピング処理手段２０およびノード知識データベース２１を備える場合を示したが、機能マッピング処理手段２０およびノード知識データベース２１を備えずに、外部のシステム（例えば、第１の実施の形態に示すセキュリティ管理支援システム）で作成された機能マップを入力し、入力された機能マップに基づいてステップＢ３００以降の処理を実行してもよい。すなわち、入力装置１０からトポロジー情報および機能マップを入力し、その後、設定パラメータ取得手段４０がステップＢ３００の処理を開始すればよい。また、キーボードやマウスなどの装置によって機能マップを入力するのではなく、外部システムから通信ネットワークを介して機能マップを受信することにより、機能マップを入力してもよい。この場合、機能マップ入力手段として、ネットワークインタフェース装置を備えていればよい。

実施の形態３．
図４０は、本発明の第３の実施の形態の例を示すブロック図である。なお、第１の実施の形態と同様の構成部については図１と同一の符号で示し、説明を省略する。本実施の形態において、セキュリティ管理支援システムは、入力装置１０と、機能マッピング処理手段２０と、ノード知識データベース２１と、脆弱性フィルタリング手段６０と、脆弱性情報データベース６１と、出力装置３０とを備える。

脆弱性情報データベース６１は、脆弱性情報６２を記憶するデータベースである。脆弱性情報６２は、ハードウェアやソフトウェアにおけるセキュリティ上の脆弱点に関する情報である。脆弱性情報データベース６１は、脆弱性情報６２を記憶するデータベースである。新たに見つかった脆弱点に関する脆弱性情報は、一般に公開されている。例えば、システム管理者は、公開された脆弱性情報の内容を、所定のフォーマットにあわせて整理する。脆弱性情報データベース６１は、この所定のフォーマットにあわせて整理された脆弱性情報６２を記憶する。

脆弱性情報フィルタリング手段６０は、機能マッピング処理手段２０から出力される機能マップと、脆弱性情報データベース６１に格納された脆弱性情報６２とを用いて、管理対象のネットワークシステムへの適用が必要な脆弱性情報を選別し、そのレポートを生成する。そして、脆弱性情報フィルタリング手段６０は、そのレポートを出力装置３０に出力（表示、印刷など）させる。

本実施の形態において、入力装置１０は、セキュリティポリシーおよびトポロジー情報のほかに、脆弱性情報も入力される。

機能マッピング処理手段２０および脆弱性情報フィルタリング手段６０は、例えば、プログラム（セキュリティ管理支援プログラム）に従って動作するＣＰＵによって実現される。この場合、セキュリティ管理支援システムは、プログラムを記憶する記憶装置（図示せず。）を備える。以下、機能マッピング処理手段２０および脆弱性情報フィルタリング手段６０は、共通のＣＰＵによって実現されているものとする。

次に、本実施の形態における処理経過について説明する。なお、入力装置１０および機能マッピング処理手段２０は、第一の実施の形態で示したステップＡ１００，Ａ２００の処理を完了し、すでに機能マップを生成しているものとする。そして、機能マッピング処理手段２０は、その機能マップを記憶装置（図示せず。）に記憶させているものとする。

図４１は、本実施の形態における処理経過の例を示す流れ図である。まず、システム管理者は、一般に公開されている新たな脆弱性情報を収集する（ステップＣ１００）。システム管理者は、一般に公開されているＷｅｂページやデータベースから脆弱性情報を入手することができる。脆弱性情報を公開しているＷｅｂページとしては、例えばＪＰＣＥＲＴ／ＣＣ（Japan Computer Emergency Response Team /Coordination Center ）のＷｅｂページがある。また、ＣＶＥ（Common Vulnerabilities&Exposures）も、脆弱性情報のデータベースを公開している。さらに、各ベンダもＷｅｂページやメーリングリストによる電子メール配信によって、脆弱性情報を公開している。システム管理者は、一般に公開されているＷｅｂページ、データベースやメーリングリストなどを利用して、脆弱性情報を収集する。そして、システム管理者は、その脆弱性情報を分析して所定のフォーマットにあわせて脆弱性情報の内容を整理し、脆弱性情報データベース６１に登録する操作を行う。セキュリティ管理支援システムのＣＰＵは、所定のフォーマットに整理された脆弱性情報６２を、入力装置１０を介して入力し、その脆弱性情報６２を脆弱性情報データベース６１に登録する（ステップＣ２００）。

図４２は、脆弱性情報データベース６１が記憶する脆弱性情報６２のフォーマットの例を示す説明図である。本例において、脆弱性情報６２は、「ＩＤ」、「名称」、「詳細」、「対象ノード／バージョン」、「脆弱原因」および「対処法」の各項目を有するように整理される。「ＩＤ」項目は、脆弱性情報データベース６１に格納される脆弱性情報を一意に識別する識別子である。「名称」項目は、脆弱性情報のタイトルである。「詳細」項目は、セキュリティ脆弱点の詳細な内容を示す情報である。例えば、「詳細」項目として、セキュリティ脆弱点の影響度や緊急性、問題の技術的な情報、可能性のある攻撃方法などの情報が記述される。「対処法」項目は、セキュリティ脆弱点を解消するための対処法を示す情報である。例えば、「対処法」項目として、バージョンアップ、セキュリティパッチの適用、設定ファイルの変更などの対処法が記述される。

「対象ノード／バージョン」項目は、「対処法」項目に記述される対処法を施すべきハードウェアまたはソフトウェアを示す。「対象ノード／バージョン」項目において、ハードウェアやソフトウェアは、セキュリティクラスまたは、ノード知識２２内に含まれているhardware-canonical-name 、hardware-canonical-version-name 、software-canonical-name 、software-canonical-version-name を用いて記述される。

「脆弱原因」項目は、脆弱点の発生原因を示す。具体的には、「脆弱原因」項目として、脆弱点の発生原因となるセキュリティ機能、あるいはハードウェア、ソフトウェアなどが記述される。例えば、ハードウェアまたはソフトウェアがあるセキュリティ機能を発揮した場合にセキュリティ上の問題が生じるが、そのセキュリティ機能を発揮しない場合には問題が生じないとする。この場合、そのセキュリティ機能が脆弱点の原因として「脆弱原因」項目に記述される。また、例えば、あるノードＡとあるノードＢとが同時に動作する場合にノードＡにセキュリティ上の問題が生じるが、ノードＢが動作していない場合にはノードＡに問題が生じないとする。この場合、ノードＢが脆弱点の原因として「脆弱原因」項目に記述される。「対象ノード／バージョン」項目において、脆弱点の原因となるセキュリティ機能やノードは、セキュリティクラスまたは、ノード知識２２内に含まれているhardware-canonical-name 、hardware-canonical-version-name 、software-canonical-name 、software-canonical-version-name を用いて記述される。

システム管理者は、新たに入手した脆弱性情報を、このような各項目を有するフォーマットに整理し、セキュリティ管理支援システムに入力する。セキュリティ管理支援システムのＣＰＵは、そのフォーマットに整理された脆弱性情報を脆弱性情報データベース６１に追加登録する。ここでは、脆弱性情報の入手および整理をシステム管理者が行う場合を示したが、セキュリティ管理支援システムのＣＰＵが脆弱性情報の入手から登録までを実行してもよい。このような脆弱性情報の登録は、例えば、以下のように実現される。セキュリティ管理支援システムのＣＰＵは、脆弱性情報を表示したＷｅｂページを提供しているサーバに定期的にＷｅｂページを要求し、そのサーバからＷｅｂページの情報を受信する。そして、ＣＰＵは、Ｗｅｂページの情報から各項目に記述すべき情報を抽出し、各項目毎に抽出した情報を脆弱性情報データベース６１に登録すればよい。なお、各項目に記述すべき情報は、所定のキーワードを含む箇所をＷｅｂページから抽出したり、Ｗｅｂページの文書構造に基づいて判断すればよい。

ステップＣ２００の後、脆弱性情報フィルタリング手段６０は、登録された脆弱性情報６２と管理対象システムの機能マップとを用いて、管理対象システムにセキュリティ脆弱点が存在する可能性の程度を判定し、その脆弱点への対処の推奨の程度を判定する（ステップＣ３００）。そして、脆弱性情報フィルタリング手段６０は、セキュリティ脆弱点に関するレポートを出力装置３０に出力する（ステップＣ４００）。

次に、ステップＣ３００について詳細に説明する。図４３は、ステップＣ３００の処理経過の例を示す流れ図である。脆弱性情報フィルタリング手段６０は、ステップＣ２００で脆弱性情報データベース６１に登録された脆弱性情報６２の「対象ノード／バージョン」項目を用いて、機能マッピング処理手段２０から出力された機能マップを検索する（ステップＣ３０１）。機能マップは、対応付けられたルール、セキュリティ機能およびノードの組み合わせの集合である。脆弱性情報フィルタリング手段６０は、「対象ノード／バージョン」項目に合致するノードを含む組み合わせが機能マップに存在しているか否かを判定する（ステップＣ３０２）。

脆弱性情報フィルタリング手段６０は、「対象ノード／バージョン」項目に合致するノードを含む組み合わせが存在すると判定した場合、脆弱性情報６２の「脆弱原因」項目を用いて機能マップを検索する（ステップＣ３０３）。そして、脆弱性情報フィルタリング手段６０は、「脆弱原因」項目に合致する内容（セキュリティ機能またはノード）を含む組み合わせが機能マップに存在しているか否かを判定する（ステップＣ３０４）。

ステップＣ３０４において、「脆弱原因」項目に合致する内容を含む組み合わせが存在すると判定した場合、セキュリティ脆弱点への対処を施す対象ノードが存在し、かつ、その脆弱点の原因となるセキュリティ機能またはノードが管理対象ネットワークシステムで使用されていることになる。従って、この場合、脆弱性情報フィルタリング手段６０は、セキュリティ脆弱点への対処を「強く推奨」する必要があると判定する（ステップＣ３０５）。

ステップＣ３０４において、「脆弱原因」項目に合致する内容を含む組み合わせが存在しないと判定した場合、セキュリティ脆弱点への対処を施す対象ノードは存在するが、その脆弱点の原因となるセキュリティ機能またはノードは管理対象ネットワークシステムで使用されていないことになる。この場合、脆弱性情報フィルタリング手段６０は、セキュリティ脆弱点への対処を「推奨」する必要があると判定する（ステップＣ３０６）。

ステップＣ３０２において、「対象ノード／バージョン」項目に合致するノードを含む組み合わせが機能マップに存在しないと判定した場合、脆弱性情報フィルタリング手段６０は、「対象ノード／バージョン」項目を用いてトポロジー記述を検索する（ステップＣ３０７）。そして、脆弱性情報フィルタリング手段６０は、「対象ノード／バージョン」項目に合致するノードがトポロジー記述に存在しているか否かを判定する（ステップＣ３０８）。

ステップＣ３０８において、「対象ノード／バージョン」項目に合致するノードがトポロジー記述に存在すると判定した場合、ルールと対応付けられていないが、セキュリティ脆弱点への対処を施す対象ノードが管理対象システム内に存在していることになる。この場合、脆弱性情報フィルタリング手段６０は、管理対象システム内に「潜在的な脆弱点」が存在する旨の報告をすると判定する（ステップＣ３０９）。

脆弱性情報フィルタリング手段６０は、ステップＣ３０５，Ｃ３０６，Ｃ３０９の後、ステップＣ３１０の処理に移行する。また、ステップＣ３０８において、「対象ノード／バージョン」項目に合致するノードがトポロジー記述に存在しないと判定した場合にも、システム管理者に報告すべき事項はないので、ステップＣ３１０に移行する。

脆弱性情報フィルタリング手段６０は、新たに登録された全ての脆弱性情報６２に対してステップＣ３０１以降の処理を実行したか否かを判定する（ステップＣ３１０）。まだ、処理を行っていない脆弱性情報６２が存在する場合、その脆弱性情報６２に対してステップＣ３０１以降の処理を行う。新たに登録された全ての脆弱性情報６２に対してステップＣ３０１以降の処理を行ったならば、ステップＣ３０５，Ｃ３０６，Ｃ３０９の判定結果に基づいてレポートを作成する（ステップＣ３１１）。脆弱性情報フィルタリング手段６０は、例えば、脆弱性情報６２の各項目とともに、推奨の程度を表示するレポートを作成すればよい。

最後に、脆弱性情報フィルタリング手段６０は、作成したレポートを出力手段３００から出力する（ステップＣ４００）。図４４は、出力されるレポートの例を示す説明図である。図４４では、「脆弱性への対処を強く推奨する」という情報とともに、「ＩＤ」、「詳細」、「対象ノード／バージョン」、「脆弱原因」および「対処法」の各項目を示すレポートを例示する。脆弱性情報フィルタリング手段６０は、「脆弱原因」項目の内容に、ユーザが指定したノードの名称（ノードのname属性）を追加して、そのname属性も併記されるようにレポートを作成してもよい。ノードのname属性もレポートに含めることにより、システム管理者にとって、対処を行わなければならないノードの把握が容易になる効果がある。

なお、図４４で示したレポートは例示であり、レポートの内容は図４４に示す内容に限定されない。

また、脆弱性情報フィルタリング手段６０は、対処を「強く推奨」する脆弱性情報のレポートは無条件に出力装置３０に出力し、「推奨（強い推奨ではない）」する脆弱性情報のレポートは、システム管理者からの要求に応じて出力してもよい。例えば、「推奨」する脆弱性情報のレポートを作成した場合、そのレポートの出力を要否の決定を促すＧＵＩを表示し、出力の指示を受け付けた場合にそのレポートを出力してもよい。「潜在的な脆弱点」が存在する旨を示すレポートは、記憶装置に記憶しておき、システム管理者からレポート出力の指示を受け付けた場合に、記憶装置からレポートを読み込んで表示させてもよい。「潜在的な脆弱点」のレポートの量は多い可能性があるので、このように管理者からの指示に応じて出力してもよい。

なお、脆弱性情報データベース６１が格納する脆弱性情報４２のフォーマットは、図４２に示すフォーマットに限定されない。脆弱性情報４２のフォーマットは、推奨の程度を分類するために「対処を施す対象ノードを示す項目」と「脆弱点の原因を示す項目」とを含み、管理者に具体的な対処法を提示するために、対処法に関する項目を含んでいればよい。

第３の実施の形態では、日々新たに脆弱性情報データベース６１に登録される脆弱性情報に基づいて、管理対象のネットワークシステムに脆弱点の原因が存在するか否かを判定し、脆弱性への対処方法を自動的にレポートする。従って、数多くの脆弱性情報の中から管理対象ネットワークシステムに関係する脆弱性情報のみ用意に選別できる。さらに、脆弱点への対処の対象ノード（ハードウェアやソフトウェア）が管理対象ネットワーク中に存在するかどうかだけでなく、その脆弱点の発生原因となるセキュリティ機能やノードをネットワークシステムで使用しているか否かを判定し、その判定結果の組み合わせによって対処実施の推奨の程度を分類する。従って、システム管理者は、脆弱点への対処をすぐに行うべきか否かを判断することができる。そして、システム管理者は、推奨の程度に応じて、「現在さしあたって対処する必要がない」ということを判断できる。従って、不必要な対処を行って他のサービスなどに不具合を生じさせる可能性を減少させることができる。

なお、本実施の形態では、機能マッピング処理手段２０およびノード知識データベース２１を備える場合を示したが、機能マッピング処理手段２０およびノード知識データベース２１を備えずに、外部のシステム（例えば、第１の実施の形態に示すセキュリティ管理支援システム）で作成された機能マップを入力してもよい。すなわち、入力装置１０を介してトポロジー情報および機能マップを入力し、また、新たな脆弱性情報の登録が完了してから、脆弱性情報フィルタリング手段６０がステップＣ３００の処理を開始すればよい。また、キーボードやマウスなどの装置が機能マップを入力するのではなく、外部システムから通信ネットワークを介して機能マップを受信することにより、機能マップを入力してもよい。この場合、機能マップ入力手段として、ネットワークインタフェース装置を備えていればよい。

また、第２の実施の形態と同様に、設定パラメータ取得手段４０と、パラメータ取得テンプレートデータベース４１と、設定スクリプト生成手段５０と、設定スクリプトテンプレートデータベース５１とを備え、第３の実施の形態に示す処理だけでなく、第２の実施の形態に示す処理（設定スクリプトの生成）を実行できるようにしてもよい。

実施の形態４．
第４の実施の形態を説明する前に、第４の実施の形態と第１の実施の形態との差異を明確にするため、第１の実施の形態について補足する。

第１の実施の形態では、１つのpolicy要素がparent要素７９（図５参照）によって親にあたるpolicy要素を特定する場合を示した。また、priority要素８０（図５参照）によって各ルール（各policy要素）の優先度の高低を示す場合も示した。このparent要素７９やpriority要素８０の記述内容は、「ルールの親子関係や優先順位を決定している制約」である。

また、第１の実施の形態では、同一のノードに対応付けられた複数のルールのsubject 要素が同一であり、かつaction 要素が異なっている場合には、ポリシー衝突として検出することを説明した。これは、「同一のノードに対応付けられた複数のルールのsubject 要素が同一であり、かつaction 要素が異なっていてはならない。」という制約が存在することを意味する。同様に、１つのノードに、予め定められた特定の複数のルールが対応付けられた場合に、ポリシー衝突として検出してもよいことを示した。第１の実施の形態では、「ノードＮ１にルールＲ１，Ｒ２が対応付けられた場合、ポリシー衝突である。」という例を示した。これは、「１つのノードに、予め定められている特定の複数のルールが対応付けられてはならない。」という制約が存在することを意味する。さらに、第１の実施の形態では、異なるノードに、それぞれ予め定められた特定のルールが対応付けられた場合に、ポリシー衝突として検出してもよいことを示した。第１の実施の形態では、「ノードＮ１とルールＲ１とが対応付けられ、かつ、ノードＮ２とルールＲ３とが対応付けられた場合、ポリシー衝突である。」という例を示した。これは、異なるノードに、それぞれ予め定められた特定のルールが対応付けられてはならないという制約が存在することを意味する。これらの制約は、「ノードとルールとの間の関係を決定している制約」である。

また、第１の実施の形態では、どのルールとも対応付けられなかったノードが存在している場合、ポリシー過少を検出することを示した。これは、ノードはルールと対応付けられなければならないという制約が存在することを意味する。この制約も、「ノードとルールとの間の関係を決定している制約」である。

以上のように、第１の実施の形態では、「ルールの親子関係や優先順位を決定している制約」や、「ノードとルールとの間の関係を決定している制約」を用いて、機能マップを作成している。

これに対し、第４の実施の形態では、上記の制約に加えて、セグメント（通信ネットワークの各区分）におけるセキュリティクラス間の制約を示す情報も用いる。「セキュリティクラスの間の制約」とは、より具体的には、function-classによって表されるセキュリティ機能の間の制約である。セグメントにおけるセキュリティ機能の間の制約を制約知識と記すことにする。

図４５は、本発明の第４の実施の形態の例を示すブロック図である。入力装置１０は、第１の実施の形態における入力装置と同様に、セキュリティポリシー１およびトポロジー情報２を入力する。セキュリティポリシー１に含まれる各ルールには、セキュリティ機能の情報が対応付けられている。また、各ルールは、セグメント毎に分類されている。従って、入力された各ルールから変換されるpolicy要素には、subject 要素７６、action要素７７、およびsegment 要素７８が含まれる。また、トポロジー情報２は、第１の実施の形態に示したトポロジー情報と同様に、通信ネットワークの各セグメントと、そのセグメントに属するハードウェアとの対応関係を示し、さらに、各ハードウェアと各ハードウェアが搭載する各ソフトウェアとの対応関係を示している。

機能マッピング処理手段２０は、例えば、プログラムに従って動作するＣＰＵによって実現される。機能マッピング処理手段２０は、入力されたセキュリティポリシー１をポリシー記述に変換する。この結果、各ルールは、policy要素として表される。また、機能マッピング処理手段２０は、入力されたトポロジー情報２をトポロジー記述に変換する。そして、機能マッピング処理手段２０は、機能マップ（ルールとセキュリティ機能とノードとの対応関係を示す情報の集合）を作成する。

ノード知識データベース２１は、第１の実施の形態において説明したノード知識と同様のノード知識２２を記憶する。また、出力装置３０は、第１の実施の形態における出力装置３０と同様である。

制約知識データベース２３は、制約知識２４を記憶するデータベースである。制約知識２４による制約の内容として、例えば、「禁止（prohibited）」、「注意（warning ）」、「推奨（recommend ）」、および「必要（must）」がある。

「禁止」は、同一セグメント内において設定されてはならない複数のセキュリティ機能の設定の組み合わせを定めた制約である。なお、分類された通信ネットワークの境界部分（例えば、インターネットとＤＭＺとの境界等）もセグメントに該当する。「注意」は、同一セグメント内で設定されたときにシステム管理者に注意を促すべき複数のセキュリティ機能の設定の組み合わせを定めた制約である。「推奨」は、同一セグメント内で設定されることが好ましいと定められる複数のセキュリティ機能の設定の組み合わせを定めた制約である。「必要」は、同一セグメント内で設定されなければならない複数のセキュリティ機能の設定の組み合わせを定めた制約である。

制約知識２４は、コンピュータが認識できる書式で記述され、制約知識データベース２３に記憶される。コンピュータが認識できる書式で記述された制約知識を、制約知識記述と記すことにする。制約知識記述全体の中において、個々の制約知識を示した部分をconstraint要素と記すことにする。図４６は、制約知識記述の例を示す説明図である。constraints タグに囲まれた範囲４０１が、制約知識記述全体に該当する。また、constraintタグに囲まれた範囲は、constraint要素を示している。図４６に示す例では、５個のconstraint要素４０２ａ〜４０２ｅを示している。ただし、制約知識記述全体に含まれるconstraint要素の数は５個に限定されるわけではない。

各constraint要素４０２ａ〜４０２ｅは、function要素４０７を含む。function要素４０７は、セキュリティ機能を示す。また、function要素４０７は、action属性４０８を含んでいる。action属性４０８は、function要素４０７が表しているセキュリティ機能を発揮させるか否かというセキュリティ機能の設定を示している。図４６に示す各function要素４０７のaction属性４０８はいずれも「add 」と記述されている。「add 」は、セキュリティ機能を発揮させることを示している。図４６では、action属性４０８を全て「add 」としているが、セキュリティ機能を発揮させない旨がaction属性４０８に記述されていてもよい。

また、各constraint要素４０２ａ〜４０２ｅは、name属性４０３と、logic 属性４０４と、type属性４０５とを含む。name属性４０３には、個々のconstraint要素をそれぞれ識別するための名前が記述される。

logic 属性４０４には、constraint要素に含まれるfunction要素４０７に対して適用する論理式が記述される。例えば、logic 属性４０４に「and 」という記述がなされているならば、constraint要素に含まれる複数のfunction要素４０７の記述内容が同時に真になること（すなわち、論理積）を意味する。また、１つのセグメントにおける機能マップにfunction要素４０７が示すセキュリティ機能が複数存在するという状態がlogic 属性４０４に記述される場合もある。このような状態は、本例では「multiple」と記述するものとする。すなわち、logic 属性４０４に「multiple」という記述がなされているならば、１つのセグメントにおける機能マップにfunction要素４０７が示すセキュリティ機能が複数存在するという状態を意味する。

type属性４０５には、constraint要素が表す制約の種類が記述される。type属性４０５に「prohibited」が記述されているならば、「禁止」を意味する。「warning 」が記述されているならば、「注意」を意味する。「recommend 」が記述されているならば、「推奨」を意味する。「must」が記述されているならば、「必要」を意味する。

また、各constraint要素４０２ａ〜４０２ｅは、comment要素４０６を含む。comment要素４０６は、個々の制約の説明を自然言語で記述したコメント文である。

また、各constraint要素４０２ａ〜４０２ｅは、segment要素４０９を含む。segment要素４０９は、constraint要素が示す制約に従うべきセグメントを表している。

以下、図４６に示す５つのconstraint要素４０２ａ〜４０２ｅを用いて、constraint要素の具体例について説明する。constraint要素４０２ａは、name属性において「c001」という名前が指定されている。constraint要素４０２ａは、２つのfunction要素４０７を含んでいる。図４６の６行目に示す１つ目のfunction要素は、action属性４０８が「add 」であるので、ＤＮＡＴ（Dynamic Network Address Translator）を実施する旨の設定を表している。同様に、７行目に示す２つ目のfunction要素は、ＳＮＡＴ（Static Network Address Translator ）を実施する旨の設定を表している。また、constraint要素４０２ａのsegment要素４０９は通信ネットワークの境界部分のセグメントを示しており、logic 属性４０４は「and （論理積）」を示し、さらにtype属性４０５は「prohibited（禁止）」を示している。従って、constraint要素４０２ａは、「通信ネットワークの境界部分のセグメントにおいて、ＤＮＡＴとＳＮＡＴとを同時に実施してはならない。」という制約を表している。ＤＮＡＴとＳＮＡＴとは、アドレス変換の手法として互いに背反的な手法であるため、このような制約が設けられる。

constraint要素４０２ｂは、name属性において「c002」という名前が指定されている。constraint要素４０２ｂは、２つのfunction要素４０７を含んでいる。図４６の１１行目に示す１つ目のfunction要素は、action属性４０８が「add 」であるので、改竄防止（function.service.integrity）を実施する旨の設定を表している。同様に、１２行目に示す２つめのfunction要素は、ログ取得を実施する旨の設定を表している。また、constraint要素４０２ｂのsegment要素４０９は境界部分ではないセグメントを示しており、logic 属性４０４は「and （論理積）」を示し、さらにtype属性４０５は「warning（注意）」を示している。従って、constraint要素４０２ｂは、「境界部分でないセグメントにおいて、改竄防止とログ取得とを同時に実施する場合には注意を要する。」という制約を表している。ログの取得を行う際における、ログをファイルに書き出す動作が、改竄行為として検出されることになってしまうため、このような注意を促すための制約が設けられる。

constraint要素４０２ｃは、name属性において「c003」という名前が指定されている。constraint要素４０２ｃは、２つのfunction要素４０７を含んでいる。図４６の１８行目に示す１つ目のfunction要素は、action属性４０８が「add 」であるので、ログ取得を実施する旨の設定を表している。同様に、１９行目に示す２つめのfunction要素は、時刻合わせを実施する旨の設定を表している。また、constraint要素４０２ｃのsegment要素４０９は境界部分ではないセグメントを示しており、logic 属性４０４は「and （論理積）」を示し、さらにtype属性４０５は「recommend （推奨）」を示している。従って、constraint要素４０２ｃは、「境界部分でないセグメントにおいて、ログ取得と時刻合わせとの双方を実施することが好ましい。」という制約を表している。constraint要素４０２ａ，４０２ｂが２つのセキュリティ機能の併存を禁止したり、あるいは併存に対して注意を促すものであるのに対し、constraint要素４０２ｃは２つのセキュリティ機能の併存を推奨するものである。

constraint要素４０２ｄは、name属性において「c004」という名前が指定されている。constraint要素４０２ｄは、１つのfunction要素４０７を含んでいる。図４６の２５行目に示すfunction要素は、action属性４０８が「add 」であるので、ネットワーク型侵入検知（function.ids.network）を実施する旨の設定を表している。また、constraint要素４０２ｄのsegment要素４０９は境界部分ではないセグメントを示しており、logic 属性４０４は「multiple」を示し、さらにtype属性４０５は「prohibited（禁止）」を示している。従って、constraint要素４０２ｄは、「境界部分でないセグメントにおいて、ネットワーク型侵入検知を複数箇所で実施してはならない。」という制約を表している。

constraint要素４０２ｅは、name属性において「c005」という名前が指定されている。constraint要素４０２ｅは、２つのfunction要素４０７を含んでいる。図４６の３１行目に示すfunction要素は、action属性４０８が「add 」であるので、改竄防止を実施する旨の設定を表している。３２行目に示すfunction要素は、ウィルスチェック（function.service.virusscan）を実施する旨の設定を表している。また、constraint要素４０２ｅのsegment要素４０９は境界部分ではないセグメントを示しており、logic 属性４０４は「add 」を示し、さらにtype属性４０５は「must（必要）」を示している。従って、constraint要素４０２ｅは、「境界部分でないセグメントにおいて、改竄防止を実施する場合にはウィルスチェックも実施しなければならない。」という制約を表している。

このように、制約知識２４は、セグメントにおけるセキュリティ機能の間の制約を表している。第１の実施の形態で示した制約が「ノードとルールとの間の関係を決定している制約」であるのに対し、制約知識２４にはノードの情報は含まれない。また、policy要素の親子関係や優先順位に関する記述も含まれない。

なお、図４６は、制約知識記述の一例を示すものであり、制約知識記述は他の書式によって記述されていてもよい。ただし、以下の説明では、図４６に例示する制約知識記述が制約知識データベース２３に記憶されているものとして説明する。

機能マッピング処理手段２０は、セキュリティポリシー１およびトポロジー情報２が入力されると、セキュリティポリシー１をポリシー記述に変換し、トポロジー情報２をトポロジー記述に変換する。図４７はポリシー記述の例を示し、図４８はトポロジー記述の例を示す。図４７に例示するポリシー記述では、segment要素として「network.segment-boundary.int-dmz」を含むpolicy要素４２１ａ，４２１ｂが記述されている。また、segment要素として「network.segment.dmz」を含むpolicy要素４２１ｃ〜４２１ｅが記述されている。また、図４８に例示するトポロジー記述では、ノード４３１ａ〜４３１ｆ等のノードが記述されている。また、セグメントもトポロジー記述に記述される。

機能マッピング処理手段２０による機能マップ作成の処理経過は、図１４に示す場合と同様である。機能マッピング処理手段２０は、ステップＡ２０１〜Ａ２０３の処理の後、セグメントを選択し（ステップＡ２０４）、ノード知識ビューを作成する（ステップＡ２０５）。そして、選択したセグメントにおけるルールとノードとを、セキュリティ機能を介して対応付け、ルールと、セキュリティ機能と、ノードとの対応関係を示す情報の集合を作成する（ステップＡ２０６〜Ａ２０８）。その後、ポリシー過多、ポリシー衝突、およびポリシー過少の有無をそれぞれ判定する（ステップＡ２０９，Ａ２１１，Ａ２１３）。そして、まだ選択していないセグメントがあれば（ステップＡ２１５におけるＮｏ）、ステップＡ２０４以降の動作を繰り返す。

ポリシー過多の有無の判定（ステップＡ２０９）において、機能マッピング処理手段２０は、対応するノードを検索できなかったルールが存在する場合、ポリシー過多が生じていると判定する。この処理は、第１の実施の形態で示したステップＡ２０９の処理と同様である。

ポリシー衝突の有無の判定（ステップＡ２１１）において、機能マッピング処理手段２０は、同一のノードに対応付けられた複数のルールのsubject 要素が同一であり、かつaction 要素が異なっているときにポリシー衝突が生じていると判定する。また、１つのノードに、予め定められた特定の複数のルールが対応付けられた場合に、ポリシー衝突が生じていると判定してもよい。さらに、異なるノードにそれぞれ予め定められた特定のルールが対応付けられた場合に、ポリシー衝突が生じていると判定してもよい。以上の判定処理は、第１の実施の形態で示した判定処理と同様である。第４の実施の形態では、以上の判定処理に加えて、制約知識２４に基くポリシー衝突の有無の判定も行う。

制約知識２４に基いてポリシー衝突の有無の判定を行う場合、type属性４０５が「prohibited（禁止）」または「warning （注意）」であるconstraint要素を用いて判定を行う。

ステップＡ２０４でセグメント「network.segment-boundary.int-dmz（インターネット−ＤＭＺ境界）」が選択され、このセグメントにおいて、図４７に示すpolicy要素４２１ａ，４２１ｂがそれぞれノードと対応付けられているとする。この場合、ＤＮＡＴの実施というセキュリティ機能およびＳＮＡＴの実施というセキュリティ機能がインターネット−ＤＭＺ境界における機能マップ内に併存することになる。この状態は、constraint要素４０２ａが示す制約に従っていない。よって、この場合、機能マッピング処理手段２０は、ポリシー衝突が生じていると判定する。そして、機能マッピング処理手段２０は、同一セグメント内で設定されてはならないセキュリティ機能の設定の組み合わせ（本例では、ＤＮＡＴの実施の設定とＳＮＡＴの実施の設定との組み合わせ）が存在する旨の情報を出力装置３０に出力させる。

また、ステップＡ２０４でセグメント「network.segment.dmz （ＤＭＺ）」が選択され、そのセグメントにおいて、図４７に示すpolicy要素４２１ｃ〜４２１ｅがそれぞれノードと対応付けられているとする。この場合、改竄防止というセキュリティ機能およびログ取得というセキュリティ機能がＤＭＺにおける機能マップ内に併存することになる。この状態は、constraint要素４０２ｂが示す制約に従っていない。よって、この場合、機能マッピング処理手段２０は、ポリシー衝突が生じていると判定する。そして、同一区分内で設定されたときにシステム管理者に注意を促すべき複数のセキュリティ機能の設定の組み合わせ（本例では、改竄防止の実施の設定とログ取得の実施の設定との組み合わせ）が存在するので、機能マッピング処理手段２０は、システム管理者に注意を促す情報を出力装置３０に出力させる。

なお、機能マッピング処理手段２０は、第１の実施の形態で示したポリシー衝突の判定は行わずに、制約知識２４のみに基いてポリシー衝突の判定を行ってもよい。

ポリシー過少の有無の判定（ステップＡ２１３）において、機能マッピング処理手段２０は、どのルールとも対応付けられなかったノードが存在している場合、ポリシー過少が生じていると判定する。この判定処理は、第１の実施の形態で示した判定処理と同様である。第４の実施の形態では、この判定処理に加えて、制約知識２４に基くポリシー過少の有無の判定も行う。

制約知識２４に基いてポリシー過少の有無の判定を行う場合、type属性４０５が「recommend （推奨）」または「must（必要）」であるconstraint要素を用いて判定を行う。

ステップＡ２０４でセグメント「network.segment.dmz （ＤＭＺ）」が選択され、そのセグメントにおいて、図４７に示すpolicy要素４２１ｃ〜４２１ｅがそれぞれノードと対応付けられているとする。この場合、ログ取得というセキュリティ機能および時刻あわせというセキュリティ機能がＤＭＺにおける機能マップ内に併存することになる。この状態は、constraint要素４０２ｃが示す制約に従っている。よって、ログ取得の実施の設定と時刻あわせの実施の設定の組み合わせは、ポリシー過少に該当しない。仮に、いずれか一方の設定のみが存在している場合には、機能マッピング処理手段２０は、同一セグメント内で設定されていることが好ましいと定められる複数のセキュリティ機能の設定の組み合わせが成立していない旨の情報を出力装置３０に出力させる。

また、ＤＭＺにおける機能マップ内には、改竄防止というセキュリティ機能が含まれるが、ウィルスチェックというセキュリティ機能は含まれていない。すなわち、constraint要素４０２ｅが示す複数のセキュリティ機能の設定の一部しか存在しておらず、この状態は、constraint要素４０２ｅが示す制約に従っていない。よって、この場合、機能マッピング処理手段２０は、ポリシー過少が生じていると判定する。そして、機能マッピング処理手段２０は、同一セグメント内で設定されていなければならないセキュリティ機能の設定の組み合わせ（本例では、改竄防止の実施の設定とウィルスチェックの実施の設定の組み合わせ）が成立していない旨の情報を出力装置３０に出力させる。

第４の実施の形態では、第１の実施の形態と同様に、ルールとノードとを、セキュリティ機能を介して対応付け、その処理結果を出力装置３０から出力する。従って、どのルールがどのノードに関係していて各ノードがどのようなルールを実現しているかを用意に確認することができる。

さらに、ポリシー過多、ポリシー衝突およびポリシー過少の判定を行う。従って、入力されたトポロジー情報によって特定されるネットワークシステムではシステム管理者が策定したルールに基づくセキュリティ機能を発揮できないという指摘をすることができる。また、同一セグメント内におけるセキュリティ機能の間の制約に従っていないポリシー衝突を指摘することができる。また、同一セグメント内におけるセキュリティ機能の間の制約に従っていないポリシー過少を指摘することができる。このように、セキュリティ機能の設定の不整合や不足を指摘することができるので、管理対象システムのセキュリティの向上およびシステム管理者の負荷軽減を図ることができる。

本発明の第１の実施の形態の例を示すブロック図である。 セキュリティクラスによる表現の説明図である。 セキュリティクラスに含まれる各クラスの例を示す説明図である。 第１の実施の形態の処理経過の例を示す流れ図である。 ポリシー記述の例を示す説明図である。 セグメントの例を示す説明図である。 トポロジー記述の記述フォーマットの例を示す説明図である。 トポロジー記述の具体例を示す説明図である。 セキュリティポリシーの入力を促すためのＧＵＩの例を示す説明図である。 トポロジー情報の入力を促すためのＧＵＩの例を示す説明図である。 機能マッピング処理の概要を示す説明図である。 ノード知識の記述フォーマットの例を示す説明図である。 セキュリティ機能の継承の具体例を示す説明図である。 機能マッピング処理の処理経過の例を示す流れ図である。 inherit 要素の展開例を示す説明図である。 機能マップの例を示す説明図である。 機能マップの出力画面の例を示す説明図である。 ポリシー過多を検出した場合の出力画面の例を示す説明図である。 ポリシー衝突を検出した場合の出力画面の例を示す説明図である。 ポリシー過少を検出した場合の出力画面の例を示す説明図である。 ポリシー衝突を検出した場合の出力画面の例を示す説明図である。 再検討結果入力画面の例を示す説明図である。 ポリシー衝突解消時の出力画面の例を示す説明図である。 ポリシー過多を検出した場合の出力画面の例を示す説明図である。 再検討結果入力画面の例を示す説明図である。 ポリシー過多解消時の出力画面の例を示す説明図である。 ポリシー過少を検出した場合の出力画面の例を示す説明図である。 再検討結果入力画面の例を示す説明図である。 ポリシー過少解消時の出力画面の例を示す説明図である。 本発明の第２の実施の形態の例を示すブロック図である。 第２の実施の形態の処理経過の例を示す流れ図である。 ステップＢ３００以降の処理の概念を示す説明図である。 パラメータ取得テンプレートの具体例を示す説明図である。 ネスト構造の条件式に基づいてパラメータ値を抽出する場合の例を示す説明図である。 パラメータ値が記述されたパラメータ取得テンプレートの例を示す説明図である。 設定スクリプトテンプレートの例を示す説明図である。 設定スクリプトテンプレートにおける置換の例を示す説明図である。 設定スクリプトを表示出力する出力画面の例を示す説明図である。 設定スクリプトを生成するか否かの確認画面の例を示す説明図である。 本発明の第３の実施の形態の例を示すブロック図である。 第３の実施の形態の処理経過の例を示す流れ図である。 脆弱性情報のフォーマットの例を示す説明図である。 推奨の程度を判定する際の処理経過の例を示す流れ図である。 出力されるレポートの例を示す説明図である。 本発明の第４の実施の形態の例を示すブロック図である。 制約知識記述の例を示す説明図である。 ポリシー記述の例を示す説明図である。 トポロジー記述の例を示す説明図である。

符号の説明

１０ 入力装置
２０ 機能マッピング処理手段
２１ ノード知識データベース
２４ 制約知識データベース
３０ 出力装置
４０ 設定パラメータ取得手段
４１ パラメータ取得テンプレートデータベース
５０ 設定スクリプト生成手段
５１ 設定スクリプトテンプレートデータベース
６０ 脆弱性情報フィルタリング手段
６１ 脆弱性情報データベース

Claims (4)

1. ネットワークシステムのセキュリティに関する基準である個々のルールと、前記ネットワークシステムが有する各ハードウェアおよび前記各ハードウェアが搭載する各ソフトウェアとを対応付けるセキュリティ管理支援システムに適用される情報表示システムであって、
   各ルール、各ハードウェアおよび各ソフトウェアを表示する表示欄を有する画面の情報を記憶する画面情報記憶手段と、
   画面情報記憶手段が記憶する画面の情報を用いて、前記表示欄の中で、ハードウェアおよびソフトウェアを表示し、ハードウェアおよびソフトウェアを表示する領域の外周にルールを表示し、対応付けられたルールとハードウェアまたはソフトウェアとを結ぶ線を表示する出力画面の情報を作成する出力画面情報作成手段と、
   前記出力画面の情報に基づいて前記出力画面を出力する出力手段とを備えた
   ことを特徴とする情報表示システム。
2. 出力画面情報作成手段は、一のルールの下位階層のルールとして定められたルールを、前記一のルールの隣に並べるように表示する出力画面の情報を作成する請求項１に記載の情報表示システム。
3. 出力画面情報作成手段は、ソフトウェアと前記ソフトウェアを搭載するハードウェアとを結ぶ線を表示する出力画面の情報を作成する請求項１または請求項２に記載の情報表示システム。
4. ネットワークシステムのセキュリティに関する基準である個々のルールと、前記ネットワークシステムが有する各ハードウェアおよび前記各ハードウェアが搭載する各ソフトウェアとを対応付けるセキュリティ管理支援システムに適用される情報表示方法であって、
   画面情報記憶手段が、各ルール、各ハードウェアおよび各ソフトウェアを表示する表示欄を有する画面の情報を記憶し、
   出力画面情報作成手段が、画面情報記憶手段が記憶する画面の情報を用いて、前記表示欄の中で、ハードウェアおよびソフトウェアを表示し、ハードウェアおよびソフトウェアを表示する領域の外周にルールを表示し、対応付けられたルールとハードウェアまたはソフトウェアとを結ぶ線を表示する出力画面の情報を作成し、
   出力手段が、前記出力画面の情報に基づいて前記出力画面を出力する
   ことを特徴とする情報表示方法。

Images