JP5125069B2 - セキュリティリスク管理システム、セキュリティリスク管理方法およびセキュリティリスク管理用プログラム - Google Patents

Description

本発明は、セキュリティリスク管理システム、セキュリティリスク管理方法およびセキュリティリスク管理用プログラムに関し、特に、多数の機器からなるシステムを複数の目的に合わせてリスク管理できるセキュリティリスク管理システム、セキュリティリスク管理方法およびセキュリティリスク管理用プログラムに関する。

現在、企業内システムの多くのセキュリティ上の問題は、クライアントの脆弱性やミスユースによって生じている。例えば、ノート型パーソナルコンピュータ（以下、ノートＰＣという。）の紛失による情報漏洩や、ウイルス感染による通信障害などである。

これらのセキュリティ上の問題を解消するために、数々のセキュリティ対策手段が実用化されている。例えば、アンチウイルスツールをインストールしておけば、かなりの確率でウイルス感染を防止することができる。また、ディスク暗号化ツールによってハードディスクを暗号化しておけば、ＰＣが盗難された場合もデータの漏洩を防止することができる。また、ＵＳＢメモリの利用を禁止するツールを用いれば、ＵＳＢメモリを介したデータの漏洩を防止することができる。

しかしながら、多くの場合、セキュリティ対策を実施すると可用性（利便性）の低下をもたらす。例えば、ＵＳＢメモリの利用を禁止した場合、ＵＳＢメモリを利用して簡単にデータの受け渡すことができなくなってしまう。

このように、セキュリティ対策の手段は多岐に亘り、その効果や制約もそれぞれ異なるため、これらを一元管理する技術が求められている。

従来では、各クライアントにインストールされているソフトウェアやパッチ適用状態、アンチウイルスツールのインストール状態などを調べ、不適切な管理がなされているクライアントの台数や不適切な設定の件数などをセキュリティ管理者に通知するためのツールが製品化されている。このような、クライアントのセキュリティ管理を一元化する技術を従来技術１と呼ぶ。

また、特許文献１には、各クライアントに導入されたセキュリティプログラムによって各クライアントがセキュリティ事象を検出して管理システムに送信し、管理システムが、セキュリティ事象とそれに対する対策とを関連づける知識データベースを保持し、最適な対策をクライアントに配布する方法が開示されている。また、特許文献２には、現状分析と資産分析の入力を支援してリスク分析を行い、対策指針データベースに保存されている内容に基づいて、対策案を生成する方法が開示されている。また、特許文献３には、対策による残存リスクと所要コストが許容範囲内に収まる対策を選択するための画面を用いたセキュリティ管理方法が開示されている。このような、クライアントの現状を分析して、予め定められた対応関係または指針に基づいて対策案を生成する技術を従来技術２と呼ぶ。

また、非特許文献１では、脆弱性の大きさや脅威の発現時における損害額、それに対策する実現方式のコスト（価格）といった情報を事前に定義しておき、それらの情報を元に、低コストで最も効率よくリスクを減らせる対策目標候補集合を選定することによって、セキュリティリスクへの効果的な対策を実現する方法が提案されている。また、非特許文献２では、脅威の発生確率と、情報資産の価値と、それらの関係を事前に定義しておき、それらの情報を元に、低コストで最も効率よくリスクを減らせる対策目標候補集合を選定することによって、セキュリティリスクへの効果的な対策を実現する方法が提案されている。このような、残存リスクとコストとの関係を考慮して効果的な対策の組み合わせ（対策目標候補集合）を選定する技術を従来技術３と呼ぶ。

特開２００５−３０１５５１号公報 特開２００５−１３５２３９号公報 特開２００３−１９６４７６号公報 永井他，「機能的適合性を考慮した情報システムのセキュリティ基本設計法の提案」，情報処理学会論文誌，２００４年４月，Ｖｏｌ．４５，Ｎｏ．４ 中村他，「セキュリティ対策選定の実用的な一手法の提案とその評価」，情報処理学会論文誌，２００４年４月，Ｖｏｌ．４５，Ｎｏ．８

しかしながら、従来技術１では、ある不適切な管理がされていることによって、現実にどのようなセキュリティ上の脅威があるのかが、セキュリティ管理者にとって明確でない。例えば、いくつかの種類の脅威があった場合に、セキュリティ管理者が、どのような種類の脅威がどの程度存在しているのかを把握することが難しい。また、警告を一律に全て無くすという目標でセキュリティ管理を行っているため、クライアントの実情に応じた個別な対策を実施できないといった問題がある。また、個々のクライアントの実情によって対策を実施できない場合、そのクライアントを管理対象外として除外せざるを得ず、そのクライアントはセキュリティ管理者のセキュリティ管理下から外れてしまうという問題がある。例えば、特別なデバイスが接続されているためセキュリティ対策ツールをインストールできない、または特殊な物理環境に置かれているため一般的な対策を実施する必要がなく実施していない場合などには、常に実施できない対策を実施すべき旨の対策案が立案されてしまったり、他に重視したい対策を犠牲にした不適切な対策案が立案されてしまう。

また、従来技術２では、対策案のリストを表示するだけであり、複数の対策がとりうる場合など、どの対策を組み合わせればよいのかが分からないという問題がある。例えば、特許文献３では、対策に要するコストとリスク削減効果が一定以下になる対策案を画面から選択することができるが、対策の組み合わせは人手によって決定しなければならない。このため、対策の数が増えると作業量は多くなり、セキュリティ管理者の手に負えなくなる可能性がある。また、複数の対策が組み合わさって初めて所望の効果を発揮したり、ある対策を実施すると別の対策は意味を成さなくなるといった制約関係が存在する場合には、人手による作業はますます困難になる。また、セキュリティ対策による残存リスクと所要コストは考慮されているものの、可用性の低下については考慮されていない。なお、クライアントに対し一律に策定されたセキュリティポリシーに従って対策案を生成しているため、各クライアントの実情に応じた対策を立案することができない点は、従来技術１と同様である。

また、従来技術３では、どの対策を組み合わせればよいのか、コストを最小化するという観点で最適な対策の組み合わせを提示することができる。しかしながら、コストと可用性の低下といった複数の要件の下での最適な対策の組み合わせについては、考慮されておらず、提示することができない。また、対策間の制約を考慮した対策を立案することができない点、および個々のクライアントの実情に応じた対策を立案することができない点は、他の従来技術と同様である。

以上をまとめると、従来技術の課題は、以下のように整理できる。

第１の問題点は、各クライアントの実情に合わない対策立案がなされてしまうことである。その理由は、クライアントとして管理する端末等の用途は様々であるが、同一の指標に基づいて対策の立案を行っているからである。結果、画一的な管理から外れるクライアントは例外扱いするといった運用による対処がなされ、セキュリティ管理システムの管理対象から外れて、人手による管理に委ねられてしまうといった問題も生じてしまう。

第２の問題点は、セキュリティ対策を実施する際に生じる利便性（可用性）の低下を考慮した対策の立案がなされないことである。例えば、特許文献１，２に開示されている方法では、予め定められたセキュリティ事象とセキュリティ対策との対応関係に基づいて、発生したセキュリティ事象に対応する対策を指示するのみである。また、例えば、特許文献３や非特許文献１，２に開示されている方法では、コストを最小化するという単目的の対策立案しか行わない。

第３の問題点は、共存できない対策の組み合わせが立案されてしまう場合があることである。その理由は、対策間の排他関係といった制約について考慮されていないからである。

そこで、本発明は、クライアントのセキュリティ管理を一元化しつつ、クライアントの実情に応じたセキュリティ対策を実施できるセキュリティリスク管理システム、セキュリティリスク管理方法およびセキュリティリスク管理用プログラムを提供することを目的とする。例えば、典型的な用途のクライアントには同一のセキュリティ対策を実施し、特殊な用途のクライアントには個別のセキュリティ対策を実施できようにする。また、例外的な対策が必要なクライアントに対しても、新たな管理区分を設けることによって、管理下におくことができるようにする。

また、本発明は、セキュリティ対策を実施することによって発生するコストだけでなく、利便性（可用性）の低下など複数の要件を考慮した上で、適切な対策立案を行うことができるようにすることを目的とする。さらに、本発明は、セキュリティ対策間の排他関係などの制約をも考慮し、現実に取りうる対策の組み合わせにおいて、適切な対策立案を行うことができるようにすることを目的とする。

また、本発明は、セキュリティ脅威の種類別に、リスクの高いクライアントを容易に発見できるようにすることを目的とする。

また、本発明は、立案された対策をクライアントで実施する際に、できるだけセキュリティ管理者の工数を割くことなく、各クライアントで実施できるようにすることを目的とする。

また、本発明は、セキュリティ管理者が、どのような残留リスクがどの程度存在することになるのかを認識した上で、対策案を選定する基準となるセキュリティ管理指針を設定することができるようにすることを目的とする。さらに、本発明は、セキュリティ管理者が、クライアントの実情に応じてどの脅威を重くみるかといった脅威の種類別のセキュリティ管理指針を設定することができるようにすることを目的とする。

本発明によるセキュリティリスク管理システムは、クライアントシステムにおけるセキュリティリスクを管理するセキュリティリスク管理システムであって、リスク管理の対象となるクライアントシステムの状態を示す情報と資産価値を示す情報とを格納する状態格納手段（例えば、状態格納手段１０２）と、各クライアントシステムの用途に応じてどのような管理区分が存在するかを定義するとともに各クライアントシステムがどの管理区分に分別されるかを定義した管理区分ポリシー（例えば、管理区分ポリシー１０６）と、クライアントシステムの状態とに基づいて、各クライアントシステムの管理区分を判別する管理区分判別手段と、対策実施に伴う１つ以上のセキュリティ要件として、少なくともセキュリティ対策を実施する際に許容する脆弱性の大きさと、可用性低下の大きさとを示す情報を含む情報を管理区分毎に定義した対策ポリシー（例えば、対策ポリシー１０７）と、少なくともクライアントシステムの状態から導出される各脅威およびその関連性に基づいてそのクライアントシステムに現在どれだけのセキュリティリスクが存在するのかを算出するためのモデル式を定義したリスクモデルであって少なくとも対策を実施することによって低減する脆弱性の大きさと、対策を実施することによって増大する可用性低下の大きさとを算出するための計算式を含むリスクモデル（例えば、リスクモデル１０９）とに基づいて、管理区分毎の対策案を生成する対策案生成手段（例えば、対策案生成手段１０４）と、状態格納手段に格納されている情報で示される各クライアントシステムの対策実施有無とリスクモデルとから、各クライアントシステムの現在のセキュリティリスクの度合いを示すリスク値を算出するリスク評価手段（例えば、リスク評価手段１１１）と、対策ポリシーおよびリスクモデルに含まれるセキュリティ対策間の関係を表す論理制約式を、前記対策案生成手段で扱える形式に変換する論理制約変換手段（例えば、論理制約変換手段１１２）とを備え、論理制約変換手段は、論理制約式を線形制約式の集合に変換し、対策案生成手段は、論理制約変換手段によって変換された線形制約式の集合を加えた上で、対策ポリシーで示されるセキュリティ要件を目標値として、管理区分毎に、各目標値に対して最もよく満たすこととなる各対策実施有無を示す２値変数の組み合わせを、基準点法を用いて、多目的最適化問題を解くことによって求め、求めた２値変数の組み合わせで示される対策実施有無の組み合わせを対策案とすることを特徴とする。

