Investigation Workflow Scenario - Blocked Login Attempts

Investigation Using Agent Cases 5-25 Figure 5–6 Reviewing Alerts 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. 5-26 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–7 Reviewing User Accounts Used From IP Address Link Sessions to Agent Case John clicks the sessions tab of the IP details screen to list sessions from this IP address. Investigation Using Agent Cases 5-27 Figure 5–8 Searching for Sessions to Link to Agent Case 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. 5-28 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–9 Linking Sessions to the Agent Case 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. Investigation Using Agent Cases 5-29 Figure 5–10 Review Linked Sessions in Agent Case 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. 5-30 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–11 Viewing Details About the Sessions Parameter 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. Investigation Using Agent Cases 5-31 Figure 5–12 Reviewing Alerts Involving the Session Parameter 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. 5-32 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–13 Exporting Linked Sessions to an Excel Sheet He exports the sessions so that he may furnish the evidence to federal law enforcement as part of an industry wide program. Investigation Using Agent Cases 5-33 Figure 5–14 Evidence to Show to Authorities 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. 5-34 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–15 Adding Session Parameters to Restricted Group Close the Case 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. Investigation Using Agent Cases 5-35 Figure 5–16 Closing Agent Case with Notes 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-36 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager Figure 5–17 Agent Case Search Results

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. Investigation Using Agent Cases 5-37

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.

1. Fraud Investigator opens the OAAM Admin Console and sees only the

appropriate user interface views and controls afforded his role.

2. Fraud Investigator creates a case.

3. Fraud Investigator links the session.

4. Fraud Investigator repeats steps 2 and 3 as required

5. Fraud Investigator changes the case status to attention required.

6. 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. 1. Fraud Investigator opens the OAAM Admin Console and sees only the appropriate user interface views and controls afforded his role. 2. Fraud Investigator searches cases. 3. Fraud Investigator opens a case. 4. Fraud Investigator links session. 5-38 Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager 5. Fraud Investigator repeats step 3 and 4 as required. 6. Fraud Investigator generates list view of users affected. 7. Fraud Investigator adds users to victim list. 8. Fraud Investigator adds device to black list. 9. 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. 1. The Investigator receives automated high alerts of the type, Fraud. 2. The Alert message notifies him that there are potentially suspicious sessions from North Carolina. 3. The Investigator immediately logs in to OAAM and searches sessions based on various filter criteria, such as the sessions from North Carolina. 4. He determines the sessions that needs investigation. 5. The Investigator creates an Agent case and start the investigation. 6. 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. 7. The Investigator looks at the city and state in the Location Details page because many of the suspicious sessions occur in North Carolina. 8. 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. Before You Begin 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. 1. 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.