JP2015534138A - セキュアな認証及び情報の共有と分析のための方法及びシステム - Google Patents

Abstract

異なる複数の機密レベルが割り当てられている情報の２つ又はそれよりも多くのセットへの、コンピュータネットワークを介したアクセスを選択的に許可する方法において、より低いレベルの機密性を有する情報へのアクセスは、ユーザＩＤ及びパスワードのみを要求する認証処理を必要とし、より高いレベルの機密性を有する情報へのアクセスは、ユーザＩＤ、パスワード、及びハードウェアトークンを要求するが、更なるＰＩＮは要求しない認証処理を必要とする。

Description

本発明は、ポータル及びウェブサイトの情報の会員認証、共有、及び分析サービスに関する。認証処理は、情報のリスク分類に基づいた、複数のレベルの情報への会員のアクセスに対する鍵管理を意味する。

出願人である金融サービス情報共有及び分析センター（ＦＳ−ＩＳＡＣ）は、銀行、保険会社、支払処理業者、及び証券会社によって考案され発展された非営利民間部門イニシアチブである。ＦＳ−ＩＳＡＣの目的は、その会員に対して、物理的な及びサイバーセキュリティ情報の、関連性があり且つ実用的な情報及び分析の適時の共有を提供することである。ＦＳ−ＩＳＡＣのポータル及びウェブサイトは、脅威データ、脆弱性情報、ＩＴリスク管理における先進的な経験、物理的なセキュリティ管理において現れる経験、並びに業務回復性のアプローチと経験を含む、金融サービス会社との信頼性のある情報の共有に良い１つの場所を会員に提供し、業務回復性、ＩＴリスク、セキュリティに関連する企業における最良の知性 − 知識、情報、リソース、及び分析の、他には無い組み合わせへの直接的なアクセスを提供する。

会員は、関連性のある／実行可能なサイバースペースの及び物理的な警報（アラート）、ｉＤＥＦＥＮＳＥの概要／白書、会員コンタクトディレクトリ、リスク緩和ツールキット、文書リポジトリ、会員匿名提出、脅威インテリジェンスリストサーブ、会員概要、観点、政府の及び部門横断の情報共有、及び政府によって提供される情報を含む、本質的な情報へのアクセスのために、ポータル及びウェブサイトを使用する。

２００３年において、銀行及び金融部門（以下金融サービス部門という）は、国家安全保障大統領指令７（ＨＳＰＤ−７）に従って、重要な基盤部門として見なされていた。また、米国財務省は、部門のための部門特定省庁（ＳＳＡ）として見なされていた。ＳＳＡのように、財務省は、その公共部門パートナー及び民間部門パートナーと連携して、人為的な又は自然的な事象に対して回復力を有する頑強な部門を維持する。金融サービス部門は、世界の経済活動の効率のために必須である。

民間部門と公共部門の双方は、重要な基盤保護及び国家安全保障のための金融サービス部門調整協議会（ＦＳＳＣＣ）、並びに金融及び銀行情報基盤委員会（ＦＢＩＩＣ）を介して、それぞれ、金融サービス部門の重要基盤及び重要資源（ＣＩＫＲ）保護プログラムの規定及び実施において、重要な役割を果たす。直接的な指令及び規制権限を介して、連邦及び州の金融規制当局は、部門の事業機能に影響を与える危機に応答して金融規制当局が実施することができる特定の規制手段を有する。更に、財務省は、ＦＢＩＩＣ、ＦＳＳＣＣ、金融サービス情報共有及び分析センター（ＦＳ−ＩＳＡＣ）、及び地域のパートナーシップと共に、金融サービス部門の目標を達成するために、多数の、保護のための、探知のための、並びに応答性のあるプログラムを実施することを、発展させており、また継続する。保護プログラムは、頑強な緊急通信プロトコルを発展及び試験することから、重要な金融サービス部門の脅威を識別すること、サイバーセキュリティの脅威及びリスク緩和ストラテジに取り組むことまで及ぶ。官民連携の成功は、信用に関して且つ流動性のあるリスクに関して部門に対して最も困難な期間のうちの１つを通して、金融サービス部門の成功に重要であることが証明された。

金融サービス部門の範囲は、資金の預金の主要な部門の機能、決済を行うこと、信用及び流動性の提供、投資、及び金融リスクの移転の実行に関わる、公共機関と民間機関を含む。多数の組織はこれらの機能を遂行して、精算機関、商業銀行、信用格付け機関、交換／電子通信ネットワーク、金融顧問サービス、保険会社、金融ユーティリティ政府及び企業規制機関、政府補助を受けている企業、投資銀行、売買業者、小売銀行、及び電子決済業者を含む金融サービス部門を集団で代表する。

金融サービス部門の３つの部門の目標は、部門の物理的な及びサイバースペースの基盤に対する、無数の意図的な、非意図的な、人為的な、及び自然的な脅威に向かい合って最良の可能なポジションを獲得して、部門の通信、情報技術、エネルギー及び輸送システム部門に対する部門の依存によって引き起こされるリスクに対処して管理して、そして法執行及び情報コミュニティ、金融規制機関、民間部門、及び我々の国際的な相手先と連携して、金融サービス部門が直面している脅威に対処することである。

ＦＳＳＣＣ及びＦＳ−ＩＳＡＣは、アドバンストパーシステントスレット（ＡＰＴ）のリスク緩和に対する白書の作成を含む、部門に対する特定の脅威プロダクトの準備に協力して取り組む。ＦＳ−ＩＳＡＣの会員は日常的に情報を共有して、重要な金融サービス基盤の事業者をより良好に調整して、金融市場に潜在的に損害を与え得る又は混乱これを潜在的に混乱させ得る及び／又は金融機関の顧客に重大なリスクをもたらし得る、業務の混乱及び回復性のリスクに対処する。情報は他の会員と共有される。