また、セキュリティリスク管理システムは、クライアントシステムの状態を示す情報として、少なくとも該クライアントシステムにおけるセキュリティ対策の実施有無を示す対策実施情報と、管理区分を判別するために必要な該クライアントシステムの構成情報とを収集し、状態格納手段に格納させる状態収集手段（例えば、状態収集手段１２１）と、クライアントシステムの資産価値を判定し、状態格納手段に格納させる資産情報収集手段（例えば、資産情報収集手段１２２）とを備えていてもよい。

また、対策案生成手段は、脅威の種類別に対策実施に伴う１つ以上のセキュリティ要件を管理区分毎に定義した対策ポリシーと、クライアントシステムの状態から導出される各脅威およびその関連性に基づいてそのクライアントシステムに現在どれだけのセキュリティリスクが存在するのかを脅威の種類別に算出するためのモデル式を定義したリスクモデルとに基づいて、管理区分毎の対策案を生成し、リスク評価手段は、状態格納手段に格納されている情報で示される各クライアントシステムの対策実施有無とリスクモデルとから、各クライアントシステムの現在のセキュリティリスクの度合いを示すリスク値を脅威の種類別に算出してもよい。

また、セキュリティリスク管理システムは、クライアントシステムのセキュリティリスクに関する情報として、少なくともリスク評価手段によって算出されるリスク値を表示するとともに、リスク値が所定の閾値よりも高いクライアントシステムの情報を強調表示する表示手段（例えば、表示手段１１０）を備えていてもよい。

また、セキュリティリスク管理システム対策案生成手段によって生成された対策案を、クライアントシステム上で自動で実施する、またはクライアントシステムのユーザに対し、実施することを喚起する対策実施手段（例えば、対策実施手段１２３）を備えていてもよい。

また、セキュリティリスク管理システムは、管理区分ポリシーおよび対策ポリシーの設定内容を変更または追加するための画面を表示することによって、ユーザに対して管理区分ポリシーおよび対策ポリシーを編集させるポリシー編集手段（例えば、ポリシー編集手段１１３）を備えていてもよい。

また、ポリシー編集手段は、対策が実施されることによって脅威の種類別にどの程度リスク値が低減するかを表示する領域と、脅威の種類別に許容できるリスク値を設定するための領域とを含む画面を表示してもよい。

また、対策ポリシーは、少なくともセキュリティ対策を実施する際に許容する脆弱性の大きさと、コストの大きさと、可用性低下の大きさとを示す情報を含み、リスクモデルは、少なくとも対策を実施することによって低減する脆弱性の大きさと、対策を実施することによって増大する可用性低下の大きさおよびコストの大きさとを算出するための計算式を含んでいてもよい。

本発明は、各クライアントシステムの管理区分を判別する管理区分判別手段と、管理区分毎にセキュリティ要件を定義した対策ポリシーとセキュリティリスクの大きさを算出するためのモデル式を定義したリスクモデルとに基づいて管理区分毎の対策案を生成する対策案生成手段と、各クライアントシステムの対策実施有無とリスクモデルとから、各クライアントシステムの現在のセキュリティリスクの度合いを示すリスク値を算出するリスク評価手段とを備えているので、クライアントシステムの実情に応じた管理区分を設定することによって、管理区分毎に、対策ポリシーに基づく対策案を生成することができる。従って、クライアントのセキュリティ管理を一元化しつつ、クライアントの実情に応じたセキュリティ対策を実施できる。

また、本発明によれば、１つ以上のセキュリティ要件を定義した対策ポリシーに基づいて、対策案を生成するので、セキュリティ対策を実施することによって発生するコストだけでなく、利便性（可用性）の低下など複数の要件を考慮した上で、適切な対策立案を行うことができる。

実施の形態１．
以下、本発明の第１の実施の形態を図面を参照して説明する。図１は、第１の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。図１に示すセキュリティリスク管理システムは、マネージャシステム１００と、複数のクライアントシステム１２０とを備える。マネージャシステム１００とクライアントシステム１２０とは、例えば、インターネット等の通信ネットワークを介して接続される。なお、マネージャシステム１００とクライアントシステム１２０とは、例えば、無線通信ネットワークを介して接続されていてもよい。

マネージャシステム１００は、具体的には、ワークステーションやパーソナルコンピュータ等の、プログラムに従って動作する情報処理装置（中央処理装置，プロセッサ，データ処理装置等）を備えたコンピュータシステムによって実現される。なお、マネージャシステム１００は、少なくとも、入力装置と表示装置（以下、合わせて入出力装置１０１と呼ぶ）とを備えたコンピュータシステムによって実現されるものとする。また、クライアントシステム１２０は、具体的には、パーソナルコンピュータ等の、プログラムに従って動作する情報処理装置を備えたコンピュータシステムによって実現される。なお、クライアントシステム１２０は、パーソナルコンピュータ装置に限らず、例えば、特殊な機器を接続した情報処理装置やサーバ装置、データベースシステムなどのコンピュータシステムであってもよい。

クライアントシステム１２０は、状態収集手段１２１と、資産情報収集手段１２２とを備える。

状態収集手段１２１は、そのクライアントシステム１２０（その状態収集手段１２１を備えるクライアントシステム１２０）の現在の状態を判別して、その情報をクライアントシステム１２０の状態を示す情報としてマネージャシステム１００に送信する。状態収集手段１２１は、例えば、そのクライアントシステム１２０のソフトウェアのインストール状態や、レジストリや設定ファイルの内容からセキュリティ対策の実施有無を判定し、その情報をマネージャシステム１００に送信して、状態格納手段１０２に格納させる。また、状態収集手段１２１は、例えば、そのクライアントシステム１２０のソフトウェアのインストール状態や、レジストリや設定ファイルの内容からクライアントシステム１２０の構成（接続されているデバイスやインストールされているＯＳ，ソフトウェアなど）を判定し、その情報をマネージャシステム１００に送信して、状態格納手段１０２に格納させてもよい。

例えば「ディスク暗号化」「アンチウイルス」という対策がなされているかどうかは、ディスク暗号化ツールやアンチウイルスツールがインストールされているかどうかで判断できる。また、例えば「認証強化」という対策がなされているかどうかは、ＯＳが短いパスワードや簡単なパスワードを許可しないような設定になっているかどうかで判断できる。また「ＵＳＢメモリ登録制」「ＵＳＢメモリ使用禁止」という探索がなされているかどうかは、ＵＳＢメモリによるデータの持ち出しを制御する持ち出し制御ツールがインストールされているか、そしてそのツールの設定がどのようになっているかによって判断できる。

また、状態収集手段１２１は、セキュリティ対策の実施状態をユーザに入力させるための入力画面を有していてもよい。入力画面は、例えば、セキュリティ対策の各項目を表示するとともに、その対策有無をチェックさせるチェック欄を含む画面である。なお、構成を入力するための入力項目を含んでいてもよい。状態収集手段１２１は、例えば、定期的に、クライアントシステム１２０上のプログラムでは自動的に収集することができない対策の有無についてのチェック欄を含む入力画面を表示し、ユーザ操作によるチェック欄の入力に従って判別してもよい。そのようにすると、クライアントシステム１２０上のプログラムでは自動的に収集することができない情報、例えば、そのクライアントシステム１２０がセキュリティワイヤで固定されているか否かといった情報について、そのクライアントシステム１２０のユーザが自己申告で設定する、といった運用が可能となる。

資産情報収集手段１２２は、そのクライアントシステム１２０の資産価値を算出して、その情報をクライアントシステム１２０の資産価値を示す情報としてマネージャシステム１００に送信する。資産情報収集手段１２２は、セキュリティ要件、すなわち機密性・完全性・可用性が失われた場合にどれだけの被害が発生するかを算出する手段である。

例えば、機密性に関する資産価値（以下、機密度と呼ぶ。）を算出する具体的な方法としては、クライアントシステム１２０内の文書ファイルの総数をカウントすることによってそのクライアントシステム１２０における機密度を概算する処理によって実現してもよい。具体的には、文書ファイルの内容を検査し、文書のヘッダ・本文・フッタ等の部分領域に分割し、部分領域毎に予め定めておいた特徴定義辞書に基づき人名や住所などの特徴要素を抽出する。そして、その特徴用をの配置状況を評価し、部分領域がどのような機密度に属するのかを判定してもよい。なお、上記で示したファイルの内容を検査して機密度を判定する方法は、例えば、文献「特開２００６−２０９６４９号公報」に記載されている。また、完全性に関する資産価値（以下、完全性価値と呼ぶ。）を算出する具体的な方法としては、そのクライアントシステム１２０にデータベース管理システムがインストールされていれば完全性価値が高く、そうでなければ低くなるように算出すればよい。可用性に関する資産価値（以下、可用性価値と呼ぶ。）を算出する手段の具体的な方法としては、そのクライアントシステム１２０の稼働時間（２４時間稼働しているか、毎日電源が投入されているか等）や、重要なサーバソフトウェアが実行されているか、といったことに基づいて算出すればよい。なお、この場合には、稼働時間が多い方が可用性価値が高く、また、重要なサーバソフトウェアが実行されている方が可用性価値が高くなるように算出する。

状態収集手段１２１、資産情報収集手段１２２は、具体的には、クライアントシステム１２０が備えるＣＰＵ等のプログラムに従って動作するデータ処理装置によって実現される。なお、状態収集手段１２１、資産情報収集手段１２２は、各クライアントシステム１２０がプログラムをインストールする等して、管理対象とするクライアントシステム１２０それぞれに備えられているものとする。

