| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース1 (11.1.1) E67347-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース1 (11.1.1) E67347-01 |
|
前 |
次 |
Oracle Adaptive Access Managerでは、エージェント・ケースを作成することにより、フォレンジック調査をより速く、より簡単に、より正しく実行できます。調査担当者は、不正なケースに接続している可能性がある関連セッションをリンクして、リンクされているデータ、疑わしいアクティビティが発生したセッション、またはアラートが生成されたセッションの関係を特定できます。調査担当者は、疑わしいセッションをリンクできます。また、疑わしくないと判断したセッションのリンクを解除することもできます。
この章では、調査担当者が新規のエージェント・ケースを使用するための情報について説明します。内容は次のとおりです。
この項では、調査担当者と、彼らがOracle Adaptive Access Managerのエージェント・ケースを使用して不正アクティビティを調査する方法の概要について説明します。
エージェント・ケースは、調査に使用されるツールです。これは、手動または自動で作成できます。
CSRは、調査担当者による調査がさらに必要なためにケースをエスカレーションする場合にエージェント・ケースを作成します。詳細は、第5.1.2.3項「エスカレーション済ケース」を参照してください。
不正調査担当者は、疑いのあるアクティビティまたは不正なシナリオが検出され、調査が必要な場合にエージェント・ケースを作成します。
構成可能なアクションにより、チェックポイント実行後に結果アクションまたはリスク・スコア(またはその両方)に基づいてトリガーされる補足アクションとしてエージェント・ケースが自動的に作成されます。
エージェント・ケースは、特定のユーザーに対して作成されません。特定のシナリオに対して作成されます。イベントは、自動的にケースを作成するように構成できます。エージェント・タイプのケースは、不正調査担当者が次の操作を行う場合に使用します。
どの調査担当者がケースに対して作業を行うかを含む監査の調査結果の収集
重大度、ステータス、所有者の変更、解決までの時間、削除されたケースおよび失われたケース、解決を含む調査のライフサイクルの管理
クローズ済の調査結果をリスク・エンジンにフィードバックして、将来の評価の正確性を自動的に改善する場合
外部レコードまたはプロセスに関する調査結果のExcelへのエクスポート
不正調査担当者は、OAAMにより取得された複雑なデータ関係を簡単に利用して、インシデントに関連するデータをすばやく表示したり、関連する状況をすぐに見つけることができます。検索および詳細ページで、不正調査担当者は次の操作を実行できます。
個別のセッションを詳細に調べて、アラートが出される原因となった一連のイベントを特定します。
異なるデータ型間の複雑な関係を表示および検索します。
調査フローから外れずに、エンティティをホワイト・リストやブラック・リストに記載します。
調査をさらに絞り込むために、セッション・データをケースにリンクします。
ケース・ステータスは、ケースの現在の状態です。ケースに使用されるステータス値は、「新規」、「保留中」、「エスカレーション済」または「クローズ済」です。
表5-1 ケース・ステータス
| ステータス | 定義 |
|---|---|
|
作成時のケースのステータス。 |
|
|
まだ解決されていないケースのステータスです。 |
|
|
問題が解決されたときのケースのステータス。 |
|
|
エスカレーション済 |
CSRがケースをエスカレーションする場合のケースのステータス。 |
ケースは、その作成時は方法(手動/構成可能なアクション)に関係なく新規となります。新規ケースに初めてアクセスすると、そのステータスは自動的に「保留中」に変わります。たとえば、エージェント・ケースを構成可能なアクションで作成する場合、その中には、作成に関するセッション・データが含まれ、ステータスは「新規」となります。調査担当者が「新規」ステータスのエージェント・タイプのケースをすべて検索し、いずれかの新規ケースのケースの詳細ページを開く場合、ケース・ステータスは、自動的に「保留中」に変わります。これによって調査担当者は、他の調査担当者がすでにそのケースを使用しているかどうかを判断できます。
CSRケースをエージェント・ケースにエスカレーションする場合、プロセスでのステータスは「エスカレーション済」に変わります。調査担当者が初めてケースにアクセスすると、ステータスが自動的に「保留中」に変わります。CSRは、ケースを解決できず、調査担当者による追加調査を必要とする場合、または特定のユーザーに関連する疑わしいアクティビティがあると判断し、調査担当者による追加調査を求める場合に、ケースをエスカレーションします。エスカレーションされたケースはエージェント・ケースとして扱われ、CSRには表示されなくなります。ただし、すべてのエージェントがエスカレーション済ケースを処理できます。
不正調査担当者および不正調査マネージャは、Oracle Adaptive Access Managerで提供されている即時利用可能なロールです。不正調査担当者は、特定の不正シナリオまたは疑わしいパターンを調査します。シナリオまたはパターンを使用するには、エージェント・ケースを作成します。不正調査マネージャは、不正調査担当者が実行権限を持たないアクションにアクセスできます。彼らは、クローズ済ケースとバルク編集ケースを再度開くことができます。不正なセッションに影響を与えるには、エージェント・ケースを作成してから、不正なセッションをそのケースにリンクします。不正のタイプに基づき、さらにケース・アクションを実行します。
不正調査に関連付けられた、即時利用可能な権限について表5-2にまとめています。その他のアクションについては、付録A「アクセス・ロール」を参照してください。
表5-2 不正調査ロールの権限
| アクション | 調査担当者の権限 | 調査マネージャの権限 |
|---|---|---|
|
アクション |
調査担当者ロールのすべての機能 |
調査担当者ロールのすべての機能と特別な権限 |
|
ケースの検索 |
|
|
|
新規ケース |
エージェント・ケースのみ |
エージェント・ケースのみ |
|
ケース詳細の表示 |
|
|
|
ケースの編集 |
|
|
|
セッションの検索 |
セッションの検索 |
セッションの検索 |
|
セッションのリンク |
セッションのリンク |
セッションのリンク |
|
セッションのリンク解除 |
セッションのリンク解除 |
セッションのリンク解除 |
|
リンク・セッションの表示 |
リンク・セッションの表示 |
リンク・セッションの表示 |
前述の操作を実行するには、調査担当者としてログインします。ナビゲーション・ツリーで「ケース」をダブルクリックしてケースの検索ページを開きます。
あるいは、次の方法でケースの検索ページを開くことができます。
ナビゲーション・ツリーで「ケース」を右クリックし、コンテキスト・メニューから「ケースのリスト」を選択します。
ナビゲーション・ツリーで「ケース」を選択し、「アクション」メニューから「ケースのリスト」を選択します。
ナビゲーション・ツリーのツールバーの「ケースのリスト」ボタンをクリックします。
ケース検索ページには、関心を持っているケースの検索に役立つ検索ツールが含まれます。「検索結果」表には、指定した基準を満たすケースのリストが表示されます。環境をアップグレードした場合、以前のリリースのエージェント・ケースも表示できます。ケース番号にはリンクが設定されています。ケース詳細を表示するには、リンクをクリックします。すべての検索表とダイアログ・ボックスの必須フィールドにはアスタリスクが付いています。
ケース検索ページには、関心を持っているケースの検索に役立つ検索ツールが含まれます。
ケース検索ページから、検索フィルタで基準を指定します。
表5-3 検索フィルタ
| フィルタ | 説明 |
|---|---|
|
組織ID |
組織のケースを検索するには、「組織ID」を選択します。CSRは、アクセス権を持つ組織の「組織ID」のリストからいずれかを選択できます。 |
|
ユーザー名 |
エージェント・ケースの「ユーザー名」フィールドは空白です。 |
|
ユーザーID |
エージェント・ケースの「ユーザーID」フィールドは空白です。 |
|
ケースID |
特定のケースを検索するには、ケースIDを入力します。 |
|
説明 |
説明に含まれるキーワードでケースを検索するには、目的の語を入力します。説明で検索すると、「説明」フィールドに一致する語が含まれるすべてのケースが表示されます。 |
|
ケース・タイプ |
ケース・タイプでケースをフィルタリングするには、「エージェント」を選択します。 |
|
重大度レベル |
重大度レベルでケースを検索するには、「低」、「高」または「中」を選択します。 |
|
ケース・ステータス |
ケース・ステータスでケースをフィルタリングするには、「新規」、「保留中」、「クローズ済」または「エスカレーション済」を選択します。 |
|
有効期限切れ |
有効期限切れかどうかでリストをフィルタリングするには、必要なオプションを選択します。 使用できるオプションは次のとおりです。
|
|
作成日 |
指定の作成日範囲内に作成されたケースを検索するには、範囲の開始日および終了日を入力します。 |
|
処置 |
処置でケースをフィルタリングするには、次のいずれかを選択します。
処置は、ケース内の問題が解決された方法を示します。ケースに処置が存在するのは、クローズされている場合のみです。ケースが「クローズ済」以外のステータスを持っている場合、処置は空白のままになります。 |
|
最終アクション |
ケースで実行された最終アクションに基づいて検索します。 |
|
ノート |
ログに特定のキーワードが含まれるケースを検索します。たとえば、支払拒否という語が含まれるすべてのエージェント・タイプ・ケースを検索する場合、「使用デバイスは支払拒否数に関連します」という文が含まれるノートを持つケースがケース・リストに返されます。 |
|
作成者 |
ケースを作成したエージェントのユーザー名で検索します。 |
|
現在の所有者 |
このケースを現在使用している(最終アクションを実行した)エージェントのユーザー名で検索します。 |
「検索」をクリックします。
マルチテナントが有効になっている場合、検索結果には、CSRがアクセス権を持っている組織に属するユーザーのケースのうち、検索基準に一致するものがすべて表示されます。ユーザーなしのケースの場合、ケース所有者の組織IDがエージェントのアクセス権リストに含まれており、ケースが検索基準に一致する場合に、ケースが結果セットに含まれます。
期限超過ケースの検索
エスカレーション済ケースとエージェント・ケースは、デフォルトで24時間を経過すると有効期限が切れて期限超過となります。その後、期限超過のフラグが設定されます。調査担当者がケースにアクセスすると、有効期限日はリセットされます。期限超過のエージェント・ケースを検索するには、「期限切れ」フィルタに「有効期限切れのみ表示」を選択します。有効期限列に日時が赤で表示されるケースが期限超過ケースです。
ケース検索ページで、自分が現在使用中のケースを検索するために「現在の所有者」フィールドに自分のユーザー名を入力し、「検索」をクリックします。「検索結果」表に自分が現在使用中のケースのリストが表示されます。
エージェントの「ケース詳細」ページは、ケースが正常に作成されると開きます。アクセス可能なグループに所属する任意のユーザーに所属するケース、または自分の「組織ID」に関連付けられたケースに対する検索結果から、エージェント・ケース詳細ページを開くこともできます。
|
注意: 一度に開くことができるケースは1つのみです。複数のケースを開こうとすると、エラーが発生します。 |
エージェント・ケースおよびエスカレーション済ケースには次のタブが含まれます。
サマリー: ケースに関する詳細をリストします
リンク・セッション: ケースにリンクされたセッションをリストします
ログ: ケース・アクション・ログをリストします
「サマリー」タブには、ケース詳細が表示され、ケースがエスカレーション済ケースの場合には、そのケースに関連付けられているユーザーの詳細が表示されます。ユーザーなしのエージェント・ケースには「ユーザー詳細」セクションが表示されます。
「サマリー」タブには、エージェント・ケースのケース詳細が表示されます。エージェント・ケースがエスカレーション済ケースの場合は、そのケースに関連付けられているユーザーの詳細も表示されます。
「ケース詳細」には、次の情報が表示されます。
表5-4 ケース詳細
| 詳細 | 説明 |
|---|---|
|
組織ID |
ケースの組織ID。 |
|
ケース作成済 |
エージェント・ケースが作成された日付。 |
|
ケース・ステータス |
ケース・ステータスは、エージェント・ケースが手動で作成された場合は「保留中」になり、エージェント・ケースが(構成可能なアクションによって)自動的に作成された場合は「新規」になり、ケースがアクセスされると「保留中」に変わります。エスカレーション済ケースでは、ケース・ステータスは「エスカレーション済」になり、エージェントがこのケースにアクセスすると、「保留中」に変わります。 ケース・ステータスは、様々な管理者によりアクセスされると変更されます。 |
|
重大度レベル |
重大度レベルはケースを作成するユーザーによって設定され、このケースの重大度をユーザーに伝えるマーカーとして使用されます。誰でもケースの重大度を変更できます。 |
|
ケース・タイプ |
「エージェント」、「CSR」または「エスカレーション済」(エスカレーション済ケースは作成できません) |
|
ケース番号 |
一意のケースID |
|
処置 |
ケースが閉じている場合、処置はケース内の問題が解決された方法を示します。ケースに処置が存在するのは、クローズされている場合のみです。ケースのステータスがクローズ済以外である場合、処置は空白です。 |
|
有効期限日 |
エージェント・ケースおよびエスカレーション済ケースには、作成日から24時間のデフォルトの有効期限日があります。有効期限日より前にケースがアクセスされない場合、ステータスが「期限超過」になります。ケースにアクセスするたびに、エージェント・ケースまたはエスカレーション済ケースの有効期限日が新しい値にリセットされ、デフォルトではこの日付はケースにアクセスがあった日付から24時間後にリセットされます。ケースの有効期限が切れるまでの時間は構成可能です。有効期限動作の構成の詳細は、第5.10項「エージェント・ケースの有効期限/期限超過動作の構成」を参照してください。 |
|
期限超過 |
有効期限日よりも前にケースにアクセスがなかった場合、期限超過フラグが設定され、マネージャはそのケースが要注意であることを判断できます。たとえば、24時間で有効期限が切れるようにエージェント・ケースが設定され、24時間を超えてケースへのアクセスがなかった場合、フラグが「期限超過」に設定されます。調査担当者がケースにアクセスしても、期限超過日に影響はありません。アクションを実行すると、期限超過はリセットされます。期限超過動作は構成可能です。詳細は、第5.10項「エージェント・ケースの有効期限/期限超過動作の構成」を参照してください |
|
説明 |
ケースの詳細。説明は必須です。 |
|
最終ケース・アクション |
エスカレーション済ケースまたはエージェント・ケースで実行された最後のアクション。エージェント・ケースにはユーザー詳細はありません。 |
|
最終ケース・アクションの日付 |
最後のアクションが行われた日付。 |
|
最終グローバル・ケース・アクション |
エスカレーション済CSRケースから作成されていないエージェント・ケースの場合、「最終グローバル・ケース・アクション」フィールドは常に空です。ユーザーに関連付けられているエージェント・ケース(エスカレーション済ケース)の場合、最終グローバル・ケース・アクションは、エージェント・ケースに関連付けられているユーザーが最後に実行したケース・アクションです。ケース・アクションは、すべてのケースに対して実行できます(CSR/エージェント) |
|
最終グローバル・ケース・アクションの日付 |
オンライン・ユーザーに対して実行された最後のアクション。 |
|
現在の所有者 |
現在このケースを使用中のエージェントの名前 |
|
作成者 |
ケースを作成したエージェントの名前が表示されます。構成可能なアクションによってケースが作成されている場合、「作成者」には「動的」と表示されます。 |
エスカレーション済ケースのユーザー・データには、次の情報が表示されます。
表5-5 ユーザー・データ
| データ | 説明 |
|---|---|
|
ユーザー名 |
ケースが作成された対象のユーザー。 |
|
ユーザーID |
自動生成されるかどうか。 |
|
組織ID |
アプリケーションの識別子。(マルチテナント・デプロイメントの場合、CSRは自分のプライマリ・アプリケーションIDに限定されたケースにのみアクセスできます。CSRマネージャおよび調査担当者は、複数のアプリケーションのケースにアクセスできます) |
|
最終オンライン・アクション |
ユーザーが実行した最後のアクション。たとえば、チャレンジ質問に回答した場合はフィールドに「チャレンジ質問」と表示され、ユーザーがブロックされた場合は「ブロック」と表示されます。 |
|
最終オンライン・アクションの日付 |
最後のオンライン・アクションが実行された日付。 |
|
一時許可の有効期限日 |
一時許可が有効になっている場合、このフィールドには、その有効期限日が示されます。一時許可が7日の場合、有効期限日は今日から1週間後です。 |
|
一時許可有効 |
一時許可が有効である場合、このフィールドには「はい」と表示され、それ以外の場合は「いいえ」と表示されます。 |
|
OTPバイパス有効 |
一時許可と似ていますが、OTPチャレンジはブロックではなく無視されます。 |
|
OTPバイパス有効期限日 |
OTPバイパスが有効でなくなる日時。 |
|
完了した登録 |
ユーザーが登録を完了している場合、このフィールドには「はい」と表示され、それ以外の場合は「いいえ」と表示されます。登録するには、ユーザーはパーソナライズ(イメージとフレーズ)、KBA質問/回答の登録、および電子メール/携帯電話の連絡先情報の入力をすべて完了する必要がある場合があります。 |
|
アクティブな質問 |
ユーザーが登録を完了していても質問がリセットされており、ユーザーが戻って新しい質問を登録していない場合、このフィールドには「いいえ」と表示されます。ユーザーが登録を完了しており、ユーザーにチャレンジするために使用できる質問が存在する場合、このフィールドには「はい」と表示されます。 |
|
OTP提供方法有効 |
ユーザーは、OTPチャレンジ用に電子メールまたは携帯電話のいずれかを登録しています。 |
|
パーソナライズ・アクティブ |
イメージ、フレーズおよび質問がユーザーに対して有効になっている場合、このフィールドには「はい」と表示されます。これらのいずれかがリセットされている場合、このフィールドには「いいえ」と表示されます。 |
「リンク・セッション」タブには、調査中のケースにリンクされているすべてのセッションが表示されます。タブには、リンクされた日付、およびリンク時に入力されたノートなどの情報も表示されます。セッション結果のページを開く「セッションのリンク」アイコンをクリックして、調査に接続していると思われるセッションをいくつでもリンクできます。このケースにすでにリンクされている1つ以上のセッションのリンクを解除できます。
ログ・セクションには、ケースに対して行われたアクションのログが表示されます。検索フィルタは次のとおりです。
表5-6 ログ検索フィルタ
| フィルタ | 説明 |
|---|---|
|
ノート・キーワード |
事前に作成したノートからのキーワード。 |
|
ARM ID |
CSR識別子。 |
|
アクション |
ケースの最後のアクション。たとえば、jsmithは昨日カスタマ・サービスに電話をかけ、自分のアカウントからお金が失われていることを伝えました。CSRはケースをエスカレーションし、jsmithに24時間以内に連絡することを伝えました。36時間後、jsmithは再度電話をかけて、連絡がない理由を尋ねます。CSRは、jsmithに対して昨日エスカレーションされたケースを表示する必要があります。彼は、「エスカレーション」アクションを含むjsmithのケースおよび過去48時間以内に期限超過していないケースを検索します。 |
|
作成日 |
ケースが作成された日付。 |
新規エージェント・ケースは、疑いのあるアクティビティまたは不正なシナリオが検出され、調査が必要な場合に作成されます。エージェント・タイプ・ケースを直接作成できるのは調査担当者のみです。エージェント・タイプ・ケースの作成では、ユーザー情報は表示されず、また必要ありません。エージェント・ケースを作成するために入力する必要があるのは、組織ID、重大度および説明のみです。
ユーザーなしの新規エージェント・ケースを作成する手順:
ケース検索ページで、「新規ケース」をクリックします。
調査担当者がこのケースを作成していることが、ログインからすでにシステムに通知されているため、ケース・タイプとして「エージェント」が指定された「ケースの作成」ダイアログが表示されます。
アクセス権のある「組織ID」のリストが表示されます。リストから「組織ID」を1つ選択できます。後で必要に応じて、異なる組織IDのケースを作成できます。
|
注意: エージェント・ケースはユーザーなしのケースであるため、ユーザー名またはユーザーIDを入力する必要はありません。 |
「重大度レベル」リストから重大度レベルを選択します。
使用可能な重大度レベルは、「高」、「中」および「低」です。
「説明」テキスト・ボックスにケースの説明を入力するか、「説明」リストから説明を選択するか、またはその両方を行います。
デフォルトの説明タイプは「カスタム説明」です。「説明」テキスト・ボックスには英数字および特殊文字を含めることができますが、4000文字以下である必要があります。「説明」リストから、一度に1つずつ、任意の数の説明を選択できます。リストから選択された各説明は、前の説明に追加されます。
「説明」は必須フィールドです。説明が入力されるまで、「作成」ボタンは無効になっています。
「作成」をクリックします。
すべてのフィールドに入力されるまで、「作成」ボタンは無効になっています。*(アスタリスク)は必須フィールドを示します。無効なパラメータが入力されると、エラー・メッセージが表示され、新規ケースは作成されません。
変更を取り消してケース検索ページに戻るには、「取消」をクリックします。「作成」をクリックして新規ケースを作成します。
ケースが作成され、新規ケースの「ケース詳細」ページが開きます。詳細は、第5.5.3.1.1項「ケースの詳細」を参照してください。「ケース詳細」ページには、ケースのステータスとして「保留中」が表示されます。エージェントが「作成者」および「現在の所有者」フィールドに示されます。ケースはユーザーなしのエージェント・ケースであるため、「ケース詳細」にはユーザー詳細は示されません。新規エージェント・ケースには、リンク・セッションは含まれません。ログを表示する場合、「ケースの作成」がアクションとして表示されます。
手動によるエージェント・ケースの作成例
エージェントは、1st Bankという組織IDに対してエージェント・タイプ・ケースを作成します。他のタイプのケース(CSRケース)は作成できません。「組織ID」は必須フィールドです。新規エージェント・ケースには、リンク・セッションは含まれません。エージェント・ケースはどのユーザーにもリンクされていないため、ケースを作成するためにユーザー情報を入力する必要はありません。
エージェント・ケースが自動的に作成されるようにアクションを構成する手順:
create_agent_caseという名前のカスタム・ルール・アクションを作成します。
適切なチェックポイントのポリシーに、必要なルール条件を持つルールを追加します。指定した条件が満たされるたびに、アクションcreate_agent_caseをトリガーして戻すようにこれを構成します。たとえば、疑いのあるアクティビティが発生するたびに、「エージェント・ケースの作成」アクションがトリガーされます。
アクション・テンプレートCaseCreationActionのアクション・インスタンスを作成し、これをチェックポイントに関連付けます。
create_agent_caseアクションを選択してトリガー基準をアクションとして設定します。
CaseCreationActionのパラメータを次のように設定します。
「ケース・タイプ」の値として2 (エージェント・タイプ)を入力します。
「重大度」に2 (中)または3 (高)を入力します。
ケースの説明を入力します。たとえば、失敗したログインです。
「ケース作成者のユーザーID」パラメータにユーザーIDを入力します。ユーザーIDにケースを作成するための適切なロールおよびアクセス権があることを確認してください。この例では、ケース作成者は動的です。
アクション・インスタンスを保存します。
アプリケーションのログインに失敗します。
ログインに失敗すると毎回、構成可能なアクションによってエージェント・ケースが自動的に作成されます。ケースのステータスは「新規」です。新規エージェント・ケースには、アクション・インスタンス・パラメータに基づく自動リンク・セッションが含まれます。この中には、その作成に関するセッション・データがあります。
自動作成されたエージェント・ケースには2つのログがあります。1つは作成用、もう1つはリンク・セッション用です。
調査担当者がケースを開くと、ケースのステータスが「保留中」に変わります。現在の所有者は調査担当者であり、「作成者」にはケース作成者のユーザーIDが表示されます。このケースのユーザー詳細も表示されます。
チェックポイント、スコア範囲、実行タイプなどのアクション・インスタンス・パラメータに対応するセッションが、構成可能なアクションによって作成されたエージェント・ケースに自動リンクされることを確認します。
エージェント・ケースの自動作成例
セキュリティ管理者は、特定のルールがトリガーされた場合にエージェント・ケースを作成するアクションを構成します。
このケース作成アクションでケースが生成されると、ルールがトリガーされたセッション・データは、リンク・セッションの形式でケースに追加されます。
不正調査担当者がOAAM管理コンソールを開くと、彼のロールで許可されているユーザー・インタフェースの適切なビューとコントロールのみが表示されます。
不正調査担当者は、新しいステータスを基準にケースを検索します
不正調査担当者が現在の所有者になるタイミングでケースを開くと、ケースのステータスが「保留中」に変わります。
彼は、引き続きケースにセッションをリンクしたり、詳細画面を使用してリンク・セッションのデータにドリルインできます。
完了したら、調査担当者は、処置およびノートを含めてケースをクローズします。
ケースをエスカレーションして調査担当者が確認できるようにする手順:
CSRからエージェント・ケースへのエスカレーション例
CSRマネージャはCSRケースをエスカレーションします
不正調査担当者は、エスカレーション済タイプのケースを取得し、CSRおよびCSRマネージャが入力したノートを読み取ります。ステータスは、「エスカレーション済」から「保留中」に自動的に変わります。
彼はユーザーのセッション履歴を検索します。
調査担当者は、Ukraineからセッションを選択し、関連するセッションとケースを検索します。疑わしいと思われるセッションまたはケースがないと判断します
このルールについて、オーバーライド・グループにユーザーを安全に追加できると判断します。
その後、調査担当者は、解決済の「カスタマ・オーバーライド」処置でケースをクローズします。
セキュリティ管理者は、3か月ごとにオーバーライド・グループからすべてのユーザーを削除します。
既存のエージェント・ケースと類似または同様の新規ケースを作成するには:
ケース検索ページの「検索結果」表で、ケースの隣にあるチェック・ボックスを選択して、エージェント・ケースを選択します。
「検索結果」表で複数の行を選択した場合、「類似作成」ボタンは無効になります。
元のケースから、組織ID、重大度レベルおよび説明が事前移入された「ケースの類似作成」ダイアログが表示されます。
必要に応じてこれらのフィールドのいずれかを編集します。
すべてのフィールドに入力してください。
必須フィールドが入力されるまで、「作成」ボタンは無効になっています。
「作成」をクリックします。
変更を取り消してケース検索ページに戻るには、「取消」をクリックします。
「作成」をクリックして新規ケースを作成します。
元のケースのデータおよび変更内容を含む新規エージェント・ケースが作成され、新規ケースの「ケース詳細」ページが開きます。エスカレーション済エージェント・ケースと同様に作成された新規エージェント・ケースには、ユーザー・データは含まれません。ケース・ステータスは「保留中」です。
エージェント・ケースでアクションを実行し、ノートの追加、ケースの重大度レベルの変更またはケースのステータスの変更が可能です。
ケースでアクションを実行するたびに、そのアクションを実行する理由を記述するノートを入力する必要があります。ノートはケース・ログに保存されます。
ケースにノートを追加するには:
「ケース詳細」ページで「ノートの追加」をクリックします。
「ノートの追加」ダイアログが表示されます。
事前に作成したノートを選択するか、テキスト・ボックスにノートを入力します。あるいは、両方を行います。
「送信」をクリックします。
ノートはケース・ログに保存されます。
「OK」をクリックして、確認ダイアログを閉じます。
ケースが作成されると、その重要度を示し、管理者がケースをフィルタできるようにするための重大度レベルがそのケースに割り当てられます。重大度レベルは「ケース詳細」ページに表示されます。
「ケース詳細」ページで、「その他のアクション」をクリックし、「重大度の変更」を選択します。
「重大度の変更」ダイアログが表示されます。
「重大度」リストで、必要な重大度レベルを選択します。
使用可能な重大度レベルは、「高」、「中」および「低」です。カスタマが不正を疑っている場合、割り当てる重大度レベルは「高」です。カスタマが異なるイメージを希望している場合、割り当てる重大度レベルは「低」です。必要に応じて、ケースの重大度レベルをエスカレーションまたはエスカレーション解除できます。
「ノート」リストで、必要なノートのタイプを選択します。
必要に応じてノートを編集し、実行するアクションに関する情報を追加します。
「送信」をクリックします。
ケースの重大度がケース・ログに保存されます。
「OK」をクリックして、確認ダイアログを閉じます。
ケースのステータスは手動または自動で変更できます。
シナリオでは、ケース・ステータスを手動で変更する方法を示しています。
手動でケースのステータスを「新規」に変更するには:
「ケース詳細」ページで、「その他のアクション」をクリックし、「ステータスの変更」を選択します。
「ステータスの変更」ダイアログが表示されます。
「ステータス」リストで、「新規」を選択します。
問題を記述するノートを入力します。
既存のノートから選択するか、新規ノートを入力するか、またはその両方を行います。
選択する既存のノートは次のとおりです。
マネージャの確認
その他
「送信」をクリックします。
確認ダイアログが表示されます。
「OK」をクリックします。
ケース・ステータスの自動変更を有効にするには、次のパラメータを設定します。
customercare.case.autostatuschange.enum.flowone.enabled=true
ケース・ステータスの自動変更を無効にするには、次のパラメータを設定します。
customercare.case.autostatuschange.enum.flowone.enabled=false
構成可能なアクションにより、「新規」のステータスでケースを作成します。ケースが開かれると、ステータスは「保留中」に変更されます。アクセス時にこれらのケースが「新規」から「保留中」に自動で変わるようにするには、次のプロパティを構成します。
customercare.case.autostatuschange.enum.flowone=1 customercare.case.autostatuschange.enum.flowone.name=Flow onecustomercare.case.autostatuschange.enum.flowone.description=Status flow onecustomercare.case.autostatuschange.enum.flowone.enabled=true customercare.case.autostatuschange.enum.flowone.from=new customercare.case.autostatuschange.enum.flowone.to=pending
エスカレーション済ケースには「エスカレーション済」のケース・ステータスが付きます。ケースが開かれると、ステータスは「保留中」に変更されます。アクセス時にケースが「エスカレーション済」から「保留中」に自動で変わるようにするには、次のプロパティを構成します。
customercare.case.autostatuschange.enum.flowtwo=2 customercare.case.autostatuschange.enum.flowtwo.name=Flow Two customercare.case.autostatuschange.enum.flowtwo.description=Status flow two customercare.case.autostatuschange.enum.flowtwo.enabled=true customercare.case.autostatuschange.enum.flowtwo.from=escalated customercare.case.autostatuschange.enum.flowtwo.to=pending customercare.case.autostatuschange.enum.flowtwo.casetype=agent
自動変更のアクション・ログは、エントリ「システムからのアクセス時にステータスを変更」で作成されます。
調査担当者が状況の調査を終えて結論に達した(状況を理解した)ら、ステータスを変更して、ケースをクローズし処置を付加できます。
「ケース詳細」ページで、「その他のアクション」をクリックし、「ステータスの変更」を選択します。
「ステータスの変更」ダイアログが表示されます。
「ステータス」リストで、「クローズ済」を選択します。
処置を選択します。
処置には次のような選択肢があります。
確認済不正
重複
偽陰性
偽陽性
問題保留中
問題解決済
不正ではない
問題を記述するノートを入力します。
既存のノートから選択するか、新規ノートを入力するか、またはその両方を行います。
選択する既存のノートは次のとおりです。
問題解決済
問題未解決
古いケースのクリーンアップ
ケースの重複
その他
「送信」をクリックします。
確認ダイアログが表示されます。
「OK」をクリックして、確認ダイアログを閉じます。
ケースのクローズ例
調査担当者が状況の調査を終え、カスタマに誤りがあり不正はないと判断します。ステータスの変更アクションを使用し、ケースをクローズして「不正ではない」処置を付加します。
ナビゲーション・ツリーで、「ケース」をダブルクリックします。ケース検索ページが表示されます。
必要なケースを選択します。
「バルク編集」をクリックします。
|
注意: 即時利用可能なOAAMロールについては、「バルク編集」ボタンは調査担当者ロールでは無効になっており、調査マネージャ・ロールでは有効になっています。 |
必要に応じてケース設定を変更し、ノートを追加します。
「閉じる」アクションは、重大度にかかわらず許可されます。
重大度はステータスにかかわらず編集可能です。また、ケースの重大度も、ケースの「クローズ済」ステータスにかかわらず変更できます。
「OK」をクリックして、バルク編集を実行します。
バルク編集操作が正常に実行されたというメッセージを示す確認ダイアログが表示されます。ケースを閉じるときに、バルク編集操作時にすでに「クローズ済」ステータスになっていたエージェント・ケースがある場合は、バルク・クローズ・アクションを実行するためにはエージェント・ケースが「新規」または「保留中」ステータスになっている必要があることを示すメッセージが表示されます。
「OK」をクリックしてダイアログ・ボックスを閉じます。
検索をリフレッシュすると、これらのケースのステータスが結果に表示されます。
「検索」ページの「最終ケース・アクション」は、バルク編集の直後には更新されません。これは、「検索」ページを再度起動したときに更新されます。
自分がアクセス権を持っている組織に属するユーザーに属するケースにセッションをリンクできます。
セッションが製品セキュリティに関与していると調査担当者が判断する場合、それらのセッションを検索して選択し(アクセス権のあるグループのみのセッションの確認が可能)、リンクするノートと説明を含めてケースにそれらをリンクします。
セッションをリンクする手順:
ケース詳細ページで、「リンク・セッション」タブをクリックします。
「セッションのリンク」アイコンをクリックします。
追加するセッションを検索できる、「リンク・セッション」ダイアログが開きます。
セッションID、ユーザー名、IPアドレス、デバイスIDおよびロケーションでセッションをフィルタし、特定のログイン時間範囲を指定します。
結果から、このケースにリンクするセッションを選択し、「次」をクリックします。
1つ以上のリンクするセッションを一度に選択できます。これらは、調査が必要なケースの一部であると思われるセッションです。
ケースにリンクできるセッションを示すダイアログが表示されます。
「ノート」フィールドで、「ノート」リストからノートを選択するか、セッションがリンクされる理由を記述する1から4000文字のノートをテキスト・ボックスに入力します。
「終了」をクリックします。
ケースにセッションがリンクされ、「リンク・セッション」タブに表示されます。
調査担当者は、1つ以上のリンク・セッションを選択し、それらを詳細分析のためにMS-Excelドキュメント(XLS)としてエクスポートできます。MS-Excelドキュメントのエクスポートのみを行えます。
エクスポートできるリンク・セッションの最大数は1000に事前構成されています。制限を変更するには、次の構成可能なプロパティを編集する必要があります。
oaam.xls.case.linkedsession.export.row.upperbound=1000
詳しい調査および分析のためにリンク・セッションをエクスポートするには:
ケース詳細ページで、「リンク・セッション」タブをクリックします。
すべてのリンク・セッションがリストされた「リンク・セッション」ページが開きます。
必要なリンク・セッションを選択して、「エクスポート」をクリックします。
「エクスポート・ファイルの保存」を選択し、保存するファイルの場所を参照して、「エクスポート」をクリックします。
次の詳細とともにセッションがエクスポートされます。
行
セッションをリンクした日時
セッションID
ユーザー名
デバイスID
デバイス・スコア
ロケーション
アラート
セッション日
ノート
調査担当者が、リンク・セッションがケースとは無関係であると判断した場合、それらをそのケースからリンク解除できます。
リンク・セッションをリンク解除するには:
ケース詳細ページで、「リンク・セッション」タブをクリックします。
「セッションのリンク解除」アイコンをクリックします。
リンク解除することを選択したすべてのセッションがリストされた「セッションのリンク解除」ダイアログが開きます。
リンク解除するリンク・セッションを検索して選択し、「次」を押します。
セッションがケースからリンク解除されたことを示すダイアログが表示されます。
セッションをリンク解除する理由に関するノートを入力します。
「終了」をクリックします。
セッションがケースからリンク解除されます。
エージェント・ケースでは、クローズ済の調査結果をリスク・エンジンにフィードバックして、将来の評価の正確性を自動的に向上します。
たとえば、調査担当者がエージェント・ケースを作成し、複数の不正なセッションをそのケースにリンクします。その後、調査担当者は確認済の不正の処置とともにケースを閉じます。予測モデルは、確認済の不正の処置を持つケースにリンクされているセッションのデータを反映するために、n時間ごとに再作成されます。調査担当者は、モデルの再作成頻度を決定できます。システム内の各セッションは、不正なセッションとの類似度を確認するために比較されます。類似度が高いほど、リスクが高くなります。評価の例は、確認済の不正ケースにリンクされているすべてのセッションに基づいて、確率が50%より高いログイン・セッションが不正であるかどうかがあります。
デフォルトでは、調査担当者および調査マネージャのみがエージェント・ケースを作成するためのアクセス権を持っています。調査担当者のアクセス権のプロパティはoaam.permission.creatagentcase=oaam.perm.create.case.type.agentです。
CSRにエージェント・ケースへのアクセス権を付与するには、oaam.permission.creatagentcase=oaam.perm.create.case.type.csrのとおりにプロパティを構成します。
プロパティの設定後、CSRにはエージェント・ケースを作成するための完全なアクセス権が必要です。
有効期限/期限超過の動作は、プロパティ・エディタを使用して構成できます。
エージェント・ケースのデフォルトの有効期限日は、作成日から24時間です。
デフォルト動作を変更するための情報を次に示します。
エージェント・ケースの有効期限/期限超過動作を設定するには、次に示すとおりに次のプロパティを変更します。
customercare.case.expirybehavior.enum.agentcase.behavior = overdue customercare.case.expirybehavior.enum.agentcase.label = Overdue customercare.case.expirybehavior.enum.agentcase.durationInHrs = 24 customercare.case.expirybehavior.enum.agentcase.resetonaccess = true
エージェント・ケースの期限超過/有効期限動作を無効にするには、次に示すとおりに次のプロパティを変更します。
customercare.case.expirybehavior.enum.agentcase.behavior = none
|
注意: 他のパラメータを変更する必要はありません。 |
エージェント・ケースの有効期限動作を設定するには、次に示すとおりに次のプロパティを変更します。
customercare.case.expirybehavior.enum.agentcase.behavior = expiry customercare.case.expirybehavior.enum.agentcase.label = Expired customercare.case.expirybehavior.enum.agentcase.durationInHrs = 24 customercare.case.expirybehavior.enum.agentcase.resetonaccess = false
エージェントの一般的なユース・ケースを次に示します。
エージェントのユース・ケースを次に示します。次の表に、例のグループを示します。
表5-7 CSRアクセス
| 組織 | アプリケーション・ユーザー | 管理ユーザー |
|---|---|---|
|
デフォルト |
|
|
|
Org2 |
|
|
|
両方の組織 |
|
|
|
組織なし |
democsrm1 |
現在ケースを使用中のエージェントが現在の所有者
現在ケースを使用中のエージェントが現在の所有者です。
democsrm1という名前のマネージャがログインします。
ノート別にケースを検索します。
ケースを開きます。
ケースを開くとすぐに
現在の所有者がdemocsr1からdemocsrm1に変わります。
「作成者」フィールドには引き続きdemocsr1が表示されます。
ケースのステータスは「保留中」です。
次に、CSRマネージャは、一時許可の付与、チャレンジ質問のリセットの実行、その他のアクションなど、必要なアクションを実行できます。
CSRによるエージェント・ケースへのケースのエスカレーション
CSRは、エージェント・ケースにケースをエスカレーションします。
democsr1という名前のCSRが、デフォルト・グループに対する権限を持っています。
システムにログインします。
新しいケースを作成します。
組織IDにデフォルトを選択します。
demouser2のケースを作成します。
重大度を選択して、説明「不正アクティビティ」を加えます。
ケースをエージェント・ケースにエスカレーションし、ノートを追加します。
ここで、CSR「democsr1」はそのケースの詳細を表示する権限を失います。
CSRケースからエスカレーションされたエージェント・ケースに表示されるユーザー詳細
エスカレーション済のエージェント・ケースにはユーザー詳細が表示されます。
調査担当者demoinvest1がシステムにログインします。
「エスカレーション済」でフィルタ処理して、エスカレーション済ケースを検索します。
ケースを開きます。
ケース・ステータスは、「エスカレーション済」から「保留中」に変わります。
「作成者」フィールドには引き続きdemocsr1が表示されます。
「現在の所有者」にdemoinvest1が表示されます。
これはユーザーなしのケースではなく、エージェント・ケースにエスカレーションされたCSRケースであるため、ユーザー詳細も表示されます
ログには、ケースが作成され、エスカレーションされ、アクセスされてから、ステータスが変更されたことが示されています。
調査担当者によるエージェント・ケースの作成が可能
調査担当者によるケースの作成が可能です。
調査担当者demoinvest1がシステムにログインします。
ケースを作成します
組織IDを選択します。
これはユーザーなしのケースであるため、ユーザーを選択する必要はありません。
重大度を選択します。
説明を加えます。
「ケース詳細」ページが表示されます。
ケース・ステータスは「保留中」です。
「作成者」フィールドにdemoinvest1が表示されます。
「現在の所有者」フィールドにdemoinvest1が表示されます。
これはユーザーなしのケースであるため、ユーザー詳細は表示されません。
調査担当者による異なる組織IDのエージェント・ケースの作成が可能
調査担当者は、複数の組織にアクセスする権利がある場合、異なる組織IDのエージェント・ケースを作成できます。ほとんどのシナリオでは、複数の組織にアクセスできるのは調査マネージャのみです。
調査担当者demoinvest1がシステムにログインします。
ケースを作成します
別の組織IDを選択します。
重大度を選択します。
説明を加えます。
ケースが作成されたことを示すログを表示します。
ケースの同時アクセス
2人のエージェントがケースを開こうとする場合の例を次に示します。
demoinvest1がログインし、ステータスが「新規」であるケースを検索します。
ケースIDが132であるケースが結果に表示されます。
別のユーザーdemoinvest2がログインし、ステータスが「新規」であるケースを検索します。
この場合も、ケースIDが132であるケースが結果に表示されます。
demoinvest2がケースを開くと、ステータスが「保留中」に変わります。
demoinvest2がこのケースの現在の所有者です。
demoinvet1には、このケースは引き続き「新規」として結果に表示されます。
彼はこの新しいケースを開こうとしますが、demoinvest2がこのケースの現在の所有者であるというメッセージが表示され、続行するかキャンセルするかを選択できます。
キャンセルを選択した場合は何も起こらず、demoinvet2が現在の所有者のまま変わりません。
続行することを選択すると、彼が現在の所有者となり、ケースのステータスが「保留中」になります。
期限超過ケースの表示
調査担当者は、「期限切れ」フィルタが「有効期限切れのみ表示」のエージェント・ケースを検索します。有効期限列に日時が赤で表示されるケースが期限超過ケースです。
アクションによるケースの検索
ユーザーは、CSRケースおよびエージェント・ケースの両方を、それらで実行されたアクションに基づいて検索できます。次に例を示します。
昨日、jsmithはカスタマ・サービスに電話をかけ、自分のアカウントからお金が失われていることを伝えました。CSRはケースをエスカレーションし、jsmithに24時間以内に連絡することを伝えました。36時間後、jsmithは再度電話をかけて、連絡がない理由を尋ねます。CSRは、jsmithに対して昨日エスカレーションされたケースを表示する必要があります。彼は、「エスカレーション」アクションを含むjsmithのケースおよび過去48時間以内に期限超過していないケースを検索します。
エージェント・タイプのケースは、不正調査担当者が次の操作を行う場合に使用します。
どの調査担当者がケースに対して作業を行うかを含む監査の調査結果の収集
重大度、ステータス、所有者の変更、解決までの時間、削除されたケースおよび失われたケース、解決を含む調査のライフサイクルの管理
クローズ済の調査結果をリスク・エンジンにフィードバックして、将来の評価の正確性を自動的に向上
外部レコードまたはプロセスに関する調査結果のExcelへのエクスポート
不正調査担当者は、OAAMにより取得された複雑なデータ関係を簡単に利用して、インシデントに関連するデータをすばやく表示したり、関連する状況をすぐに見つけることができます。検索および詳細ページで、不正調査担当者は次の操作を実行できます。
個別のセッションを詳細に調べて、アラートが出される原因となった一連のイベントを特定します。
異なるデータ型間の複雑な関係を表示および検索します。
調査フローから外れずに、エンティティをホワイト・リストやブラック・リストに記載します。
これは、リスク評価にフィードバックされます。たとえば、高リスク・デバイス・グループです。
調査をさらに絞り込むために、セッション・データをケースにリンクします。
セキュリティ管理者は、特定のルールがトリガーされた場合にエージェント・ケースを作成するアクションを構成します。これらの自動作成ケースでは、トランザクションの確認が必要です。詳細ページには、調査担当者がこのタスクを完了するために必要な情報が含まれています。自動生成されたケースのワークフローの例を次に示します。
自動作成された新規エージェント・ケースの検索
Johnは、銀行の不正調査担当者です。Johnは、ブロックされたアクセス・リクエストの結果として動的に作成された新規エージェント・ケースを検索します。
ベスト・プラクティス: タイムスタンプ列をフィルタして、最も古いケースが先頭にくるようにします。
生成されたアラートの確認
Johnは、リスト内で最も古いケース109を開き、その使用を開始します。ケースのステータスが自動的に「新規」から「保留中」に変わり、現在のケース所有者がJohnになります。他の調査担当者が、このケースが現在使用中であることを判別できるようになります(ケースの所有者がJohnになり、ステータスが「新規」ではなく「保留中」であるため)。ケース109が自動的に作成されたときに、ブロックされたセッションがそのケースにリンクされたため、すべてのセッション・データが取得され、確認できるようになっています。これには、そのセッションでトリガーされた一連のアラートがすべて含まれます。この例では、5つの異なるアラートがトリガーされたセッションを示しています。Johnは、アラート・メッセージを読んで、この状況で何が発生したのかを容易に理解できます。匿名プロキシであることがわかっているIPからアクセスが試みられたために、高アラートが生成されていました。匿名プロキシは本当の地理的位置を隠すために犯罪者によって使用されることが多いため、匿名プロキシが使用されている間、銀行のセキュリティ・ポリシーによってバンキングが制限されます。
高リスクIPアドレスから使用されるユーザー・アカウントの確認
JohnはこのIPアドレスをクリックして、さらに調査するためにロケーションの詳細を確認します。表5-6「ログ検索フィルタ」に、最も重大度の高いアラートがIPアドレス(匿名プロキシ)に関するものであることが示されています。注意してください。これによって、隣のユーザー・インタフェース・タブにIPアドレス詳細ページが開きます。Johnは、「ユーザー」タブを選択し、この高リスクIPアドレスから利用しているユーザー・アカウントを確認します。このロケーションから行われているアクティビティに関与している可能性のある銀行ユーザーが4人いることがわかります。
エージェント・ケースへのセッションのリンク
JohnはIP詳細ページの「セッション」タブをクリックし、このIPアドレスからのセッションをリストします。
すべてのセッションを選択して、使用中のケース109にリンクします。この方法により、見つかったデータを、この操作を行った理由についてのノートとともに収集します。このケースでは、すべてのセッションがブロックされていますが、ブロックされていないセッションがある場合には、さらに追跡調査できるようそれらのセッションをケースにリンクすることが非常に有用です(詳細画面のデータを相互参照できない場合、そのような状況を検出できない可能性があるため)。
エージェント・ケースでのリンク・セッションの確認
これで、これらのリンクされたセッションのすべてのデータがケース109に取得されました。Johnは、同じデバイス(#14)が、これらのブロックされたアクセス試行すべてで使用されていたことがわかります。
質問でのセッション・パラメータの詳細の確認
Johnはデバイス14をクリックし、デバイス詳細画面を開きます。「デバイス詳細」で調査担当者は、このデバイスのデータの関係およびセッションも表示できるほか、デバイス自体のフィンガープリント処理の詳細も表示できます。たとえば、使用されたブラウザのロケールです。
セッション・パラメータに関連するアクティビティからのアラートの確認
Johnは「アラート」タブを開き、アラートのタイプおよびこのデバイスに関連してアクティビティからそれぞれ生成されたアラートの頻度を表示します。たとえば、アノニマイザ・アラートの集計件数は4件であることを表示できます。
リンク・ケースのExcelへのエクスポート
Johnはさらに、関連する4つのカスタマ・アカウント所有者に電話をかけて、彼らがこれらのブロックされた試行を行っていないことを確認します。このインシデントについて十分な調査を行ったと考え、不正を確認したので、Johnはこのケースを閉じ、次のインシデントに進むことができます。ケースを閉じる前に、Johnはリンク・セッションをExcelにエクスポートします。
業界全体のプログラムの一環として、連邦法執行機関に証拠を提供できるようにセッションをエクスポートします。
制限付きグループへのセッション・パラメータの追加
Johnは、このデバイスは不正なアクセス試行でのみ使用されていると確信したため、このデバイスをブラックリストに記載する必要があると判断します。Johnは、詳細画面から直接デバイスを「制限付きデバイス」グループに追加します。これによって、このデバイスは、他のセッション・データが有効であるように見え、他にトリガーされたルールがなくても、オンライン・バンキングへのアクセスに使用できなくなります。不正の実行者は、セキュリティの回避方法を調べるためにアプリケーションのセキュリティを複数回テストすることがよくあるため、これは非常に重要です。デバイスのフィンガープリントは、不正な試行間で変わらない1つのデータ・ポイントである場合があります。
ケースのクローズ
Johnは、調査結果を要約したノートとともに、確認済の不正としてケースを閉じます。彼のマネージャまたは監査者は、行われたアクション、ノートおよび関与したユーザーを含む、ケース・アクティビティのすべてのログを確認できます。
ケースは「確認済不正」としてマークされているため、不正なアクセス・リクエストで検出された特定のデータの組合せが、リスク評価エンジンに自動的に取り込まれ、不正がどのようなものであるかが学習されます。これによって、将来のリスク評価の正確性が高まります。同様に、確認したアラートが不正によるものではないとわかった場合、Johnはケースを「不正ではない」とマークして閉じます。この場合にも、偽陽性を減らすように将来のリスク評価が調整されます。
CSRマネージャはCSRケースをエスカレーションします。Mattは、カスタマ固有のセキュリティに関する問題を専門とする不正調査エージェントです。彼は、「エスカレーション済」ケース・ステータスを持つすべてのケースを検索します。調査担当者は、他の調査担当者が使用中のケースを開かないことがベスト・プラクティスです。調査担当者が初めてケースにアクセスすると、ステータスが自動的に「保留中」に変わります。これによって調査担当者は、他の調査担当者がすでにそのケースを使用しているかどうかを判断できます。Mattは、エスカレーション済ケースを開きます。ステータスが自動的に「エスカレーション済」から「保留中」に変わり、現在の所有者がMattになります。エスカレーション済ケースを開き、CSRおよびCSRマネージャが入力したノートをログで確認することがベスト・プラクティスです。彼らが不正アクティビティを疑ったために、CSRケースがエージェント・ケースにエスカレーションされたことがわかります。このケースはカスタマ・サービス・ケースに基づくため、特定のユーザーの情報が詳細に含まれます。Mattはケースの詳細およびjsmithがユーザーであるというノートを確認します。セッションの検索にユーザーIDが必要となるため、そのIDを書き留めます。Mattは「リンク・セッション」タブにナビゲートして、jsmithというユーザーIDでセッションを検索するために「リンク・セッション」を開きます。jsmithはセッションを持っているため、Mattは日付およびタイムスタンプでフィルタして、最新のセッションを探します。Mattは、エスカレーションの原因となった最新のセッションを見つけようとしています。アラート・メッセージを確認して、何が発生したのかを理解します。匿名プロキシであることがわかっているIPからアクセスが試みられたために、高アラートが生成されていました。MattはこのIPアドレスをクリックして、調査するためにロケーション・ログインの詳細を確認します。過去の他のロケーションを確認して、不正が行われた可能性があるかどうかを判別します。他にも質問があるため、彼は実際のユーザーjsmithに電話をかけて話をし、メモを取ります。納得のいく結論が出たら、Mattは処置とともにケースを閉じます。
Harryは、オンライン・セキュリティ・マガジンで新しいタイプの不正を読み取ります。彼は、Dollar Bankで攻撃が行われようとしたかどうかを確認するために、新しいレポートの構成と実行を決定します。疑わしいと思われる3つのセッションが判明します。エージェント・ケースを作成してこれらのセッションをそれにリンクするように、さらに調査を希望します。Harryは、3つのセッションからいくつかのデータ・ポイントを取得してさらに詳しく調査します。詳細画面では、リンク・セッションのいずれかのデバイスが、単一ユーザーIDに対して大量のセッションを返しています。彼のシフトはほぼ終了していますが、この調査は十分に緊急性があるものと判断し、次のシフトの別の調査担当者によるケースの継続調査を希望します。Harryは、他の担当者がこのケースを引き続き担当することと、彼が所有する見識をそのまま残すことを求めるノートをケースに追加します。Harryは、別の調査担当者がそのケースを取り上げるように、ステータスを「要注意」に変更します。
不正調査担当者がOAAM管理コンソールを開くと、彼のロールで許可されているユーザー・インタフェースの適切なビューとコントロールのみが表示されます。
不正調査担当者がケースを作成します。
不正調査担当者がセッションをリンクします。
不正調査担当者は、必要に応じて手順2と3を繰り返します
不正調査担当者は、ケース・ステータスを「要注意」に変更します。
不正調査担当者はノートを追加します。
Garyは、Dollar Bankの不正調査エージェントです。Garyは、処理する新規ケースを検索します。彼はステータスが「新規」であるすべてのケースを検索し、期限超過までの時間が最も短いケースが先頭にくるように表示をフィルタします。Garyは最初のケースを選択し、アラートおよびリンク・セッションに含まれるその他のデータを確認します。次に、北朝鮮からの他のセッションを見つけるために検索します。過去6か月間を検索すると、さらに1件のセッションが返されます。Garyはこの2番目のセッションをケースにリンクして、両方のセッションのデータに基づく関係を調査に使用できるようにします。Garyは、この2件のリンク・セッションが同じデバイスから行われていることに気付きます。Garyは、過去1年間にこのデバイスから行われたその他のセッションを調べて調査を続けます。このデバイスから行われた別のセッションがあり、中国から行われていると記されていることを見つけます。このセッションもリンクします。3件のセッションはそれぞれ異なるIPアドレスを使用していました。次にGaryは各IPからのセッションを個別に確認します。そのうち2つのIPは、これらのセッションでのみ使用されていました。中国からの3番目のIPでは、過去3か月間に178件のセッションがありました。この状況により影響を受けている可能性があるユーザーを確認するため、彼は「IP詳細」画面を開いて「ユーザー」タブを表示します。すべてのユーザーのリストがそれぞれの詳細とともに示されます。Garyはアイデンティティ管理製品を確認し、中国の連絡先情報を持つユーザーがいないかどうか、各ユーザーを調べます。誰もおらず、全員が米国本土に住むアメリカ人でした。GaryはユーザーのリストをXLSにエクスポートし、アカウントが使用されているカスタマに連絡を取っていくつか質問をします。誰も北朝鮮または中国にいたことはないことがわかったため、この会話をケース・ノートに入力します。彼らに、パスワードを変更し、チャレンジ質問をリセットするよう伝えます。また、彼らを被害者ウォッチ・リスト・グループに追加し、このデバイスを高リスクウォッチ・リストに追加します。Garyは、確認済の不正の処置とともにケースを閉じます。
不正調査担当者がOAAM管理コンソールを開くと、彼のロールで許可されているユーザー・インタフェースの適切なビューとコントロールのみが表示されます。
不正調査担当者は、ケースを検索します。
不正調査担当者はケースを開きます。
不正調査担当者はセッションをリンクします。
不正調査担当者は、必要に応じて手順3と4を繰り返します。
不正調査担当者は、影響を受けるユーザーのリスト・ビューを生成します。
不正調査担当者は、被害者リストにユーザーを追加します。
不正調査担当者は、ブラック・リストにデバイスを追加します。
不正調査担当者は、ケースをクローズします。
Oracle Adaptive Access Managerでは、エージェント・ケースを作成することにより、フォレンジック調査をより速く、より簡単に、より正しく実行できます。
エージェント・ケースは、疑いのあるアクティビティまたは不正なシナリオが検出され、調査が必要な場合に作成されます。
調査担当者がエージェント・ケースを使用する場合の例を次に示します。
調査担当者は、タイプが「不正」の自動化高アラートを受信します。
アラート・メッセージにより、ノース・カロライナ州に疑わしいセッションが存在する可能性があることが通知されます。
調査担当者はすぐにOAAMにログインして、各種フィルタ基準に基づき、ノース・カロライナ州のセッションなどのセッションを検索します。
彼は、調査が必要なセッションを判断します。
調査担当者は、エージェント・ケースを作成し、調査を開始します。
彼はこれらのセッションを選択して、ケースにリンクします。
調査担当者は、リンク処理の一環として、セッションをリンクした理由を説明するノートを入力します。ケース・ログには、リンク・アクションを実行したユーザーとともにノートが記録されます。調査担当者またはマネージャによってリンクが解除されないかぎり、これらのセッションはケースにリンクされたままになります。
調査担当者は、ロケーション詳細ページで市区町村と州を確認します。これは、疑わしいセッションの多くがノース・カロライナ州で発生しているためです。
調査担当者の納得のいく結論が出たら、処置を含めてケースをクローズします。
次のセクションでは、調査のために不正セッションをケースに関連付ける手順を概説します。
始める前に
エージェント・ケースを作成して操作するための適切な権限を持っていることを確認します。
調査のための不正セッションとケースの関連付け
タイプが「不正」の高アラートが自動的に表示され、アラート・メッセージにより、疑わしいセッションが存在することが通知されます。
OAAM管理コンソールにログインし、各種条件に基づいてセッションを検索します。
たとえば、過去12時間に「高」アラートによってブロックされたすべてのセッション(「時間」、「アラート・レベル」および「アクション」によってフィルタされたセッション)を検索する場合があります。
セッション詳細ページに移動し、関心のあるセッションに関する詳細情報を収集します。
次を確認できます:
チェックポイントの結果
トリガーされたポリシーとルール
調査担当者であれば、なぜ特定のルールがトリガーされたかに関心があります。たとえば、どのポリシーとルールによってアラートがトリガーされたのかを調査する場合があります。
これらの詳細を確認することにより情報を収集できます。たとえば、認証前と認証後のチェックポイントを正常に通過したユーザーであれば、パスワードと質問および回答を知っていたことになり、有効なユーザーである可能性が高いといえます。一方、質問に2度答えようとして3度目に正しい答えを出したユーザーは、疑わしいとみなされる場合があります。このユーザーは答えが即座に分からなかったため、新しい答えを試行する不正である可能性があります。
セッション詳細のポリシー・エクスプローラで、トリガーされたポリシーとルールそれぞれのランタイム値を表示します。
たとえば、あるルールがトリガーされ、ユーザーが通常ログインする国とは別の国からログインしたことが示された場合は、ランタイムの詳細を調査して、どの国からログインしたかを調査できます。
ポリシー・エクスプローラには、トリガーされたポリシー、条件パラメータおよび実際の値が表示されます。
調査が必要なセッションを決定します。
エージェント・ケースを作成し、調査を開始します。
これらのセッションを検索および選択し、ケースにリンクします。
リンク処理の一環として、セッションをリンクした理由を説明するノートを入力します。ケース・ログには、リンク・アクションを実行したユーザーとともにノートが記録されます。調査担当者またはマネージャによってリンクが解除されないかぎり、これらのセッションはケースにリンクされたままになります。
セッション間の関係を識別し、適切な詳細ページを表示します。
たとえば、疑わしいセッションで同じデバイスが使用されている場合は、デバイス詳細ページを表示します。疑わしいセッションが同じロケーションからのセッションである場合は、ロケーション詳細ページを表示します。疑わしいセッションが同じユーザーのものである場合は、ユーザー詳細ページを表示します。疑わしいセッションすべてでスペイン語のブラウザが使用されている場合は、フィンガープリント詳細ページを表示します。
ロケーション詳細ページを表示します。
デバイス詳細ページを表示します。
フィンガープリント詳細ページを表示します。
アラート詳細ページを表示します。
ユーザー詳細ページを表示します。
セッションを分析し、結論に達したら、処置でケースをクローズします。
CSRとエージェントのどちらのタイプのケースでも、現在の所有者に基づいて検索できます。この検索フィルタでは、検索対象のユーザーによって最後のアクションが実行されたケースが返されます。
始める前に
ケースを操作するための適切な権限を持っていることを確認します。
現在使用中のケースのリスト
OAAM管理コンソールにログインします。
CSRまたはCSRマネージャの場合は、ケース検索ページで検索フィルタに次の条件を指定することにより、現在使用中のケースを検索します。
調査担当者の場合は、ケース検索ページで検索フィルタに次の条件を指定することにより、現在使用中のケースを検索します。
次に、1つ以上のセッションを確認済不正としてマークする手順を概説します。具体的な情報がある他のセクションへの参照が含まれています。
始める前に
エージェント・ケースを作成して操作するための適切な権限を持っていることを確認します。
1つ以上のセッションを確認済不正としてマークする
セッションを「不正」/「不正ではない」としてマークするには、セッションをリンクするエージェント・ケースを作成し、「確認済不正」または「不正ではない」の処置とともにエージェント・ケースをクローズします。
OAAM管理コンソールに調査担当者としてログインします。
エージェント・ケースを作成します。第5.5.5項「手動によるエージェント・ケースの作成」を参照してください。
セッションをケースにリンクします。詳細は、第5.7.1項「セッションのリンク」を参照してください。
ケースの重大度を「高」に変更します。第5.6.2項「ケースの重大度レベルの変更」を参照してください。
「確認済不正」の処置とともにケースをクローズします。第5.6.3項「ケースのステータスの変更」を参照してください。
次の項では、重大度高をクローズする手順を概説します。
始める前に
ケースを操作するための適切な権限を持っていることを確認します。
ケースのクローズ
ケースをクローズするには:
OAAM管理コンソールにログインします。
ケース検索ページにナビゲートします。第5.3項「ケースの検索ページを開く」を参照してください。
「ケース詳細」ページを開きます。第5.5.3項「エージェント・ケースの詳細の表示」を参照してください。
ケースの重大度を「高」に変更します。第5.6.2項「ケースの重大度レベルの変更」を参照してください。
ケースのステータスを変更します。第5.6.3項「ケースのステータスの変更」を参照してください。
処置とともにケースをクローズします。第5.6.4.1項「ケースの手動によるクローズ」を参照してください。
次のセクションでは、複数のケースをクローズする手順を概説します。
始める前に
ケースを操作するための適切な権限を持っていることを確認します。
ケースのクローズ
複数のケースをクローズするには:
OAAM管理コンソールにログインします。
ケース検索ページにナビゲートします。第5.3項「ケースの検索ページを開く」を参照してください。
複数のケースをクローズします。第5.6.5項「エージェント・ケースのバルク編集」を参照してください。
アクター: セキュリティ調査担当者/セキュリティ調査マネージャ
CSRケースは、2つの可能なフロー(自動/手動)のいずれかによって作成されます。
CSRは、ケースのエスカレーション・アクションを実行します。ケースは、ステータスが「エスカレーション済」のエージェント・タイプ・ケースになります。
調査担当者は、「エスカレーション済」ステータスのすべてのケースを検索します。彼は、「重大度」列の結果をフィルタして、最も重大度の高いケースが先頭に表示されるようにします。
リストにある重大度高のいずれかのケースIDをクリックします。検証によって、ケース画面を開く前にケースのステータスが引き続き「エスカレーション済」であるかどうかが確認され、ステータスは自動的に「保留中」に変わります。
ケース・ログには、ユーザーによる作成、エスカレーション・アクションおよびアクセスが表示され、ステータスは「保留中」に変わります。
ベスト・プラクティスと推奨事項を次に示します。
不正調査担当者は、カスタマ・サービスからエスカレーションされたか、アラートから直接示された疑わしい状況を調査します。
不正調査マネージャは、自分のチームがどのケースに注目する必要があるかを確認します。
不正調査マネージャは、定期的に期限超過ケースを検索して、それらのケースがいずれも保留中になっていないことを確認する必要があります。
カスタマが不正を疑っている場合、割り当てられる重大度レベルは「高」になります。たとえば、カスタマが異なるイメージを必要としている場合、割り当てられる重大度レベルは「低」になります。ケースの重大度レベルは、必要に応じてエスカレーションまたはエスカレーション解除できます。誰でもケースの重大度を変更できます。
