JP7015889B1 - リスク評価支援システム - Google Patents

Abstract

【課題】 対象エンティティのリスク評価の取得を支援することを可能とするリスク評価支援システムを提供する。【解決手段】 リスク評価支援システムは、第１ユーザエンティティと第１対象エンティティとの対応関係を管理し、前記第１対象エンティティのセキュリティ対策に関するリスク評価を前記第１対象エンティティと対応付けて管理する管理部と、前記リスク評価が更新された場合に、前記第１対象エンティティと対応付けられた前記第１ユーザエンティティに対して、更新されたリスク評価を提供する制御部と、を備える。【選択図】 図２

Description

本発明は、リスク評価支援システムに関する。

近年、サイバー攻撃が増加していることから、サイバー攻撃に対するリスク評価が注目を集めている。例えば、セキュリティ対策に関する質問のリスト（以下、チェックリスト）に対する回答に基づいて、セキュリティ対策に関するリスク評価を導出するシステムが提案されている（例えば、特許文献１）。

特開２０１９－０７０９１２号公報

ところで、個人、法人又は団体などのエンティティは、取引関係や資本関係などの関係を他のエンティティ（以下、対象エンティティ）と有することが多い。このようなケースにおいて、エンティティは、自らのリスク評価を取得するだけではなく、対象エンティティのリスク評価を取得することが好ましい。

しかしながら、多数の対象エンティティが存在するケースにおいて、全ての対象エンティティのリスク評価をエンティティが自ら取得する手間は極めて煩雑である。さらに、最新版の対象エンティティのリスク評価を更新し続ける手間も極めて煩雑である。

そこで、本発明は、上述した課題を解決するためになされたものであり、対象エンティティのリスク評価の取得を支援することを可能とするリスク評価支援システムを提供することを目的とする。

第１の特徴は、リスク評価支援システムであって、第１ユーザエンティティと第１対象エンティティとの対応関係を管理し、前記第１対象エンティティのセキュリティ対策に関するリスク評価を前記第１対象エンティティと対応付けて管理する管理部と、前記リスク評価が更新された場合に、前記第１対象エンティティと対応付けられた前記第１ユーザエンティティに対して、更新されたリスク評価を提供する制御部と、を備える、ことを要旨とする。

第２の特徴は、第１の特徴において、前記制御部は、前記リスク評価の更新に関する前記第１対象エンティティの許諾がある場合に、前記更新されたリスク評価を提供する、ことを要旨とする。

第３の特徴は、第１の特徴又は第２の特徴において、前記制御部は、前記第１対象エンティティから提供された情報に基づいて前記リスク評価を更新する、ことを要旨とする。

第４の特徴は、第１の特徴乃至第３の特徴のいずれかにおいて、前記制御部は、前記リスク評価の取得を第２ユーザエンティティから要求された場合に、前記管理部で管理されている前記リスク評価を前記第２ユーザエンティティに提供する、ことを要旨とする。

第５の特徴は、第４の特徴において、前記制御部は、前記リスク評価の提供に関する前記第１対象エンティティの許諾がある場合に、前記管理部で管理されている前記リスク評価を提供する、ことを要旨とする。

第６の特徴は、第１の特徴乃至第５の特徴において、前記制御部は、対象エンティティから提供された情報に基づいて、前記対象エンティティのセキュリティ対策に関するリスク評価を取得する、ことを要旨とする。

第７の特徴は、第１の特徴乃至第５の特徴において、前記制御部は、対象エンティティについて公開された情報に基づいて、前記対象エンティティのセキュリティ対策に関するリスク評価を取得する、ことを要旨とする。

本発明によれば、対象エンティティのリスク評価の取得を支援することを可能とするリスク評価支援システムを提供することができる。

図１は、実施形態に係るリスク評価支援システム１００を示す図である。 図２は、実施形態に係る支援サーバ３０を示す図である。 図３は、実施形態に係る管理部３２に格納されたデータの一例を示す図である。 図４は、実施形態に係る管理部３２に格納されたデータの一例を示す図である。 図５は、実施形態に係るチェックシートの一例を示す図である。 図６は、実施形態に係るリスク評価の一例を示す図である。 図７は、実施形態に係るリスク評価支援方法を示す図である。 図８は、実施形態に係るリスク評価支援方法を示す図である。 図９は、実施形態に係るリスク評価支援方法を示す図である。 図１０は、変更例１に係るリスク評価支援方法を示す図である。 図１１は、変更例２に係る確認画面の一例を示す図である。

以下において、実施形態について図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。

但し、図面は模式的なものであり、各寸法の比率などは現実のものとは異なる場合があることに留意すべきである。従って、具体的な寸法などは以下の説明を参酌して判断すべきである。また、図面相互間においても互いの寸法の関係又は比率が異なる部分が含まれている場合があることは勿論である。

［開示の概要］
開示の概要に係るリスク評価支援システムは、第１ユーザエンティティと第１対象エンティティとの対応関係を管理し、前記第１対象エンティティのセキュリティ対策に関するリスク評価を前記第１対象エンティティと対応付けて管理する管理部と、前記リスク評価が更新された場合に、前記第１対象エンティティと対応付けられた前記第１ユーザエンティティに対して、更新されたリスク評価を提供する制御部と、を備える。