マネージャシステム１００は、状態格納手段１０２と、管理区分判定手段１０３と、対策案生成手段１０４と、ポリシー格納手段１０５と、リスクモデル格納手段１０８と、表示手段１１０と、リスク評価手段１１１とを備える。

状態格納手段１０２は、管理対象である各クライアントシステム１２０の状態を示す情報（対策実施の有無や構成その他の状態を示す情報）と、資産価値を示す情報とを格納（記憶）する。また、状態格納手段１０２は、各クライアントシステム１２０について、管理区分判定手段１０３で判定される管理区分を示す情報や、対策案生成手段１０４によって生成される対策案を示す情報を格納する。

ポリシー格納手段１０５は、管理区分ポリシー１０６と、対策ポリシー１０７とを格納する。ここで、管理区分とは、セキュリティ要件別にクライアントシステム１２０を分類する区分のことをいう。例えば、管理区分として、「オフィス用」「業務用」「持ち出し用」の３つの区分が考えられる。例えば、「オフィス用」には、オフィス内でメールや文書作成などを行うための、いわゆるオフィス業務に用いるクライアントシステム１２０を分類する。また、「業務用」には、経理システムや在庫管理システムのような業務システムと連動するクライアントシステム１２０を分類する。また、「持ち出し用」には、出張や外出時に社外に持ち出すクライアントシステム１２０を分類する。

このような分類において、「オフィス用」に分類されたクライアントシステム１２０は、屋外に持ち出されることがないので、クライアントシステム１２０本体の紛失による情報漏洩はあまり考慮しなくてもよい。その代わり、文書作成時に様々なアプリケーションを使用することを見越して、例えば、ユーザが新しいソフトウェアをインストールできるようにするなど、可用性を重視した運用が望まれる。一方「業務用」に分類されたクライアントシステム１２０は、より重要な情報を扱うのでセキュリティレベルを上げる必要がある。その代わり、定型的な使われ方しかされないので、可用性はあまり考慮しなくてもよい。また、「持ち出し用」に分類されたクライアントシステム１２０は、紛失による情報漏洩を十分に考慮する必要がある。このように、管理区分とは、クライアントシステム１２０の用途やその置かれている状況などに応じて、クライアントシステム１２０のセキュリティ要件を分けるために定義される区分を言う。

管理区分ポリシー１０６とは、どのような管理区分が存在するかを定義するとともに、各クライアントシステム１２０がどの管理区分に分別されるかを示す分別手順や対応関係を定義したもの（情報）である。図２は、管理区分ポリシー１０６として登録される情報の例を示す説明図である。管理区分ポリシー１０６は、例えば、図２に示すようなクライアントシステム１２０の状態や構成から管理区分を判定するスクリプトプログラムとして与えることも可能である。図２に示す管理区分ポリシー１０６によると、ノートＰＣと判定されたクライアントシステム１２０は「持ち出し用」、業務アプリケーションがインストールされているクライアントシステム１２０は「業務用」、それ以外のクライアントシステム１２０は「オフィス用」と判定される。なお、管理区分ポリシー１０６は、各クライアントシステム１２０を識別するためのＩＤと管理区分とを対応づけて記憶させた対応表として与えられてもよい。

管理区分判定手段１０３は、ポリシー格納手段１０５に格納される管理区分ポリシー１０６に格納されている管理区分ポリシー１０６に基づいて、各クライアントシステム１２０の管理区分を判定し、状態格納手段１０２にその結果を格納する。

対策ポリシー１０７とは、クライアントシステム１２０の管理区分に応じた対策案を生成（選定）するための制約条件を示す情報である。具体的には、管理区分ポリシー１０６によって定義された管理区分毎に、その管理区分に分類されるクライアントシステム１２０に対し許容する脆弱性の大きさや対策に伴うコストの大きさ、対策に伴う可用性低下の大きさ（すなわち、対策を立案する際に必要とするセキュリティ要件）を定義したもの（情報）である。なお、対策ポリシー１０７は、脆弱性の大きさや対策に伴うコストの大きさ、対策に伴う可用性低下の大きさといった３つの許容値に限らず、セキュリティ対策の善し悪しを評価する他の基準、例えば「対策の実施のしやすさ」や「対策に要する時間」といった基準の許容値を含んでいてもよい。

図３は、対策ポリシー１０７として登録される情報の例を示す説明図である。対策ポリシー１０７は、例えば、図３に示すような表として与えることも可能である。図３に示す例では、各管理区分に対し、残存リスクとコストと可用性低下の各許容値とを対応づけて記憶している。ここでは、各許容値は、０〜１０までの数値で表され、１０が最も許容度が大きく、０が最も許容度が小さいものとする。図３では、例えば「業務用」クライアントシステム１２０の許容値として、許容リスク＝１，許容コスト＝８，許容可用性低下＝１０が登録されている。また、例えば「持ち出し用」クライアントシステム１２０の許容値として、許容リスク＝２，許容コスト＝８，許容可用性低下＝４が登録されている。また、例えば「オフィス用」クライアントシステム１２０の許容値として、許容リスク＝３，許容コスト＝３，許容可用性低下＝２が登録されている。

この例では、「業務用」クライアントシステム１２０に対しては、可用性低下の許容値よりも残存リスクの許容値を大幅に小さくするとともに、コストの許容性を大きく設定することによって、利便性よりもセキュリティを大幅に優先させ、かつ、コスト上昇を大きく許容させることで、セキュリティ最優先の対策ポリシーを設定している。一方「オフィス用」クライアントシステム１２０に対しては、可用性低下と残存リスクとコストとをほぼ同等の許容値で設定することにより、コストがかかりすぎたり、業務効率が落ちたりすることをさけつつ、セキュリティを確保するバランス重視の対策ポリシーを設定している。また、「持ち出し用」クライアントシステム１２０に対しては、コストの許容値を大きく設定した上で、可用性とセキュリティとを両立させる対策ポリシーを設定している。

このように、対策ポリシー１０７には、クライアントシステム１２０の管理区分（すなわち用途）に応じたセキュリティ管理指針（すなわち、対策案を選定するための制約条件）が設定される。

リスクモデル格納手段１０８は、リスクモデル１０９を格納する。リスクモデル１０９とは、クライアントシステム１２０の状態から導出される各脅威、およびその関連性に基づいて、クライアントシステム１２０に現在どれだけのセキュリティリスクが存在するかを算出するためのモデル（情報）である。本実施の形態においては、リスクモデル１０９は、様々なセキュリティ対策の効果やコスト、利便性に精通した専門家によって予め作成される、少なくとも脆弱性の大きさ、コストの大きさ、可用性低下の大きさを算出するための計算式を含むモデルである。

なお、以降の説明を簡単にするため、機密性に関するリスク管理を例として説明する。本実施の形態において、（リスクの大きさ）＝（資産価値の大きさ）×（脆弱性の大きさ）の式でリスクの大きさを表す。脆弱性の大きさは、０〜１０までの相対値であり、０は想定しうる対策を全て実施した脆弱性が最も小さい場合を表し、１０は想定しうる対策を全く実施していない脆弱性が最も大きい場合を表す。つまり、（脆弱性の大きさ）＝１０−（対策による効果の大きさ）の式で示すように、対策による効果の大きさの補数で表す。

また、可用性低下およびコストの大きさは、対策による制約の大きさで表す。可用性低下およびコストの大きさは、０〜１０までの相対値であり、０は想定しうる対策を全て実施しない可用性低下・コストが最も小さい場合を表し、１０は想定しうる対策を全て実施した可用性低下・コストが最も大きい場合を表す。

図４は、リスクモデル１０９の例を示す説明図である。図４に示す例では、情報漏洩をもたらす４つの脅威に対して、５つの対策がある場合における脆弱性の大きさ・コストの大きさ・可用性低下の大きさを算出する計算式が示されている。ここで、４つの脅威とは、１：「ノートＰＣ紛失」，２：「なりすましユーザ」，３：「ウイルス感染」，４：「ＵＳＢメモリ紛失」である。また、５つの対策とは、１：「ディスク暗号化」，２：「認証強化」，３：「アンチウイルスツールの導入」，４：「ＵＳＢメモリの登録制」，５：「ＵＳＢメモリの使用禁止」である。

図４に示すリスクモデル１０９では、対策実施状態に基づいて、それぞれの対策がなされている場合は１、そうでない場合は０となる２値変数ｘ_１，ｘ_２，ｘ_３，ｘ_４，ｘ_５と、構成情報に基づいて、ノートＰＣである場合は１、そうでない場合は０となる２値変数ｘ_６とを用いて、脆弱性の大きさ・コストの大きさ・可用性低下の大きさを算出する。なお、関数の値域はいずれも０から１０までの整数値である。また、式中のｍａｘ（ｘ，ｙ）という式は、ｘとｙのうち大きい方の値をとる関数を表す。

図４に示す例では、脆弱性の大きさを求めるための計算式は、以下の式４０１として示されている。

（脆弱性の大きさ）＝１０−（４（１−ｘ_６＋ｘ_１ｘ_６）＋ｘ_２＋２ｘ_３＋３ｍａｘ（０．４ｘ_４，ｘ_５）） ・・・式４０１

式４０１は、次のようなセキュリティ対策に関する知識に基づいて記述されたものである。
（１）ノートＰＣであるならば、ディスク暗号化をしないと紛失による機密情報の漏洩を帽子できない。
（２）パスワードなしのログオンのような弱い認証を用いていると、なりすましユーザによって機密情報が盗まれる可能性がある。
（３）機密情報を第三者に送信するような機能を持つウイルスに感染すると、機密情報の漏洩を生じる。
（４）ＵＳＢメモリの登録制か、ＵＳＢメモリの使用禁止を実施しないと、ＵＳＢメモリの紛失による漏洩を防止できない。ただし、ＵＳＢメモリの登録制による漏洩防止効果は、ＵＳＢメモリの使用禁止による漏洩防止効果と比較して４割程度の効果しかない。
（５）ノートＰＣ紛失による漏洩、なりすましユーザによる漏洩、ウイルス感染による漏洩、ＵＳＢメモリ紛失による漏洩の発生頻度は、４対１対２対３程度である。

なお、上記の内容は、説明を簡単にするために簡略化したものであり、全ての条件を列挙したものではなく、また数値も必ずしも現実的な値とは限らない。