現在、ＦＳ−ＩＳＡＣ会員ポータルは、一要素認証（ユーザ名／パスワード）と多要素認証（ＲＳＡセキュアＩＤ（ＳｅｃｕｒＩＤ）ハードウェアトークン）との両方をサポートする。ユーザは、彼らの会員組織の会員権限レベルに基づいて、ユーザ名／パスワードか、ユーザ名／セキュアＩＤトークンかのいずれかが割り当てられる。更に、ＧＩＳＦプログラム及びＣＳＩＳＦプログラムは多要素認証の使用を必要とするため、そのようなプログラムの参加者には、セキュアＩＤトークンが割り当てられる。

会員は、ホームページ上の「会員ログイン」ボタンを選択して彼らの会員権限レベルを選択することによって、ＦＳ−ＩＳＡＣ会員ポータルにログインする（例えば、図５参照）。これにより、ユーザの会員権限の種類に応じて、ユーザにユーザ名とパスワードの入力を要求するログインページ、及びＲＳＡセキュアＩＤログインページの２つのログインページのうちの１つが開かれる。

別の方法として、ユーザは、ポータルにおける特定のレコードに、そのレコードのための電子メール通知における「深いリンク」をたどることによって、アクセスできる。この「深いリンク」は、各受信者の会員権限レベルに基づいてポータルによってカスタマイズされ、それによって、リンクは、ユーザを、彼らの会員権限レベル（ユーザ名／パスワード、又はＲＳＡセキュアＩＤ）に適する正しいログインページに導き、次いでユーザをポータル内の特定のレコードにリダイレクトする。

以下の表は、ＦＳ−ＩＳＡＣ会員ポータル上で用いられる認証のメカニズムを示す。

ＵＡＧ及びシェアポイント（ＳｈａｒｅＰｏｉｎｔ）がユーザ認証及びセッション管理を処理する方法が原因で、どのユーザが彼らのセキュアＩＤ認証に基づいているのかを、ＵＡＧが適切に識別する簡単な方法はない。セキュアＩＤクッキーからユーザ名を抽出してそれらをシェアポイントにプログラムで識別するようにカスタムコードが書かれることは可能であるが、この解決手段は既存の適応認証統合コードと適合しない。

本発明によれば、ユーザが、彼らのセキュアＩＤトークンを用いてログインするとき、認証モデルは、彼らのセキュアＩＤトークンコードと共に、彼らのパスワードを入力することをユーザに要求するであろう。ユーザが彼らのユーザ名／パスワードを用いてログインする場合、ユーザ認証処理に変化は生じることはないであろう。

このことがユーザ経験に大きな影響を与えることを防止するために、本発明の一実施形態は、セキュアＩＤトークンのためのＰＩＮ要求を省く。本質的には、ユーザが彼らのトークンを用いて認証を行うとき、ユーザのパスワードは彼らのセキュアＩＤ ＰＩＮの代わりとなろう。本発明のこの特徴によって、ＵＡＧ及びシェアポイントが、ユーザ名／パスワードの組み合わせを用いてユーザを識別でき、またセキュアＩＤが、ユーザ名／パスワード認証の上部の、セキュリティの付加的な層としての機能を果たすことができる。

要するに、システムは、ユーザ名とパスワードを用いて常に認証を行うこととなる。高度に制限されたすなわち「赤」のコンテンツにユーザがアクセスを試み、且つ個別のセキュアＩＤ ＰＩＮが必要とされないときのみのために、セキュアＩＤが要求される。セキュアＩＤ認証の要求に応答するとき、ユーザは、ユーザ名、パスワード、及びトークンコードを入力することとなる。

ＦＳ−ＩＳＡＣポータル及びウェブサイトに関する全ての情報は、図２に示すプロトコルに従って分類される。

使用事例＃１：ユーザが、ユーザ名／パスワードを用いて、ＦＳ−ＩＳＡＣポータルにログインする。

「標準的な」ユーザログインのために、ユーザはログインページに行き、そして彼らのユーザ名とパスワードを入力し得る。例えば、図６参照。一度認証されると、ユーザは、全てのＦＳ−ＩＳＡＣの白、緑、及び黄のコンテンツにアクセスでき得る。

使用事例＃２：ユーザが、セキュアＩＤトークンを用いて、ＦＳ−ＩＳＡＣポータルにログインする。

ログインページ上にて、ユーザは、ユーザ名とパスワードよりもむしろ、彼らのセキュアＩＤトークンを用いてログインするオプションを有し得る。図６の「セキュアＩＤトークンを用いたログイン」のオプション参照。ユーザは、彼らのユーザ名、パスワード、及びセキュアＩＤトークンコードを入力するように要求され得る。例えば、図７参照。これは、ＰＩＮではなく、６桁のトークンコードのみであり得る。一度認証されると、ユーザは、彼らが得る権限が与えられている、全てのＦＳ−ＩＳＡＣの白、緑、黄、及び赤のコンテンツにアクセスでき得る。

使用事例＃３：ユーザ名／パスワードを用いてＦＳ−ＩＳＡＣポータルにログインしているユーザが、ＦＳ−ＩＳＡＣの赤のコンテンツにアクセスを試み、彼らのセキュアＩＤトークンコードの入力が要求される。

ユーザがＦＳ−ＩＳＡＣの赤のコンテンツにアクセスを試みるとき、彼らは、彼らのセキュアＩＤトークンを用いて認証するように要求され得る。例えば、図８参照。本発明の一実施形態によれば、ユーザは、セキュリティの強化のために彼らのパスワードを再入力するように要求され得る。本発明の別の実施形態によれば、ユーザは、彼らのパスワードを再入力するように要求されることはない。

使用事例＃４：彼らのセキュアＩＤトークンを用いて既に認証されているユーザが、ＦＳ−ＩＳＡＣの赤のコンテンツにアクセスを試みる。

ユーザは彼らのセキュアＩＤトークンを用いて既に認証されているため、彼らは再認証するように要求されることはなく、且つ、ＦＳ−ＩＳＡＣの赤のコンテンツにアクセスすることが許可される。

全てが同一の初期認証制御を使用することとなる、異なる複数の会員権限レベルがある。

