JP2015069618A

JP2015069618A - セキュリティ状態可視化方法、プログラム及びシステム

Info

Publication number: JP2015069618A
Application number: JP2013206260A
Authority: JP
Inventors: 裕一桜庭; Yuichi Sakuraba; 拓実目黒; Takumi Meguro
Original assignee: NEC Engineering Ltd
Current assignee: NEC Engineering Ltd
Priority date: 2013-10-01
Filing date: 2013-10-01
Publication date: 2015-04-13
Anticipated expiration: 2033-10-01
Also published as: JP6249474B2

Abstract

【課題】ユーザー自身がＳＮＳ上でのセキュリティ状態を認識できるセキュリティ状態可視化プログラムを提供する。
【解決手段】本発明の一形態に係るセキュリティ状態可視化プログラムは、第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び第１のユーザーのクライアント情報に基づいて評価した第１のユーザーのセキュリティ危険度と、書き込みを受信するように登録した第２のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び第２のユーザーのクライアント情報に基づいて評価した第２のユーザーのセキュリティ危険度と、に基づいて、第１のユーザーのＳＮＳ上でのセキュリティ状態を評価し、セキュリティ状態を表示する処理をコンピュータに実行させる。
【選択図】図１

Description

本発明は、ＳＮＳ(ソーシャルネットワークサービス)上でのセキュリティ状態可視化方法、プログラム及びシステムに関する。

ＳＮＳは、現在、種々の分野で用いられている（例えば、特許文献１を参照）。このようなＳＮＳ上でのセキュリティ対策はユーザー自身がサービス毎に独自に対策する方法が主であり、例えば、ＳＮＳの設定による情報の公開範囲設定などで実行されている。

特開２０１１−２２７８４６号公報

セキュリティ状態はユーザー自身の設定に依存するので、安定したセキュリティ対策にはならない。また、ＳＮＳ上でのセキュリティ対策が万全であっても、使用している機器(例えば、ＰＣなど)のセキュリティ対策がされていない場合、意図しない形でＳＮＳによる情報の流出が起きてしまう可能性がある。更に、使用機器やＳＮＳ上でのセキュリティ対策が万全であっても、ＳＮＳ上で接している別のユーザーのセキュリティ対策が不十分であった場合、なりすましによる情報流出などの問題が発生する可能性がある。
このような状況において、ユーザー自身がＳＮＳ上でのセキュリティ状態を認識できる技術は見聞することができない。

本発明の目的は、上述した課題を解決するためになされたものであり、ユーザー自身がＳＮＳ上でのセキュリティ状態を認識できるセキュリティ状態可視化方法、プログラム及びシステムを提供することである。

本発明の一形態に係るセキュリティ状態可視化プログラムは、第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する処理と、
前記セキュリティ状態を示す情報を表示する処理と、
をコンピュータに実行させる。

本発明の一形態に係るセキュリティ状態可視化方法は、第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する工程と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する工程と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する工程と、
前記セキュリティ状態を示す情報を表示する工程と、
を備える。

本発明の一形態に係るセキュリティ状態可視化システムは、サーバから取得した第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
サーバから取得した前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する処理と、
画面表示部に前記セキュリティ状態を示す情報を表示させる処理と、
を実行する可視化処理部を備える。

本発明によれば、ユーザー自身がＳＮＳ上でのセキュリティ状態を認識できるセキュリティ状態可視化方法、プログラム及びシステムを提供することができる。

実施の形態によるセキュリティ状態可視化システムの概略を示したブロック図である。画面表示部のイメージ図である。（ａ）及び（ｂ）は、ツイートを一般公開しているユーザーと、ツイートを全体に公開していないユーザーと、のツイート閲覧状態などを説明する図である。（ｃ）は、公式のクライアントを利用したユーザーと、非公式のクライアントを利用したユーザーと、のツイート閲覧状態などを説明する図である。（ａ）及び（ｂ）は、ユーザーのダイレクトメッセージの扱いを説明する図である。ユーザーのセキュリティ危険度を評価する処理フローを示すフローチャートである。フォロワーのセキュリティ危険度を評価する処理フローを示すフローチャートである。現在のユーザーのＳＮＳ上でのセキュリティ状態を評価し、画面表示部に表示させるまでの流れを示すフローチャートである

本発明の実施の形態に係るセキュリティ状態可視化方法、プログラム及びシステムについて説明する。但し、本発明が以下の実施の形態に限定される訳ではない。また、説明を明確にするため、以下の記載及び図面は、適宜、簡略化されている。なお、以下の説明においては、ＳＮＳの一例としてtwitter（登録商標）を挙げているが、他のＳＮＳでもよい。

図１は、本実施の形態によるセキュリティ状態可視化システムの概略を示したブロック図である。セキュリティ状態可視化システム１は、ユーザーが使用する通信機器２と、twitterサーバ３と、外部サーバ４と、を備えている。