ここで、上記（１）の内容に基づいて、「ディスク暗号化」（対策１）による漏洩防止効果は、１−ｘ_６＋ｘ_１ｘ_６と表される。また、上記（４）の内容に基づいて、「ＵＳＢメモリ登録制」（対策４）と「ＵＳＢメモリの使用禁止」（対策５）とによる漏洩防止効果は、ｍａｘ（０．４ｘ_４，ｘ_５）と表される。また、上記（５）の内容に基づいて、全ての対策による漏洩防止効果は、効果の最大値を１０とすると、４（１−ｘ_６＋ｘ_１ｘ_６）＋ｘ_２＋２ｘ_３＋３ｍａｘ（０．４ｘ_４，ｘ_５）と表すことができる。そして、脆弱性の大きさは、効果の補数なので、結果、式４０１となる。

また、例えば、コストの大きさおよび可用性低下の大きさを求めるための計算式は、図４において以下の式４０２，式４０３で示されている。

（コストの大きさ）＝５ｘ_１＋ｘ_３＋ｘ_４＋２ｘ_５ ・・・式４０２
（可用性低下の大きさ）＝２ｘ_２＋２ｘ_４＋６ｘ_５ ・・・式４０３

式４０２，式４０３は、次のようなセキュリティ対策に関する知識に基づいて記述されたものである。
（６）ディスク暗号化ツールの購入・運用費用と、ウイルス対策ツールの購入・運用費用と、ＵＳＢメモリ登録ツールの購入・運用費用と、ＵＳＢメモリ利用禁止ツールの購入・運用費用の比は、５対１対１対２程度であり、その他の対策は、購入・運用費用はかからない。
（７）認証強化と、ＵＳＢメモリ登録制と、ＵＳＢメモリ使用禁止とによって、ユーザが被る利便性の低下の比は、２対２対６程度であり、その他の対策は利便性の低下をもたらさない。

なお、上記の内容も、説明を簡単にするために簡略化したものであり、全ての条件を列挙したものではなく、また数値も必ずしも現実的な値とは限らない。

ここで、上記（６）の内容に基づいて、「ディスク暗号化」（対策１）と、「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリ登録制」（対策４）と、「ＵＳＢメモリの使用禁止」（対策５）とによる可用性低下の大きさは、５ｘ_１＋ｘ_３＋ｘ_４＋２ｘ_５と表され、結果、式４０２となる。また、上記（７）の内容に基づいて、「認証強化」（対策２）と、「ＵＳＢメモリ登録制」（対策４）と、「ＵＳＢメモリの使用禁止」（対策５）とによるコストの大きさは、２ｘ_２＋２ｘ_４＋６ｘ_５と表され、結果、式４０３となる。

リスク評価手段１１１は、状態格納手段１０２に格納されている現在の各クライアントシステム１２０の状態（セキュリティ対策実施状態や構成）を、リスクモデル１０９で示される脆弱性の大きさを求めるための関数（例えば、式４０１）に代入して得られた結果と、各クライアントシステム１２０の資産価値の大きさとを乗じて得られる各クライアントシステム１２０のリスク値を計算し、状態格納手段１０２に格納する。

対策案生成手段１０４は、リスクモデル格納手段１０８に格納されるリスクモデル１０９に基づいて、現在のリスク値に対してとりうる対策であって、ポリシー格納手段１０５に格納される対策ポリシー１０７で示される管理区分毎の制約条件を同時に最もよく満たす対策案（複数の対策の組み合わせを含む）を立案する。

表示手段１１０は、対策案生成手段１０４によって生成される対策案を含む、各クライアントシステム１２０のセキュリティリスクに関する情報を表示する。表示手段１１０は、例えば、クライアントシステム１２０の管理区分、資産価値、現在のリスク値、対策の実施状態、実施すべき対策を、一覧表示してもよい。

状態格納手段１０２、ポリシー格納手段１０５、リスクモデル格納手段１０８は、具体的には、マネージャシステム１００が備える記憶装置によって実現される。また、管理区分判定手段１０３、対策案生成手段１０４、表示手段１１０、リスク評価手段１１１は、具体的には、マネージャシステム１００が備えるＣＰＵ等のプログラムに従って動作するデータ処理装置によって実現される。

次に、図５を参照して、本実施の形態によるセキュリティリスク管理システムの動作について説明する。図５は、第１の実施の形態によるセキュリティリスク管理システムの動作例を示すフローチャートである。図５に示すように、まず、管理対象の各クライアントシステム１２０からそれぞれのクライアントシステム１２０の状態収集手段１２１および資産情報収集手段１２２によって収集されたデータ（状態や資産価値）が、マネージャシステム１００の状態格納手段１０２に格納される（ステップＳ５０１）。例えば、クライアントシステム１２０は、ＳＮＭＰのＴＲＡＰ機能を利用してもよい。すなわち、状態格納手段１０２に、予め各クライアントシステム１２０毎に所定の記憶領域を割り当てておき、クライアントシステム１２０の状態収集手段１２１および資産情報収集手段１２２が所定のタイミングや状態変化を認識した場合に、状態格納手段１０２の自クライアントシステム１２０に割り当てられた所定の記憶領域に、自クライアントシステム１２０の状態および資産価値を示す情報を記憶させてもよい。なお、マネージャシステム１００がポーリング形式でクライアントシステム１２０の状態収集手段１２１および資産情報収集手段１２２に問い合わせてもよい。状態収集手段１２１および資産情報収集手段１２２は、マネージャシステム１００からの問い合わせに応じて、自クライアントシステム１２０の状態および資産価値を示す情報を送信する。そして、マネージャシステム１００がクライアントシステム１２０から問い合わせの応答として受信した情報を状態格納手段１０２に記憶させればよい。

図６は、状態格納手段１０２に格納される情報の例を示す説明図である。図６は、５つのクライアントシステム１２０を管理対象とした場合の例である。図６に示す例では、上述した５つの対策が実施されているか否かを示す情報（対策実施状態６０１）が状態収集手段１２１によって収集され、格納されている。また、それぞれのクライアントシステム１２０がノートＰＣであるか否か、また乗務用アプリケーション（図中では業務ＡＰと記す。）がインストールされているか否かを示す情報（構成情報などその他の状態６０２）も合わせて状態収集手段１２１によって収集され、格納されている。また、それぞれのクライアントシステム１２０の機密性に関する資産価値（機密度６０３）が資産情報収集手段１２２によって収集され、格納されている。なお、図６に示す例では、各クライアントシステム１２０を識別するためのＩＤ（ＰＣ１〜５）と対応づけて、各クライアントシステム１２０のデータが格納されている。具体的には、対策実施状態を示す情報６０１と、構成やその他の状態を示す情報６０２と、資産価値を示す情報６０３とを記憶してもよい。

例えば、図６では、クライアントシステム１２０「ＰＣ１」における現在の対策実施状態として、「ディスク暗号化」（対策１）と、「認証強化」（対策２）と「ＵＳＢメモリの使用禁止」（対策５）とが実施されていないこと、および「アンチウイルスツールの導入」（対策３）と「ＵＳＢメモリ登録制」（対策４）とが実施されていることが示されている。また、クライアントシステム１２０「ＰＣ１」における構成その他の状態として、ノートＰＣではないこと、および業務用アプリケーション（業務ＡＰ）がインストールされていることが示されている。また、クライアントシステム１２０「ＰＣ１」における機密度が９であることが示されている。

次に、マネージャシステム１００の管理区分判定手段１０３は、それぞれのクライアントシステム１２０の管理区分を判定する（ステップＳ５０２）。管理区分判定手段１０３は、状態格納手段１０２に格納されている各クライアントシステム１２０のデータから、管理区分ポリシー１０６で示される対応関係または判定方法に基づいて、各クライアントシステム１２０に、所定の管理区分を割り振る。なお、本実施の形態では、管理区分ポリシー１０６および対策ポリシー１０７は事前に与えられ、ポリシー格納手段１０５に格納されているものとする。管理区分判定手段１０３は、例えば、状態格納手段１０２に格納される各クライアントシステム１２０の状態を示す情報を引数として、管理区分ポリシー１０６として与えられるスクリプトファイルを実行することによって、所定の分別方法に従って、現在のクライアントシステム１２０の状態から判定される管理区分を割り振ればよい。または、管理区分ポリシー１０６がクライアントシステム１２０の各状態と管理区分を対応づけた対応関係を示す情報として与えられる場合には、その対応関係に従って、現在の各クライアントシステム１２０の各状態と対応づけられた管理区分を割り振ればよい。

次に、リスク評価手段１１１は、各クライアントシステム１２０における現在のセキュリティリスクの大きさを評価する（ステップＳ５０３）。リスク評価手段１１１は、例えば、各クライアントシステム１２０について、状態格納手段１０２に格納されている現在のクライアントシステム１２０の状態（対策実施状態６０１）を、リスクモデル１０９として示される脆弱性の大きさを求めるための関数（式４０１）に代入して得られた結果と、そのクライアントシステム１２０の機密性の関する資産価値の大きさの値（機密度６０３）とを乗じて１０で割ることによって、そのクライアントシステム１２０のリスク値を算出し、状態格納手段１０２に格納する。

次に、対策案生成手段１０４は、リスクモデル１０９で示される対策と効果（または制約）との関係性に基づいて、現在の各クライアントシステム１２０に対しとりうる対策であって、対策ポリシー１０７によって管理区分毎に示される制約条件を最もよく満たす対策の組み合わせを対策案として生成する（ステップＳ５０４）。

対策案生成手段１０４は、例えば、多目的整数計画法を用いて、リスクモデル１０９として示される関数式によって求まる脆弱性の大きさ，コストの大きさ，可用性低下の大きさが、対策ポリシー１０７として示される各目標値（制約条件）に対して最もよく満たすこととなる２値変数の組み合わせを見つけることによって実現することができる。具体的には、公知の基準点法を用いることができる。基準点法とは、多目的最適化問題”ｍｉｎｉｍｉｚｅ ｆ_ｉ（ｘ_１，・・・，ｘ_ｎ）”（０＜ｉ＜ｍ）が与えられたとき、各目的関数ｆ_ｉ毎に、目標値（基準点）となる定数値Ｃ_ｉを与えることによって、その目標値をどの目的関数ｆ_ｉも可能な限り下回るような最適解を算出する手法である。目標とのずれ” ｆ_ｉ（ｘ_１，・・・，ｘ_ｎ）−Ｃ_ｉ”の最大値が全ての目的関数で最小となるようにする、つまり、” ｍｉｎｉｍｉｚｅ ｍａｘ（ｆ_１（ｘ_１，・・・，ｘ_ｎ）−Ｃ_ｉ，・・・，ｆ_ｍ（ｘ_１，・・・，ｘ_ｎ）−Ｃ_ｍ”で表される単一目的の最適化問題を解くことによって最適解を得る手法である。なお、上記に示した基準点法は、例えば、文献「坂和正敏、”離散システムの最適化”、森北出版、２０００年、ｐｐ．１５０」に記載されている。