異なる複数の会員権限レベルは、情報分類モデルに基づいて、特定の許可を有する：プレミアム会員は白、緑、及び黄に分類された情報にアクセスする権利を有し、スタンダード会員は白及び緑に分類された情報にアクセスする権利を有する。

会員権限レベルに対する許可要求は、ポータル情報の情報分類に基づいて異なることとなる。任意の赤に分類された情報は、ハードウェアトークン認証を必要とする。全ての黄に分類された情報は、少なくとも２つの認証制御、又は任意のより低い分類からの「強化した」認証を必要とする。任意の緑に分類された情報は、ユーザ名とパスワードを必要とする。任意の白に分類された情報は公開された情報であり、如何なる認証も必要とされない。

会員に対する認証処理は、ポータルにアクセスするために使用されている機器の種類を判別する機能を含み、特にスマートフォンか携帯機器が使用されているかを判別する機能を含む。携帯機器が使用されている場合（例えば、アンドロイド、アイフォン、アイパッド（登録商標）、ブラックベリー、パーム、タブレット、スマートフォン等）、付加的な確認用質問、又は強化した認証が要求されてもよい。

本発明の別の実施形態によれば、リスクベースの認証等（また、適応認証、強化した認証、知識ベースの認証、アウトオブバンド許可等といわれる）の付加的な認証方法が用いられてもよく、これらは、情報の感度を用いて、又はアクセスのために用いられる機器の種類及び位置に基づいて、制御を増大させるであろう。特定の地理的位置がアクセスのために用いられるとき、システムは、特にパスワードリセットトランザクション要求の場合に身元（識別）を判別／確認するために、付加的な確認用質問を提供して身元を確認してもよい。

会員の取扱い及びサイバーセキュリティイベントの分析提出を示すフローチャートである。 セキュリティ分類レベル及びそれらの対象顧客を示す図である。 ＦＳ−ＩＳＡＣポータル及びウェブサイト上で共有する情報の例である。 ＦＳ−ＩＳＡＣのセキュリティオペレーションセンターを介した情報の流れを示す図である。 会員ホームページの実施形態である。 ログイン画面の第１の実施形態である。 ログイン画面の第２の実施形態である。 ログイン画面の第３の実施形態である。 リスク評価メカニズムのフローチャートである。 会員提出処理の実施形態のフローチャートである。

セキュリティアーキテクチャ

ＦＳ−ＩＳＡＣ情報は、白、緑、黄、及び赤を含む信号灯プロトコル（ＴＬＰ）を用いて、フラグが立てられる。図２参照。これらのセキュリティレベルは、その固有のサイト／リスト／アイテムが継承されるセキュリティモデルを用いて、シェアポイント（ＳｈａｒｅＰｏｉｎｔ）において構成される。システムは、ＲＳＡ適応認証の形式で、２種類の認証に加えてリスク評価メカニズムを用いてＵＡＧサーバを利用して、コンテンツへの未許可のアクセスを防止する。ネットワークを介したデータ転送は、ＳＳＬを用いて暗号化される。図７は、サイトのコンテンツにアクセスするためにユーザが経験し得る経路を示す。

認証

アクティブディレクトリ（ＡＤ）のシステムは信頼できる認証ストアであり、本システムでは、セキュアＩＤが、赤のレベルのコンテンツ以外の全てのコンテンツにアクセスする際のオプションである付加的な保護を付加する。全てのユーザは、ＲＳＡトークン／セキュアＩＤに加えて、アクティブディレクトリのためのユーザ名とパスワードを有することとなる。システムは、アクティブディレクトリからのユーザアカウントを、ＲＳＡ認証マネージャに同期させるように構成されることとなる。この同期は、ユーザの一貫性が２つの認証ソースの間で自動的に維持されることを確実にする。例えば、アクティブディレクトリにおいて無効にされたユーザは、ＲＳＡ認証マネージャにおいても無効にされる。その固有の機能性の一部として、ＵＡＧログインページによって、任意に、ユーザは、彼らが選択した場合には彼らのセキュアＩＤを入力することができることとなる。赤のレベルのコンテンツは、ユーザが彼らのセキュアＩＤを用いてログインしていることを要求することとなり、これはＵＡＧを用いたポリシーとして強化されることとなる。

使用事例＃１ − ユーザが、彼らのセキュアＩＤを入力することなく、彼らのＡＤ認証情報を用いてサイトにログインして、赤としてマークが付されていない全てのコンテンツを自由に閲覧することができる。ユーザは、サイト上のランディングページ上のいくつかの新たな赤のレベルのコンテンツの表題を見ることができる。ユーザはこれらの表題のうちの１つをクリックするが、この場合、ユーザは、ユーザが彼らのセキュアＩＤを用いてログインすることを赤のレベルのコンテンツが要求することを示すログインページにリダイレクトされる。一度ユーザが彼らのセキュアＩＤを用いてログインすると、彼らは、彼らがアクセスを試みていた元の赤のコンテンツに、リダイレクトされて戻される。

使用事例＃２ − ユーザがブラウザを開き、ユーザ名とパスワードに加えて彼らのセキュアＩＤ認証情報を用いてサイトにログインする。このユーザは、全てのコンテンツを閲覧することができ、彼らが赤のレベルのコンテンツ上をクリックしたときに再ログインするように要求されることはない。

使用事例＃３ − ユーザが会議に参加している。彼らは、彼らの携帯機器上にて赤のレベルの通知を受信して、そのコンテンツを閲覧するために電子メールにおけるリンクをクリックする。ユーザは彼らのセキュアＩＤを有さないため、彼らはコンテンツを閲覧できない。

ＲＳＡ認証マネージャサーバは、アクティブディレクトリとＲＳＡデータベースとの間でユーザを同期させるように構成されることとなる。このことは、ユーザが両方の場所において生成され／無効にされることを確実にするべきであるが、まだユーザにトークンを発行してアクティブディレクトリの細部を管理するために運用サポートである必要がある。

