5 Investigation Using Agent Cases
Oracle Adaptive Access Manager allows the creation of Agent cases to make forensic investigations quicker, easier and more successful. Investigators can link relevant sessions that may be connected to fraud cases to locate relationships between data that is linked, sessions in which suspicious activity occurred, or sessions in which alerts were generated. Investigators can link suspicious sessions. They can also unlink sessions that they think are no longer suspicious.
This chapter provides information to Investigators for using the new Agent cases. It contains the following sections:
5.1 Introduction and Concepts
This section provides an introduction to Investigators and a high-level view of how they might use the Oracle Adaptive Access Manager Agent cases to investigate fraudulent activity.
5.1.1 Agent Cases
An Agent case is a tool used for investigation. It can be created manually or automatically.
-
A CSR creates an Agent case when he escalates a case because further investigation from an Investigator is needed. Refer to Section 5.1.2.3, "Escalated Cases."
-
A fraud investigator creates an Agent case when a suspicious activity or fraud scenario is detected and needs investigation.
-
A configurable action creates an Agent case automatically as a supplementary action that is triggered based on a result action and/or risk score after a checkpoint execution.
Agent cases are not created for specific users. They are created for specific scenarios. Events can be configured to create a case automatically. Agent type cases are used by fraud investigators to do the following:
-
Collect investigation findings for audit including which investigators have worked on a case
-
Manage the lifecycle of an investigation including severity, status, ownership changes, time to resolution, dropped/lost cases and resolution
-
When closed findings are fed back into the risk engine to improve accuracy of future evaluations automatically
-
Export findings to Excel for external records or processes
A fraud investigator can quickly view the data involved in an incident and quickly locate related situations by easily harnessing the complex data relationships captured by OAAM. Search and detail pages provide fraud investigators the ability to:
-
Drill into individual sessions to see the exact chain of events that led to an alert
-
View and search for complex relationships between different data types
-
White/black list entities "on the fly" without leaving the investigation flow
-
Link session data to a case to further narrow the investigation
5.1.2 Case Status
Case Status is the current state of a case. Status values used for the case are New, Pending, Escalated, or Closed.
| Status | Definition |
|---|---|
|
The status of a case when it is created. |
|
|
The status of a case that is not yet resolved. |
|
|
The status of a case when the issue is resolved. |
|
|
Escalated |
The status of a case when a CSR escalates a case. |
5.1.2.1 New and Pending Cases
Cases are "New" when they are created regardless of the method (manual/configurable action). When a new case is accessed for the first time, the status automatically changes to "Pending." For example, if an Agent case is created by a configurable action, it contains the session data for which it was created and it has a "New" status. If an investigator searches for all Agent type cases with a "New" status, and he opens the case details page for one of the new cases, the case status automatically changes to "Pending". This allows Investigators to know if someone is already working on a case.
5.1.2.3 Escalated Cases
If a CSR case is escalated to an Agent case, the status changes to "Escalated" in the process. The first time an investigator accesses the case, the status changes to "Pending" automatically. The CSR escalates a case when he cannot resolve a case and needs further investigation by an investigator or when he determines there is suspicious activity associated with the specific user and he wants further investigation by an investigator. Once escalated the case is treated as an Agent case, which is no longer visible to the CSR. However, any agent can work on the escalated case.
5.2 Fraud Investigation Role Permission
Fraud Investigator and Fraud Investigation Manager are out-of-the-box roles provided by Oracle Adaptive Access Manager. A Fraud Investigator investigates a specific fraud scenario or suspicious pattern. In order to work on the scenario or pattern, he creates an Agent case. A Fraud Investigation Manager has access to actions that the Fraud Investigator does not have. They can reopen closed cases and bulk edit cases. To act upon the fraudulent sessions, they create Agent cases, and then link the fraudulent sessions to the case. Based on the type of fraud, they perform further case actions.
The out-of-the-box permissions associated with fraud investigation are summarized in Table 5-2. Additional actions are listed in Appendix A, "Access Roles."
Table 5-2 Fraud Investigation Role Permissions
| Action | Investigator Permissions | Investigation Manager Permissions |
|---|---|---|
|
Actions |
All functions of Investigator role |
All functions of Investigator role and some special privileges |
|
Search Cases |
|
|
|
New Case |
Only Agent cases |
Only Agent cases |
|
View Case Details |
|
|
|
Edit Case |
|
|
|
Search session |
Search sessions |
Search sessions |
|
Link sessions |
Link sessions |
Link sessions |
|
Unlink sessions |
Unlink sessions |
Unlink sessions |
|
View linked sessions |
View linked sessions |
View linked sessions |
5.3 Opening the Case Search Page
To perform the operations listed earlier, log in as an Investigator. Open to the Cases Search page by double-clicking Cases in the Navigation tree.
Alternatively, you can open the Cases Search page by:
-
Right-clicking Cases in the Navigation tree and selecting List Cases from the context menu.
-
Selecting Cases in the Navigation tree and then choosing List Cases from the Actions menu.
-
Clicking the List Cases button in the Navigation tree toolbar.
The Cases Search page contains the search tools to help you find cases that you are interested in. The Search Results table displays a list of cases that meet the criteria you specified. If you upgraded your environment, agent cases from previous releases are also visible. There is a link on the case number. To view the case details, click the link. All search tables and dialog boxes should have asterisks for the required fields.
5.4 Searching for Cases
The Cases Search page contains the search tools to help you find cases that you are interested in.
-
From the Cases Search page, specify criteria in the Search Filter.
Filter Description Organization ID
To locate cases for an organization, select the Organization ID. CSRs can choose one from a list of Organization IDs of organizations which they have access to.
User Name
The User Name field is blank for Agent cases.
User ID
The UserID field is blank for Agent cases.
Case ID
To locate a specific case, enter the Case ID.
Description
To locate a case by a keyword that is in the description, enter the word you want. Search by description displays all cases with any matching words in the description field.
Case Type
To filter cases by case type, select Agent.
Severity Level
To filter cases by severity level, select Low, High, or Medium.
Case Status
To filter cases by case status, select New, Pending, Closed, Escalated.
Expired
To filer the list by expired, select the option you want.
The options available are:
-
Hide Expired
-
Show Only Expired
Created Date
To locates cases created within a given create date range, enter the start and end dates you want for the range.
Disposition
To filter cases by dispositions, you can select:
-
Confirmed Fraud
-
Duplicate
-
False Negative
-
False Positive
-
Issue Pending
-
Issue Resolved
-
Not Fraud
The disposition describes the way in which the issue was resolved in a case. Cases only have dispositions when they are closed. If a case has any status besides closed, the disposition is left blank.
Last Action
Search based on the last action that was taken in case.
Notes
Search for cases that contain specific keywords in their log. For example, if you search for all Agent type cases that contain the word "chargeback," a case with a note that contains "The device used seems to be related to a number of chargebacks" would return in the list of cases.
Created by
Search by user name of the agent who created the case.
Current Owner
Search by user name of the agent who is working on this case currently (who performed the last action)
-
-
Click Search.
If multitenancy is enabled, search results display all the cases whose users belong to the organizations that the CSR has access to if they match the search criteria. User less cases are part of the result set if the case owner's Organization ID is on the agent's access permission list and the case matches the search criteria.
By default Escalated and Agent cases expire after 24 hours and become overdue. The overdue flag is then set. When Investigators access the case, the expiration date is reset. To search for overdue Agent cases, select Shown Only Expired as the Expired filter. The cases with dates and time in red in the Expiration Column are overdue cases.
5.5 Viewing, Editing, and Creating Cases
Procedures to view, edit, and create are listed below.
5.5.1 Viewing a List of Cases
From the Cases Search page, enter filter criteria and click Search. The Search Results table displays the list of cases you filtered for.
5.5.2 Viewing a List Cases You are Currently Working On
From the Cases Search page, enter your user name in the Current Owner field to locate cases that you are currently working on and click Search. The Search Results table displays the list of cases you are currently working on.
5.5.3 Viewing Agent Case Details
The Agent Case Details page is opened when you create a case successfully. You can also open the Agent Case Details from the Search results for cases that belong to any user belonging to a group you have access to or cases that are associated with your Organization ID.
Note:
You can only open one case at a time. An error occurs if you try to open more than one case.
Agent and Escalated cases contain the following tabs:
-
Summary - Lists the details about the case
-
Linked Sessions - Lists the sessions linked to the case
-
Logs - Lists the case action logs
The Summary tab shows the case detail and if the case is an Escalated case then it shows the details of the user associated with the case. Agent cases that are user less show a User Details section.
5.5.3.1 Summary Tab
The Summary tab shows the case details for Agent cases. If the Agent case is an Escalated case, it also shows the detail of the user associated with the case.
5.5.3.1.1 Case Details
The following information is displayed in Case Details.
| Details | Description |
|---|---|
|
Organization ID |
The Organization ID of the case. |
|
Case Created |
The date when the Agent Case was created |
|
Case Status |
The case status is "Pending" when the Agent Case is created manually and "New" when an Agent Cases is created automatically (with Configurable Action) and changes to "Pending" once the case is accessed. The case status is "Escalated" for Escalated cases and changes to "Pending" when the agent accesses this case. Case status is changed when accessed by various administrators. |
|
Severity Level |
The severity level is set by the user who creates the case and used as a marker to communicate to users how severe the case is. Anyone can change the severity of cases |
|
Case Type |
Agent, CSR or Escalated (Escalated cases cannot be created) |
|
Case Number |
Unique Case ID |
|
Disposition |
When a case is closed the disposition describes the way in which the issue was resolved. Cases only have dispositions when they are closed. If a case has any status besides closed, the disposition is blank. |
|
Expiration Date |
Agent cases and Escalated cases have a default expiration date of 24 hours from the date of creation. If the case has not been accessed before the expiration date, it has the status of Overdue. Each time you access the case, the expiration date of the Agent case or Escalated Case is reset to a new value; by default the date is reset to 24 hours from the date of accessing the case. The length of time before a case expires is configurable. Refer to Section 5.10, "Configuring Expiry/Overdue Behavior for Agent Cases" for details for configuring the expiry behavior. |
|
Overdue |
If the case has not been accessed before the expiration date, the overdue flag is set to allow managers to see that the cases require attention. For example, if Agent cases are set to expire in 24 hours, then the flag is set to "overdue" if a case has not been accessed in more than 24 hours. When Investigators access the case, the overdue date is not affected. When they perform actions, the overdue is reset. The overdue behavior is configurable. Refer to Section 5.10, "Configuring Expiry/Overdue Behavior for Agent Cases" for details |
|
Description |
The details for the case. A description is required. |
|
Last Case Action |
The last action performed in the Escalated or Agent case. There are no user details in Agent cases. |
|
Date of Last Case Action |
The date when last action occurred. |
|
Last Global Case Action |
For an Agent case that is not created from an escalated CSR case, the last global case action field is always empty. For an Agent case associated to a user (escalated case), the last global case action is the last case action performed by the user associated with the Agent case. The case action could be performed on any case (CSR/Agent) |
|
Date of Last Global Case Action |
The last action performed against the user online. |
|
Current Owner |
Name of agent who is working on this case currently |
|
Created By |
This displays the name of the agent who created the case. If the case was created by a configurable action "Created by" displays "dynamic." |
5.5.3.1.2 User Data
The following information is displayed in User Data for Escalated cases.
| Data | Description |
|---|---|
|
User Name |
User for whom case is created |
|
User ID |
Auto generated? |
|
Organization ID |
The identifier of the application. (In a multitenant deployment, CSRs only have access to cases limited to their primary Application ID. CSR Managers and Investigators can access cases from multiple applications) |
|
Last Online Action |
The last action that user executed. For example, the Answered challenge question field show "Challenge Question" or if user is blocked, "Block." |
|
Date of Last Online Action |
Date when last online action was executed. |
|
Temporary Allow Expiration Date |
When a temporary allow is enabled. This field shows you when it expires. If temporary allow is 7 days, the expiry date is a week from today. |
|
Temporary Allow Active |
If temporary allow is active, this field shows "Yes," otherwise the field shows "No." |
|
OTP Bypass Active |
Similar to temporary allow but OTP challenges are ignored instead of blocks |
|
OTP Bypass Expiration Date |
Date and time OTP Bypass is no longer be active |
|
Completed Registration |
If a user completed registration, this field shows "Yes;" otherwise it shows "No." To be registered, a user may need to complete all of the following tasks: personalization (image and phrase), registering KBA questions/answers, and providing email/cell phone contact information. |
|
Questions Active |
If user completed registration, but questions were reset, and he did not go back to register new ones, this field displays "No." This field shows "Yes" if the user completed registration and questions exist that can be used to challenge him. |
|
OTP Delivery method active |
User has either email or cell phone registered for the OTP challenge |
|
Personalization Active |
When an image, a phrase and questions are active for the user, this field displays, "Yes." If anyone of these are reset, this field displays "No." |
5.5.3.2 Linked Sessions
The Linked Sessions tab displays all of the sessions that you linked for the case you are investigating. The tab also displays information such as the date at which it was linked and any notes provided at the time of linking. You can link any number of sessions as you think might be connected to an investigation by clicking the Link Sessions icon, which opens a Sessions search page. You can unlink one or more sessions already linked to this case.
5.5.3.3 Logs
The logs sections to show the logs of action performed on the case. The search filters are as follows:
| Filters | Description |
|---|---|
|
Notes Keyword |
Keyword from Canned Notes |
|
ARM ID |
CSR identifier |
|
Action |
Last action in the case. For example, yesterday jsmith called customer service claiming to have lost money out of his account. The CSR escalated the case and told jsmith he would be contacted within 24 hours. About 36 hours later, jsmith calls back to see why he has not been contacted. The CSR must view the case escalated yesterday for "jsmith". He searches cases for "jsmith" with an "Escalate" action and ones that are not overdue in the last 48 hours. |
|
Created Date |
Date case was created. |
5.5.4 Creating Agent Cases
Agent cases can be created in one of three ways:
-
Manually
-
Automatically
-
CSR Escalation
5.5.5 Creating an Agent Case Manually
A new Agent case is created when a suspicious activity or fraud scenario is detected and needs investigation. Only an Investigator can create an Agent type case directly. No user information is shown or required for the creation of an Agent type case. The only required inputs to create an Agent case are Organization ID, severity, and description.
To create a new user less Agent case:
-
In the Cases Search page, click New Case.
The Create Case dialog appears with Agent specified as the Case Type because the system already knows from the login that an Investigator is creating this case.
-
Enter the Organization ID you are creating the case for.
A list of Organization IDs for which you have access to is provided. From the list you can select one Organization ID. Later, you can create a case for a different Organization ID if you need to.
Note:
You do not have to enter a user name or User ID because the Agent case is a user less one.
-
Select a severity level from the Severity Level list
The available severity levels are High, Medium, and Low.
-
Enter a description of the case in the Description text box, or select descriptions from the Description list, or do both.
The default description type is Custom Description. The Description text box can contain alphanumeric and special characters, but it should not exceed 4000 characters. You can select a description from the Description list, one at a time for any number of times. Each description selected from the list is appended to the previous.
Description is a required field. The Create button is disabled until a description is entered.
-
Click Create.
The Create button is disabled until all the fields are entered. Required fields are marked with a "*" (asterisks). If invalid parameters were entered, an error message is displayed and the new case is not created.
Click Cancel to cancel changes and return to the Cases Search page. Click Create to create a new case.
The case is created and the Case Details page opens for the new case. For information, refer to Section 5.5.3.1.1, "Case Details." The Case Details page shows "Pending" as the status of the case. The agent is listed in the Created by and Current Owner fields. There are no user details shown in the Case Details because the case is a user less Agent case. The new Agent case does not contain any linked sessions. When you view the logs, Create Case is displayed as the Action.
Manual Agent Case Creation Example
An Agent creates an Agent type case for the 1st Bank Organization ID. He is not given the option to create cases of other types (CSR case). Organization ID is a required field. The new Agent case does not contain any linked sessions. He is not required to enter any user information to create the case since Agent cases are not linked to any single user.
5.5.6 Creating an Agent Case Automatically by a Configurable Action
To configure an action so that an Agent case is created automatically:
-
Create a custom rule action called create_agent_case.
-
Add a rule with the rule condition you want to a policy for the appropriate checkpoint. Configure it such a way that it triggers and returns the action create_agent_case whenever the specified conditions are met. For example, whenever a suspicious activity occurs the create Agent case action is triggered.
-
Create an action instance of the action template CaseCreationAction and associate it to the checkpoint.
-
Set the trigger criteria as the action by selecting create_agent_case action.
-
Set the parameters of CaseCreationAction as follows:
-
Enter "2" (for Agent type) as value of Case Type.
-
Enter "2" (for Medium) or "3" (for High) for the Severity.
-
Enter a case description. For example, "Failed login."
-
Enter the userId for "Case Creator UserId" parameter. Make sure that userId has a proper role and access permissions for creating the case. For our example, the Case Creator is Dynamic.
-
-
Save the action instance.
-
Log in to the application unsuccessfully.
On every unsuccessful log in, you should see an automatic creation of an Agent case by the configurable action. The status of the case is "New." The new Agent case has auto linked sessions based on the action instance parameters. It will contain the session data for which it was created.
There are two logs for the autocreated Agent case: one for creation and one for the link session.
If an Investigator opens the case, the Status of the case changes to "Pending." The Current Owner is the Investigator and the Created by displays the Case Creator UserId. User Details are also shown for this case.
-
Verify that the sessions that correspond to the action instance parameters like checkpoint, score range, execution type are autolinked to the Agent case that is created by the configurable action.
Agent Case Autocreation Example
-
A Security Administrator configures an action to create agent cases when specific rules trigger.
When this case creation action generates a case, the session data in which the rule triggered is added to the case in the form of a linked session.
-
Fraud Investigator opens the OAAM Admin Console and sees only the appropriate user interface views and controls afforded his role.
-
Fraud Investigator searches cases by new status
-
Fraud Investigator opens the case at which time he becomes the current owner and the status of the case changes to pending.
-
He can continue linking session to the case and/or drill in on the data in the linked session using the details screens.
-
When finished, the Investigator closes the case with a disposition and notes.
5.5.7 Creating an Agent Case from an Escalation
To escalate a case so that Investigators can review it:
Escalate CSR to Agent Case Example
-
CSR Manager escalates CSR case
-
A fraud investigator picks up the escalated type case and reads the notes entered by the CSR and CSR Manager. The status automatically changes from escalated to pending.
-
He searches for the session history of the user.
-
Investigator selects the session from the Ukraine and searches for related sessions and cases. He finds no sessions or cases that seem suspicious
-
He determines that he can safely add the user to the override group for this rule.
-
The investigator then closes the case with a resolved "customer override" disposition.
-
Every three months a security administrator removes all users from the override group.
5.5.8 Creating a Case Like Another Agent Case
To create a new case that is similar— or "like"—an existing Agent case:
-
From the Cases Search page, select an Agent case by clicking in the checkbox next to case in the Search Results table.
The Create Like button is disabled if you select multiple rows in the Search Results table.
-
The Create Case Like dialog appears with Organization ID, Severity level and description pre-populated from the original case.
-
Edit any of these fields if you want.
Do not leave any fields blank.
The Create button is disabled until the required fields are filled in.
-
Click Create.
Click Cancel to cancel changes and return to the Cases Search page.
Click Create to create a new case.
A new Agent case is created with data from the original case and your changes, and the Case Details page opens for the new case. A new Agent case created like an escalated Agent case does not contain any user data. The case status is "Pending."
5.6 Editing Agent Cases
You can take action in an Agent case to add notes, change the severity level of a case, or change the status of a case.
5.6.1 Adding Notes to Cases
Each time you take an action in a case you should enter a note describing why you are taking the action. The notes are saved to the case log.
To add notes to cases:
-
In the Case Details page, click Add Notes.
The Add Notes dialog appears.
-
Select a canned note or enter notes in the text box or both.
-
Click Submit.
The notes are saved to the case log.
-
Click OK to dismiss the confirmation dialog.
5.6.2 Changing Severity Level of a Case
When a case is created it is assigned a severity level to indicate its importance and allow administrators to filter cases. The severity level is shown on the Case Details page.
-
In the Case Details page, click More Actions and select Change Severity.
The Change Severity dialog appears.
-
In the Severity List, select the severity level you want.
The available severity levels are High, Medium, and Low. If a customer suspects fraud, then the severity level assigned would be High. If the customer wants a different image, then the severity level assigned would be Low. You can escalate or de-escalate the severity level of a case when necessary.
-
In the Notes list, select the type of note you want.
-
If necessary edit the note to add information about the action you are taking.
-
Click Submit.
The case severity is saved to the case log.
-
Click OK to dismiss the confirmation dialog.
5.6.3 Changing Status of a Case
The status of a case can be changed manually or automatically.
5.6.3.1 Changing the Status of a Case Manually
The scenarios show how to change the case status manually.
5.6.3.1.1 Changing the Status of the Case to New Manually
To change the status of a case to New manually:
-
In the Case Details page, click More Actions and select Change Status.
The Change Status dialog appears.
-
In the Status list, select New.
-
Enter a note describing the issue.
You can select from existing notes, or enter a new note, or both.
Existing notes to choose from are the following:
-
Manager Review
-
Other
-
-
Click Submit.
A confirmation dialog is displayed.
-
Click OK.
5.6.3.1.2 Changing the Status of the Case to Pending Manually
To change the status of a case to Pending manually:
-
In the Case Details page, click More Actions and select Change Status.
The Change Status dialog appears.
-
In the Status list, select Pending.
-
Enter a note describing the issue.
You can select from existing notes, or enter a new note, or both.
Existing notes to choose from are the following:
-
Manager Review
-
Issue in Progress
-
Other
-
-
Click Submit.
A confirmation dialog is displayed.
-
Click OK.
5.6.3.2 Configuring Auto Change for Case Status
To enable Auto Change of Case Status set the following parameter:
customercare.case.autostatuschange.enum.flowone.enabled=true
To disable Auto Change of Case Status set the following parameter:
customercare.case.autostatuschange.enum.flowone.enabled=false
Configurable actions create cases with a status of "New". When the case is opened, the status is changed to "Pending." For these cases to change from "New" to "Pending" automatically on access, configure the following properties:
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
Escalated cases have a Case Status of Escalated. When the case is opened, the status is changed to "Pending". For cases to change from Escalated to Pending automatically on access, configure the following properties:
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
The action log for the auto-change is created with the entry, "Status changed on access by the system."
5.6.4 Closing Cases
After an investigator finishes investigating a situation and comes up with a conclusion, he can change the status to close the case and give a disposition.
5.6.4.1 Closing a Case Manually
-
In the Case Details page, click More Actions and select Change Status.
The Change Status dialog appears.
-
In the Status list, select Closed.
-
Select a disposition.
Choices for the disposition are the following:
-
Confirmed Fraud
-
Duplicate
-
False Negative
-
False Positive
-
Issue Pending
-
Issue Resolved
-
Not Fraud
-
-
Enter a note describing the issue.
You can select from existing notes, or enter a new note, or both.
Existing notes to choose from are the following:
-
Issue Resolved
-
Issue Not Resolved
-
Old Case Cleanup
-
Duplicate Case
-
Other
-
-
Click Submit.
A confirmation dialog is displayed.
-
Click OK to dismiss the confirmation dialog.
An investigator finishes investigating a situation and determines that the customer was mistaken, there was no fraud. He uses the change status action to close the case and give a disposition of "not fraud".
5.6.4.2 Closing Multiple Cases
To close multiple cases:
-
In the Navigation tree, double-click Cases. The Cases Search page is displayed.
-
In the Search Results table, select the cases you want to close.
-
Click the Bulk Edit button.
-
Select Closed as the status.
-
Select the disposition and enter notes.
-
Click Save.
-
Click OK to dismiss the Confirmation dialog.
5.6.5 Bulk-Editing Agent Cases
To change the case settings for multiple cases at once:
-
In the Navigation tree, double-click Cases. The Cases Search page is displayed.
-
Select the cases you want.
-
Click Bulk Edit.
Note:
For out-of-the-box OAAM roles, the Bulk Edit button is disabled for the Investigator role and enabled for the Investigation Manager role.
-
Change the case settings you want and add notes.
The Close action is allowed regardless of severity.
Severity is editable regardless of status. You can also change the severity of cases irrespective of their Closed status.
-
Click OK to perform the bulk edit.
A confirmation dialog appears with a message that the bulk editing operation was performed successfully. If you are closing a case and there are Agent cases that were already in the Closed status at the time of the bulk edit operation, a message appears, saying that the Agent cases have to be in the New or Pending status for a bulk close action to be executed.
-
Click OK to dismiss the dialog.
When you refresh the search, the status is shown for those cases in the results.
"Last Case Action" on the Search page is not updated immediately after a bulk edit. It is updated when you launch the Search page again.
5.7 Linking and Unlinking Suspected Sessions to a Case
You can link sessions to the cases belonging to the users that belong to the organizations that you have access to.
5.7.1 Linking Sessions
If the Investigator feels that sessions are involved in the product security, he can search for those sessions, select them (you can see the sessions of only those groups to which you have access) and link them to the case with linking notes and descriptions.
To link sessions:
-
On the Case Details page, click the Linked Sessions tab.
-
Click the Link Sessions icon.
A Linked Session dialog opens where you can find the sessions to add.
-
Filter sessions on Session ID, User Name, IP Address, Device ID, and Location and specifying a specific login time range.
-
From the results, select the sessions to link to this case and click Next.
You can select one or more sessions to link at a time. These are the sessions that you think are part of the case that needs investigation.
A dialog appears showing that the sessions that can be linked to the case.
-
In the Notes field, select a note from the Note list or enter a note between 1 and 4000 characters into the text box to describe why you are linking the sessions.
-
Click Finish.
The sessions are linked to the case and appear in the Linked Sessions tab.
5.7.2 Export Linked Session for Further Analysis
The Investigator can select one or more linked sessions and export them as MS-Excel document (XLS) for further analysis. Only MS-Excel document export is available.
The maximum number of linked session you are allowed to export is pre-configured for 1000. If you want to change the limit, you must edit the following configurable property:
oaam.xls.case.linkedsession.export.row.upperbound=1000
To export linked sessions for further investigation and analysis:
-
In the Case Details page, click the Linked Sessions tab.
The Linked Sessions page opens, listing all the linked sessions.
-
Select the linked sessions you want and click Export.
-
Select Save Export File, browse for the location for file to be saved and click Export.
The sessions are exported with the following details:
-
Row
-
Date and time the session was linked
-
Session ID
-
User Name
-
Device ID
-
Device score
-
Location
-
Alerts
-
Session date
-
Notes
-
5.7.3 Unlinking Linked Sessions
If they feel that the linked sessions are not relevant to the case, an Investigator can unlink them from the case.
To unlink linked sessions:
-
On the Case Details page, click the Linked Sessions tab.
-
Click the Unlink Sessions icon.
The Unlink Sessions dialog opens, listing all the selected sessions to be unlinked.
-
Search for and select the linked sessions to unlink and press Next.
A dialog appears showing that the sessions have been unlinked from the case.
-
Enter notes about why you are unlinking the session.
-
Click Finish.
The sessions are unlinked from the case.
5.8 Agent Case Feedback
Agent case feed back closed findings into the risk engine to improve accuracy of future evaluations automatically.
For example, an investigator creates an Agent case and links several fraudulent sessions to it. Later, the investigator closes the case with a disposition of confirmed fraud. A predictive model is rebuilt every "n" hours to take into account data from sessions linked to cases with a confirmed fraud disposition. Investigators can determine the frequency of rebuilding the models. Each session in the system is compared to see how close it is to the fraudulent ones. The closer the match the higher the risk. An example evaluation would be, was the probability more than 50% that this login session is fraudulent based on all sessions linked to confirmed fraud cases?
5.9 Configuring Agent Case Access
By default only Investigators and Investigation Managers have access to create Agent cases. The property for investigator access is oaam.permission.creatagentcase=oaam.perm.create.case.type.agent
To give a CSR access to Agent cases, configure the property as follows: oaam.permission.creatagentcase=oaam.perm.create.case.type.csr
After setting the property, the CSR should have full access to create agent cases.
5.10 Configuring Expiry/Overdue Behavior for Agent Cases
The expiry/overdue behavior can be configured using the Properties Editor.
Agent Cases have a default expiration date of 24 hours from the date of creation.
Information to change the default behavior is provided below.
5.10.1 Set "Overdue" Behavior for Agent Cases (Default Setting)
To set "expiry/overdue" behavior for Agent cases, modify the following properties as shown below.
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
5.10.2 Disable "Overdue/Expiry" Behavior for Agent Cases
To disable the "overdue/expiry" behavior for Agent cases, modify the following property as shown below.
customercare.case.expirybehavior.enum.agentcase.behavior = none
Note:
You do not need to change the other parameters.
5.10.3 Set "Expiry" Behavior for Agent Cases
To set "expiry" behavior for Agent cases, modify the following properties as shown below.
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.11 Agent Use Cases
Common agent use cases are listed below.
5.11.1 Agent Creation
Agent use cases are provided below. Groups for the examples are presented in the following chart.
| Organization | Application Users | Admin Users |
|---|---|---|
|
Default |
|
|
|
Org2 |
|
|
|
Both organizations |
|
|
|
No organization |
democsrm1 |
Current Owner is the Agent who is Working on the Case Currently
The Current Owner is the agent who is working on the case currently.
-
A manager named "democsrm1" logs in.
-
He searches for the case by Notes.
-
He opens the case.
-
As soon as he opens the case
-
The Current Owner changes from "democsr1" to "democsrm1."
-
The Created By field still shows "democsr1."
-
The status of the case is "Pending."
-
-
Next, the CSR Manager can perform the necessary actions such as granting a temporary allow, performing challenge question resets, and other actions.
CSR Escalates a Case to an Agent Case
CSR escalates a case to an Agent Case.
CSR named "democsr1" has permission for group "Default."
-
He logs in to the system.
-
He creates a new case
-
He selects the Organization ID, "Default."
-
He creates the case for "demouser2."
-
He selects the severity and gives the description, "fraudulent activity."
-
-
He escalates the case to an Agent case and adds notes.
-
Now the CSR, "democsr1" does not have permissions to see the details of the case.
Agent Cases Escalated from CSR Case has User Details
User details are shown in escalated Agent cases.
-
An Investigator, "demoinvest1" logs in to the system.
-
He searches for Escalated cases by filtering on Escalated.
-
He opens the case.
-
Case Status changes from "Escalated" to "Pending."
-
Created By field still shows "democsr1."
-
Current Owner shows "demoinvest1."
-
User details are also displayed because this is not a user less case, but a CSR case that was escalated to an Agent case
-
Log shows that the case was created, then escalated, then accessed, and then the status changed.
-
Investigator can Create Agent Cases
A case can be created by an Investigator.
-
The Investigator, "demoinvest1," logs in to the system.
-
He creates a case
-
He selects the Organization ID.
-
He does not have to select a user because this is a user less case.
-
He selects the severity.
-
He gives a description.
The Case Details page appears.
-
The Case Status is "Pending."
-
The Created By field shows "demoinvest1."
-
The Current Owner field shows "demoinvest1."
-
User details are not shown because this is a user less case.
-
Investigator Can Create Agent Case for a Different Organization ID
Investigator can create Agent case for a different Organization ID if he has permissions to access multiple organizations. In most scenarios only the Investigation Manager has access to multiple organizations.
-
The Investigator, "demoinvest1," logs in to the system.
-
He creates a case
-
He selects a different Organization ID.
-
He selects the severity.
-
He gives a description.
-
-
He views the logs, which shows that the case was created.
An example of when two agents try to open a case is described below.
-
demoinvest1 logs in and searches for a case with status "New."
-
He can see the case, Case ID 132, in the results.
-
Another user demoinvest2 logs in and searches for a case with status "New."
-
He can also see the case, Case ID 132, in the results.
-
demoinvest2 opens the case and the status changes to "Pending."
-
demoinvest2 is the current owner of the case.
-
demoinvet1 still sees the case as "New" in the results.
-
He tries to open this new case but a message appears saying that demoinvest2 is the current owner of the case and he can choose to continue or cancel.
-
If he chooses to cancel, nothing happens and demoinvet2 remains the current owner.
-
If he chooses to continue, he becomes the current owner and the status of the case is "Pending."
The Investigator searches for Agent cases with Shown Only Expired as the Expired filter. The cases with dates and time displayed in red in the Expiration Column are overdue cases.
Users can search both CSR and Agent cases based on actions that were taken in them. An example is provided below:
Yesterday jsmith called customer service claiming to have lost money out of his account. The CSR escalated the case and told jsmith he would be contacted within 24 hours. jsmith calls back 36 hours later to see why he has not been contacted. The CSR needs to view the case escalated yesterday for jsmith. He searches cases for jsmith with an "Escalate" action and ones that are not overdue in the last 48 hours.
5.11.2 Investigation Workflow Scenario - Blocked Login Attempts
Agent type cases are used by fraud investigators to do the following:
-
Collect investigation findings for audit including which investigators have worked on a case
-
Manage the lifecycle of an investigation including severity, status, ownership changes, time to resolution, dropped/lost cases and resolution
-
Feed back closed findings into the risk engine to improve accuracy of future evaluations automatically
-
Export findings to Excel for external records or processes
A fraud investigator can quickly view the data involved in an incident and quickly locate related situations by easily harnessing the complex data relationships captured by OAAM. Search and detail pages provide fraud investigators the ability to:
-
Drill into individual sessions to see the exact chain of events that led to an alert
-
View and search for complex relationships between different data types
-
White/black list entities "on the fly" without leaving the investigation flow
This feeds back into risk evaluation. For example, a high risk device group.
-
Link session data to a case to further narrow the investigation
A security administrator configures an action to create an Agent cases when specific rules trigger. These autocreated cases require a review of the transaction. The details pages contain the information needed by the investigator in order to accomplish this task. An example workflow is shown below for an autocreated case.
Search for New Autocreated Agent Cases
John is a fraud investigator for the bank. John searches for new Agent cases dynamically created as a result of blocked access requests.
Best Practice: Filter the time-stamp column so the oldest case is on top.
John opens case 109 the oldest case in the listing to start working on it. Automatically the case status changes from New to Pending and the current case owner becomes John. Other investigators can now see that this case is actively being worked (since the case has an owner, John, and the status is not new, but pending). When case 109 was automatically created the session which was blocked was linked to the case so all the session data is captured and ready for review. This includes a full set of the alerts triggered in the session. This example show a session in which five different alerts were triggered. John can easily read the alert messages to understand what was going on in this situation. The highest alert was generated because the access attempt was from an IP known to be an anonymizing proxy. The bank security policy restricts banking while utilizing an anonymizing proxy as they are often used by criminals to hide their true geographic location.
Review User Accounts Used From High Risk IP Address
John clicks the IP address to drill in on the location to investigate further. Note Table 5-6, "Log Search Filters" shows the most severe alert as one that concerns an IP address (an anonymizing proxy). This opens the IP address details screen in an adjacent user interface tab. John selects the users tab to see what user accounts have been utilized from this high risk IP address. He can see that there are four different bank users potentially affected by the activity originating from this location.
John clicks the sessions tab of the IP details screen to list sessions from this IP address.
He selects them all and links them to case 109 that he is working on. This way he collects the data he has found along with notes as to why he did this. In this case all the sessions had been blocked but if there were some sessions that had not been blocked then linking those sessions to the case for further follow up is extremely useful since without the data cross referencing ability of the details screens such a situation may have gone undetected.
Review Linked Sessions in Agent Case
Now all data from these linked sessions is captured in case 109. John can see that the same device (#14) was used in all these blocked access attempts.
Review Details of the Sessions Parameter in Question
John clicks device 14 to open the device details screen. In the device details an investigator can also see data relationships and sessions for this device but can as well view the fingerprinting details of the device itself. For example, the browser locale used.
Review Alerts From Activity Involving the Session Parameter
John opens the alerts tab to view the types of alerts and frequency of each generated from activity by involving this device. For example he can see the aggregate count for the anonymizer alert is four.
Export the Linked Cases to Excel
John follows up with phone calls to the four affected customer account holders to further confirm that they were not the ones attempting these blocked attempts. Feeling he has investigated this incident to the fullest and confirmed fraud John is ready to close the case and move on to the next incident. Before closing the case John exports the linked sessions to Excel.
He exports the sessions so that he may furnish the evidence to federal law enforcement as part of an industry wide program.
Add Session Parameters to a Restricted Group
John feels confident that this device has only been used for fraudulent access attempts so he determines it should be blacklisted. Directly from the details screen John adds the device to the Restricted Devices group. This ensures it cannot be used to access online banking even if the other session data seems valid and no other rules trigger. This is very important as fraudsters often hit multiple times testing the security of an application to see how they can get around it. Device fingerprinting can be the one data point that stays the same across fraudulent attempts.
John closes the case as confirmed fraud with notes summarizing his findings. His manager or auditors can view a full log of case activity including actions taken, notes and individuals involved.
Since the case was marked as confirmed fraud the combinations of specific data found in the fraudulent access requests are automatically consumed by the risk evaluation engine to "teach" it what fraud looks like. This helps improve accuracy of future risk evaluations. Likewise, if John has found that the alerts he saw were not the result of fraud he would have closed the case and marked it as not fraud. This would also adjust future risk evaluations to reduce false positives.
5.11.3 Investigation Workflow for CSR Escalated Agent Cases
A CSR Manager escalates a CSR case. Matt is a fraud investigation agent specializing in customer specific security issues. He searches for all cases with the Escalated case status. Best practice is for investigators not to open cases that other investigators are working on. The first time an investigator accesses a case, the status changes to "Pending" automatically. This allows investigators to know if another investigator is already working on the case. Matt opens the escalated case. The status automatically changes from Escalated to Pending and the Current owner becomes Matt. Best practice is to open the escalated case and view the logs for notes entered by the CSR and CSR Manager. He sees they escalated the CSR case to an agent case because they suspected fraud activity. Because the case originated from a customer service case, it contains specific user information in the details. Matt looks at the case details and notes that jsmith is the user. He writes down the user ID because he needs it to search for sessions. Matt navigates to the Linked Sessions tab and opens Linked Sessions to search for sessions by the user ID, jsmith. jsmith has sessions so Matt looks for the most recent session by filtering on the date and the timestamp. Matt wants the most recent one because it caused the escalation. He reviews the alerts messages to understand what occurred. The highest alert was generated because the access attempt was from an IP known to be an anonymizing proxy. Matt clicks the IP address to drill in on location logins to investigate. He looks at other locations from the past to determine if a fraud potentially occurred. Since he has more questions, he calls the actual user, jsmith, and talks to him and takes notes. When Matt is satisfied his conclusion, he closes the case with a disposition.
5.11.4 Investigation Workflow for Manually Created Cases
Harry reads about a new type of fraud in an online security magazine. He decides to configure and run new reports to see if the attack has been attempted at Dollar Bank. He finds three sessions that seem suspicious. He wants to investigate further so he creates an Agent case and links these sessions to it. Harry picks some data points from the three sessions to drill in on. On the details screen one of the devices in the linked sessions is returning a large amount of sessions for a single user ID. His shift is almost over but this investigation has enough urgency that he would like another investigator in the next shift to continue investigating the case. Harry adds some notes to the case requesting that someone keep working on this case and any insights he has. Harry changes the status of the case to "attention required" so another Investigator picks it up.
-
Fraud Investigator opens the OAAM Admin Console and sees only the appropriate user interface views and controls afforded his role.
-
Fraud Investigator creates a case.
-
Fraud Investigator links the session.
-
Fraud Investigator repeats steps 2 and 3 as required
-
Fraud Investigator changes the case status to "attention required."
-
Fraud Investigator adds notes.
5.11.5 Investigation Workflow for Auto-Created Cases
Gary is a Fraud Investigation Agent for Dollar Bank. Gary searches for a new case to work on. He performs a search for all cases with new status, no current owner and filters the view by cases with least time to overdue at the top. Gary selects the first case, looks at the alerts and other data in the linked session. He then searches to find other sessions from North Korea. One other session is returned when he searches for the last six months. Gary links this second session to the case so relationships based on data from both of the sessions can be used to investigate. Gary notices that the two linked sessions were from the same device. Gary continues the investigation by looking into other sessions from this device in the past year. He finds there is another session from this device that says it was from China. He links that session as well. Each of the three sessions used a different IP address. Next Gary individually looks for sessions from each IP. Two of the IPs was only used in those sessions. The third IP from China had 178 sessions in the last three months. He wants to see the users potentially affected by this situation so he opens the IP details screen and views the users tab. A listing of all the users with details for each is shown. Gary looks into the identity management product to investigate each user to see if any have contact information in China. None of them do, all are Americans living in the continental US. Gary exports the list of user to XLS and contacts the customers who accounts were being used to ask a few questions. He finds that none of them had been in North Korea or China so he enters the conversations in the case notes. He asks them to change their passwords and resets their challenge questions. He also adds them to a victim watch list group and the device to a high risk watch list. Gary then closes the case with a confirmed fraud disposition.
-
Fraud Investigator opens the OAAM Admin Console and sees only the appropriate user interface views and controls afforded his role.
-
Fraud Investigator searches cases.
-
Fraud Investigator opens a case.
-
Fraud Investigator links session.
-
Fraud Investigator repeats step 3 and 4 as required.
-
Fraud Investigator generates list view of users affected.
-
Fraud Investigator adds users to victim list.
-
Fraud Investigator adds device to black list.
-
Fraud Investigator closes case.
5.11.6 How Users Use Agent Cases for Investigation
Oracle Adaptive Access Manager allows the creation of Agent cases to make forensic investigations quicker, easier and more successful.
An Agent case is created when a suspicious activity or fraud scenario is detected and needs investigation.
An example of how an Investigator uses Agent cases is shown below.
-
The Investigator receives automated high alerts of the type, "Fraud."
-
The Alert message notifies him that there are potentially suspicious sessions from North Carolina.
-
The Investigator immediately logs in to OAAM and searches sessions based on various filter criteria, such as the sessions from North Carolina.
-
He determines the sessions that needs investigation.
-
The Investigator creates an Agent case and start the investigation.
-
He selects these sessions and links them to the case.
As part of the linking the Investigator enters notes describing why the sessions were linked. The case log records the notes as well as the user who performed the link action. These sessions stay linked to the case unless they are unlinked by an investigator or manager.
-
The Investigator looks at the city and state in the Location Details page because many of the suspicious sessions occur in North Carolina.
-
Once the Investigator comes up with a conclusion, he closes the case with a disposition.
5.11.7 Associating Fraud Sessions with a Case for Investigation
The following section outlines the steps to associate fraud sessions with a case for investigation.
Ensure that you have the proper permissions to create and work with Agent cases.
Associating the Fraud Sessions with a Case for Investigation
You receive automated high alerts of the type, "Fraud," and the alert message notifies you that there are potentially suspicious sessions.
-
Log in to the OAAM Admin Console and search for sessions based on various criteria.
For example, you might search for all sessions that were blocked in the last 12 hours with High alerts (sessions filtered by Time, Alert Level and Action).
-
Go to the Session Details page to collect more information about the session you are interested in.
You could look at:
-
Outcomes of checkpoints
-
Policies and rules triggered
As an investigator, you are interested in why a particular rule triggered. For example, you might look at which policy and rules triggered the alert.
Information can be gathered by looking at these details. For example, a user who successfully went through Pre-Authentication and Post-Authentication checkpoints knew the password and the questions and answers and there fore, there is a good chance that he is a valid user. On the other hand, a user who attempted to answer the questions twice and succeeded in providing a correct answer on his third attempt might be considered suspicious. This user did not know the answers right away so there is a chance that he may be a fraud trying out new answers.
-
-
In the Policy Explorer in Session Details, view the runtime values for each one of the policies and rules that were triggered.
For example, if a rule triggered that showed that the user had logged in from a country that he did not usually log in from, you would want to look at the runtime details to see which country he logged in from.
The Policy Explorer shows the policies that were triggered, the condition parameters, and the actual values.
-
Determine the sessions you need to investigate.
-
Create an Agent case and start the investigation.
-
Search and select these sessions and link them to the case.
As part of the linking enter notes describing why the sessions were linked. The case log records the notes as well as the user who performed the link action. These sessions stay linked to the case unless they are unlinked by an investigator or manager.
-
Identify the relationship between the sessions and view the appropriate detail pages.
For example: If the suspicious sessions used the same device, view the Device Details page. If the suspicious sessions are from the same location, view the Location Details page. If the suspicious sessions are from the same user, view the User Details page. If the suspicious sessions all used a Spanish browser, view the Fingerprint Details page.
-
View Location Details page.
-
View Device Details page.
-
View Fingerprint Details page.
-
View Alert Details page.
-
View User Details page.
-
-
Analyze the sessions and when you reach a conclusion, close the case with a disposition.
5.11.8 Listing the Cases that I Am Currently Working With
Both CSR and Agent type cases can be searched based on the current owner. This search filter finds cases for which the last action performed was by the user you are searching.
Ensure that you have the proper permissions work with cases.
List Cases I'm Currently Working On
-
Log in to the OAAM Admin Console.
-
As a CSR or CSR Manager: In the Cases search page, search for the cases you are currently working on by specifying the following criteria in the search filters:
-
As an Investigator: In the Cases search page, search for the cases you are currently working on by specifying the following criteria in the search filters.
5.11.9 Marking One or More Sessions as Confirmed Fraud
The following section outlines the steps to mark one or more sessions as confirmed fraud. Included are references to other sections where you can find specific information.
Ensure that you have the proper permissions to create and work with Agent cases.
Mark One or More Sessions as Confirmed Fraud
To mark a session as Fraud/Not Fraud, create an agent case link the session and close the Agent case with Disposition as either "Confirmed Fraud" or "Not Fraud".
-
Log in to the OAAM Admin Console as an Investigator.
-
Create an Agent case. Refer to Section 5.5.5, "Creating an Agent Case Manually."
-
Link sessions to the case. Refer to Section 5.7.1, "Linking Sessions."
-
Change the severity of the case to High. Refer to Section 5.6.2, "Changing Severity Level of a Case."
-
Close the case with Disposition as "Confirmed Fraud." Refer to Section 5.6.3, "Changing Status of a Case."
5.11.10 Closing a Case
The following section outlines the steps to close a severity of High.
Ensure that you have the proper permissions to work with cases.
To close a case:
-
Log in to the OAAM Admin Console.
-
Navigate to the Cases search page. Refer to Section 5.3, "Opening the Case Search Page."
-
Open the Case Details page. Refer to Section 5.5.3, "Viewing Agent Case Details."
-
Change the severity of the case to High. Refer to Section 5.6.2, "Changing Severity Level of a Case."
-
Change the status of the case. Refer to Section 5.6.3, "Changing Status of a Case."
-
Close the case with a disposition. Refer to Section 5.6.4.1, "Closing a Case Manually."
5.11.11 Closing Multiple Cases
The following section outlines the steps to close multiple cases.
Ensure that you have the proper permissions to work with cases.
To close multiple cases:
-
Log in to the OAAM Admin Console.
-
Navigate to the Cases search page. Refer to Section 5.3, "Opening the Case Search Page."
-
Close multiple cases. Refer to Section 5.6.5, "Bulk-Editing Agent Cases."
5.11.12 Auto-Status Change (Escalated Cases)
Actor: Security Investigator/Security Investigator Manager
CSR case is created via one of the two possible flows (auto/manual).
-
CSR performs escalate case action. Case is turned into an Agent type case with a status of "Escalated".
-
Investigator searches for all the cases with "Escalated" status. He filters the results on the severity column so the highest severity cases are shown at the top.
-
He clicks one of the high severity case IDs in the list. Validation checks if the case still has "Escalated" status before opening the case screen and automatically changes the status to pending.
-
Case log displays creation, escalate action, access by user and status change to pending.
5.12 Best Practices and Recommendations
Best practices and recommendations are provided below:
-
A Fraud Investigator looks into suspicious situations either escalated from customer service or directly from alerts.
-
An Fraud Investigation Manager would want to see which cases need to be given attention by his team.
-
A Fraud Investigation Manager must routinely search for overdue cases to make sure none of the cases are pending.
-
If a customer suspects fraud, then the severity level assigned is "High." For example, if the customer wants a different image, then the severity level assigned is "Low." Severity levels of a case can be escalated or de-escalated as necessary. Anyone can change the severity of cases.