図７は、基準点法を用いて対策案を生成する動作の具体例を示すフローチャートである。ステップＳ５０４における動作は、図７に示すように、対策案生成手段１０４は、まず、リスクモデル１０９に含まれる非線形項（式４０１においては”ｘ_１ｘ_６”と”ｍａｘ（０．４ｘ_４，ｘ_５）”の２つの項）を線形化する（ステップＳ７０１）。線形化の手法では、例えば、”ｍａｘ（ｘ，ｙ）”という項の場合、”ｍａｘ（ｘ，ｙ）＝ｚ”と置き換え、”ｚ≧ｘ，ｚ≧ｙ，ｚ≦ｘ＋δＭ，ｚ≦ｙ＋（１−δ）Ｍ”という制約条件を加えれば、”ｚ”という１次の項に変換することができる。ここで、”Ｍ”はｘの最大値とｙの最大値よりも大きな値とする。また、例えば、”ｚｙ”という項の場合には、”ｚｙ＝ｚ”と置き換え、”ｘ＋ｙ−ｚ≦１，ｘ−ｚ≧０，ｙ−ｚ≧０”という制約条件を加えれば、”ｚ”という１次の項に変換することができる。対策案生成手段１０４は、論理条件を表すための０か１かを定義域に持つ変数を新たに導入し、それに付随する制約式を追加することによって、”ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ〜”といった条件（「ｉｆ ｔｈｅｎ式」ともいう。）で表される非線形式を線形式に変形する。ここで、”ｍａｘ（ｘ，ｙ）”は、”ｉｆ（ｘ≧ｙ） ｔｈｅｎ ｘ ｅｌｓｅ ｙ”というように「ｉｆ ｔｈｅｎ式」で表されるので、線形化することができる。なお、上記に示した線形化の手法は、文献「Ｈ．Ｐ．ウイリアムズ、”数理計画モデルの作成法”、産業図書、１９９５年」に記載されている。つまり、図８に示すように、新しい制約式と新しい変数を導入することによって、リスクモデル１０９のリスク演算式（ここでは、脆弱性の大きさ・コストの大きさ・可用性低下の大きさを求めるための関数）を線形式に変換する。図８は、対策案生成の一手法である線形化および目標関数作成の例を示す説明図である。

次に、対策案生成手段１０４は、リスクモデル１０９に基づいて、対策ポリシーを基準点とするミニマックス問題を作成する（ステップＳ７０２）。すなわち、図８に示すように、対策ポリシーとして示される各目標値と実際の値との差の最大値を最小にするような目標関数を持つ数理計画問題を作成する。ここで、目標値と実際の値とは、具体的には、（対策実施後の脆弱性の大きさ）−（許容する脆弱性の大きさ）と、（対策実施後のコストの大きさ）−（許容するコストの大きさ）と、（対策実施後の可用性低下の大きさ）−（許容する可溶性低下の大きさ）とする。

ここで、最大値を最小にするタイプの数理計画問題は、１つの変数を最小化する線形計画問題に変換できることが知られているので、その変換を施すと、図８に示すように、線形混合整数計画問題に帰着（変換）することができる。そして、対策案生成手段１０４は、このように作成される線形混合整数計画問題に対し、公知の解法を適用することにより、最適なｘ_１，ｘ_２，ｘ_３，ｘ_４，ｘ_５（対策１〜５の実施有無を示す２値変数）の組み合わせを得る（ステップＳ７０３）。この解は、指定された対策ポリシー１０７との差が最も少ない対策実施の組み合わせであるので、対策案生成手段１０４は、この結果を対策案として状態格納手段１０２に格納する（ステップＳ７０４）。

例えば、図３に示す対策ポリシー１０７を適用した場合、すなわち「オフィス用」管理区分における目標値として（許容リスク，許容コスト，許容可用性低下）＝（３，３，２）が指定され、「持ち出し用」管理区分における目標値として（２，８，４）が指定され、「業務用」管理区分における目標値として（１，８，１０）が指定された場合には、各管理区分に対して次のような対策案が生成されることとなる。まず、「オフィス用」管理区分における対策案としては、「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリ登録制」（対策４）の２つの対策を実施する旨の対策案が生成される。また、「持ち出し用」管理区分における対策案としては、「ディスク暗号化」（対策１）と、「認証強化」（対策２）と、「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリ登録制」（対策４）の４つの対策を実施する旨の対策案が生成される。また、「業務用」管理区分における対策案としては、「認証強化」（対策２）と、「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリの使用禁止」（対策５）の３つの対策を実施する旨の対策案が生成される。

最後に、図５に示すように、表示手段１１０は、状態格納手段１０２に格納されている各クライアントシステム１２０のセキュリティリスクに関する情報（管理区分、資産価値、リスク値、対策の実施状態、対策案等）を、入出力装置１０１を介して管理者にわかりやすい形で表示する（ステップＳ５０５）。管理者は、表示された結果を元に、提案された対策を実施するように、各クライアントシステム１２０の管理者に通達する。

図９は、表示手段１１０によって表示される画面の例を示す説明図である。図９に示すように、表示手段１１０は、例えば、クライアントシステム１２０を識別するためのＩＤまたはクライアントシステム１２０の名称（図中では”ＰＣ名”）を示す情報欄９０６と、管理区分を示す情報欄９０１と、資産価値を示す情報欄９０２と、現在のリスク値を示す情報欄９０３と、対策実施状況を示す情報欄９０４と、対策実施後のリスク値を示す情報欄９０５とを含む画面を生成して表示してもよい。図９に示す例では、対策実施状況を示す情報欄９０４に、実施すべき対策と既に行われている対策との差分を調べ、実施すべきだがまだ実施されていない対策が何件あるかを示している。なお、対策実施状況を示す情報欄９０４に合わせて、どの対策が実施されていないかを示す情報を表示してもよい。また、対策実施後のリスク値を示す情報欄９０４に、実施すべき対策を実施した場合に、リスク値がどのようになるのかを示している。

図９では、例えば、”ＰＣ１”のセキュリティリスクに関する情報として、ＰＣ１が業務用のクライアントシステム１２０であり、ＰＣ１の資産価値（機密度）が９であり、現在のリスク値が２．５であり、実施すべき対策が２件未実施であり、その対策を実施すればリスク値が０になることが示されている。このように、表示手段１１０が表示する画面によって、セキュリティ管理者は、各クライアントシステム１２０での対策実施状態が十分なのかどうかを把握することができる。また、セキュリティ管理者は、未実施の対策を実施することによって、どの程度のリスク低減効果があるのかを知ることができる。

表示手段１１０は、現在のリスク値が高いクライアントシステム１２０の情報に対して、色を付けるなどして強調表示しもよい。なお、図９では、”ＰＣ１”および”ＰＣ５”の情報を示している行を色付け（図中においては網掛け）した例を示している。また、リスク値を”低／中／高”のように表示してもよい。このようにすれば、どのクライアントシステム１２０がリスクの高い状態にあるのかがひと目でわかるようになる。また、現在のリスク値が大きい順に表示したり、現在のリスク値の大きさで行を並び替える機能を持たせてもよい。

また、表示手段１１０は、各クライアントシステム１２０がネットワーク上のどの位置に存在するかを示すネットワーク構成図を合わせて表示してもよい。なお、ネットワーク構成図上で各クライアントシステム１２０をリスク値に応じて色分けする等のユーザインタフェースと組み合わせて表示してもよい。このようにすれば、セキュリティ管理者は、リスクの高いクライアントシステム１２０がネットワーク上のどこに集中しているかといった情報も把握することができる。

以上のように、本実施の形態によれば、クライアント（ここでは、クライアントシステム１２０）のセキュリティ管理を一元化しつつ、各クライアントの実情に応じて、適切な対策を立案することができる。例えば、オフィス用や持ち出し用のような典型的な用途に用いられるクライアントに対しては一律的な管理手法を適用し、業務用のような特殊な用途に用いられるクライアントには個別の管理手法を適用するといった利用方法も可能である。また、セキュリティ対策を実施することによって発生するコストだけでなく、可用性（利便性）の低下など、複数の要件を考慮した対策を立案することができる。

なお、同一の管理区分に属するクライアントシステム１２０には同一の対策が立案されるため、対策立案の計算量は、クライアントシステム１２０の数ではなく管理区分の数に比例する。従って、管理対象とするクライアントシステム１２０が多くなっても、対策立案の計算量が大幅に増えることはない。また、クライアントシステム１２０を使用するユーザにとっても、クライアントシステム１２０毎に利用可能な機能（例えば、ＵＳＢメモリ）がまちまちといったわかりにくい管理形態にならずにすむため、理解しやすいという効果もある。

また、図４に示したリスクモデル１０９の例では、脆弱性の大きさを１つのスカラー値として算出する関数を定義したが、脅威の種類ごとに脆弱性の大きさを算出する式を定義してもよい。そのような場合、対策ポリシー１０７において、脅威の種類毎に許容値を設定できるようにしてもよい。図１０は、リスクモデル１０９に脅威の種類毎にセキュリティリスクが存在するかを算出するための計算式を含む例を示す説明図である。図１０に示すように、例えば、情報漏洩という脅威に対し、さらに「ＰＣ紛失による情報漏洩」、「なりすましによる情報漏洩」、「ウイルス感染による情報漏洩」、「ＵＳＢメモリ紛失による情報漏洩」という４つの種類を定義し、それぞれの脅威の種類毎に、脆弱性の大きさを算出するための式を定義してもよい。また、脅威の種類毎に脆弱性の大きさを算出するための式を定義し、さらに、それらを合わせて全体の脆弱性の大きさを算出するための式を定義してもよい。

図１０に示す例では、各脅威の種類に対する脆弱性の大きさを求める計算式は、次に示すような式で示されている。

（ＰＣ紛失に対する脆弱性の大きさ）＝４−４（１−ｘ_６＋ｘ_１ｘ_６）
（なりすましに対する脆弱性の大きさ）＝１−ｘ_２
（ウイルス感染に対する脆弱性の大きさ）＝２−２ｘ_３
（ＵＳＢメモリ紛失に対する脆弱性の大きさ）＝３−３ｍａｘ（０．４ｘ_４，ｘ_５））