開示の概要では、リスク評価支援システムは、第１ユーザエンティティと第１対象エンティティとの対応関係を管理している前提下において、第１対象エンティティのリスク評価が更新された場合に、第１対象エンティティと対応付けられた第１ユーザエンティティに対して、更新されたリスク評価を提供する。このような構成によれば、第１ユーザエンティティが最新版のリスク評価を容易に取得することができ、リスク評価の取得に伴うユーザエンティティの煩雑さを軽減することができる。

ここで、エンティティは、個人、法人又は団体などを指す用語と考えてもよい。エンティティは、個人、法人又は団体などが用いる端末と考えてもよい。ユーザエンティティは、対象エンティティのリスク評価を要求するエンティティである。対象エンティティは、リスク評価の対象とされるエンティティである。例えば、対象エンティティは、ユーザエンティティと取引関係や資本関係などの何らかの関係を有するエンティティである。対象エンティティは、ユーザエンティティと将来的に何らかの関係を有する可能性があるエンティティを含んでもよい。対象エンティティは、ユーザエンティティが用いるソフトウェア又はアプリケーションを提供するエンティティを含んでもよい。

［実施形態］
（リスク評価支援システム）
以下において、実施形態に係るリスク評価支援システムについて説明する。図１は、実施形態に係るリスク評価支援システム１００を示す図である。

図１に示すように、リスク評価支援システム１００は、第１端末１０と、第２端末２０と、支援サーバ３０と、を有する。第１端末１０、第２端末２０及び支援サーバ３０は、ネットワーク１１０によって接続される。特に限定されるものではないが、ネットワーク１１０は、インターネットによって構成されてもよい。ネットワーク１１０は、ローカルエリアネットワークを含んでもよく、移動体通信網を含んでもよく、VPN（Virtual Private Network）を含んでもよい。

第１端末１０は、ユーザエンティティが用いる端末である。ユーザエンティティは、対象エンティティのリスク評価を要求するエンティティである。ユーザエンティティは、第１端末１０を示す用語として用いられてもよい。例えば、第１端末１０は、パーソナルコンピュータであってもよく、スマートフォンであってもよく、タブレット端末であってもよい。図１では、第１端末１０Ａ及び第１端末１０Ｂが例示されている。第１端末１０Ａは、第１ユーザエンティティが用いる端末であってもよい。以下において、第１端末１０Ａを用いる第１ユーザエンティティを“AAA”と称することもある。第１端末１０Ｂは、第２ユーザエンティティが用いる端末であってもよい。以下において、第１端末１０Ｂを用いる第１ユーザエンティティを“BBB”と称することもある。

なお、第１ユーザエンティティは、支援サーバ３０において対象エンティティと対応付けられたユーザエンティティである。第２ユーザエンティティは、支援サーバ３０において対象エンティティと対応付けられていないユーザエンティティである。

第２端末２０は、対象エンティティが用いる端末である。対象エンティティは、リスク評価の対象とされるエンティティである。対象エンティティは、ユーザエンティティが用いるソフトウェア又はアプリケーションを提供するエンティティを含んでもよい。対象エンティティは、第２端末２０を示す用語として用いられてもよい。例えば、第２端末２０は、パーソナルコンピュータであってもよく、スマートフォンであってもよく、タブレット端末であってもよい。図１では、第２端末２０Ａ～第２端末２０Ｄが例示されている。第２端末２０Ａ～第２端末２０Ｃは、第１対象エンティティが用いる端末であってもよい。以下において、第２端末２０Ａ～第２端末２０Ｃを用いる第１対象エンティティを“aaa”～“ccc”と称することもある。第２端末２０Ｄは、第１対象エンティティ以外の対象エンティティ（第２対象エンティティと称してもよい）が用いる端末であってもよい。第２端末２０Ｄを用いる第２対象エンティティを“ddd”と称することもある。

なお、第１対象エンティティは、支援サーバ３０において対象エンティティと対応付けられた対象エンティティである。第２対象エンティティは、支援サーバ３０において対象エンティティと対応付けられていない対象エンティティである。

支援サーバ３０は、リスク評価の提供を支援するオペレータによって管理されるサーバである。オペレータは、支援サーバ３０を示す用語として用いられてもよい。支援サーバ３０は、対象エンティティのセキュリティ対策に関するリスク評価を管理するサーバである。支援サーバ３０は、対象エンティティのリスク評価をユーザエンティティに提供する。リスク評価の提供は、リスク評価を示す情報要素を第１端末１０に送信する処理を含む。支援サーバ３０の詳細については後述する。

（支援サーバ）
以下において、実施形態に係る支援サーバについて説明する。図２は、実施形態に係る支援サーバ３０を示す図である。図２に示すように、支援サーバ３０は、通信部３１と、管理部３２と、制御部３３と、を有する。

通信部３１は、通信モジュールによって構成される。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTE、5Gなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3などの規格に準拠する有線通信モジュールであってもよい。

