(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
本発明の実施の形態に係るセキュリティ状態可視化方法、プログラム及びシステムについて説明する。但し、本発明が以下の実施の形態に限定される訳ではない。また、説明を明確にするため、以下の記載及び図面は、適宜、簡略化されている。なお、以下の説明においては、SNSの一例としてtwitter(登録商標)を挙げているが、他のSNSでもよい。
【0012】
図1は、本実施の形態によるセキュリティ状態可視化システムの概略を示したブロック図である。セキュリティ状態可視化システム1は、ユーザーが使用する通信機器2と、twitterサーバ3と、外部サーバ4と、を備えている。
【0013】
通信機器2は、演算処理部2aと画面表示部2bと情報入力部2cとを備えており、例えば携帯電話、スマートフォン、パソコンなど、外部とのネットワーク通信機能(外部通信機能)を持った機器である。通信機器2は、図示を省略した記憶部からクライアントや認証アプリを演算処理部2aが読み出して処理することによって、twitterや後述のセキュリティ状態可視化処理などを実行する。
【0014】
画面表示部2bは、通信機器2が持つ表示手段の一具体例であり、認証アプリの情報など任意の情報を表示する。画面表示部2bは、例えば液晶ディスプレイ装置、有機又は無機ELディスプレイ装置などにより構成されている。
図2は、画面表示部2bのイメージ図である。図示例では認証アプリが実行されることによって評価されたセキュリティ状態を示す情報を表示している。なお、通信機器2が表示可能な情報は、セキュリティ状態を示す情報だけではない。
【0015】
情報入力部2cは、情報の入力/選択手段の一具体例であり、ユーザーが操作を行い、その操作に応じた入力情報を出力する機能を持つ。情報入力部2cは、例えばパソコンのキーボードやマウス、携帯電話のボタン、タッチパネルなどの入力機器で構成されている。ユーザーは、情報入力部2cを用いて、例えば認証アプリにアカウント名やパスワード、twitterのツイート公開の有無など任意の情報を入力できる。情報入力部2cで入力された情報は、取得情報管理部で管理される。
【0016】
認証アプリ(セキュリティ状態可視化プログラム)は、演算処理部2aによって実行される機能の1つであり、ユーザーのセキュリティ危険度を示す情報と、フォロワーのセキュリティ危険度を示す情報と、に基づいて現在のユーザーのtwitter上でのセキュリティ状態を評価する可視化処理部に加え、twitterサーバ3から取得したアカウント関連情報及び情報入力部2cから入力された情報などを管理する取得情報管理部、可視化処理部や取得情報管理部などで使用する情報を管理する内部DB部を備えている。本発明の一実施の形態に係わる認証アプリは、評価したセキュリティ状態を示す情報を画面表示部2bに表示する。これにより、twitter上でのセキュリティ状態を容易に認識することが可能になる。
【0017】
詳細には、認証アプリは、例えばWEB(World Wide Web)アプリケーション、スマートフォンのアプリケーション、携帯電話のアプリケーション、など任意の機器の機能(もしくはサービス)として演算処理部2aで動作する。また、認証アプリが実行する機能は、本発明で説明するセキュリティ状態可視化処理のみに限らず、他の機能を有する場合もある。
【0018】
認証アプリは、twitterのクライアントと連携を行うプログラムであり、twitterのクライアントと連携が取れている場合のみ正常に動作する。また、twitterのクライアントに連携アプリとして登録する際に設定した権限(読み込み権限、読み込み書込み権限)で実行可能なAPI(Application Program Interface)を実行することで、ユーザーの管理しているtwitterのユーザーアカウント関連情報を取得することができる。
【0019】
認証アプリは、通信機器2の持つ外部通信機能を用いてtwitterサーバ3とネットワーク通信を行う。認証アプリはtwitterのクライアントと連携を行うため、ユーザーに画面表示部2bを介して、OAuth認証によるアクセストークンの取得を促す画面を表示する(表示する画面は任意)。ユーザーが認証の手続きを行うと、認証アプリを使用している通信機器2の画面表示部2bに認証アプリのアクセス許可の可否を求める画面が表示される。ユーザーが“許可する“を選択することで、認証アプリはユーザーアカウント関連情報を取得可能となる。なお、認証方法は、ユーザーが利用するSNSによって適宜変更される。
【0020】
可視化処理部は、セキュリティ状態で判別した、ユーザーのセキュリティ危険度を示す情報と、フォロワーのセキュリティ危険度を示す情報と、に基づいて、画面表示部2bに表示するセキュリティ状態を示す情報を作成する。
【0021】
詳細には、可視化処理部は、セキュリティ状態評価部を備えており、セキュリティ状態評価部は、取得情報管理部と内部DB部からセキュリティ状態の評価に必要な情報を取得し、ユーザーのセキュリティ危険度と、フォロワーのセキュリティ危険度と、上記2点に基づいてユーザーのtwitter上でのセキュリティ状態と、を評価する。
【0022】
取得情報管理部は、外部通信機能を用いてtwitterサーバ3から取得した情報と、ユーザーが情報入力部2cを用いて入力した情報と、を管理する。取得情報管理部で管理する情報は、可視化処理部が必要とする情報のみとは限らない。
【0023】
内部DB部は、可視化処理部がセキュリティ状態を評価するために必要な内部情報を管理する。また、内部DB部は通信機器2の外部通信機能を用いて、定期的に外部サーバ4と通信を行い、セキュリティ状態評価用の情報を外部サーバ4から取得する。また、セキュリティ状態評価部が取得情報管理部から取得した情報から解析した情報(例えば、ユーザーが使用しているクライアント情報)を定期的に外部サーバ4に送信する。
【0024】
次に、
図3を参照してtwitterのクライアント上でのユーザーのツイート閲覧状態について具体的に説明する。
図3(a)及び(b)は、ツイートを一般公開しているユーザーと、ツイートを全体に公開していないユーザーと、のツイート閲覧状態などを説明する図である。
図3(c)は、公式のクライアントを利用したユーザーと、非公式のクライアントを利用したユーザーと、のツイート閲覧状態などを説明する図である。
【0025】
図3(a)及び(b)に示すように、ツイート公開ユーザーとツイート非公開ユーザーに対して、ユーザーをフォロー状態(ツイートを受信するように登録した状態)のユーザーAと、ユーザーを未フォロー状態のユーザーBと、twitterを利用していないユーザーCが表示されている。
【0026】
ツイートを一般公開しているユーザーに関しては、すべてのユーザーがツイートを閲覧可能となっている。ユーザーCのみ、閲覧しかできない状態になっているが、これはtwitterを登録していないため、twitter上でのみ可能な動作が利用できないためである。
【0027】
このように、ツイートを一般公開しているユーザーは、フォローの有無に関係なくツイートの閲覧・引用・拡散が可能になり、ツイートの流出リスクが非常に高くなるため、一般公開しているユーザーはセキュリティレベルが著しく低下することとなる。一方、ツイートを非公開にしているユーザーに関しては、フォロー状態にあるユーザーのみがツイートを閲覧可能な状態になるため、ツイートの拡散リスクは極めて低く、またフォローしているユーザーであってもツイートの引用・拡散が不可能になるため、セキュリティレベルを高く設定できる。
【0028】
しかし、
図3(c)のように、twitter登録ユーザーが使用しているクライアントによって例外が発生する可能性がある。本来、
図3(b)のようにツイート非公開ユーザーのツイートは引用・拡散できないが、非公式のクライアント等を利用する場合、ユーザーにおけるツイートの公開/非公開に関係なくツイートを引用することが可能になるため、引用した内容からツイートが流出する可能性がある。
【0029】
また、ツイートを引用して拡散した場合、誰が・いつ・どのような形で・どのくらいツイートが広がったのかを、ユーザーは判断することができない。そのため、ユーザーをフォローしているユーザーの中で、どのクライアントを使用してツイートをしているのか、(自分がツイートを非公開にしていた場合)ツイートを拡散したことがあるのか、をtwitterサーバ3から取得したツイートの内容から解析し、フォロワーのセキュリティ危険度に反映する必要がある。
【0030】
図4(a)及び(b)は、ユーザーのダイレクトメッセージ(DM)の扱いを説明する図である。ダイレクトメッセージは、ユーザーがフォローし、かつ相手側からもフォローされている状態でのみ使用可能なメッセージ機能であり、またアカウントのツイート公開/非公開に関わらず、内容は第三者に見られることは無い(使用中クライアントの作成者を除く)ため、セキュリティ上安全性の高い機能である。
【0031】
しかし、相手側の通信機器がウイルス感染している場合や、相手側のアカウントのパスワードが不正使用されている場合に、ダイレクトメッセージを使用してユーザーに悪意のある内容のダイレクトメッセージや、不正なリンク先に移動するURL(Uniform Resource Locator)が送られてくる可能性もある。そのため、過去のダイレクトメッセージの内容などを参照し、ダイレクトメッセージが送られてきたユーザーの危険度を判断し、フォロワーのセキュリティ危険度に反映させる必要がある。
【0032】
次に、ユーザーのセキュリティ危険度を評価する方法について詳細に説明する。
図5は、ユーザーのセキュリティ危険度を評価する処理フローを示すフローチャートである。
【0033】
ステップS411において、認証アプリは、ツイートの公開/非公開情報とtwitterで設定しているパスワードの入力画面を画面表示部2bに表示し、ユーザーに情報入力部2cを用いた情報の入力を促す。ユーザーが情報入力部2cを用いて情報を入力すると、認証アプリは入力した情報を取得情報管理部に管理させる。
【0034】
また、認証アプリは、当該入力された情報をユーザーのセキュリティ危険度評価用にセキュリティ状態評価部に送る。セキュリティ状態評価部に送った情報が、過去の状態から変更があった場合、セキュリティ状態評価部は、変更の内容と変更した日時を示す情報を、セキュリティ状態評価部で変更があった回数を示す情報を含め内部DB部に管理させる。
【0035】
ステップS412において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3からユーザーのフォロー/フォロワー数の情報を取得させる。セキュリティ状態評価部は、取得した情報に基づいて、フォローしているユーザーとフォローされているユーザーを照らし合わせ、互いにフォローしているユーザーと、ユーザーのみフォローしているユーザーと、相手からのみフォローされているユーザーと、に分ける。セキュリティ状態評価部は、分けた際のそれぞれの数を示す情報を、解析した日時を示す情報と共に内部DB部に管理させる。
【0036】
ステップS413において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3からユーザーのツイート情報を取得させる。
【0037】
ステップS414において、セキュリティ状態評価部は、ステップS413で取得したツイート情報を解析し、ユーザーがツイート時に使用しているクライアント情報を解析する。このとき、セキュリティ状態評価部は、複数のクライアントを使用している場合は、使用頻度や使用回数も解析する。
【0038】
更に、ステップS414において、セキュリティ状態評価部は、解析したユーザーが使用しているクライアント情報を、内部DB部に管理させているアカウント別の危険度の情報と照らし合わせる。セキュリティ状態評価部は、照らし合わせた情報から、ユーザーのクライアントのセキュリティ危険度を評価する。
【0039】
ステップS415において、セキュリティ状態評価部は、ステップS413で取得したツイート情報を解析し、過去の位置情報付のツイートがあるか否かを判断する。そして、セキュリティ状態評価部は、位置情報が付いたツイートがあった場合、位置情報を解析し、公開した位置情報の分布や、場所別の回数を解析する。
【0040】
ステップS416において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3から自分がツイートした内容と自分が送信したダイレクトメッセージを取得させ、ツイートした内容やダイレクトメッセージの内容を解析する。セキュリティ状態評価部は、解析した内容にURLが含まれていた場合、外部サーバ4と通信を行い、URLのリンク先のチェックを行う。
【0041】
ステップS417において、セキュリティ状態評価部は、ステップS411〜ステップS416に解析した内容に基づいて、ユーザーのセキュリティ危険度を評価する。
【0042】
ここで、ステップS411で入力したツイートの公開/非公開情報について、ユーザーが非公開設定にしていた場合は、ユーザーが許可したフォロワーのみユーザーのツイートが閲覧可能であるため、ツイートの拡散リスクは極めて低くなる。しかし、ステップS412で入力したツイートの”フォロワー数”が多かった場合、閲覧者が多くなる場合や、悪質なユーザーが含まれる可能性も高くなるため、拡散リスクは多少上がる。
【0043】
ステップS413で確認したツイート情報で、画像などを添付したツイートが多い場合、拡散されたくない画像などがフォロワーなどによって拡散されてしまうリスクがある。
【0044】
ステップS414で解析したクライアント情報について、クライアントがtwitter公式のものではない場合、自分のツイートが非公開であっても、クライアントの作成者は内容の確認ができてしまう。また、ダイレクトメッセージも同じように内容が確認できてしまう。更に、クライアントを使用する際に行ったユーザー認証時に、クライアントの作成者はユーザーのパスワード等も取得できるため、アカウントを乗っ取られる可能性も高くなる。そのため、安全性が定かでないクライアントを使用している場合、ユーザーのセキュリティ危険度は大きく上がる。
【0045】
ステップS415で解析したツイートの位置情報設定について、ユーザーが頻繁に位置情報つきのツイートを行っていた場合、そのツイートを閲覧している人にユーザーの行動範囲や住居などを特定されてしまう可能性があるため、セキュリティ上大きなリスクとなる。
【0046】
ステップS416において、ユーザーのツイート/ダイレクトメッセージを解析し、悪意のあるリンク先が記載されたツイートが勝手に行われていた場合、ユーザーのアカウントが乗っ取られている可能性が極めて高くなるため、セキュリティ上大きな問題となる。
【0047】
上述の危惧を考慮して、ユーザーのセキュリティ危険度を評価する方法は、ステップS411〜ステップS416の解析内容を基にパラメータを設定し、その値から評価する。各ステップで設定するパラメータの詳細については、表1に示す。
【0049】
パラメータ値が“3”の項目が1つでもあれば、セキュリティ状態評価部は、ユーザーのセキュリティ危険度は高と評価する。パラメータ値が“2”の項目が2つあれば、セキュリティ状態評価部は、セキュリティ危険度は中、それ以外は低と評価する。ただし、ステップS412とステップS413で解析するフォロワー数と画像添付のツイートについては評価の条件とせず、セキュリティ状態評価部は、画面表示部2bに拡散のリスクがある旨を表示させる。
【0050】
セキュリティ状態評価部は、評価したユーザーのセキュリティ危険度を示す情報を、評価を行った日時を示す情報と共に内部DB部に管理させる。また、セキュリティ状態評価部は、過去の評価結果を示す情報が内部DB部に管理されている場合、当該評価結果と比較し差分を画面表示部2bに表示させる。ここで、最新の評価結果を示す情報のみを内部DB部で管理するようにする。
【0051】
次に、フォロワーのセキュリティ危険度を評価する方法について詳細に説明する。
図6は、フォロワーのセキュリティ危険度を評価する処理フローを示すフローチャートである。
【0052】
図6のセキュリティ危険度の評価は、セキュリティ状態評価部が取得情報管理部にtwitterサーバ3から取得させたユーザー情報からフォロワー情報を取得し、フォロワー全てのアカウント関連情報の解析を行う。なお、
図6ではフォロワーのアカウント1つを解析する手順を説明する。
【0053】
ステップS511において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3からユーザー宛のメッセージ情報(返信情報)を取得させ、メッセージの内容を解析する。内容にURLが含まれていた場合、セキュリティ状態評価部は、外部サーバ4と通信を行い、URLのリンク先のチェックを行う、リンク先が悪意のあるリンク先だった場合、セキュリティ状態評価部は、メッセージを送信したアカウント名を示す情報と時間を示す情報を内部DB部に管理させる。
【0054】
ステップS512において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3からアカウント関連情報を取得させ、当該アカウント関連情報に基づいてツイートの公開/非公開設定を解析する。また、セキュリティ状態評価部は、過去に公開、または非公開であったユーザーの場合は、変更があった時期や回数を記録し、内部DB部に管理させる。
【0055】
ステップS513において、セキュリティ状態評価部は、当該アカウント関連情報に基づいてアカウントのフォロー/フォロワーの人数を示す情報を取得する。また、セキュリティ状態評価部は、フォローしているアカウント数とフォローされているアカウント数の差分を算出し、算出結果を示す情報を内部DB部に管理させる。
【0056】
ステップS514において、セキュリティ状態評価部は、内部DB部が管理するフォローしているアカウント数とフォローされているアカウント数の差分を示す情報に基づいて、フォロー/フォロワーの増減を算出する。セキュリティ状態評価部は、算出結果を示す情報を日時毎に内部DB部に管理させる。なお、セキュリティ状態評価部は、増減を算出する際、比較を行う過去情報が存在しない場合(新たにフォローされたユーザーの場合)、算出は行わずに現在の情報のみを内部DB部に管理させる。
【0057】
ステップS515において、セキュリティ状態評価部は、当該アカウント関連情報に基づいてツイートを行う際に使用しているクライアント情報を解析する。解析方法は
図5のステップS414と略等しい方法を用いることができる。
【0058】
ステップS516において、セキュリティ状態評価部は、当該アカウント関連情報に基づいて解析を行うアカウントのツイート数を算出する。セキュリティ状態評価部は、ツイート数は1日あたりの数を示す情報と、総数(アカウント取得時〜現在までの数)を示す情報と、に分け、各々の情報を内部DB部に管理させる。ちなみに、1日あたりの数というのは、24時間前から情報取得時までの数値である。
【0059】
ステップS517において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ3からアカウントのツイート情報を取得させ、ツイートの内容を解析する。解析対象は、例えばアカウントの最新ツイートから最新20件分である。但し、解析対象の件数は、特に限定されない。解析対象のユーザーがツイートを非公開にしている場合は、解析を行わない。また、自分のフォロワーではあるが、自分はフォローしていないユーザーの場合、ツイートの内容を取得できないため、本ステップではデータを取得しない。
【0060】
ステップS518において、セキュリティ状態評価部は、当該アカウント関連情報から解析を行うアカウントでツイートの引用(公式リツイート、非公式リツイート)が何回行われているかを算出する。非公式RTの場合、APIで検索する方法が提供されていないため、セキュリティ状態評価部は、ツイート中の文章に“RT”や“QT”など、ツイート引用時に付く文字が存在するかを解析することで引用回数を算出する。また、セキュリティ状態評価部は、解析を行うアカウントが自分のツイートを何回引用したかを算出する。セキュリティ状態評価部は、算出結果を示す情報を内部DB部に管理させる。なお、ツイートの引用が存在するか否かの解析方法は、フォロワーが使用するSNSによって適宜変更される。
【0061】
ここで、ステップS518で解析を行う際、セキュリティ状態評価部は、自分のアカウントが非公開設定だった場合にツイートの引用が行われていた場合、行われた際に使用していたアカウント関連情報を含めて内部DB部に管理させる。
【0062】
ステップS519において、セキュリティ状態評価部は、当該アカウント関連情報から解析を行うアカウントが前回解析時も存在していたか否かを解析する。今回の解析で新規に追加されたアカウントの場合、ステップS524に遷移する。前回解析時から存在するアカウントの場合、ステップS520に遷移する。
【0063】
ステップS520において、セキュリティ状態評価部は、解析を行っているアカウントからユーザーが過去にダイレクトメッセージを受信しているか否かを解析する。ユーザーが過去にダイレクトメッセージを受信していなかった場合、ステップS524に遷移する。ユーザーが過去にダイレクトメッセージを受信していた場合、S521に遷移する。
【0064】
ステップS521において、セキュリティ状態評価部は、受信したダイレクトメッセージの内容を解析する。解析方法は、ステップS511と同じ方法を用いることができる。
【0065】
ステップS522において、セキュリティ状態評価部は、ステップS521でダイレクトメッセージの内容を解析した結果により遷移先を決定する。そして、セキュリティ状態評価部は、ステップS521の解析で悪意のあるサイトのURLが貼り付けられていた場合、ステップS523に遷移する。また、セキュリティ状態評価部は、ダイレクトメッセージの内容を解析して問題が無かった場合、ステップS524に遷移する。
【0066】
ステップS523に遷移した場合、解析中のユーザーはアカウントの乗っ取り、もしくは使用中の機器(例えば、携帯電話、スマートフォン、PCなど)がウイルスに感染している可能性が高いユーザーであると判断できるため、セキュリティ状態評価部は、解析中のアカウント情報と解析した日時を示す情報を内部DB部で管理させる。
【0067】
ステップS524において、セキュリティ状態評価部は、ステップS511〜ステップS518に解析した情報と、ステップS521で解析した情報と、を照らし合わせ、ユーザーのセキュリティ危険度を評価する。
【0068】
ここで、ステップS511やステップS521などで自分宛のメッセージや送信したダイレクトメッセージに悪意のあるサイトに遷移するURLが含まれていたアカウントは、ウイルスに感染している可能性や、アカウントの乗っ取りが行われている可能性があるため、セキュリティ状態評価部は、内部DB部にウイルス感染リスクの高いアカウントとして管理させる。
【0069】
ステップS513において、ツイートを非公開にしているユーザーの場合、自分のツイートが引用された場合であっても再度引用される可能性は低いため、ツイートの拡散リスクが低いユーザーと判断できる。しかし、ツイートを非公開にしているユーザーであっても、フォロワー数が多い場合(ステップS513で確認)や、フォロー/フォロワー数の増減が多い場合(ステップS514で確認)は、ツイートを引用してリツイートした場合に閲覧する人数が多くなる可能性があるので、拡散リスクはある程度高くなる。
【0070】
ステップS516でツイート数が多い場合や、ステップS518でツイートの引用数が多いと判断されたアカウントの場合も、自分のツイートが引用される確立が高くなる可能性があるため、拡散リスクが高いアカウントと判断できる。
【0071】
ステップS515で確認した使用中のクライアントに関して、公式アプリケーション以外を用いているユーザーの場合は、クライアントの作成者などに情報が漏れる可能性がある。また、公式以外のアプリケーションの中でも、個人作成のクライアントなどは更に危険性が高い。それ以外に、非公式クライアントの中には、本来引用することができない非公開ユーザーのツイートを引用してリツイートできるものもあり、そういったクライアントを使用している場合はツイートの拡散リスクが大きく上がる。
【0072】
クライアントには、携帯機器(例えば、スマートフォン、携帯電話など)やパソコンで使用されているものだけではなく、ニュースサイトやブログなど、WEB上で使用されるものもある。このクライアントの場合、ツイートの内容がtwitter上だけでなく、投稿したWEB上でも公開される可能性が極めて高いため、WEB上でのツイートの拡散リスクも高くなる。
【0073】
上述の危惧を考慮して、フォロワーのセキュリティ危険度を評価する方法は、ステップS511〜ステップS523の解析内容を基にパラメータを設定し、その値から評価する。各ステップで設定するパラメータの詳細については、表2に示す。
【0075】
セキュリティ状態評価部は、評価したユーザーのセキュリティ危険度を示す情報を、ユーザー毎に解析を行った日時を示す情報と共に内部DB部に管理させる。すでに同じアカウントのセキュリティ危険度を示す情報が内部DB部で管理されている場合は、最新の評価結果と比較し、差分を画面表示部2bで表示させる。また、最新の評価結果を示す情報のみを内部DB部で管理するようにする。
【0076】
次に、
図5と
図6のフローチャートで評価したセキュリティ危険度を示す情報に基づいて、現在のユーザーのSNS上でのセキュリティ状態を評価し、画面表示部2bに表示させるまでの流れを説明する。
図7は、
図5と
図6のフローチャートで評価した情報に基づいて、現在のユーザーのSNS上でのセキュリティ状態を評価し、画面表示部2bに表示させるまでの流れを示すフローチャートである。
【0077】
まず、ユーザーのセキュリティ危険度(
図5のフローチャート)とフォロワーのセキュリティ危険度(
図6のフローチャート)とに基づいて、ステップS611において、セキュリティ状態評価部はユーザーのSNS上でのセキュリティ状態を評価する。
【0078】
セキュリティ状態の評価方法は、ユーザーのセキュリティ危険度の評価結果と、フォロワーのセキュリティ危険度の評価結果と、の組合せにより、高・中・中低・低の4段階で評価する。評価方法の詳細は、表3に示す。
【0080】
セキュリティ状態評価部は、ステップS611で評価した最新の評価結果を示す情報を内部DB部に管理させる。この際、すでに過去の評価結果を示す情報が内部DB部に残っていた場合は、最新の評価結果を示す情報を過去の評価結果を示す情報に上書きして保存する。
【0081】
ステップS612において、セキュリティ状態評価部は、ステップS611での評価結果を示す情報を画面表示部2bへの表示情報に変換する。このとき、表示情報は、ユーザーのセキュリティ危険度の評価結果と、フォロワーのセキュリティ危険度の評価結果と、上記2点から総合的に評価したユーザーのSNS上でのセキュリティ状態と、の3点である。
【0082】
表示情報を表示する際、内部DB部は前回の評価結果を示す情報を管理しているか否かの検索を行う。検索の結果、前回の評価結果を示す情報が残っていた場合、セキュリティ状態評価部は、最新の評価結果と前回の評価結果との比較を行い、比較結果を示す情報も画面表示部2bへの表示情報に変換する。比較結果も画面表示部2bに表示させることで、ユーザーはセキュリティ状態の変化を容易に認識することができる。
【0083】
ステップS613において、セキュリティ状態評価部で作成した表示情報を画面表示部2bに表示させる。通信機器内部で動作している内部アプリ上で、セキュリティ設定状態の表示要求があった場合、認証アプリの画面として表示する。それにより、ユーザーは自分が使用しているアカウントのセキュリティ状態を容易に認識することができる。
【0084】
従来のセキュリティ設定方法では、ユーザー自身が情報の公開範囲やパスワードなどを設定する。この場合、セキュリティ対策はすべてユーザー自身の設定に依存してしまい、設定方法などの知識が乏しい新規ユーザーや通信機器端末などを触る機会が少ないユーザーの場合、セキュリティ対策が行わないままサービスを使用することで、情報流出やウイルス感染につながる可能性がある。
【0085】
また、ユーザー自身がセキュリティ対策を行った場合でも、設定後のセキュリティ状態がどの程度になっているかをユーザー自身が判断することは難しく、ユーザーが望んだレベルのセキュリティ設定がされていないままサービスを利用してしまい、思いがけない情報の流出が起きてしまう可能性がある。
【0086】
更に、ダイレクトメッセージ機能では、ユーザーは危険な情報の有無を意識せず内容を確認する場合もあり、悪質なURLと知らずにリンク先に遷移し、ウイルスに感染してしまう場合などもある。
【0087】
加えて、ユーザー登録が容易であり、なおかつ不特定多数のサービス利用者と交流が可能なSNSの場合、悪質なユーザーであるかどうかの判断はユーザー自身の判断に依存する形になってしまうため、十分な対策方法は確立されていない。
【0088】
本実施の形態のセキュリティ状態可視化方法、プログラム及びシステムによれば、SNS関連の知識の有無に関係なく、自分が使用しているSNS上でのセキュリティ状態を容易に認識することができ、すなわち、SNSのセキュリティ向上に繋がる。
【0089】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で変更することが可能である。
【0090】
例えば、ステップS411で入力したtwitterのパスワードが、長い期間変更されていない場合(例えば、6ヶ月以上)は、パスワードの安全性が下がっている場合がある。そこで、画面表示部2bにパスワードの安全性が低下している旨を示す情報を表示することが好ましい。
【0091】
例えば、パスワードが簡単すぎるものや推測されやすいものの場合(例えば、電話番号、英単語など)、アカウントが乗っ取られる危険性が高くなる。そこで、画面表示部2bにパスワードが推測されやすいものである旨を示す情報を表示することが好ましい。
【0092】
上述した実施の形態の一部または全部は、以下の付記のように記載され得るが、以下の記載に限らない。
【0093】
<付記1>
第1のユーザーのSNS上での書き込みの公開範囲を示す情報及び前記第1のユーザーのクライアント情報に基づいて、前記第1のユーザーのセキュリティ危険度を評価する処理と、
前記書き込みを受信するように登録した第2のユーザーの前記SNS上での書き込みの公開範囲を示す情報及び前記第2のユーザーのクライアント情報に基づいて、前記第2のユーザーのセキュリティ危険度を評価する処理と、
前記第1のユーザーのセキュリティ危険度を示す情報及び前記第2のユーザーのセキュリティ危険度を示す情報に基づいて、前記第1のユーザーの前記SNS上でのセキュリティ状態を判別する処理と、
前記セキュリティ状態を示す情報を表示する処理と、
をコンピュータに実行させるセキュリティ状態可視化プログラム。
【0094】
<付記2>
前記第1のユーザーのセキュリティ危険度を評価する処理では、画像を添付した書き込みが存在するか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価し、
前記セキュリティ状態を示す情報を表示する処理では、前記画像を添付した書き込みが存在すると、前記画像が拡散する可能性がある旨を示す情報を表示する付記1に記載のセキュリティ状態可視化プログラム。
【0095】
<付記3>
前記第1のユーザーのセキュリティ危険度を評価する処理では、前記書き込みに位置情報が含まれているか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価する付記1又は2に記載のセキュリティ状態可視化プログラム。
【0096】
<付記4>
前記第1のユーザーのセキュリティ危険度を評価する処理では、前記第1のユーザーが送信したメッセージの内容にURLが含まれているか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価する付記1乃至3のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0097】
<付記5>
前記第2のユーザーのセキュリティ危険度を評価する処理では、前記第2のユーザーが送信したメッセージの内容にURLが含まれているか否かの解析結果を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記1乃至4のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0098】
<付記6>
前記第2のユーザーのセキュリティ危険度を評価する処理では、前記第2のユーザーが書き込みを受信するように登録した数と、前記第2のユーザーの書き込みを受信するように登録した第3のユーザーの数と、の差分を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記1乃至5のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0099】
<付記7>
前記第2のユーザーのセキュリティ危険度を評価する処理では、前記第2のユーザーが書き込みを受信するように登録した数の増減を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記1乃至6のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0100】
<付記8>
前記第2のユーザーのセキュリティ危険度を評価する処理では、前記第2のユーザーが1日に書き込んだ数、前記第2のユーザーが1日に書き込みを受信した数、又は前記第2のユーザーが1日に送信したメッセージの数を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記1乃至7のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0101】
<付記9>
前記第2のユーザーのセキュリティ危険度を評価する処理では、前記2のユーザーが前記第1のユーザーの書き込みを受信する新規のユーザーか否かの解析結果を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記1乃至8のいずれか1項に記載のセキュリティ状態可視化プログラム。
【0102】
<付記10>
第1のユーザーのSNS上での書き込みの公開範囲を示す情報及び前記第1のユーザーのクライアント情報に基づいて、前記第1のユーザーのセキュリティ危険度を評価する工程と、
前記書き込みを受信するように登録した第2のユーザーの前記SNS上での書き込みの公開範囲を示す情報及び前記第2のユーザーのクライアント情報に基づいて、前記第2のユーザーのセキュリティ危険度を評価する工程と、
前記第1のユーザーのセキュリティ危険度を示す情報及び前記第2のユーザーのセキュリティ危険度を示す情報に基づいて、前記第1のユーザーの前記SNS上でのセキュリティ状態を判別する工程と、
前記セキュリティ状態を示す情報を表示する工程と、
を備えるセキュリティ状態可視化方法。
【0103】
<付記11>
前記第1のユーザーのセキュリティ危険度を評価する工程では、画像を添付した書き込みが存在するか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価し、
前記セキュリティ状態を示す情報を表示する工程では、前記画像を添付した書き込みが存在すると、前記画像が拡散する可能性がある旨を示す情報を表示する付記10に記載のセキュリティ状態可視化方法。
【0104】
<付記12>
前記第1のユーザーのセキュリティ危険度を評価する工程では、前記書き込みに位置情報が含まれているか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価する付記10又は11に記載のセキュリティ状態可視化方法。
【0105】
<付記13>
前記第1のユーザーのセキュリティ危険度を評価する工程では、前記第1のユーザーが送信したメッセージの内容にURLが含まれているか否かの解析結果を示す情報をさらに加えて、前記第1のユーザーのセキュリティ危険度を評価する付記10乃至12のいずれか1項に記載のセキュリティ状態可視化方法。
【0106】
<付記14>
前記第2のユーザーのセキュリティ危険度を評価する工程では、前記第2のユーザーが送信したメッセージの内容にURLが含まれているか否かの解析結果を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記10乃至13のいずれか1項に記載のセキュリティ状態可視化方法。
【0107】
<付記15>
前記第2のユーザーのセキュリティ危険度を評価する工程では、前記第2のユーザーが書き込みを受信するように登録した数と、前記第2のユーザーの書き込みを受信するように登録した第3のユーザーの数と、の差分を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記10乃至14のいずれか1項に記載のセキュリティ状態可視化方法。
【0108】
<付記16>
前記第2のユーザーのセキュリティ危険度を評価する工程では、前記第2のユーザーが書き込みを受信するように登録した数の増減を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記10乃至15のいずれか1項に記載のセキュリティ状態可視化方法。
【0109】
<付記17>
前記第2のユーザーのセキュリティ危険度を評価する工程では、前記第2のユーザーが1日に書き込んだ数、前記第2のユーザーが1日に書き込みを受信した数、又は前記第2のユーザーが1日に送信したメッセージの数を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記10乃至16のいずれか1項に記載のセキュリティ状態可視化方法。
【0110】
<付記18>
前記第2のユーザーのセキュリティ危険度を評価する工程では、前記2のユーザーが前記第1のユーザーの書き込みを受信する新規のユーザーか否かの解析結果を示す情報をさらに加えて、前記第2のユーザーのセキュリティ危険度を評価する付記10乃至17のいずれか1項に記載のセキュリティ状態可視化方法。
【0111】
<付記19>
サーバから取得した第1のユーザーのSNS上での書き込みの公開範囲を示す情報及び前記第1のユーザーのクライアント情報に基づいて、前記第1のユーザーのセキュリティ危険度を評価する処理と、
サーバから取得した前記書き込みを受信するように登録した第2のユーザーの前記SNS上での書き込みの公開範囲を示す情報及び前記第2のユーザーのクライアント情報に基づいて、前記第2のユーザーのセキュリティ危険度を評価する処理と、
前記第1のユーザーのセキュリティ危険度を示す情報及び前記第2のユーザーのセキュリティ危険度を示す情報と、に基づいて、前記第1のユーザーの前記SNS上でのセキュリティ状態を判別する処理と、
画面表示部に前記セキュリティ状態を示す情報を表示させる処理と、
を実行する可視化処理部を備えるセキュリティ状態可視化システム。