このようにすれば、セキュリティ管理者は、各クライアント（クライアントシステム１２０）がどのようなセキュリティ上の脅威に晒されているのかをより明確に把握することができる。例えば、セキュリティ管理者は、セキュリティ監査時に、リスクの高いクライアントを容易に発見することができる。図１１に、脅威の種類別にリスク値を表示した場合の表示手段１１０の画面例を示す。

表示手段１１０は、図１１に示すように、現在の脅威の種類別リスク値を示す情報欄を追加し、脅威の種類毎に、現在のリスク値を表示してもよい。図１１では、例えば、”ＰＣ１”の現在の脅威の種類別リスク値として、ＰＣ紛失による情報漏洩のリスク値が０であり、なりすましによる情報漏洩のリスク値が０．９であり、ウイルス感染による情報漏洩のリスク値が０であり、ＵＳＢメモリ紛失による情報漏洩のリスク値が１．６であることが示されている。

また、対策ポリシー１０７において、脅威の種類毎に許容値を設定する場合には、設定項目は増えるものの、管理区分毎に、どの脅威への対応を重視するかを考慮した対策案を立案させることができるようになる。

なお、本実施の形態では、脆弱性の大きさ・コストの大きさ・可用性低下の大きさを、０〜１０までの数値で相対的に割り振る例を示したが、例えば、コストを購入金額や運用費用のような絶対的な数値で表すようにしてもよい。このようにすれば、より現実に即した対策立案が可能になる。なお、絶対的な数値で表現する場合には、多目的最適化問題に帰着する際に、脆弱性の大きさや可用性低下の大きさとスケールが同じになるように重み付けする必要がある。

また、本実施の形態では、（リスクの大きさ）＝（資産価値の大きさ）×（脆弱性の大きさ）の式でリスクの大きさを定義し、それぞれ０〜１０までの相対値を割り振る例を示したが、（リスクの大きさ）＝（資産価値の大きさ）×（脅威の発生頻度）×（脆弱性の大きさ）の式でリスクの大きさを定義してもよい。ここで、資産価値の大きさを、その資産が失われたことによって生ずる損害額のような絶対的な数値で表してもよい。また、脅威の発生頻度を、その脅威に対する対策が一切なされていない場合に１年間にどの程度の頻度でその脅威が発生するかというような数値で表してもよい。また、脆弱性の大きさを、対策を実施することによって脅威の発生が何パーセント抑えることができるかというような数値で表すようにしてもよい。このようにすれば、算出されるリスク値は、年間予想損失金額として表され、リスクの大きさを明確に把握できるという長所がある。ただし、資産が失われたことによって生ずる損害額や、年間の脅威の発生頻度といった数値を信頼できる具体的な値にする必要があるので、このような定量的なリスク管理ができる局面は限定される。

また、本実施の形態では、機密性に関する資産価値の情報を収集し、機密性に関するリスクモデル１０９を定義することによって、機密性に関するセキュリティリスク管理を実現する例を説明したいが、状態収集手段１２１の手法を変更するとともに、リスクモデル１０９の脆弱性の大きさを算出するための式を変更することによって、機密性以外のセキュリティ要件に適用することができる。例えば、完全性に関するセキュリティリスク管理を実現する場合には、認証の強度や改ざん検出ツールのインストール状態を状態収集手段１２１が収集するよう変更し、リスクモデル１０９において、それらの状態から完全性に関する脆弱性の大きさを算出するための式を定義すればよい。

また、本実施の形態では、対策案生成手段１０４が、リスク値を求めるための計算式を線形化して、線形混合整数計画問題に帰着させて解くことによって最適な対策の組み合わせを生成する方法を説明したが、非線形式のまま、非線形整数計画問題に帰着させて解くようにしてもよい。なお、線形混合整数計画問題の方がよく研究されているので、より実用的である。

実施の形態２．
次に、本発明の第２の実施の形態について図面を参照して説明する。図１２は、第２の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。図１２に示すセキュリティリスク管理システムは、図１に示す第１の実施の形態と比べて、マネージャシステム１００が論理制約変換手段１１２を備える点で異なる。また、本実施の形態による対策ポリシー１０７およびリスクモデル１０９は、クライアントシステム１２０の状態（対策実施状態や構成その他の状態）を示す２値変数を、論理変数と見なした上で、論理式による制約条件を含む。

論理制約変換手段１１２は、論理式で記述された制約条件（論理制約式）を読み込んで、線形制約式の集合に変換する。

論理式による制約式として、例えば、「ＵＳＢメモリ登録制」（対策４）と「ＵＳＢメモリの使用禁止」（対策５）とを同時に実施することは意味がないので、このような組み合わせを除外するためには、リスクモデル１０９に、”¬（ｘ_４∧ｘ_５）”という制約条件（制約式）を加えればよい。また、「ノートＰＣであれば必ずディスク暗号化と認証強化を行う」という運用ルールを常に満たしたい場合には、対策ポリシー１０７に、”ｘ_６→（ｘ_１∧ｘ_２）”という制約条件（制約式）を加えればよい。このように、様々な要因にも基づく制約を、論理制約関数として記述したものを対策ポリシー１０７およびリスクモデル１０９に含めればよい。

論理制約変換手段１１２は、具体的には、マネージャシステム１００が備えるＣＰＵ等のプログラムに従って動作するデータ処理装置によって実現される。

次に、論理制約変換手段１１２の動作を中心に本実施の形態の動作について説明する。例えば、論理制約変換手段１１２は、対策案生成手段１０４が対策案を立案する前までに、次に示すような論理制約式変換動作を行う。まず、論理制約変換手段１１２は、対策ポリシー１０７およびリスクモデル１０９に含まれる論理制約式を読み込む。次に、読み込んだ論理制約式を、論理積標準形（ＣＮＦ）に変換する。論理積標準形とは、論理式が”（Ｌ_１１∨・・・∨Ｌ_１ｎ１）∧（Ｌ_２１∨・・・∨Ｌ_２ｎ２）∧・・・∧（Ｌ_ｋ１∨・・・∨Ｌ_ｋｎｍ）”のように、リテラル（論理変数および論理変数の否定）の”∨（論理和）”で表される節が”∧（論理積）”で連結させた形をいう。任意の論理式は、論理積標準形に変換可能であることが知られており、効率よく論理積標準形に変換するアルゴリズムとして、例えば、文献「David A. Plaisted and Steven Greenbaum, "A structure-preserving clause form translation.", Journal of symbolic Computation, September 1986, 2(3):pp.293-304 」に記載されている”Structure Preserving Conversion ”アルゴリズムを用いることができる。このアルゴリズムは、論理積標準形となっていない式を１つの新しい論理変数に置き換え、新しく導入された変数と、元の式が等しいことを表す式を”∧”で結合していくことにより、節を爆発的に増やすことなく論理積標準形に変換するアルゴリズムである。

次に、論理制約変換手段１１２は、論理積標準形で表された論理式を、整数計画問題の制約式に変換する。これは、論理積標準形を構成するそれぞれの節”（Ｌ_ｉｊ∨・・・∨Ｌ_ｉｎｊ）”を、”Ｌ_ｉｊ∨・・・∨Ｌ_ｉｎｊ≧１”と置き換え、否定形のリテラル”Ｌ＝¬ｘ”を”１−ｘ”に、肯定形のリテラル”Ｌ＝ｘ”を”ｘ”に置き換えることによって実現できる。以上の動作により、論理制約変換手段１１２によって論理制約式が線形制約式の集合に変換される。

対策案生成手段１０４は、第１の実施の形態において示した制約式と、論理制約変換手段１１２によって変換された制約式とを合わせて解く。そして、得られた解を、最適な対策の組み合わせを示す対策案として状態格納手段１０２に格納する。

以上のように、本実施の形態によれば、対策の排他・同時実施などの制約条件を定義した対策ポリシーに基づく対策案を生成することができるので、セキュリティ対策間の制約を考慮した、現実に取りうる対策の組み合わせにおいて、適切な対策を立案することができる。

実施の形態３．
次に、本発明の第３の実施の形態について図面を参照して説明する。図１３は、第３の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。図１３に示すセキュリティリスク管理システムは、図１２に示す第２の実施の形態と比べて、クライアントシステム１２０が対策実施手段１２３を備える点で異なる。

対策実施手段１２３は、立案された対策をクライアントシステム１２０上で実施する。例えば、対策実施手段１２３は、マネージャシステム１００上の状態格納手段１０２に、自身のクライアントシステム１２０（その対策実施手段１２３を備えたクライアントシステム１２０）上で現在未実施の対策があるか否かを、状態格納手段１０２に格納されている情報から判定すればよい。対策実施手段１２３は、例えば、状態格納手段１０２に格納されている対策実施状況を示す情報と、実施すべき対策案を示す情報とを比較して、実施すべきだがまだ実施されていない対策があるかどうかを判定すればよい。なお、表示手段１１０が画面表示をする際に、実施すべき対策が何件あるか、またどの対策を実施するかを示す情報を状態格納手段１０２に格納し、対策実施手段１２３は、表示手段１１０が格納した情報を問い合わせることによって判定することも可能である。

対策実施手段１２３は、判定した結果、現在未実施の対策があった場合には、その対策が自動的に実施可能なものであれば実施し、自動的に実施可能でなければ、クライアントシステム１２０のユーザに対して、対策を実施することを喚起する表示を行う。

例えば、認証強化のような対策の場合には、自動でＯＳの設定を変更する。例えば、ディスク暗号化のような対策の場合は、ユーザに対してディスク暗号化ツールをインストールする指示をする画面を表示する。

対策実施手段１２３は、具体的には、クライアントシステム１２０が備えるＣＰＵ等のプログラムに従って動作するデータ処理装置によって実現される。なお、対策実施手段１２３は、各クライアントシステム１２０がプログラムをインストールする等して、管理対象とするクライアントシステム１２０それぞれに備えられているものとする。

以上のように、本実施の形態によれば、立案された対策をクライアント（クライアントシステム１２０）で実施する際に、セキュリティ管理者の工数を割くことなく、各クライアント側で自立的に実施することが可能となる。結果、セキュリティ管理者が各クライアントシステム１２０のユーザに対して個別に対策の指示を出さなくても、セキュリティ対策を徹底することができる。

実施の形態４．
次に、本発明による第４の実施の形態について図面を参照して説明する。図１４は、第４の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。図１４に示すセキュリティリスク管理システムは、図１３に示す第３の実施の形態と比べて、マネージャシステム１００がポリシー編集手段１１３を備える点が異なる。

ポリシー編集手段１１３は、ポリシー格納手段１０５に格納されている管理区分ポリシー１０６や対策ポリシー１０７を、ユーザに対して表示して編集させる。