例えば、通信部３１は、管理部３２によって管理されるデータ（例えば、対象エンティティのリスク評価）を第１端末１０に送信してもよい。通信部３１は、セキュリティ対策に関する質問のリスト（以下、チェックリスト）を第２端末２０に送信してもよい。通信部３１は、チェックリストに対する回答を第２端末２０から受信してもよい。

管理部３２は、不揮発性メモリ、HDD（Hard Disk Drive）、SSD（Solid State Drive）、磁気テープなどの記憶媒体によって構成される。

実施形態では、管理部３２は、第１ユーザエンティティと第１対象エンティティとの対応関係を管理する。管理部３２は、第１対象エンティティのセキュリティ対策に関するリスク評価を第１対象エンティティと対応付けて管理する。

例えば、第１ユーザエンティティが“AAA”であり、第１対象エンティティが“aaa”、“bbb”及び“ccc”であるケースについて例示する。

第１に、管理部３２は、図３に示すように、対象エンティティとリスク評価とを対応付けて管理（格納）する。管理部３２は、対象エンティティ及びリスク評価に加えて、第１ユーザエンティティとは異なる第２ユーザエンティティに対するリスク評価の提供を許諾するか否かを示す情報要素（図３では、許諾（提供））を管理してもよい。許諾（提供）がOKである情報要素は、リスク評価の提供に関する第１対象エンティティの許諾があることを意味する情報要素である。許諾（提供）がNGである情報要素は、リスク評価の提供に関する第１対象エンティティの許諾がないことを意味する情報要素である。例えば、図３では、“aaa”及び“bbb”は、“AAA”以外のユーザエンティティへのリスク評価の提供を許諾しており、“ccc”は、“AAA”以外のユーザエンティティへのリスク評価の提供を許諾していないケースが例示されている。

なお、実施形態では、第１ユーザエンティティ（“AAA”）に対するリスク評価の提供が許諾されている前提であるため、図３では、許諾（提供）は、第２ユーザエンティティに対するリスク評価の提供を許諾するか否かを示す情報要素である。しかしながら、実施形態はこれに限定されるものではない。許諾（提供）は、第１対象エンティティがリスク評価の提供を許諾するユーザエンティティを特定する情報要素であればよい。例えば、許諾（提供）は、第１対象エンティティがリスク評価の提供を許諾するユーザエンティティを指定する情報要素であってもよく、第１対象エンティティがリスク評価の提供を許諾するユーザエンティティの条件を指定する情報要素であってもよい。特に限定されるものではないが、ユーザエンティティの条件は、オペレータと契約を締結しているか否か、ユーザエンティティの信用リスク、ユーザエンティティの規模などを含んでもよい。なお、契約は、利用規約に同意する契約を含んでもよい。契約は、NDA（Non-Disclosure Agreement）契約を含んでもよい。

第２に、管理部３２は、図４に示すように、ユーザエンティティと対象エンティティとの対応関係を管理（格納）する。管理部３２は、ユーザエンティティ及び対象エンティティに加えて、更新されたリスク評価の提供を第１ユーザエンティティに提供することを許諾するか否かを示す情報要素（図４では、許諾（更新））を管理してもよい。許諾（更新）がOKである情報要素は、リスク評価の更新に関する第１対象エンティティの許諾があることを意味する情報要素である。許諾（更新）がNGである情報要素は、リスク評価の更新に関する第１対象エンティティの許諾がないことを意味する情報要素である。例えば、図４では、“aaa”及び“bbb”は、“AAA”への更新されたリスク評価の提供を許諾しており、“ccc”は、“AAA”への更新されたリスク評価の提供を許諾していないケースが例示されている。

制御部３３は、少なくとも１つのプロセッサを含んでもよい。少なくとも１つのプロセッサは、単一の集積回路によって構成されてもよく、通信可能に接続された複数の回路（集積回路及び又はディスクリート回路（discrete circuits）など）によって構成されてもよい。

例えば、制御部３３は、対象エンティティから提供された情報に基づいて、対象エンティティのセキュリティ対策に関するリスク評価を取得する。例えば、制御部３３は、“aaa”～“ccc”から提供された情報に基づいて“aaa”～“ccc”のリスク評価を取得してもよい。対象エンティティから提供された情報は、チェックリストに対する対象エンティティの回答であってもよい。

さらに、制御部３３は、第１対象エンティティから提供された情報に基づいてリスク評価を更新してもよい。第１対象エンティティから提供された情報は、チェックリストに対する対象エンティティの回答であってもよい。

ここで、チェックリストは、セキュリティ対策に関する複数の質問項目を含む。図５に示すように、質問項目は、S：戦略に関する質問項目、P：人・組織に関する質問項目、O：運用に関する質問項目、T：技術に関する質問項目を含んでもよい。なお、チェックリストは、オペレータによって策定されたものであってもよい。

リスク評価は、チェックリストに対する回答に基づいて取得されてもよい。図６に示すように、対象エンティティの名称及びリスク評価を含んでもよい。リスク評価は、総合リスク評価（図６では、“XX”）、機密性（C）に関するリスク評価（図６では、“PP”）、完全性（I）に関するリスク評価（図６では、“QQ”）及び可用性（A）に関するリスク評価（図６では、“RR”）を含んでもよい。“XX”は、“PP”、“QQ”及び“RR”に基づいて取得される。