通信機器２は、演算処理部２ａと画面表示部２ｂと情報入力部２ｃとを備えており、例えば携帯電話、スマートフォン、パソコンなど、外部とのネットワーク通信機能（外部通信機能）を持った機器である。通信機器２は、図示を省略した記憶部からクライアントや認証アプリを演算処理部２ａが読み出して処理することによって、twitterや後述のセキュリティ状態可視化処理などを実行する。

画面表示部２ｂは、通信機器２が持つ表示手段の一具体例であり、認証アプリの情報など任意の情報を表示する。画面表示部２ｂは、例えば液晶ディスプレイ装置、有機又は無機ＥＬディスプレイ装置などにより構成されている。図２は、画面表示部２ｂのイメージ図である。図示例では認証アプリが実行されることによって評価されたセキュリティ状態を示す情報を表示している。なお、通信機器２が表示可能な情報は、セキュリティ状態を示す情報だけではない。

情報入力部２ｃは、情報の入力／選択手段の一具体例であり、ユーザーが操作を行い、その操作に応じた入力情報を出力する機能を持つ。情報入力部２ｃは、例えばパソコンのキーボードやマウス、携帯電話のボタン、タッチパネルなどの入力機器で構成されている。ユーザーは、情報入力部２ｃを用いて、例えば認証アプリにアカウント名やパスワード、twitterのツイート公開の有無など任意の情報を入力できる。情報入力部２ｃで入力された情報は、取得情報管理部で管理される。

認証アプリ（セキュリティ状態可視化プログラム）は、演算処理部２ａによって実行される機能の１つであり、ユーザーのセキュリティ危険度を示す情報と、フォロワーのセキュリティ危険度を示す情報と、に基づいて現在のユーザーのtwitter上でのセキュリティ状態を評価する可視化処理部に加え、twitterサーバ３から取得したアカウント関連情報及び情報入力部２ｃから入力された情報などを管理する取得情報管理部、可視化処理部や取得情報管理部などで使用する情報を管理する内部ＤＢ部を備えている。本発明の一実施の形態に係わる認証アプリは、評価したセキュリティ状態を示す情報を画面表示部２ｂに表示する。これにより、twitter上でのセキュリティ状態を容易に認識することが可能になる。

詳細には、認証アプリは、例えばＷＥＢ（World Wide Web）アプリケーション、スマートフォンのアプリケーション、携帯電話のアプリケーション、など任意の機器の機能（もしくはサービス）として演算処理部２ａで動作する。また、認証アプリが実行する機能は、本発明で説明するセキュリティ状態可視化処理のみに限らず、他の機能を有する場合もある。

認証アプリは、twitterのクライアントと連携を行うプログラムであり、twitterのクライアントと連携が取れている場合のみ正常に動作する。また、twitterのクライアントに連携アプリとして登録する際に設定した権限（読み込み権限、読み込み書込み権限）で実行可能なＡＰＩ（Application Program Interface）を実行することで、ユーザーの管理しているtwitterのユーザーアカウント関連情報を取得することができる。

認証アプリは、通信機器２の持つ外部通信機能を用いてtwitterサーバ３とネットワーク通信を行う。認証アプリはtwitterのクライアントと連携を行うため、ユーザーに画面表示部２ｂを介して、OAuth認証によるアクセストークンの取得を促す画面を表示する（表示する画面は任意）。ユーザーが認証の手続きを行うと、認証アプリを使用している通信機器２の画面表示部２ｂに認証アプリのアクセス許可の可否を求める画面が表示される。ユーザーが“許可する“を選択することで、認証アプリはユーザーアカウント関連情報を取得可能となる。なお、認証方法は、ユーザーが利用するＳＮＳによって適宜変更される。

可視化処理部は、セキュリティ状態で判別した、ユーザーのセキュリティ危険度を示す情報と、フォロワーのセキュリティ危険度を示す情報と、に基づいて、画面表示部２ｂに表示するセキュリティ状態を示す情報を作成する。

詳細には、可視化処理部は、セキュリティ状態評価部を備えており、セキュリティ状態評価部は、取得情報管理部と内部ＤＢ部からセキュリティ状態の評価に必要な情報を取得し、ユーザーのセキュリティ危険度と、フォロワーのセキュリティ危険度と、上記２点に基づいてユーザーのtwitter上でのセキュリティ状態と、を評価する。

取得情報管理部は、外部通信機能を用いてtwitterサーバ３から取得した情報と、ユーザーが情報入力部２ｃを用いて入力した情報と、を管理する。取得情報管理部で管理する情報は、可視化処理部が必要とする情報のみとは限らない。

内部ＤＢ部は、可視化処理部がセキュリティ状態を評価するために必要な内部情報を管理する。また、内部ＤＢ部は通信機器２の外部通信機能を用いて、定期的に外部サーバ４と通信を行い、セキュリティ状態評価用の情報を外部サーバ４から取得する。また、セキュリティ状態評価部が取得情報管理部から取得した情報から解析した情報（例えば、ユーザーが使用しているクライアント情報）を定期的に外部サーバ４に送信する。