アウトオブザボックスのＵＡＧは、シェアポイント、アクティブディレクトリ、ＲＳＡセキュアＩＤの間の統合と共に、ログインページのために必要とされるロジックを含む。ＲＳＡ適応認証を用いたＵＡＧ統合はカスタム構成である。

アクティブディレクトリは、ＦＳ−ＩＳＡＣサイトユーザがただ１つの組織単位（「ＯＵ」）内に含まれるような方法で、構成されることとなる。ＵＡＧは、このＯＵ内のユーザがログインすることを許可のみするように構成されることとなる。任意の管理ユーザ及びサービスアカウントは個別のサービスアカウントＯＵにおいて存在することとなり、また、（公然とＵＡＧを通過することなく）シェアポイントに直接的に接続される内部ネットワーク内で使用されることのみが可能である。

ＵＡＧ終点クライアントユーティリティは、構成において停止される。これにより、ユーザは、ＡｃｔｉｖｅＸ及びＪａｖａ（登録商標）プラグインのいずれもアクティブにすることを必要とされることなく、サイトにアクセスできることとなる。

シェアポイントが継承されるセキュリティモデル

シェアポイントは、許可が、リストされるサイトからユーザへ、そして最後に実際のコンテンツアイテムへ流れ落ちる、継承されるセキュリティモデルを使用する。このセキュリティチェイン内に種々のレベルで一意的なセキュリティを配置することが可能である。この継承は、特定のセキュリティが与えられない限りにおいて、ファイルが配置されるフォルダのセキュリティをファイルが継承する手段に、非常に類似している。ユーザはまた、以下のセキュリティグループに設定可能である。

アクティブディレクトリグループ − アクティブディレクトリグループは、シェアポイントにおいて特定の許可セットが許可されることが可能である。このＡＤグループに追加される任意のユーザは、該グループに割り当てられる許可を自動的に継承する。複数のＡＤグループにおいて現れるユーザがシェアポイントに追加される場合、ユーザは、競合がある場合には、より特権を有するグループを継承することとなる。ＡＤグループの欠点は、会員権限を管理する唯一の方法がアクティブディレクトリツールを使うことであってシェアポイントを使うことではない、ということである。

シェアポイントグループ − シェアポイントグループは、あなたがグループにおいて現れるユーザを管理できるグループ所有者を宣言できることを除いて、ＡＤグループと同様の方法で使用可能である。これは、あなたがサイトへのアクセスを管理するための指定されるユーザのセットを必要とするチームサイトにおいて役に立つこととなる。

ＲＳＡ適応認証

ＦＳ−ＩＳＡＣは、認証メカニズムの上部にセキュリティの層を追加することを提供するＲＳＡ適応認証リスク評価クラウドを使用することとなる。このリスク評価は、ＲＳＡがユーザに対するリスクスコアの全体を確定するために使用する複数の因子に基づく。例えば、通常であればユーザが標準的な勤務時間にニューヨークからサイトにアクセスするところ、真夜中にモスクワから該ユーザからの要求が来る場合、より高いリスクとしてフラグが立てられることとなり、ユーザは確認される。このリスクはユーザに個別化され、そのためユーザが１ヶ月に一度モスクワに訪れる場合にはシステムは学習してこの状況に「適合」することとなる。

使用事例＃１ − ユーザが初めてサイトにログインする。ユーザが彼らの認証情報を用いて認証に成功した後、適応認証は、ユーザを登録するために、ユーザに、質問プールから選択されたランダムな質問のセットを用いて、彼ら自身を識別するように要求する。一度ユーザがこれらの質問に回答すると、彼らはサイトにログインできる。

使用事例＃２ − 適応認証を用いて予め登録されているユーザが、彼らの認証情報を用いて認証に成功する。適応認証は、ユーザが、彼らの通常の使用形態内で、且つ、サイトへのアクセスに成功した際に以前使用されたコンピュータから、システムにアクセスしていることを認識する。ユーザのリスクスコアは低く、そのためユーザは、付加的な要求無しに、シェアポイントサイト内に直接的に入れられる。

使用事例＃３ − 適応認証を用いて予め登録されているユーザが、彼らの認証情報を用いて認証に成功するが、彼らは、彼らが他の州において休暇中に購入した新しいコンピュータを使用している。適応認証はこの場合、彼らが適応認証登録の間に以前提供した回答に基づいて、彼らの識別を確認するために、付加的な質問を用いて、彼らに入力を要求する。ユーザがこれらの質問に対する回答の提供に成功した後、彼らはサイト内に入れられる。

カスタマイズオプション

パスワードリセットセルフサービス

ＵＡＧサーバは、ユーザに彼らのパスワードの変更を許す能力を有するが、あなたのパスワードをリセットする要求に対するアウトオブザボックスの機能はない。この機能はログインページ上のリンクとして追加されることとなる。このリンク上をクリックすると、ユーザは、彼らの電子メールアドレスを入力するように要求される。ユーザが彼らの電子メールアドレスを入力し、且つ電子メールアドレスがアクティブディレクトリにおける有効なユーザに合致することをシステムが確認した後、電子メールがユーザに送信されて、彼らは、彼らのパスワードをリセットするための埋め込まれたリンクをクリックするように要求されることとなる。このリンクは、彼らが新しいパスワードを選ぶための、サイト内のページを開くこととなる。一度ユーザが新しいパスワードを生成すると、ページはアクティブディレクトリにおけるパスワードを更新することとなる。

このカスタマイズの一部として、リセット要求のために生成されることとなる一意的な識別を格納するカスタムデータベーステーブルが生成されることとなる。このテーブルは、リセットを要求しているユーザから、ＩＰアドレス等を含むユーザ情報を収集することとなる。このテーブルは、セクション３．５において収集されるロギング情報とともに、セキュリティ目的のために評価されることができる。

赤のレベルのコンテンツ − セキュアＩＤ強化