“XX”、“PP”、“QQ”及び“RR”は、数値によって表されてもよい。このようなケースにおいて、“XX”は、“PP”、“QQ”及び“RR”の平均値であってもよく、“XX”は、“PP”、“QQ”及び“RR”の合計値であってもよい。“PP”、“QQ”及び“RR”は、異なる係数によって重み付けされてもよい。

或いは、“XX”、“PP”、“QQ”及び“RR”の少なくともいずれか１つは、抽象的なレベルやランクなどの指標によって表されてもよい。

ここで、リスク評価は、他のエンティティのリスク評価と関係なく取得される絶対的な評価であってもよく、他のエンティティのリスク評価との関係を考慮して取得される相対的な評価であってもよい。

なお、リスク評価は、ISO27000シリーズ（例えば、ISO27001）などの規格に準拠する評価であってもよく、オペレータが独自に実行する評価であってもよい。

このような背景下において、制御部３３は、管理部３２によって管理される第１対象エンティティのリスク評価を第１ユーザエンティティに提供する。制御部３３は、第１対象エンティティのリスク評価が更新された場合に、第１対象エンティティと対応付けられた第１ユーザエンティティに対して、更新されたリスク評価を提供する。制御部３３は、リスク評価の更新に関する第１対象エンティティの許諾がある場合に、更新されたリスク評価を提供してもよい。

例えば、図４に示すケースを例に挙げると、“aaa”及び“bbb”のリスク評価が更新された場合に、制御部３３は、更新されたリスク評価を“AAA”に提供する。一方で、“ccc”のリスク評価が更新された場合に、制御部３３は、更新されたリスク評価を“AAA”に提供しない。なお、“ccc”は、“AAA”以外のユーザエンティティに対して、更新されたリスク評価の提供を許諾していてもよい。

さらに、制御部３３は、第１対象エンティティのリスク評価の取得を第２ユーザエンティティから要求された場合に、管理部３２で管理されているリスク評価を第２ユーザエンティティに提供してもよい。制御部３３は、リスク評価の提供に関する第１対象エンティティの許諾がある場合に、管理部３２で管理されているリスク評価を提供してもよい。

例えば、図３に示すケースを例に挙げると、“aaa”及び“bbb”のリスク評価を“BBB”から要求された場合に、制御部３３は、“aaa”及び“bbb”のリスク評価を“BBB”に提供する。一方で、“ccc”のリスク評価を“BBB”から要求された場合に、制御部３３は、“ccc”のリスク評価を“BBB”に提供しない。

（リスク評価支援方法）
以下において、実施形態に係るリスク評価支援方法について説明する。図７～図９は、実施形態に係るリスク評価支援方法を示す図である。ここでは、ユーザエンティティが“AAA”及び“BBB”であり、対象エンティティが“aaa”、“bbb”及び“ccc”であるケースについて例示する。

第１に、ユーザエンティティが対象エンティティのリスク評価を取得するケースについて図７を参照しながら説明する。図７は、リスク評価の取得を示すシーケンス図である。

なお、図７に示すシーケンスの初期段階において、“AAA”は、支援サーバ３０において対象エンティティと対応付けられていないため、第２ユーザエンティティであると考えてもよい。同様に、“aaa”、“bbb”及び“ccc”は、支援サーバ３０においてユーザエンティティと対応付けられていないため、第２対象エンティティであると考えてもよい。

図７に示すように、ステップS10において、支援サーバ３０（オペレータ）は、第１端末１０Ａ（ユーザエンティティ“AAA”）と契約を結ぶ。例えば、契約は、利用規約に同意する契約を含んでもよい。

ステップS20において、第１端末１０Ａは、対象エンティティのリスク評価の評価要求を支援サーバ３０に送信する。評価要求は、少なくとも対象エンティティ（例えば、“aaa”～“ccc”）を指定する情報要素を含む。

ステップS21において、支援サーバ３０は、評価要求によって特定される対象エンティティのリスク評価を既に管理しているか否かを判定する。ここでは、対象エンティティのリスク評価が管理されていないものとして説明を続ける。

ステップS22において、支援サーバ３０（オペレータ）は、第２端末２０（対象エンティティ“aaa”～“ccc”）と契約を締結する。対象エンティティは、ステップS20においてリスク評価が要求された対象であってもよい。例えば、契約は、利用規約に同意する契約を含んでもよい。契約は、図３に示す許諾（提供）を含んでもよく、図４に示す許諾（更新）を含んでもよい。

ステップS30において、支援サーバ３０は、チェックリストを第２端末２０に送信する。上述したように、チェックリストは、セキュリティ対策に関する複数の質問項目を含む（図５を参照）。

ステップS31において、支援サーバ３０は、チェックリストに対する回答を第２端末２０から受信する。