次に、図３を参照してtwitterのクライアント上でのユーザーのツイート閲覧状態について具体的に説明する。図３（ａ）及び（ｂ）は、ツイートを一般公開しているユーザーと、ツイートを全体に公開していないユーザーと、のツイート閲覧状態などを説明する図である。図３（ｃ）は、公式のクライアントを利用したユーザーと、非公式のクライアントを利用したユーザーと、のツイート閲覧状態などを説明する図である。

図３（ａ）及び（ｂ）に示すように、ツイート公開ユーザーとツイート非公開ユーザーに対して、ユーザーをフォロー状態（ツイートを受信するように登録した状態）のユーザーＡと、ユーザーを未フォロー状態のユーザーＢと、twitterを利用していないユーザーＣが表示されている。

ツイートを一般公開しているユーザーに関しては、すべてのユーザーがツイートを閲覧可能となっている。ユーザーＣのみ、閲覧しかできない状態になっているが、これはtwitterを登録していないため、twitter上でのみ可能な動作が利用できないためである。

このように、ツイートを一般公開しているユーザーは、フォローの有無に関係なくツイートの閲覧・引用・拡散が可能になり、ツイートの流出リスクが非常に高くなるため、一般公開しているユーザーはセキュリティレベルが著しく低下することとなる。一方、ツイートを非公開にしているユーザーに関しては、フォロー状態にあるユーザーのみがツイートを閲覧可能な状態になるため、ツイートの拡散リスクは極めて低く、またフォローしているユーザーであってもツイートの引用・拡散が不可能になるため、セキュリティレベルを高く設定できる。

しかし、図３（ｃ）のように、twitter登録ユーザーが使用しているクライアントによって例外が発生する可能性がある。本来、図３（ｂ）のようにツイート非公開ユーザーのツイートは引用・拡散できないが、非公式のクライアント等を利用する場合、ユーザーにおけるツイートの公開／非公開に関係なくツイートを引用することが可能になるため、引用した内容からツイートが流出する可能性がある。

また、ツイートを引用して拡散した場合、誰が・いつ・どのような形で・どのくらいツイートが広がったのかを、ユーザーは判断することができない。そのため、ユーザーをフォローしているユーザーの中で、どのクライアントを使用してツイートをしているのか、（自分がツイートを非公開にしていた場合）ツイートを拡散したことがあるのか、をtwitterサーバ３から取得したツイートの内容から解析し、フォロワーのセキュリティ危険度に反映する必要がある。

図４（ａ）及び（ｂ）は、ユーザーのダイレクトメッセージ（ＤＭ）の扱いを説明する図である。ダイレクトメッセージは、ユーザーがフォローし、かつ相手側からもフォローされている状態でのみ使用可能なメッセージ機能であり、またアカウントのツイート公開／非公開に関わらず、内容は第三者に見られることは無い（使用中クライアントの作成者を除く）ため、セキュリティ上安全性の高い機能である。

しかし、相手側の通信機器がウイルス感染している場合や、相手側のアカウントのパスワードが不正使用されている場合に、ダイレクトメッセージを使用してユーザーに悪意のある内容のダイレクトメッセージや、不正なリンク先に移動するＵＲＬ（Uniform Resource Locator）が送られてくる可能性もある。そのため、過去のダイレクトメッセージの内容などを参照し、ダイレクトメッセージが送られてきたユーザーの危険度を判断し、フォロワーのセキュリティ危険度に反映させる必要がある。

次に、ユーザーのセキュリティ危険度を評価する方法について詳細に説明する。図５は、ユーザーのセキュリティ危険度を評価する処理フローを示すフローチャートである。

ステップＳ４１１において、認証アプリは、ツイートの公開／非公開情報とtwitterで設定しているパスワードの入力画面を画面表示部２ｂに表示し、ユーザーに情報入力部２ｃを用いた情報の入力を促す。ユーザーが情報入力部２ｃを用いて情報を入力すると、認証アプリは入力した情報を取得情報管理部に管理させる。

また、認証アプリは、当該入力された情報をユーザーのセキュリティ危険度評価用にセキュリティ状態評価部に送る。セキュリティ状態評価部に送った情報が、過去の状態から変更があった場合、セキュリティ状態評価部は、変更の内容と変更した日時を示す情報を、セキュリティ状態評価部で変更があった回数を示す情報を含め内部ＤＢ部に管理させる。

ステップＳ４１２において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３からユーザーのフォロー／フォロワー数の情報を取得させる。セキュリティ状態評価部は、取得した情報に基づいて、フォローしているユーザーとフォローされているユーザーを照らし合わせ、互いにフォローしているユーザーと、ユーザーのみフォローしているユーザーと、相手からのみフォローされているユーザーと、に分ける。セキュリティ状態評価部は、分けた際のそれぞれの数を示す情報を、解析した日時を示す情報と共に内部ＤＢ部に管理させる。

ステップＳ４１３において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３からユーザーのツイート情報を取得させる。

ステップＳ４１４において、セキュリティ状態評価部は、ステップS４１３で取得したツイート情報を解析し、ユーザーがツイート時に使用しているクライアント情報を解析する。このとき、セキュリティ状態評価部は、複数のクライアントを使用している場合は、使用頻度や使用回数も解析する。