「赤の警報（緊急警報）」と呼ばれる警報リスト内のフォルダが生成されることとなる。赤のコンテンツが常にこのフォルダに含まれることを確実にする、リスト上のイベントレシーバが生成されることとなる。このフォルダは次いで、任意の赤のコンテンツへのＵＲＬパスを常に表示することとなる。ＵＡＧは、パスが「赤警報」を含む場合、セキュアＩＤログインを強化するポリシーを用いて構成されることとなる。この解決のために必要とされる唯一のカスタムコードは、赤のレベルのコンテンツが赤の警報フォルダに含まれることを強化するイベントレシーバである。

パスワード変更、及び期限切れセルフサービス

ＵＡＧは、ユーザに、期限切れまでの一定の日数内のうちに彼らのパスワードが期限切れになろうとしていることを通知する能力を有する。ＵＡＧはまた、ユーザに、任意の時点において彼らのパスワードを変更することを許可する能力を有する。しかしながら、この機能性は使用しているＵＡＧポータルラウンチページ上で表示されるのみである。この制限を回避するために、「パスワードの変更」リンクは、シェアポイントの「パーソナルアクション」メニューの「ログアウト」のすぐ上に生成されることとなる。このリンクをクリックすると、ある簡単な区分けが適用されたネイティブのＵＡＧのパスワード変更ページが開かれる。ユーザは既にアクティブセッションにあるため、ユーザは、彼らを戻してサインインさせるために、ログインページに送り戻されることが「できる」。

セキュリティ、及びユーザロギング

任意のセキュアなシステムと同様に、ユーザ認証動作及びサイトの使用を追跡するのに使用可能な監視メカニズムを提供する必要がある。システムの管理者は、システム内のユーザ活動を追跡する手段を必要とし、サイト内の普通ではない活動を見つける手段を有する。サイトは、認証、コンテンツアクセス、及びサイト使用を含む種々の層におけるユーザの活動を追跡することができることとなる。アクティブディレクトリ、ＲＳＡ、ＩＩＳ、シェアポイント等の複数の層があるため、完全な追跡可能性は、種々のログをマニュアルで組み合わせることを含む。警報の観点から、管理者は、ビルトインシェアポイントログを使用して、どのユーザが所与の警報を見ているかを理解できることとなる。このシステムは、現在のシステムよりも非常に多くの、ユーザロギング／監視に関する機能を提供することとなる。以下のメカニズムは、任意の他のネットワークファイアウォール及び配置済みであり得るセキュリティ機器に加えて、システムによって直接的に用いられることとなる。

アクティブディレクトリ監視 − アクティブディレクトリは、信頼のある認証ソースとして使用されることとなり、またロギングが重要となる主要な位置となる。アクティブディレクトリロギングは、サイトのユーザのために設定されたＯＵ上で有効にされることとなる。このロギングは本質的に、パスワード、グループ会員権限、及び他の特性を含む、ＡＤにおける各ユーザオブジェクトに対して行われる全ての変更を追跡することとなる。このデータは、イベントによって検索可能、ソート可能にされることを可能にするＡＤイベントログを介して表に現れる。ログ上の分析を行うサードパーティツールが利用可能である。

ＲＳＡ認証マネージャ − ＲＳＡ認証マネージャサーバは、セキュアＩＤトークンの使用に関連する全ての活動をログに記録することとなる。サーバは、トークンに関連する全ての他の管理イベントとともに、成功した認証の試み及び失敗した認証の試みをログに記録する。

ＲＳ適応認証 − 本明細書の別の場所で説明されるように、適応認証クラウドホスト型の製品はまた、システムへのユーザの接続に関するリスクベースの評価を提供している。監視ロギングは、アクセスの試み並びに失敗した確認及び記載の試みに関する情報を追跡するように維持されることとなる。

ＩＩＳログ − 全てのユーザは、ＩＩＳを用いてサイトにアクセスすることとなる。ＩＩＳロギングはオンされて、現在使用されるＡＷＳｔａｔｓパッケージはこれらのログ上で分析を行うために使用可能である。これらのログは、使用されるブラウザ、発信元の国等に関する情報を収集することとなる。セキュリティの観点から、ログは、入力されるＩＰアドレス及びユーザ名、並びにアクセスされたページを収集し得る。任意の標準的なＩＩＳトラフィックログ分析ツールが使用可能である。

シェアポイント監視 − シェアポイントは、サイト内の種々のレベルにおいて「監視ロギング」をオンにする能力を有する。これらのログは、シェアポイントコンテンツの観点からの、アクセス及び変更の情報を追跡する。例えば、それは、警報に関する生の監視ビュー情報を示すであろう。これらの監視ログは、ある日付範囲に基づいた更なる分析のために、エクセルスプレッドシートにコンパイルされる。

シェアポイント分析、及びクエリロギング − シェアポイントは、ＩＩＳログのそれと同様の分析を追跡する能力を有する。これらのログは上述のＩＩＳログに類似するが、それらはシェアポイントコンテンツに特有であり、且つ、ナビゲーション等のために調整を行うことが可能なようにコンテンツがどのようにアクセスされているのかに関して管理者がある洞察を有することができるように設計される。シェアポイントのクエリロギングの機能によって、管理者は、どの人々が検索を行っているかを見ることができ、また調整を行うことができる。これらは特定の種類のログを監視する「セキュリティ」ではないが、それらによってあなたは、サイトがどのようにアクセスされているかにおいて、通常ではない振る舞いを見つけることができる。これらのログは、ＩＩＳログとともに使用されるべきである。

会員提出

サイト会員は会員提出を生成することが可能になる必要があり、会員提出はその場合分析者によって受信される（図１参照）。ユーザは、他のユーザによって生成された提出を見ることが可能であるべきではない。これらの提出は、分析者によって行われる調査に応じて新たな警報を生成するために、使用される場合があり、又は使用されない場合がある。インフォパス（ＩｎｆｏＰａｔｈ）「スマートフォーム（Ｓｍａｒｔ Ｆｏｒｍ）」プロトタイプは予め生成されて、提出を生成するときにユーザが経験するであろう情報収集経験の一部を形作る。このプロトタイプ用のインフォパスは、ユーザが入力している回答に適合するようにルールを形成する。例えば、ユーザが動作の種類として「マルウェア」を選んでいる場合、フォームはマルウェアに関連する質問を表示する。