ステップS32において、支援サーバ３０は、チェックリストに対する回答に不備があるか否かを確認する。チェックリストに対する回答に不備がある場合には、支援サーバ３０は、チェックリストに対する回答の修正要求を第２端末２０に送信し（ステップS33）、修正要求に対する修正回答を端末20から受信する（ステップS34）。ステップS33及びステップS34は、チェックリストに対する回答の不備が解消するまで実行される。チェックリストに対する回答に不備がない場合には、ステップS33及びステップS34の処理は省略される。

ステップS35において、支援サーバ３０は、第１端末１０Ａにリスク評価を送信する。リスク評価は、第２端末２０から受信する情報（チェックリストに対する回答）に基づいて取得される。

図７に示す動作の結果、支援サーバ３０は、“AAA”と“aaa”～“ccc”との対応関係が管理される。言い換えると、支援サーバ３０は、第１対象エンティティ（“aaa”～“ccc”）のリスク評価を管理するとともに、第１ユーザエンティティ（“AAA”）と第１対象エンティティ（“aaa”～“ccc”）との対応関係を管理する。図７に示す動作によれば、支援サーバ３０は、対象エンティティのリスク評価をユーザエンティティに代わって取得した上で、対象エンティティのリスク評価をユーザエンティティに提供することができる。

第２に、支援サーバ３０によって管理されるリスク評価を第２ユーザエンティティが取得するケースについて図８を参照しながら説明する。

なお、図８に示すシーケンスの初期段階として、第１ユーザエンティティ（“AAA”）と第１対象エンティティ（“aaa”～“ccc”）との対応関係が既に管理されているケースについて説明する。また、“BBB”は、支援サーバ３０において対象エンティティと対応付けられていないため、第２ユーザエンティティである。

図８では、ステップS40において、支援サーバ３０（オペレータ）が第２端末２０（対象エンティティ）と契約を既に締結しているケースについて説明する。

図８に示すように、ステップS51において、支援サーバ３０（オペレータ）は、第１端末１０Ｂ（第２ユーザエンティティ“BBB”）と契約を結ぶ。例えば、契約は、利用規約に同意する契約を含んでもよい。

ステップS52において、第１端末１０Ｂは、支援サーバ３０によって管理されているリスク評価の評価要求を支援サーバ３０に送信する。ここでは、評価要求は、支援サーバ３０で管理されている第１対象エンティティ（例えば、“aaa”～“ccc”）を指定する情報要素を含む。

ステップS53において、支援サーバ３０は、リスク評価の提供に関する第１対象エンティティの許諾があるか否かを判定する。第１対象エンティティの許諾がある場合には、支援サーバ３０は、支援サーバ３０で管理されているリスク評価を第１端末１０Ｂに送信する（ステップS54）。

例えば、図３に示すケースを例に挙げると、“aaa”又は“bbb”のリスク評価が要求された場合には、支援サーバ３０は、“aaa”又は“bbb”のリスク評価を第１端末１０Ｂに送信する。一方で、“ccc”のリスク評価が要求された場合には、支援サーバ３０は、“ccc”のリスク評価を第１端末１０Ｂに送信しない。このようなケースにおいて、支援サーバ３０は、リスク評価を提供できない旨を示すメッセージを第１端末１０Ｂに送信してもよい。

図８に示す動作の結果、支援サーバ３０は、“BBB”と“aaa”又は“bbb”との対応関係が管理される。言い換えると、支援サーバ３０は、“aaa”又は“bbb”との関係においては、“BBB”が第１ユーザエンティティとして扱ってもよい。但し、“ccc”の関係においては、“BBB”は第２ユーザエンティティのままである。

図８では、第１対象エンティティの許諾（提供）が事前に支援サーバ３０に登録されているケースについて例示しているが、実施形態は、これに限定されるものではない。例えば、支援サーバ３０は、第１端末１０Ｂ（第２ユーザエンティティ）からリスク評価の評価要求を受信した場合に、第２ユーザエンティティに対してリスク評価の提供を許可するか否かを問い合わせる問合せメッセージを第２端末２０（第１対象エンティティ）に送信してもよい。支援サーバ３０は、問合せメッセージに対する応答メッセージに基づいて、リスク評価の提供に関する第１対象エンティティの許諾があるか否かを判定してもよい。

第３に、支援サーバ３０によって管理されるリスク評価が更新されるケースについて図９を参照しながら説明する。

なお、図９に示すシーケンスの初期段階として、第１ユーザエンティティ（“AAA”）と第１対象エンティティ（“aaa”～“ccc”）との対応関係が既に管理されているケースについて説明する。また、“aaa”又は“bbb”との関係においては、“BBB”が第１対象エンティティとして扱われるケースについて説明する。

図９に示すように、ステップS60において、支援サーバ３０は、更新情報を第２端末２０（例えば、第１対象エンティティ“aaa”～“ccc”）から受信する。更新情報は、上述したチェックリストに対する回答の更新情報であってもよい。更新情報は、未だ回答していない質問に対する回答を含んでもよく、既に回答した質問に対する新たな回答を含んでもよい。

ステップS61において、支援サーバ３０は、更新情報に基づいてリスク評価を更新する。

ステップS62において、支援サーバ３０は、更新されたリスク評価を第１ユーザエンティティ（“AAA”又は“BBB”）に提供できるか否かを判定する。