ポリシー編集手段１１３は、具体的には、マネージャシステム１００が備えるＣＰＵ等のプログラムに従って動作するデータ処理装置によって実現される。

次に、ポリシー編集手段１１３の動作を中心に本実施の形態の動作について説明する。例えば、ポリシー編集手段１１３は、ユーザの操作に応じて、次に示すようなポリシー編集動作を行う。まず、ポリシー編集手段１１３は、図１５に示すような管理区分毎に立案された対策のリストを示す情報欄と、その管理区分に対する対策ポリシー１０７を編集する旨を指示するための「編集ボタン」とを含む画面を表示する。図１５は、対策ポリシーを編集するための画面の一例を示す説明図である。なお、ポリシー編集手段１１３は、その画面に脅威の種類別の対策後のリスク値（ここでは、資産価値が１０の場合のリスクの大きさ）を示す情報欄を含めてもよい。ここで、ユーザがある管理区分に対して「編集ボタン」を押下すると、ポリシー編集手段１１３は、その管理区分に対する対策ポリシー１０７を編集するための対策ポリシー編集画面を生成して表示する。

図１６は、対策ポリシー編集画面の一例を示す説明図である。対策ポリシー編集画面は、図１６に示すように、例えば、編集対象とする管理区分を表示または指定するためのユーザインタフェース１６０１と、対策を立案する際に必要とするセキュリティ要件（すなわち、コストとリスクの制限値）を設定するためのユーザインタフェース１６０２と、対策を立案する際に必要とするその他の制約条件（論理制約条件）を設定するためのユーザインタフェース１６０３（制約条件式を編集する旨を指示する「編集ボタン」１６０４を含む）とを含んでいてもよい。

ユーザインタフェース１６０２では、例えば、許容するリスクの大きさ（許容リスク）と許容するコストの大きさ（許容コスト）と許容する利便性低下の大きさとを入力させればよい。また、ユーザインタフェース１６０３では、任意の論理式を入力させてもよいが、例えば、よく利用される論理式のパターンのみを入力させるように制限してもよい。例えば、ある対策の集合｛ｘ_１，・・・，ｘ_ｎ｝を常に実施するという論理制約式”ｘ_１∧・・・∧ｘ_ｎ”と、ある対策の集合｛ｘ_１，・・・，ｘ_ｎ｝は常に実施しないという論理制約式”¬ｘ_１∧・・・∧¬ｘ_ｎ”のみが入力できるようにしてもよい。このように制限した場合、対策ポリシー１０７の記述力は劣ることになるが、設定する内容が明快でわかりやすく、設定するためのユーザインタフェースも理解しやすいものにすることができる。

ユーザ（セキュリティ管理者）が、例えば、ユーザインタフェース１６０３に含まれる「必ず実施する対策」に対応づけられた「編集ボタン」を押下すると、ポリシー編集手段１１３は、図１７に示すような対策候補を選択可能に一覧表示するリストボックスと、必ず実施する対策を選択可能に一覧表示するリストボックスと、それぞれのリストボックスの項目を移動させる「追加ボタン」，「削除ボタン」とを含むパラメータの調整画面を表示してもよい。ここで、ユーザが、対策候補を表示するリストボックスから「ディスク暗号化」（対策１）と「認証強化」（対策２）とを追加する操作を行った場合、ポリシー編集手段１１３は、そのユーザ操作に応じて、編集中の管理区分に対応する対策ポリシー１０７に”ｘ_１∧ｘ_２”という論理制約式を追加すればよい。また、ユーザが、例えば、「必ず実施しない対策」に対応づけられた「編集ボタン」を押下した場合には、ポリシー編集手段１１３は、対策候補を選択可能に一覧表示するリストボックスと、必ず実施しない対策を選択可能に一覧表示するリストボックスと、それぞれのリストボックスの項目を移動させる「追加ボタン」，「削除ボタン」とを含むパラメータの調整画面を表示してもよい。ここで、ユーザが、「ＵＳＢメモリ使用禁止」（対策５）を追加する操作を行った場合、ポリシー編集手段１１３は、そのユーザ操作に応じて、編集中の管理区分に対応する対策ポリシー１０７に”¬ｘ_５”という論理制約式を追加すればよい。

また、ポリシー編集手段１１３は、「保存ボタン」１６０９を含む対策ポリシー編集画面を用意して、「保存ボタン」１６０９が押下されるまでは編集用の対策ポリシー１０７に追加しておき、「保存ボタン」１６０９が押下されて初めて正式に対策ポリシー１０７に反映させるようにしてもよい。

また、ポリシー編集手段１１３は、編集の結果を確認する旨を指示するための「決定ボタン」１６０５と、編集結果として対策案を表示するためのリストボックス１６０６と、その対策案を実施した後の状況を表示するためのテキスト領域１６０７とを含む対策ポリシー編集画面を用意してもよい。そのような場合には、ユーザが必要に応じて編集した後、「決定ボタン」１６０５を押下すると、ポリシー編集手段１１３は、設定された内容を反映させた対策ポリシー１０７を、対策案生成手段１０４に入力し、対策案生成手段１０４が新たな対策ポリシー１０７に基づいて生成した対策案を、例えばリストボックス１６０６に表示してもよい。また、その対策案を実施した場合に、リスクや可用性低下、コストがどのような値になるかをテキスト領域１６０７に表示してもよい。このようにすれば、セキュリティ管理者は、対策ポリシー１０７を編集した結果、どのような対策案が生成されるようになるか、またその対策案によってどの程度セキュリティリスクが緩和され、反面どの程度利便性が低下し、コストがかかるかを把握することができる。

また、ポリシー編集手段１１３は、編集した内容を新しい管理区分として保存する旨を指示するための「名前を変えて保存ボタン」１６０８を含む対策ポリシー編集画面を用意し、そのボタンが押下された場合には、新しい管理区分名を付けるためのユーザインタフェースを表示して、新しい管理区分の対策ポリシー１０７を作成できるようにしてもよい。なお、ポリシー編集手段１１３は、編集対象とする管理区分を表示または指定するためのユーザインタフェース１６０１（例えば、選択コンボボックス）に、”新規管理区分．．．”という項目を設けることによって、新しい管理区分の対策ポリシーを作成できるようにしてもよい。ポリシー編集手段１１３は、ユーザが編集した内容を新しい管理区分名で保存する旨の操作を行った場合には、その新しい管理区分名を持つ管理区分を管理区分ポリシー１０６に追加する。なお、この時点では、その管理区分に割り振られるクライアントシステム１２０がなくてもよい。

また、ポリシー編集手段１１３は、対策ポリシー編集画面とは別に、各クライアントシステム１２０の管理区分を明示的に変更するための管理区分設定画面を生成して表示してもよい。管理区分設定画面は、例えば、表示手段１１０が表示する画面上のクライアントシステム１２０の名称を示す情報欄（図９の情報欄９０６）にリンク機能を持たせ、そのリンクのクリック操作に応じて”詳細画面”として表示するようにしてもよい。図１８は、管理区分設定画面の一例を示す説明図である。図１８は、管理区分設定画面が、”ＰＣ２”の詳細画面として表示される例を示している。管理区分設定画面は、例えば、図１８に示すように、編集対象とするクライアントシステム１２０の名称と、その管理区分を表示または指定するためのユーザインタフェース１８０１（例えば、選択コンボボックス）と、現在の対策実施状況として、実施済みの対策を示すリストボックス１８０２と、実施すべきだが未実施の対策を示すリストボックス１８０３とを含んでいてもよい。

ここで、ユーザが、選択コンボボックス１８０１を介してクライアントの管理区分を変更する操作を行うと、ポリシー編集手段１１３は、その操作に応じて、編集対象のクライアントシステム１２０が指定された管理区分に分類されるように管理区分ポリシー１０６を変更する。

例えば、”ＰＣ２”は、機密度が高いので、オフィス用よりもややセキュリティを重視した対策を実施すべきであるとセキュリティ管理者が判断した場合、図１６に示すような対策ポリシー編集画面を用いて、オフィス用よりもややセキュリティを重視した対策が立案されるような対策ポリシーを追加する操作を行う。そして、それを「重要オフィス用」と名付けて保存する。この操作に応じて、ポリシー編集手段１１３が、管理区分ポリシー１０６に、「重要オフィス用」という名前をもつ管理区分の定義を追加する。

その後、ユーザは、図１８に示すような管理区分設定画面を用いて、”ＰＣ２”の管理区分を「重要オフィス用」に変更する操作を行う。この操作に応じて、ポリシー編集手段１１３が、管理区分ポリシー１０６に、”ＰＣ２”が「重要オフィス用」に分類されるような対応関係または判定方法を変更する。図１９は、変更後の管理区分ポリシー１０６の例を示す説明図である。図１９に示すように、例えば、管理区分ポリシー１０６がスクリプトプログラムとして与えられる場合には、クライアントシステム１２０が”ＰＣ２”であれば、管理区分を「重要オフィス用」と判定するような判定文を最初に実行するようなスクリプトプログラムに変更すればよい。

また、ポリシー編集手段１１３によって対策ポリシー１０７または管理区分ポリシー１０６が変更された時、変更されたクライアントシステム１２０に対して、直ちに図５に示すような一連の動作を実施するようにしてもよい。そのようにすれば、最新の対策ポリシーや管理区分ポリシーの元で、リスクの表示と対策の実施を即座に行うことができる。

以上のように、本実施の形態によれば、典型的な用途に用いられる大多数のクライアント（クライアントシステム１２０）に対しては、同一の管理区分で一律に管理しつつ、例外的な対策を実施したいクライアントに対しては、新たな管理区分を設けることによって、特別な対策を指定することができる。結果、例外的な対策が必要なクライアントも適切なリスク管理化におくことができる。

なお、ポリシー編集手段１１３は、対策ポリシー編集画面として、図２０に示すような画面を備え、脅威の種類別に許容リスク値を設定できるようにしてもよい。図２０は、対策ポリシー編集画面の他の例を示す説明図である。図２０では、ユーザインタフェース１６０２が、各脅威の種類別に許容するリスクの大きさを入力できるようになっている例を示している。また、編集結果の対策案を実施した後の状況を表示するためのテキスト領域１６０７が、各脅威の種類別のリスクを表示するようになっている例を示している。