更に、ステップＳ４１４において、セキュリティ状態評価部は、解析したユーザーが使用しているクライアント情報を、内部ＤＢ部に管理させているアカウント別の危険度の情報と照らし合わせる。セキュリティ状態評価部は、照らし合わせた情報から、ユーザーのクライアントのセキュリティ危険度を評価する。

ステップＳ４１５において、セキュリティ状態評価部は、ステップＳ４１３で取得したツイート情報を解析し、過去の位置情報付のツイートがあるか否かを判断する。そして、セキュリティ状態評価部は、位置情報が付いたツイートがあった場合、位置情報を解析し、公開した位置情報の分布や、場所別の回数を解析する。

ステップＳ４１６において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３から自分がツイートした内容と自分が送信したダイレクトメッセージを取得させ、ツイートした内容やダイレクトメッセージの内容を解析する。セキュリティ状態評価部は、解析した内容にＵＲＬが含まれていた場合、外部サーバ４と通信を行い、ＵＲＬのリンク先のチェックを行う。

ステップＳ４１７において、セキュリティ状態評価部は、ステップＳ４１１〜ステップＳ４１６に解析した内容に基づいて、ユーザーのセキュリティ危険度を評価する。

ここで、ステップＳ４１１で入力したツイートの公開／非公開情報について、ユーザーが非公開設定にしていた場合は、ユーザーが許可したフォロワーのみユーザーのツイートが閲覧可能であるため、ツイートの拡散リスクは極めて低くなる。しかし、ステップＳ４１２で入力したツイートの”フォロワー数”が多かった場合、閲覧者が多くなる場合や、悪質なユーザーが含まれる可能性も高くなるため、拡散リスクは多少上がる。

ステップＳ４１３で確認したツイート情報で、画像などを添付したツイートが多い場合、拡散されたくない画像などがフォロワーなどによって拡散されてしまうリスクがある。

ステップＳ４１４で解析したクライアント情報について、クライアントがtwitter公式のものではない場合、自分のツイートが非公開であっても、クライアントの作成者は内容の確認ができてしまう。また、ダイレクトメッセージも同じように内容が確認できてしまう。更に、クライアントを使用する際に行ったユーザー認証時に、クライアントの作成者はユーザーのパスワード等も取得できるため、アカウントを乗っ取られる可能性も高くなる。そのため、安全性が定かでないクライアントを使用している場合、ユーザーのセキュリティ危険度は大きく上がる。

ステップＳ４１５で解析したツイートの位置情報設定について、ユーザーが頻繁に位置情報つきのツイートを行っていた場合、そのツイートを閲覧している人にユーザーの行動範囲や住居などを特定されてしまう可能性があるため、セキュリティ上大きなリスクとなる。

ステップＳ４１６において、ユーザーのツイート／ダイレクトメッセージを解析し、悪意のあるリンク先が記載されたツイートが勝手に行われていた場合、ユーザーのアカウントが乗っ取られている可能性が極めて高くなるため、セキュリティ上大きな問題となる。

上述の危惧を考慮して、ユーザーのセキュリティ危険度を評価する方法は、ステップＳ４１１〜ステップＳ４１６の解析内容を基にパラメータを設定し、その値から評価する。各ステップで設定するパラメータの詳細については、表１に示す。

パラメータ値が“３”の項目が１つでもあれば、セキュリティ状態評価部は、ユーザーのセキュリティ危険度は高と評価する。パラメータ値が“２”の項目が２つあれば、セキュリティ状態評価部は、セキュリティ危険度は中、それ以外は低と評価する。ただし、ステップＳ４１２とステップＳ４１３で解析するフォロワー数と画像添付のツイートについては評価の条件とせず、セキュリティ状態評価部は、画面表示部２ｂに拡散のリスクがある旨を表示させる。

セキュリティ状態評価部は、評価したユーザーのセキュリティ危険度を示す情報を、評価を行った日時を示す情報と共に内部ＤＢ部に管理させる。また、セキュリティ状態評価部は、過去の評価結果を示す情報が内部ＤＢ部に管理されている場合、当該評価結果と比較し差分を画面表示部２ｂに表示させる。ここで、最新の評価結果を示す情報のみを内部ＤＢ部で管理するようにする。

次に、フォロワーのセキュリティ危険度を評価する方法について詳細に説明する。図６は、フォロワーのセキュリティ危険度を評価する処理フローを示すフローチャートである。

図６のセキュリティ危険度の評価は、セキュリティ状態評価部が取得情報管理部にtwitterサーバ３から取得させたユーザー情報からフォロワー情報を取得し、フォロワー全てのアカウント関連情報の解析を行う。なお、図６ではフォロワーのアカウント１つを解析する手順を説明する。