例えば、支援サーバ３０は、支援サーバ３０で第１対象エンティティと対応付けられている第１ユーザエンティティに対して更新されたリスク評価を提供できると判定してもよい。支援サーバ３０は、支援サーバ３０で第１対象エンティティと対応付けられていない第２ユーザエンティティに対して更新されたリスク評価を提供できないと判定してもよい。なお、支援サーバ３０は、更新されたリスク評価を提供できると判定した場合に、更新されたリスク評価を第１端末１０に送信する。

或いは、支援サーバ３０は、リスク評価の更新に関する第１対象エンティティの許諾があるか否かを判定する。第１対象エンティティの許諾がある場合には、支援サーバ３０は、更新されたリスク評価を第１端末１０Ａに送信する（ステップS63A）。同様に、第１対象エンティティの許諾がある場合には、支援サーバ３０は、更新されたリスク評価を第１端末１０Ｂに送信する（ステップS63B）。

例えば、図４に示すケースを例に挙げると、“aaa”又は“bbb”のリスク評価が更新された場合には、支援サーバ３０は、“aaa”又は“bbb”のリスク評価を第１端末１０Ａに送信する。一方で、“ccc”のリスク評価が更新された場合には、支援サーバ３０は、“ccc”のリスク評価を第１端末１０Ａに送信しない。このようなケースにおいて、支援サーバ３０は、リスク評価を提供できない旨を示すメッセージを第１端末１０Ａに送信してもよい。

なお、図４では、“aaa”又は“bbb”との関係において“BBB”が第１ユーザエンティティとして取り扱われるケースについて例示していない。“aaa”又は“bbb”がリスク評価の更新に関する許諾を“AAA”と同様に“BBB”に与えている場合には、支援サーバ３０は、“aaa”又は“bbb”のリスク評価を第１端末１０Ｂに送信してもよい。但し、“ccc”の関係においては“BBB”は第２ユーザエンティティのままであるため、“ccc”のリスク評価が更新されても、第１端末１０Ｂに対する処理は特に実行されなくてもよい。

図９では、第１対象エンティティの許諾（更新）が事前に支援サーバ３０に登録されているケースについて例示しているが、実施形態は、これに限定されるものではない。例えば、支援サーバ３０は、第１ユーザエンティティに対して更新されたリスク評価の提供を許可するか否かを問い合わせる問合せメッセージを第２端末２０（第１対象エンティティ）に送信してもよい。支援サーバ３０は、問合せメッセージに対する応答メッセージに基づいて、リスク評価の更新に関する第１対象エンティティの許諾があるか否かを判定してもよい。

（作用及び効果）
実施形態では、支援サーバ３０は、リスク評価の取得要求に応じて、対象エンティティのリスク評価をユーザエンティティに提供する。言い換えると、支援サーバ３０は、対象エンティティのリスク評価の取得を代行する。このような構成によれば、リスク評価の取得に伴うユーザエンティティの煩雑さを軽減することができる。

実施形態では、支援サーバ３０は、第１ユーザエンティティと第１対象エンティティとの対応関係を管理している前提下において、第１対象エンティティのリスク評価が更新された場合に、第１対象エンティティと対応付けられた第１ユーザエンティティに対して、更新されたリスク評価を提供する。このような構成によれば、第１ユーザエンティティが最新版のリスク評価を容易に取得することができ、リスク評価の取得に伴うユーザエンティティの煩雑さを軽減することができる。

実施形態では、支援サーバ３０は、第１対象エンティティと対応付けられた第１ユーザエンティティに対して、更新されたリスク評価を提供する。さらに、支援サーバ３０は、リスク評価の更新に係る許諾がある場合に、更新されたリスク評価を提供してもよい。このような構成によれば、更新されたリスク評価が無制限に提供される事態を抑制することができ、第１対象エンティティが望まないリスク評価の提供を抑制することができる。

実施形態では、支援サーバ３０は、対象エンティティのリスク評価の取得を第２ユーザエンティティから要求された場合に、管理部３２で管理されているリスク評価を第２ユーザエンティティに提供してもよい。このような構成によれば、対象エンティティのリスク評価を改めて取得する支援サーバ３０（オペレータ）の負荷を軽減することができる。

実施形態では、支援サーバ３０は、リスク評価の提供に係る許諾がある場合に、管理部３２で管理されているリスク評価を提供してもよい。このような構成によれば、更新されたリスク評価が無制限に提供される事態を抑制することができ、第１対象エンティティが望まないリスク評価の提供を抑制することができる。

実施形態では、対象エンティティのリスク評価は、対象エンティティから提供された情報に基づいて取得されてもよい。このようなケースにおいて、対象エンティティのリスク評価が無制限に提供される事態の抑制は対象エンティティにとって極めて重要であることに留意すべきである。

［変更例１］
以下において、実施形態の変更例１について説明する。以下においては、実施形態に対する相違点について主として説明する。