インフォパスを用いてユーザ提出を収集することは、技術に対する完璧な使用事例である。本発明の一部として、システムは、全ての種々の動作の種類及び質問を含むように拡張されることとなる。更に、アウトオブザボックスのレビューフローのうちの１つは利用されて、一度会員が提出すると自動的に開始する。このワークフローはレビューグループを割り当てるように構成されることとなり、またこのグループの会員は新しい提出が生成されていることが通知されることとなる。ユーザは、提出の後、彼らの提出の閲覧が許可されることはない。これは、多くのウェブサイト上で「問い合わせ」フォームがどのように機能するのかと、同様である。技術的側面において、インフォパス「スマートフォーム」は、データを、提出の記録を保持することとなる標準的なシェアポイントリスト（ライブラリではない）に提出するように構成されることとなる。それは、管理者のみがこれらの提出を閲覧でき且つこれに対して動作を起こすことができるように、保護されることとなる。図８は、受信されるデータに基づいて提出をレビューする動作並びに警報を生成する動作とともに、ワークフローにおいて使用される通知点を例示する。

ユーザは、匿名で提出にマークを付すことができ、又は彼らはシステムに対して彼ら自身を特定できる。

カスタムセキュリティイベントレシーバ − ユーザが彼らの以前の提出を閲覧することが可能となることを必要とする場合、単純なコードが、特定のセキュリティを、提出される各アイテムに適用するために実行可能である。このコードはイベントレシーバとして実行し、提出者に対して読み出し専用とするセキュリティを設定し、また閲覧している分析者グループに対して寄与許可を与えるであろう。

警報への自動変換 − 分析者に対して、収集されたフィールドのいくつかを新たな警報にコピーすることを許す、カスタムワークフロー動作は使用されてもよい。この処理は、他の重要な側面とともに、警報の種類を識別でき得る。

リストベースの収集 − 通常のシェアポイントリストは、ユーザが彼らが生成したアイテムを閲覧することのみを許可されるように、許可を管理することをあなたに任せる設定を有する。この設定は、インフォパスフォームライブラリ等の、文書ライブラリベースのリスト上で利用可能ではない。これらのセキュリティ設定は、どのユーザが閲覧可能であるかの、あるレベルの制御を許可し得る。

入力されるデータ供給

ＦＳ−ＩＳＡＣは現在、ＮＣ４警報を、特定の入力される電子メールアドレスを介して、添付されたＸＭＬファイルとして受信する。パイソン（Ｐｈｙｔｈｏｎ）コードはこの場合、このＸＭＬを抜き出して、ノードを読み出し、次いでそのＡＰＩを用いることによってアーチャー（Ａｒｃｈｅｒ）内の対応する警報を生成する。新たなシステムは、同様の方法でＮＣ４警報を処理できるであろうが、特徴のＸＭＬ供給がサポートされることを可能とするように構成されることとなる。

ＮＣ４ｘｍｌを例として用いることで、ウェブサービスは、入力されるＸＭＬデータを受信するように、且つそれを、「管理者」（設定可能）のみがアクセス可能である「入力される供給」と呼ばれるシェアポイントフォームライブラリに配置するように生成する。このリストは、全ての入力される供給データのログとして動作することとなり、ソート可能／検索可能であろう。インフォパスは、ＵＩを供給データに提供するように使用可能であり、またカスタムワークフロー動作を使用して実際の警報を生成することができる。これが機能するために必要とされる構成要素について、以下に説明する。

カスタム入力供給ウェブサービス − カスタムソープ（ＳＯＡＰ）ベースのウェブサービスは、入力されるデータ供給ＸＭＬファイルをサポートするように、生成されることとなる。ウェブサービスはユーザ名／パスワードを用いて保護されることとなり、また接続パーティは適応認証を用いて白にリストされる。ウェブサービスは、型（「ＮＣ４」、「他」）を識別するために、入力されるＸＭＬファイルのための１つのパラメータと、別のパラメータとを必要とすることとなる。ウェブサービスは、入力されるＸＭＬが、特定された型のスキーマに一致することを確認する。ラウンチ時において、いかなる外部ユーザもウェブサービスを直接的に使用することはないが、ＮＣ４警報を同時に処理する同一のパイソンコードはまた、それらを処理してそれらをシェアポイントに追加することとなる。

インフォパスフォーム、及びコンテンツの種類 − インフォパスは、構造化されたＸＭＬの周辺のＵＩを提供する能力を有する。インフォパスベースのフォームは、ＮＣ４警報構造化ＸＭＬに基づいて生成されることとなる。フォームは、読み出し専用ではあるが、入力されるデータを閲覧する良い方法をユーザに対して提供することとなる。

入力されるＸＭＬ処理動作 − 入力されるＸＭＬにおけるデータに基づいて通常の「警報」リストにおけるＮＣ４警報を生成することとなるシェアポイントワークフロー動作が生成可能である。ワークフロー動作は、必要に応じて、付加的な処理及び通知ステップを付加するように、ある柔軟性を与えるように使用されることができる。

これらのステップは、ウェブサービス及びＸＭＬ処理動作のために、適切な量のコーディングを必要とする。フォーム、リスト、及びコンテンツの種類はまた全て、相対的に直接的である。

全ての入力される供給データは、ＸＭＬである。

全ての入力されるＸＭＬ供給は、構造化されたＸＳＤ文書によって規定されることとなる。

データはサーバに押し出され／送信されることとなり、またサーバは設定可能なスケジュールに基づいてデータを引き出すことを必要とすることとはならない。

入力される供給データをライブラリの形式のＸＭＬとして格納することの代わりに、ＸＭＬはＳＱＬ統合サービスを用いて処理されてもよい。このシナリオでは、ＸＭＬはウェブサービスによって受信され、ＳＱＬ統合サービスによって処理され、またテーブル構造にマップされ得る。そのことはＢＣＳ外部リストを介してユーザに明らかにされるであろう。入力されるフォーマットがＣＳＶである場合において、若しくはデータが複数のアイテムを含み且つそれらがインポートされる前にある変換を必要とする場合において、この設計は良いアプローチである。