ステップＳ５１１において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３からユーザー宛のメッセージ情報（返信情報）を取得させ、メッセージの内容を解析する。内容にＵＲＬが含まれていた場合、セキュリティ状態評価部は、外部サーバ４と通信を行い、ＵＲＬのリンク先のチェックを行う、リンク先が悪意のあるリンク先だった場合、セキュリティ状態評価部は、メッセージを送信したアカウント名を示す情報と時間を示す情報を内部ＤＢ部に管理させる。

ステップＳ５１２において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３からアカウント関連情報を取得させ、当該アカウント関連情報に基づいてツイートの公開／非公開設定を解析する。また、セキュリティ状態評価部は、過去に公開、または非公開であったユーザーの場合は、変更があった時期や回数を記録し、内部ＤＢ部に管理させる。

ステップＳ５１３において、セキュリティ状態評価部は、当該アカウント関連情報に基づいてアカウントのフォロー／フォロワーの人数を示す情報を取得する。また、セキュリティ状態評価部は、フォローしているアカウント数とフォローされているアカウント数の差分を算出し、算出結果を示す情報を内部ＤＢ部に管理させる。

ステップＳ５１４において、セキュリティ状態評価部は、内部ＤＢ部が管理するフォローしているアカウント数とフォローされているアカウント数の差分を示す情報に基づいて、フォロー／フォロワーの増減を算出する。セキュリティ状態評価部は、算出結果を示す情報を日時毎に内部ＤＢ部に管理させる。なお、セキュリティ状態評価部は、増減を算出する際、比較を行う過去情報が存在しない場合（新たにフォローされたユーザーの場合）、算出は行わずに現在の情報のみを内部ＤＢ部に管理させる。

ステップＳ５１５において、セキュリティ状態評価部は、当該アカウント関連情報に基づいてツイートを行う際に使用しているクライアント情報を解析する。解析方法は図５のステップＳ４１４と略等しい方法を用いることができる。

ステップＳ５１６において、セキュリティ状態評価部は、当該アカウント関連情報に基づいて解析を行うアカウントのツイート数を算出する。セキュリティ状態評価部は、ツイート数は１日あたりの数を示す情報と、総数（アカウント取得時〜現在までの数）を示す情報と、に分け、各々の情報を内部ＤＢ部に管理させる。ちなみに、１日あたりの数というのは、２４時間前から情報取得時までの数値である。

ステップＳ５１７において、セキュリティ状態評価部は、取得情報管理部にtwitterサーバ３からアカウントのツイート情報を取得させ、ツイートの内容を解析する。解析対象は、例えばアカウントの最新ツイートから最新２０件分である。但し、解析対象の件数は、特に限定されない。解析対象のユーザーがツイートを非公開にしている場合は、解析を行わない。また、自分のフォロワーではあるが、自分はフォローしていないユーザーの場合、ツイートの内容を取得できないため、本ステップではデータを取得しない。

ステップＳ５１８において、セキュリティ状態評価部は、当該アカウント関連情報から解析を行うアカウントでツイートの引用（公式リツイート、非公式リツイート）が何回行われているかを算出する。非公式ＲＴの場合、ＡＰＩで検索する方法が提供されていないため、セキュリティ状態評価部は、ツイート中の文章に“RT”や“QT”など、ツイート引用時に付く文字が存在するかを解析することで引用回数を算出する。また、セキュリティ状態評価部は、解析を行うアカウントが自分のツイートを何回引用したかを算出する。セキュリティ状態評価部は、算出結果を示す情報を内部ＤＢ部に管理させる。なお、ツイートの引用が存在するか否かの解析方法は、フォロワーが使用するＳＮＳによって適宜変更される。

ここで、ステップＳ５１８で解析を行う際、セキュリティ状態評価部は、自分のアカウントが非公開設定だった場合にツイートの引用が行われていた場合、行われた際に使用していたアカウント関連情報を含めて内部ＤＢ部に管理させる。

ステップＳ５１９において、セキュリティ状態評価部は、当該アカウント関連情報から解析を行うアカウントが前回解析時も存在していたか否かを解析する。今回の解析で新規に追加されたアカウントの場合、ステップＳ５２４に遷移する。前回解析時から存在するアカウントの場合、ステップＳ５２０に遷移する。

ステップＳ５２０において、セキュリティ状態評価部は、解析を行っているアカウントからユーザーが過去にダイレクトメッセージを受信しているか否かを解析する。ユーザーが過去にダイレクトメッセージを受信していなかった場合、ステップＳ５２４に遷移する。ユーザーが過去にダイレクトメッセージを受信していた場合、Ｓ５２１に遷移する。

ステップＳ５２１において、セキュリティ状態評価部は、受信したダイレクトメッセージの内容を解析する。解析方法は、ステップＳ５１１と同じ方法を用いることができる。

ステップＳ５２２において、セキュリティ状態評価部は、ステップＳ５２１でダイレクトメッセージの内容を解析した結果により遷移先を決定する。そして、セキュリティ状態評価部は、ステップＳ５２１の解析で悪意のあるサイトのＵＲＬが貼り付けられていた場合、ステップＳ５２３に遷移する。また、セキュリティ状態評価部は、ダイレクトメッセージの内容を解析して問題が無かった場合、ステップＳ５２４に遷移する。