実施形態では、支援サーバ３０は、対象エンティティから提供された情報（例えば、チェックリストに対する回答）に基づいて、対象エンティティのセキュリティ対策に関するリスク評価を取得する。これに対して、変更例１では、支援サーバ３０は、対象エンティティについて公開された情報に基づいて、対象エンティティのセキュリティ対策に関するリスク評価を取得する。特に限定されるものではないが、対象エンティティについて公開された情報は、インターネットなどの手段で取得される情報を含んでもよく、雑誌や書籍などの刊行物などの手段で取得される情報を含んでもよい。例えば、対象エンティティについて公開された情報は、対象エンティティのWebサイトから得られる情報であってもよく、対象エンティティによって提供されるソフトウェア又はアプリケーションに関する情報を含んでもよい。対象エンティティについて公開された情報は、対象エンティティが秘密に保持すべきものと指定した秘密情報以外の情報であればよい。

（リスク評価支援方法）
以下において、変更例１に係るリスク評価支援方法について説明する。図１０は、変更例１に係るリスク評価支援方法を示す図である。ここでは、図７に示すシーケンスにおいて、チェックリストに対する回答を対象エンティティが拒否するケースについて説明する。図１０では、図７と同様の処理について同様のステップ番号を付しているため、図７と同様の処理の説明については省略する。

図１０に示すように、ステップS71において、支援サーバ３０は、チェックリストに対する回答を拒否するメッセージを第２端末２０から受信する。

ステップS72において、支援サーバ３０は、対象エンティティについて公開された情報に基づいて、対象エンティティのセキュリティ対策に関するリスク評価を取得する。

ステップS73において、支援サーバ３０は、ステップS72で取得されたリスク評価を第１端末１０Ａに送信する。

図７と同様に、図１０に示す動作の結果、支援サーバ３０は、“AAA”と“aaa”～“ccc”との対応関係が管理される。言い換えると、支援サーバ３０は、第１対象エンティティ（“aaa”～“ccc”）のリスク評価を管理するとともに、第１ユーザエンティティ（“AAA”）と第１対象エンティティ（“aaa”～“ccc”）との対応関係を管理する。図７に示す動作の結果、支援サーバ３０は、対象エンティティのリスク評価をユーザエンティティに提供することができる。

ここで、対象エンティティについて公開された情報に基づいて取得されたリスク評価については、提供及び更新に関する第１対象エンティティの許諾は不要であると考えられる。従って、支援サーバ３０は、第１対象エンティティの許諾を必要とせずに、第１対象エンティティのリスク評価を第２ユーザエンティティに提供してもよく、更新されたリスク評価を第１ユーザエンティティに提供してもよい。

［変更例２］
以下において、実施形態の変更例２について説明する。以下においては、実施形態に対する相違点について主として説明する。

実施形態では、対象エンティティ毎にリスク評価が取得されるが、変更例２では、対象エンティティが２以上のサービスを提供する場合には、対象エンティティが提供するサービス毎にリスク評価が取得される。また、変更例２では、対象エンティティがチェックリストに対する回答状況を確認する画面（確認画面）について説明する。このようなケースにおいて、支援サーバ３０は、確認画面を表示するためのデータを管理しており、確認画面を表示するためのデータを第２端末２０に送信してもよい。

ここでは、対象エンティティが“aaa”であり、“aaa”が提供するサービスが“PPP”～“RRR”であるケースについて例示する。特に限定されるものではないが、サービスは、ユーザエンティティが用いる可能性があるソフトウェア又はアプリケーションを含んでもよい。サービスは、クラウドサービス又はSaaS（Service as a Software）の形態で提供されてもよい。

図１１に示すように、確認画面は、ユーザエンティティと、サービスと、進捗状況と、ステータスと、回答者と、を含んでもよい。

ユーザエンティティは、“aaa”のリスク評価の取得を依頼するエンティティを示す項目である。図１１に示すように、異なるサービスのリスク評価の取得を同一のユーザエンティティ（例えば、AAA）が依頼してもよい。

サービスは、“aaa”によって提供されるサービスを示す項目である。図１１では、サービスとして“PPP”～“RRR”が例示されている。

進捗状況は、チェックリストに対する回答の進捗を示す項目である。例えば、進捗状況は、チェックリストに含まれる質問の総数と回答済みの質問の数との比率によって表されてもよい。

ステータスは、チェックリストに対する回答のステータスを示す項目である。ステータスは、“回答中”、“回答確認中”、“回答済”、“拒否”などを含んでもよい。“回答中”は、“aaa”においてチェックリストに対する回答を行っている途中であることを意味する。“回答確認中”は、支援サーバ３０（オペレータ）においてチェックリストに対する“aaa”の回答を確認している途中であることを意味する。“回答済”は、チェックリストに対する“aaa”の回答及び支援サーバ３０の確認の双方が完了していることを意味する。“拒否”は、チェックリストに対する回答を“aaa”が拒否したことを意味する。

回答者は、チェックリストに対する回答を作成又は入力する回答者を示す項目である。回答者は、１人の回答者であってもよく、２人以上の回答者であってもよい。