出力されるデータ供給

警報情報を供給として引き出す能力。これらの供給は、外部の消費アプリケーションが警報情報をセキュアに読み出す能力をもたらし、それは本発明の更なる実施形態である。「黄」のレベルまでのコンテンツのみが供給に含まれ得る。なぜならば「赤」はセキュアＩＤを必要とするからである。ユーザは、彼らのユーザ名／パスワードを使用して供給情報にアクセスすることが可能であり得る。

シェアポイントは基本的なＲＳＳの機能を含むが、シェアポイントはまた、フィルタ及びクエリを消費アプリケーションが特定することを許可することによって、それらが受信する情報に対するより高い管理能力を利用アプリケーションが有することを許可する「ＲＥＳＴ」ベースのインタフェースを提供する。消費アプリケーションはまた、ＪＳＯＮ、Ａｔｏｍ、及びＡｔｏｍＰｕｂを含む、返される結果をそれらが受信することを望む出力フォーマットを特定することができるであろう。アウトオブザボックスのｒｅｓｔＡＰＩは、このサービスの周辺にラッパを生成して「赤」のコンテンツを除外するであろう「ＬｉｓｔＤａｔａ．ｓｖｃ」サービスを介して存在する。以下は、コンポーネントに関するいくつかの詳細である。

データ供給サービス - 「ＡｌｅｒｔＤａｔａＦｅｅｄ．ｓｖｃ」は、アウトオブザボックスＲＥＳＴ ＡＰＩの周辺のラッパとしての機能を果たすこととなるが、「赤」のコンテンツを除外して「警報」リストへのアクセスのみを許すこととなる。

制限されたＵＲＬ - データ供給がアクセスされる「ｄａｔａ．ｆｓｉｓａｃ．ｃｏｍ」等のデータ特有のＵＲＬを設定することが必要であり得る。

各ユーザ／クライアントシステムは、データ供給ＵＲＬにアクセスするように個別に要求される場合があり、データ供給ＵＲＬは今度はクエリをシェアポイントに送信してデータを返し得る。このようにＡＰＩ機能を開くとき、呼び出しアプリケーションことは過度に多くの要求を送信して、意図しないサービス妨害攻撃を実質的に引き起こしてしまうという懸念が常にある。デフォルトでは、シェアポイントは、クライアントアプリケーションがマークを付してそのためこれがサイトの性能全体に悪影響を及ぼし得る、呼び出しの数を制限する如何なる種類の機能も有しない。また、クライアントシステムが警報の集合全体をダウンロードすることができることを必要とする場合、これはシステムに付加的な負荷を課し得る。以下は、これらの点に対処し得るいくつかの考察である。

データ供給サーバ - シェアポイント上でデータ供給をホスティングすることに代えて、データ供給は、夜間のジョブの一部として、シェアポイントから別のサーバにダンプされてもよい。この２次的なサーバは、データを消費アプリケーションに供給し得、従って最新のデータダンプであり得、しかしエンドユーザの性能に悪影響は与えないであろう。

ＡＰＩ不正検出 - ＡＰＩロックアウトは、クライアントシステムがマークを付している呼び出しの数を検出でき、設定可能な閾値を超える全ての呼び出しをブロックでき得る。これにより確実に、データ供給ＵＲＬが応答できる状態を保てる。

フルデータダンプ、及び差分 - 夜間のデータダンプを用いて、設定可能な差分ダンプはもちろん、警報のフルエクスポートを行うことが可能となり得る。これは、加入しているユーザが、彼らの受信することを欲するデータを選ぶことができることを可能にし得る。テキストベースのデータのみがダンプ（添付無し）に含まれ、且つ実際の警報の数が与えられるため、実際のダンプファイルサイズは、まだ管理可能であろう。ダンプファイルは、更なる圧縮のためにジップ圧縮され得る。

ＶＥＲＩＳフレームワーク分類

ＶＥＲＩＳフレームワークの一部として使用されるタクソノミーの実施は、望ましい。

現在の実施において収集されるメタデータの一部との重複がある。これらの重複のマッピングは、データの種類の互換性とともに実行され得る。標準的な分類種類、並びにサポートしている検索リスト及び値のいくつかは、実施され得る。関連性のあるメタデータを用いた新しいＶＥＲＩＳ準拠コンテンツタイプは生成され得、また警報リストと関連付けられ得る。既存の非準拠コンテンツタイプは、隠し（ｈｉｄｄｅｎ）としてマークが付され得るが、以前に生成されたコンテンツはもとのままの状態を保ち得る。更に、これらの新しいコンテンツタイプのために編集及び閲覧ページは生成されてもよい。

任意に、既存のコンテンツの全てがＶＥＲＩＳフォーマットに移行すべきである場合、ある移行処理は設定され得る。アーチャー（Ａｒｃｈｅｒ）からの移行のために使用される同じＭｅｔａＬｏｇｉｘ移行ツールはこの目的のために使用されてもよい。価値変換は、移行構成の一部として設定され得る。例えば、列１に対する「価値Ａ」は今や、列２における「価値Ｂ」になる。

ＣＩＮＳプロファイル同期

ＦＳ−ＩＳＡＣは、「ＣＩＮＳ」（重要基盤通知システム）と呼ばれるデル／メッセージワン（Ｄｅｌｌ／ＭｅｓｓａｇｅＯｎｅ）によってホストされる「警報発見（ＡｌｅｒｔＦｉｎｄ）」と呼ばれるサービスを利用する。ＦＳ−ＩＳＡＣの全会員は、ポータルな通知のためには使用されないが他の重要な／障害に関連するシナリオのために使用されるこのサービスを用いて登録される。現在の会員は、ＣＩＮＳにおいて彼らのコンタクト情報を維持する必要があり、また彼らのシェアポイントプロファイルにおいて彼らの情報を維持することが必要であることとなる。本発明の実施形態によれば、シェアポイントにおける変更は、ＣＩＮＳ内の、ユーザの、対応するプロファイルに同期されてもよい。