ステップＳ５２３に遷移した場合、解析中のユーザーはアカウントの乗っ取り、もしくは使用中の機器（例えば、携帯電話、スマートフォン、ＰＣなど）がウイルスに感染している可能性が高いユーザーであると判断できるため、セキュリティ状態評価部は、解析中のアカウント情報と解析した日時を示す情報を内部ＤＢ部で管理させる。

ステップＳ５２４において、セキュリティ状態評価部は、ステップＳ５１１〜ステップＳ５１８に解析した情報と、ステップＳ５２１で解析した情報と、を照らし合わせ、ユーザーのセキュリティ危険度を評価する。

ここで、ステップＳ５１１やステップＳ５２１などで自分宛のメッセージや送信したダイレクトメッセージに悪意のあるサイトに遷移するＵＲＬが含まれていたアカウントは、ウイルスに感染している可能性や、アカウントの乗っ取りが行われている可能性があるため、セキュリティ状態評価部は、内部ＤＢ部にウイルス感染リスクの高いアカウントとして管理させる。

ステップＳ５１３において、ツイートを非公開にしているユーザーの場合、自分のツイートが引用された場合であっても再度引用される可能性は低いため、ツイートの拡散リスクが低いユーザーと判断できる。しかし、ツイートを非公開にしているユーザーであっても、フォロワー数が多い場合（ステップＳ５１３で確認）や、フォロー／フォロワー数の増減が多い場合（ステップＳ５１４で確認）は、ツイートを引用してリツイートした場合に閲覧する人数が多くなる可能性があるので、拡散リスクはある程度高くなる。

ステップＳ５１６でツイート数が多い場合や、ステップＳ５１８でツイートの引用数が多いと判断されたアカウントの場合も、自分のツイートが引用される確立が高くなる可能性があるため、拡散リスクが高いアカウントと判断できる。

ステップＳ５１５で確認した使用中のクライアントに関して、公式アプリケーション以外を用いているユーザーの場合は、クライアントの作成者などに情報が漏れる可能性がある。また、公式以外のアプリケーションの中でも、個人作成のクライアントなどは更に危険性が高い。それ以外に、非公式クライアントの中には、本来引用することができない非公開ユーザーのツイートを引用してリツイートできるものもあり、そういったクライアントを使用している場合はツイートの拡散リスクが大きく上がる。

クライアントには、携帯機器（例えば、スマートフォン、携帯電話など）やパソコンで使用されているものだけではなく、ニュースサイトやブログなど、ＷＥＢ上で使用されるものもある。このクライアントの場合、ツイートの内容がtwitter上だけでなく、投稿したＷＥＢ上でも公開される可能性が極めて高いため、ＷＥＢ上でのツイートの拡散リスクも高くなる。

上述の危惧を考慮して、フォロワーのセキュリティ危険度を評価する方法は、ステップＳ５１１〜ステップＳ５２３の解析内容を基にパラメータを設定し、その値から評価する。各ステップで設定するパラメータの詳細については、表２に示す。

セキュリティ状態評価部は、評価したユーザーのセキュリティ危険度を示す情報を、ユーザー毎に解析を行った日時を示す情報と共に内部ＤＢ部に管理させる。すでに同じアカウントのセキュリティ危険度を示す情報が内部ＤＢ部で管理されている場合は、最新の評価結果と比較し、差分を画面表示部２ｂで表示させる。また、最新の評価結果を示す情報のみを内部ＤＢ部で管理するようにする。

次に、図５と図６のフローチャートで評価したセキュリティ危険度を示す情報に基づいて、現在のユーザーのＳＮＳ上でのセキュリティ状態を評価し、画面表示部２ｂに表示させるまでの流れを説明する。図７は、図５と図６のフローチャートで評価した情報に基づいて、現在のユーザーのＳＮＳ上でのセキュリティ状態を評価し、画面表示部２ｂに表示させるまでの流れを示すフローチャートである。

まず、ユーザーのセキュリティ危険度（図５のフローチャート）とフォロワーのセキュリティ危険度（図６のフローチャート）とに基づいて、ステップＳ６１１において、セキュリティ状態評価部はユーザーのＳＮＳ上でのセキュリティ状態を評価する。

セキュリティ状態の評価方法は、ユーザーのセキュリティ危険度の評価結果と、フォロワーのセキュリティ危険度の評価結果と、の組合せにより、高・中・中低・低の４段階で評価する。評価方法の詳細は、表３に示す。

セキュリティ状態評価部は、ステップＳ６１１で評価した最新の評価結果を示す情報を内部ＤＢ部に管理させる。この際、すでに過去の評価結果を示す情報が内部ＤＢ部に残っていた場合は、最新の評価結果を示す情報を過去の評価結果を示す情報に上書きして保存する。

ステップＳ６１２において、セキュリティ状態評価部は、ステップＳ６１１での評価結果を示す情報を画面表示部２ｂへの表示情報に変換する。このとき、表示情報は、ユーザーのセキュリティ危険度の評価結果と、フォロワーのセキュリティ危険度の評価結果と、上記２点から総合的に評価したユーザーのＳＮＳ上でのセキュリティ状態と、の３点である。