上述したように、対象エンティティは、ユーザエンティティ及びサービスとの関係でチェックリストに対する回答を行う。チェックリストに対する回答は、支援サーバ３０においてリスク評価の取得に用いられる。言い換えると、対象エンティティは、ユーザエンティティ及びサービスとの関係でリスク評価を提供するか否か（チェックリストに回答するか否か）を決定することができ、チェックリストに対する回答状況を確認することができる。

このような背景下において、対象エンティティによって閲覧される確認画面は、支援サーバ３０によって管理されるデータに基づいて生成される。従って、支援サーバ３０は、図１１に示す対応関係を特定するためのデータを管理している。すなわち、支援サーバ３０は、ユーザエンティティ、対象エンティティ及びサービスの組合せに対して、チェックリストに対する回答状況を管理する。また、支援サーバ３０は、ユーザエンティティ、対象エンティティ及びサービスの組合せに対して、サービスのリスク評価を管理してもよい。さらに、支援サーバ３０は、ユーザエンティティ、対象エンティティ及びサービスの組合せに対して、図３に示す許諾（提供）を管理してもよく、図４に示す許諾（更新）を管理してもよい。

［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。

実施形態では、対象エンティティと契約を締結する段階で、リスク評価の提供に関する対象エンティティの許諾が取得されるケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。支援サーバ３０は、所定トリガに応じて、リスク評価の提供に関する許諾を対象エンティティに問い合わせてもよい。所定トリガは、第２ユーザエンティティからリスク評価の提供を要求されることであってもよい。

実施形態では、対象エンティティと契約を締結する段階で、リスク評価の更新に関する対象エンティティの許諾が取得されるケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。支援サーバ３０は、所定トリガに応じて、リスク評価の更新に関する許諾を対象エンティティに問い合わせてもよい。所定トリガは、対象エンティティのリスク評価が更新されることであってもよい。

実施形態では、ユーザエンティティ“AAA”が対象エンティティ“aaa”～“ccc”との関係で第１ユーザエンティティとして扱われるケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。ユーザエンティティ“AAA”は、対象エンティティ“ddd”との関係では第２ユーザエンティティとして扱われてもよい。すなわち、第１ユーザエンティティ及び第２ユーザエンティティの用語は、支援サーバ３０においてユーザエンティティと対象エンティティとの対応関係が管理されているか否かで判断されてもよい。

実施形態では特に触れていないが、支援サーバ３０は、第１対象エンティティのリスク評価が更新された場合に、更新されたリスク評価を自律的に第１ユーザエンティティに提供してもよい。或いは、支援サーバ３０は、第１対象エンティティのリスク評価が更新された場合に、リスク評価が更新された旨を第１ユーザエンティティに通知するとともに、第１ユーザエンティティから要求された場合に、更新されたリスク評価を第１ユーザエンティティに提供してもよい。

実施形態では特に触れていないが、対象エンティティのリスク評価は、対象エンティティについて公開された情報に基づいて更新されてもよい。

実施形態では特に触れていないが、支援サーバ３０が有する機能は、クラウドサービス又はSaaS（Service as a Software）の形態で提供されてもよい。

実施形態では、リスク評価支援システム１００は、第１端末１０及び第２端末２０を含むケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。リスク評価支援システム１００は、第１端末１０及び第２端末２０を含まずに支援サーバ３０を含んでもよい。

１０…第１端末、２０…第２端末、３０…支援サーバ、３１…通信部、３２…管理部、３３…制御部、１００…リスク評価支援システム、１１０…ネットワーク

Claims (4)

1. 第１対象エンティティに対して質問のリストを送信し、前記質問に対する回答を受信する通信部と、
   前記回答に基づいて取得された前記第１対象エンティティのセキュリティ対策に関するリスク評価を前記第１対象エンティティと対応付けて管理する管理部と、
   前記回答の更新情報に基づいて前記リスク評価を更新する制御部と、を備え、
   前記管理部は、第１ユーザエンティティから前記リスク評価が要求され、前記リスク評価が前記第１ユーザエンティティに提供された場合に、前記第１ユーザエンティティと前記第１対象エンティティとの対応関係を管理し、
   前記制御部は、前記リスク評価が更新された場合に、前記リスク評価の更新に関する前記第１対象エンティティの許諾がなければ、更新されたリスク評価を前記第１ユーザエンティティに提供せずに、前記リスク評価の更新に関する前記第１対象エンティティの許諾があれば、前記更新されたリスク評価を前記第１ユーザエンティティに提供する、リスク評価支援システム。
2. 前記制御部は、前記リスク評価の取得を第２ユーザエンティティから要求された場合に、前記管理部で管理されている前記リスク評価を前記第２ユーザエンティティに提供する、請求項１に記載のリスク評価支援システム。
3. 前記制御部は、前記第２ユーザエンティティに対する前記リスク評価の提供に関する前記第１対象エンティティの許諾がある場合に、前記管理部で管理されている前記リスク評価を提供する、請求項２に記載のリスク評価支援システム。
4. 前記制御部は、前記第１対象エンティティについて公開された情報に基づいて、前記第１対象エンティティのセキュリティ対策に関するリスク評価を取得する、請求項１乃至請求項３のいずれか１項に記載のリスク評価支援システム。

Images