ＣＩＮＳシステムは、このデータを同期させるために利用可能なＡＰＩを有する。アクティブディレクトリに対するプロファイル同期の一部として、しかしながら、同期を、ＣＩＮＳ等の他のカスタムの場所に設定することはまた可能である。これを行うためにＳｈａｒｅＰｏｉｎｔ．ＮＥＴ ＢＣＳコネクタは生成されてもよく、これはシェアポイントプロファイルフィールドとＣＩＮＳを介して利用可能なフィールドとの間のマッピングを含み得る。「ユーザ名」は、これら２つを一緒にマップするための鍵として使用され得るが、これはＡＰＩを見ることによって確認される必要があり得る。

プロファイル同期ジョブは、同期されている情報の種類と量に依存する。典型的には、ユーザプロファイルデータベースに対するＢＣＳコンテナは、それを完全にライトバックすることとは対照的に、付加的な情報をシェアポイントに引き出している。コンテナをＣＩＮＳサーバに統合する１つの方法は、如何なるフィールドマッピングも行われないが、コードがプロファイルサービス同期タイマージョブの一部として実行することであろう。別のオプションは、ＣＩＮＳに対する同期がＡＤプロファイル同期に独立して起きるカスタムタイマージョブを生成することである。

ＣＩＮＳに対する同期は、シェアポイントからＣＩＮＳへの、１つの方法である。

ユーザが彼らのＣＩＮＳプロファイルを更新する場合、値は、次の更新時に、シェアポイントによって上書きされる。

「ユーザ名」は、ＣＩＮＳにおける記録にアクセスするための鍵として使用可能であり、他の特定の「ＩＤ」フィールドは使用される必要はないであろう。

警報発見（ＡｌｅｒｔＦｉｎｄ）製品はまた、ＸＭＬフォーマット又はＣＳＶフォーマットでのある種のデータダンプを受け入れる。重要なユーザプロファイル情報をこのデータダンプフォーマットにエクスポートするジョブを生成することが可能であり、次いでこのファイルはＣＩＮＳに送信される。ファイルのＣＩＮＳへの送信はマニュアル処理であり得る。これは、どの程度の頻度でプロファイル情報が変化するかに依存して、より経済的なアプローチであってもよいことが可能である。

Claims (12)

1. 異なる複数の機密レベルが割り当てられている情報の２つ又はそれよりも多くのセットへの、コンピュータネットワークを介したアクセスを選択的に許可する方法であって、
   コンピュータを用いて、許可されるアクセスの第１のレベルを有する情報の第１のセット又はデータの集合を指定するステップと、
   コンピュータを用いて、許可されるアクセスの第２のレベルを有するデータの集合の情報の第２のセットを指定するステップであって、前記情報の第１のセット及び前記情報の第２のセットは、非一時的コンピュータ読み出し可能な媒体上に格納される、ステップと、
   ユーザＩＤ及びパスワードのみを要求する認証処理を介して、前記情報の第１のセットへの、コンピュータネットワークを介したアクセスを許可するステップと、
   ユーザＩＤ、パスワード、及びハードウェアトークンのみを要求する認証処理を介して、前記情報の第２のセットへの、コンピュータネットワークを介したアクセスを許可するステップと、
   を含む方法。
2. 同一セッションにおいて、ユーザＩＤ及びパスワードを用いて、前記情報の第１のセットへのアクセスの権限が既に与えられている場合、ハードウェアトークンのみを要求する認証処理を介して、前記情報の第２のセットへのアクセスを許可するステップを含む、
   請求項１記載の方法。
3. ユーザＩＤ及びパスワードのみを要求する認証処理を介して、前記情報の第１のセットへのアクセスを許可し、次いで、同一セッションにおいて、ハードウェアトークンのみを要求する更なる認証処理を介して、前記情報の第２のセットへのアクセスを許可するステップを含む、
   請求項１記載の方法。
4. 前記パスワードは、前記ハードウェアトークンのためのＰＩＮとしての役割を果たす、
   請求項１記載の方法。
5. コンピュータを用いて、許可されるアクセスの第３のレベルを有する情報の第３のセット又はデータの集合を指定するステップであって、前記情報の第３のセットは、非一時的コンピュータ読み出し可能な媒体上に格納される、ステップと、
   認証処理を必要とすることなく、前記情報の第３のセットへの、コンピュータネットワークを介したアクセスを許可するステップと、を更に含む、
   請求項１記載の方法。
6. 単一のセッションにおいて、認証処理を必要とすることなく前記情報の第３のセットへのアクセスを許可し、次いで、前記情報の第３のセットへのアクセスを許可した後、ユーザＩＤ及びパスワードのみを要求する認証処理を介して、前記情報の第１のセットへのアクセスを許可し、次いで、前記情報の第１のセットへのアクセスを許可した後、ハードウェアトークンのみを要求する認証処理を介して、前記情報の第２のセットへのアクセスを許可するステップを含む、
   請求項５記載の方法。
7. 電子メッセージ配信リストを、オンラインディスカッションフォーラムと統合する方法であって、
   配信リストに送信される全てのメッセージを、前記オンラインディスカッションフォーラムに投稿するステップを含む方法。
8. 前記配信リストに送信されるメッセージの、前記オンラインディスカッションフォーラム上への投稿は、前記メッセージと関連付けられるディスカッションスレッドを含む、
   請求項７記載の方法。
9. 前記オンラインディスカッションフォーラムへのアクセスは、ユーザＩＤ及びパスワードのみを要求する認証処理を介して許可される、請求項７記載の方法。
10. 前記オンラインディスカッションフォーラムへのアクセスは、ユーザＩＤ、パスワード、及びハードウェアトークンのみを要求する認証処理を介して、許可される、
    請求項７記載の方法。
11. 前記情報の第１のセットは、オンラインディスカッションフォーラムを含む、
    請求項１記載の方法。
12. 前記情報の第２のセットは、オンラインディスカッションフォーラムを含む、
    請求項１記載の方法。