表示情報を表示する際、内部ＤＢ部は前回の評価結果を示す情報を管理しているか否かの検索を行う。検索の結果、前回の評価結果を示す情報が残っていた場合、セキュリティ状態評価部は、最新の評価結果と前回の評価結果との比較を行い、比較結果を示す情報も画面表示部２ｂへの表示情報に変換する。比較結果も画面表示部２ｂに表示させることで、ユーザーはセキュリティ状態の変化を容易に認識することができる。

ステップＳ６１３において、セキュリティ状態評価部で作成した表示情報を画面表示部２ｂに表示させる。通信機器内部で動作している内部アプリ上で、セキュリティ設定状態の表示要求があった場合、認証アプリの画面として表示する。それにより、ユーザーは自分が使用しているアカウントのセキュリティ状態を容易に認識することができる。

従来のセキュリティ設定方法では、ユーザー自身が情報の公開範囲やパスワードなどを設定する。この場合、セキュリティ対策はすべてユーザー自身の設定に依存してしまい、設定方法などの知識が乏しい新規ユーザーや通信機器端末などを触る機会が少ないユーザーの場合、セキュリティ対策が行わないままサービスを使用することで、情報流出やウイルス感染につながる可能性がある。

また、ユーザー自身がセキュリティ対策を行った場合でも、設定後のセキュリティ状態がどの程度になっているかをユーザー自身が判断することは難しく、ユーザーが望んだレベルのセキュリティ設定がされていないままサービスを利用してしまい、思いがけない情報の流出が起きてしまう可能性がある。

更に、ダイレクトメッセージ機能では、ユーザーは危険な情報の有無を意識せず内容を確認する場合もあり、悪質なＵＲＬと知らずにリンク先に遷移し、ウイルスに感染してしまう場合などもある。

加えて、ユーザー登録が容易であり、なおかつ不特定多数のサービス利用者と交流が可能なＳＮＳの場合、悪質なユーザーであるかどうかの判断はユーザー自身の判断に依存する形になってしまうため、十分な対策方法は確立されていない。

本実施の形態のセキュリティ状態可視化方法、プログラム及びシステムによれば、ＳＮＳ関連の知識の有無に関係なく、自分が使用しているＳＮＳ上でのセキュリティ状態を容易に認識することができ、すなわち、ＳＮＳのセキュリティ向上に繋がる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で変更することが可能である。

例えば、ステップＳ４１１で入力したtwitterのパスワードが、長い期間変更されていない場合（例えば、６ヶ月以上）は、パスワードの安全性が下がっている場合がある。そこで、画面表示部２ｂにパスワードの安全性が低下している旨を示す情報を表示することが好ましい。

例えば、パスワードが簡単すぎるものや推測されやすいものの場合（例えば、電話番号、英単語など）、アカウントが乗っ取られる危険性が高くなる。そこで、画面表示部２ｂにパスワードが推測されやすいものである旨を示す情報を表示することが好ましい。

上述した実施の形態の一部または全部は、以下の付記のように記載され得るが、以下の記載に限らない。

＜付記１＞
第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を判別する処理と、
前記セキュリティ状態を示す情報を表示する処理と、
をコンピュータに実行させるセキュリティ状態可視化プログラム。

＜付記２＞
前記第１のユーザーのセキュリティ危険度を評価する処理では、画像を添付した書き込みが存在するか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価し、
前記セキュリティ状態を示す情報を表示する処理では、前記画像を添付した書き込みが存在すると、前記画像が拡散する可能性がある旨を示す情報を表示する付記１に記載のセキュリティ状態可視化プログラム。

＜付記３＞
前記第１のユーザーのセキュリティ危険度を評価する処理では、前記書き込みに位置情報が含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する付記１又は２に記載のセキュリティ状態可視化プログラム。

＜付記４＞
前記第１のユーザーのセキュリティ危険度を評価する処理では、前記第１のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する付記１乃至３のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記５＞
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１乃至４のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記６＞
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが書き込みを受信するように登録した数と、前記第２のユーザーの書き込みを受信するように登録した第３のユーザーの数と、の差分を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１乃至５のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記７＞
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが書き込みを受信するように登録した数の増減を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１乃至６のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記８＞
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが１日に書き込んだ数、前記第２のユーザーが１日に書き込みを受信した数、又は前記第２のユーザーが１日に送信したメッセージの数を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１乃至７のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記９＞
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記２のユーザーが前記第１のユーザーの書き込みを受信する新規のユーザーか否かの解析結果を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１乃至８のいずれか１項に記載のセキュリティ状態可視化プログラム。

＜付記１０＞
第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する工程と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する工程と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を判別する工程と、
前記セキュリティ状態を示す情報を表示する工程と、
を備えるセキュリティ状態可視化方法。