このようなユーザインタフェースを用いることによって、脅威の種類別にどの程度リスクを許容するのかを個別に設定することができる。例えば、部外者の侵入ができないように物理的にセキュリティが守られるとともに、セキュリティ教育の徹底により内部犯の生じる可能性も少ないクライアントシステム１２０に対しては、図２０に示す例のように、ＰＣ紛失やなりすましによる漏洩リスクは許容し、その他の要因による漏洩リスクを厳しく監視するような対策ポリシー１０７を作成してもよい。図２０では、ＰＣ紛失やなりすましによる漏洩リスクの許容値を５に設定し、その他の要因による漏洩リスクの許容値を０に設定する例を示している。このように、ポリシー編集手段１１３を用いることによって、組織の実情に応じてどの脅威を重視するかを考慮しながら対策を策定することができる。

例えば、業務用ＰＣが非常に強固な認証システム（ＩＣカード認証＋虹彩認証など）を持つ部屋に置かれているために、そのようなＰＣ向けに特別な管理区分を作成した場合には、その管理区分に対しては、「認証強化」（対策２）を常に実施しない旨の対策ポリシー１０７を設定すればよい。すなわち、対策ポリシー１０７に、”¬ｘ_２”という論理制約条件を含めればよい。対策案生成手段１０４は、その他の条件が「業務用」と同じである場合には、対策案として、「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリの使用禁止」（対策５）の２つの対策を実施する旨の対策案を生成することとなる。すなわち、既に強固な認証がなされているので、そのＰＣに対して「認証強化」（対策２）を立案しないように動作させることができる。その分、他の対策に割り当てられるコストが増えることにもなる。

また、例えば、暗号化機能付きハードディスク装置が搭載されているか否かを、状態収集手段１２１が構成その他の状態として収集できるとした場合、「暗号化付き持ち出し用」という管理区分を追加してもよい。ここで、管理区分ポリシー１０６には、暗号化機能付きハードディスク装置が搭載されているクライアントシステム１２０を「暗号化付き持ち出し用」管理区分に分別されるような分別方法が定義されているものとする。また、リスクモデル１０９には、暗号化機能付きハードディスク装置が搭載されているか否かを示す変数”ｘ_７”を加味して、（ＰＣ紛失に対する脆弱性の大きさ）＝４−４（１−ｘ_６＋ｘ_１ｘ_６＋ｘ_６ｘ_７−ｘ_１ｘ_６ｘ_７）と定義されているものとする。

対策案生成手段１０４は、その他の条件が「持ち出し用」と同じである場合には、暗号化機能付きハードディスク装置が搭載されているクライアントシステム１２０に対しては、「認証強化」（対策２）と「アンチウイルスツールの導入」（対策３）と、「ＵＳＢメモリ登録制」（対策４）の３つの対策を実施する旨の対策案を生成することとなる。すなわち、既に暗号化機能付きハードディスク装置が搭載されているので、そのクライアントシステム１２０に対して「ディスク暗号化」（対策１）を立案しないように動作させることができる。なお、ここで例示した対策立案動作は、予め管理区分ポリシー１０６や対策ポリシー１０７やリスクモデル１０９にそのような定義がされていれば、第１の実施の形態においても可能である。

また、どのようなリスクが残るかを明確に把握することができるので、セキュリティ管理の最終責任者が、どのような残留リスクがどの程度存在するのかを承認した上でセキュリティ対策の実施を許可するような運営をする場合であっても、本システムを好適に適用することができる。すなわち、ポリシー編集手段１１３を用いることによって、どのような残留リスクがどの程度存在することになるのかを認識した上で、組織の実情に応じてどの脅威を重視するか等、脅威の種類別のセキュリティ管理指針を策定（設定）することができる。

本発明は、システムの脆弱性を収集し適切な対策を立案するようなセキュリティ運用管理ツールといった用途に適用できる。また、ポリシーに基づいてシステムのセキュリティ状態を保証するようなセキュリティポリシーコンプライアンス支援ツールといった用途に適用できる。

第１の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。 管理区分ポリシー１０６として登録される情報の例を示す説明図である。 対策ポリシー１０７として登録される情報の例を示す説明図である。 リスクモデル１０９の例を示す説明図である。 第１の実施の形態によるセキュリティリスク管理システムの動作例を示すフローチャートである。 状態格納手段１０２に格納される情報の例を示す説明図である。 基準点法を用いて対策案を生成する動作の具体例を示すフローチャートである。 対策案生成の一手法である線形化および目標関数作成の例を示す説明図である。 表示手段１１０によって表示される画面の例を示す説明図である。 リスクモデル１０９に脅威の種類毎にセキュリティリスクが存在するかを算出するための計算式を含む例を示す説明図である。 脅威の種類別にリスク値を表示した場合の表示手段１１０の画面例を示す説明図である。 第２の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。 第３の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。 第４の実施の形態によるセキュリティリスク管理システムの構成例を示すブロック図である。 対策ポリシーを編集するための画面の一例を示す説明図である。 対策ポリシー編集画面の一例を示す説明図である。 対策ポリシーを編集するための画面の一例を示す説明図である。 管理区分設定画面の一例を示す説明図である。 変更後の管理区分ポリシー１０６の例を示す説明図である。 対策ポリシー編集画面の他の例を示す説明図である。

符号の説明

１００ マネージャシステム
１０１ 表示装置・入力装置（入出力装置）
１０２ 状態格納手段
１０３ 管理区分判定手段
１０４ 対策案生成手段
１０５ ポリシー格納手段
１０６ 管理区分ポリシー
１０７ 対策ポリシー
１０８ リスクモデル格納手段
１０９ リスクモデル
１１０ 表示手段
１１１ リスク評価手段
１１２ 論理制約変換手段
１１３ ポリシー編集手段
１２０ クライアントシステム
１２１ 状態収集手段
１２２ 資産情報収集手段
１２３ 対策実施手段

Claims (8)

1. クライアントシステムにおけるセキュリティリスクを管理するセキュリティリスク管理システムであって、
   リスク管理の対象となるクライアントシステムの状態を示す情報と資産価値を示す情報とを格納する状態格納手段と、
   各クライアントシステムの用途に応じてどのような管理区分が存在するかを定義するとともに各クライアントシステムがどの管理区分に分別されるかを定義した管理区分ポリシーと、クライアントシステムの状態とに基づいて、各クライアントシステムの管理区分を判別する管理区分判別手段と、
   対策実施に伴う１つ以上のセキュリティ要件として、少なくともセキュリティ対策を実施する際に許容する脆弱性の大きさと、可用性低下の大きさとを示す情報を含む情報を前記管理区分毎に定義した対策ポリシーと、少なくともクライアントシステムの状態から導出される各脅威およびその関連性に基づいてそのクライアントシステムに現在どれだけのセキュリティリスクが存在するのかを算出するためのモデル式を定義したリスクモデルであって少なくとも対策を実施することによって低減する脆弱性の大きさと、対策を実施することによって増大する可用性低下の大きさとを算出するための計算式を含むリスクモデルとに基づいて、前記管理区分毎の対策案を生成する対策案生成手段と、
   前記状態格納手段に格納されている情報で示される各クライアントシステムの対策実施有無と前記リスクモデルとから、各クライアントシステムの現在のセキュリティリスクの度合いを示すリスク値を算出するリスク評価手段と、
   前記対策ポリシーおよび前記リスクモデルに含まれるセキュリティ対策間の関係を表す論理制約式を、前記対策案生成手段で扱える形式である線形制約式の集合に変換する論理制約変換手段とを備え、
   前記対策案生成手段は、前記論理制約変換手段によって変換された線形制約式の集合を加えた上で、前記対策ポリシーで示されるセキュリティ要件を目標値として、前記管理区分毎に、各目標値に対して最もよく満たすこととなる各対策実施有無を示す２値変数の組み合わせを、基準点法を用いて、多目的最適化問題を解くことによって求め、求めた２値変数の組み合わせで示される対策実施有無の組み合わせを対策案とする
   ことを特徴とするセキュリティリスク管理システム。
2. クライアントシステムの状態を示す情報として、少なくとも該クライアントシステムにおけるセキュリティ対策の実施有無を示す対策実施情報と、管理区分を判別するために必要な該クライアントシステムの構成情報とを収集し、状態格納手段に格納させる状態収集手段と、
   クライアントシステムの資産価値を判定し、状態格納手段に格納させる資産情報収集手段とを備えた
   請求項１に記載のセキュリティリスク管理システム。
3. 対策案生成手段は、脅威の種類別に対策実施に伴う１つ以上のセキュリティ要件を管理区分毎に定義した対策ポリシーと、クライアントシステムの状態から導出される各脅威およびその関連性に基づいてそのクライアントシステムに現在どれだけのセキュリティリスクが存在するのかを脅威の種類別に算出するためのモデル式を定義したリスクモデルとに基づいて、管理区分毎の対策案を生成し、
   リスク評価手段は、状態格納手段に格納されている情報で示される各クライアントシステムの対策実施有無と前記リスクモデルとから、各クライアントシステムの現在のセキュリティリスクの度合いを示すリスク値を脅威の種類別に算出する
   請求項１または請求項２に記載のセキュリティ管理システム。
4. クライアントシステムのセキュリティリスクに関する情報として、少なくともリスク評価手段によって算出されるリスク値を表示するとともに、リスク値が所定の閾値よりも高いクライアントシステムの情報を強調表示する表示手段を備えた
   請求項１から請求項３のうちのいずれか１項に記載のセキュリティリスク管理システム。
5. 対策案生成手段によって生成された対策案を、クライアントシステム上で自動で実施する、またはクライアントシステムのユーザに対し、実施することを喚起する対策実施手段を備えた
   請求項１から請求項４のうちのいずれか１項に記載のセキュリティリスク管理システム。
6. 管理区分ポリシーおよび対策ポリシーの設定内容を変更または追加するための画面を表示することによって、ユーザに対して管理区分ポリシーおよび対策ポリシーを編集させるポリシー編集手段を備えた
   請求項１から請求項５のうちのいずれか１項に記載のセキュリティリスク管理システム。
7. ポリシー編集手段は、対策が実施されることによって脅威の種類別にどの程度リスク値が低減するかを表示する領域と、脅威の種類別に許容できるリスク値を設定するための領域とを含む画面を表示する
   請求項６に記載のセキュリティリスク管理システム。
8. 対策ポリシーは、少なくともセキュリティ対策を実施する際に許容する脆弱性の大きさと、コストの大きさと、可用性低下の大きさとを示す情報を含み、
   リスクモデルは、少なくとも対策を実施することによって低減する脆弱性の大きさと、対策を実施することによって増大する可用性低下の大きさおよびコストの大きさとを算出するための計算式を含む
   請求項１から請求項７のうちのいずれか１項に記載のセキュリティリスク管理システム。

Images