＜付記１１＞
前記第１のユーザーのセキュリティ危険度を評価する工程では、画像を添付した書き込みが存在するか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価し、
前記セキュリティ状態を示す情報を表示する工程では、前記画像を添付した書き込みが存在すると、前記画像が拡散する可能性がある旨を示す情報を表示する付記１０に記載のセキュリティ状態可視化方法。

＜付記１２＞
前記第１のユーザーのセキュリティ危険度を評価する工程では、前記書き込みに位置情報が含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する付記１０又は１１に記載のセキュリティ状態可視化方法。

＜付記１３＞
前記第１のユーザーのセキュリティ危険度を評価する工程では、前記第１のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する付記１０乃至１２のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１４＞
前記第２のユーザーのセキュリティ危険度を評価する工程では、前記第２のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１０乃至１３のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１５＞
前記第２のユーザーのセキュリティ危険度を評価する工程では、前記第２のユーザーが書き込みを受信するように登録した数と、前記第２のユーザーの書き込みを受信するように登録した第３のユーザーの数と、の差分を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１０乃至１４のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１６＞
前記第２のユーザーのセキュリティ危険度を評価する工程では、前記第２のユーザーが書き込みを受信するように登録した数の増減を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１０乃至１５のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１７＞
前記第２のユーザーのセキュリティ危険度を評価する工程では、前記第２のユーザーが１日に書き込んだ数、前記第２のユーザーが１日に書き込みを受信した数、又は前記第２のユーザーが１日に送信したメッセージの数を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１０乃至１６のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１８＞
前記第２のユーザーのセキュリティ危険度を評価する工程では、前記２のユーザーが前記第１のユーザーの書き込みを受信する新規のユーザーか否かの解析結果を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する付記１０乃至１７のいずれか１項に記載のセキュリティ状態可視化方法。

＜付記１９＞
サーバから取得した第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
サーバから取得した前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報と、に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を判別する処理と、
画面表示部に前記セキュリティ状態を示す情報を表示させる処理と、
を実行する可視化処理部を備えるセキュリティ状態可視化システム。

１セキュリティ状態可視化システム
２通信機器
２ａ演算処理部
２ｂ画面表示部
２ｃ情報入力部
３ twitterサーバ
４外部サーバ

Claims

第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する処理と、
前記セキュリティ状態を示す情報を表示する処理と、
をコンピュータに実行させるセキュリティ状態可視化プログラム。
前記第１のユーザーのセキュリティ危険度を評価する処理では、画像を添付した書き込みが存在するか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価し、
前記セキュリティ状態を示す情報を表示する処理では、前記画像を添付した書き込みが存在すると、前記画像が拡散する可能性がある旨を示す情報を表示する請求項１に記載のセキュリティ状態可視化プログラム。
前記第１のユーザーのセキュリティ危険度を評価する処理では、前記書き込みに位置情報が含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する請求項１又は２に記載のセキュリティ状態可視化プログラム。
前記第１のユーザーのセキュリティ危険度を評価する処理では、前記第１のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第１のユーザーのセキュリティ危険度を評価する請求項１乃至３のいずれか１項に記載のセキュリティ状態可視化プログラム。
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが送信したメッセージの内容にＵＲＬが含まれているか否かの解析結果を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する請求項１乃至４のいずれか１項に記載のセキュリティ状態可視化プログラム。
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが書き込みを受信するように登録した数と、前記第２のユーザーの書き込みを受信するように登録した第３のユーザーの数と、の差分を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する請求項１乃至５のいずれか１項に記載のセキュリティ状態可視化プログラム。
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが書き込みを受信するように登録した数の増減を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する請求項１乃至６のいずれか１項に記載のセキュリティ状態可視化プログラム。
前記第２のユーザーのセキュリティ危険度を評価する処理では、前記第２のユーザーが１日に書き込んだ数、前記第２のユーザーが１日に書き込みを受信した数、又は前記第２のユーザーが１日に送信したメッセージの数を示す情報をさらに加えて、前記第２のユーザーのセキュリティ危険度を評価する請求項１乃至７のいずれか１項に記載のセキュリティ状態可視化プログラム。
第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する工程と、
前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する工程と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する工程と、
前記セキュリティ状態を示す情報を表示する工程と、
を備えるセキュリティ状態可視化方法。
サーバから取得した第１のユーザーのＳＮＳ上での書き込みの公開範囲を示す情報及び前記第１のユーザーのクライアント情報に基づいて、前記第１のユーザーのセキュリティ危険度を評価する処理と、
サーバから取得した前記書き込みを受信するように登録した第２のユーザーの前記ＳＮＳ上での書き込みの公開範囲を示す情報及び前記第２のユーザーのクライアント情報に基づいて、前記第２のユーザーのセキュリティ危険度を評価する処理と、
前記第１のユーザーのセキュリティ危険度を示す情報及び前記第２のユーザーのセキュリティ危険度を示す情報に基づいて、前記第１のユーザーの前記ＳＮＳ上でのセキュリティ状態を評価する処理と、
画面表示部に前記セキュリティ状態を示す情報を表示させる処理と、
を実行する可視化処理部を備えるセキュリティ状態可視化システム。