ArcSight FraudView Solution User Guide v1.0.1

Summary:

The provided text outlines the comprehensive approach taken by an organization in detecting financial transaction anomalies using the ArcSight™ FraudView software. This document serves as a guide for users on how to effectively utilize the software's features to monitor and detect fraudulent activities, which are categorized into various use cases based on specific patterns of suspicious behavior. Here’s a breakdown of each use case mentioned: 1. **Geographic Disparity of Account Access (case 89)**: This involves transactions where access is granted from locations not typically associated with legitimate activity. The ArcSight™ FraudView software helps in identifying these anomalies by analyzing differences in IP addresses or geographical locations related to account access and raising alerts for further investigation. 2. **Trading Violation - Single transaction dollar threshold (case 89)**: This use case involves transactions that exceed a predefined dollar amount, which could be indicative of fraudulent activities such as insider trading or market manipulation. The software tracks these instances across multiple accounts and payees to detect potential anomalies. 3. **Multiple Accounts Paying Same Payee: In this scenario, the same vendor or recipient is paid by several different accounts, which may suggest collusion among users for fraudulent purposes. The ArcSight™ FraudView can identify such patterns and correlate them across various transactions to uncover possible fraud. 4. **Penny Stock Transactions (case 87)**: This use case involves suspicious trading activities involving penny stocks, a type of stock typically seen in speculative or potentially manipulative trading scenarios. Alerts are triggered when such trades exceed normal thresholds for volume and value. 5. **Successful Login from Known Fraudulent Address: When logins occur from IP addresses known to be associated with fraudulent activity, this indicates potential insider threats or unauthorized access attempts that should be investigated. The ArcSight™ FraudView software helps by tracking these events across different user accounts. 6. **Multiple Failed Logon Attempts (case 70)**: This use case involves multiple failed login attempts made from different locations or devices by a single user, which may signal potential insider threats or compromised credentials. The software can help in monitoring and detecting such behaviors that could lead to fraudulent activities. In summary, the ArcSight™ FraudView v1.0.1 Guide provides detailed steps and use cases for leveraging the software's features to detect various types of financial fraud. By tracking suspicious patterns across multiple transactions and user accounts, organizations can proactively monitor their systems and respond swiftly to potential threats, thereby protecting themselves against fraudulent activities.

Details:

The provided text appears to be the preface and revision history of a user guide for ArcSight™ FraudView v1.0.1, dated July 6, 2010. Here's a summary of its content:

• **Title and Copyright Information**: The document is titled "ArcSight™ FraudView v1.0.1 Guide" and is copyrighted by ArcSight, Inc., with various trademarks noted including those for products such as ArcSight, the ArcSight logo, FlexConnector, SmartConnector, SmartStorage, CounterACT, and others.

• **Disclaimer**: The document states that network information used in examples (like IP addresses and hostnames) is only for illustration purposes.

• **Confidentiality Notice**: It's marked as confidential by ArcSight.

• **Revision History**: This section provides a list of updates made to the guide, including changes from previous versions and details about what has been updated in this version (v1.0.1), such as compatibility with ArcSight™ ESM v5.0.

• **Support Information**: Contact information for ArcSight Customer Support is provided, including phone numbers and an email address for support inquiries, along with a web site for further assistance.

• **Preface**: This section outlines who should read the guide, how to use it, and provides text conventions used in the document. The preface also mentions that related documentation can be accessed via a link provided at the end of the preface.

• **Chapter 1: FraudView Overview**: Although not detailed here, this chapter likely introduces the main features and functionalities of ArcSight™ FraudView v1.0.1.

The guide is intended for users who need to understand and operate ArcSight™ FraudView version 1.0.1, with instructions on how to use the software effectively based on its updates and previous versions. The provided text appears to be a structured document, likely part of an internal documentation or technical guide for a software product named "FraudView." It outlines various components and processes related to fraud detection and management. Here's a summarized breakdown of its content: 1. **FraudView Components**: Lists the main modules or features within FraudView that include Early Warning Account Escalation, Escalating Risk Model, Real-Time Correlation Engine, Pattern Discovery, Workflow, and Use Cases. 2. **Early Warning Account Escalation** and **Escalating Risk Model**: These sections describe how to use the software's built-in tools for early detection of potential fraud by escalating risk models based on specific criteria. 3. **Real-Time Correlation Engine** and **Pattern Discovery**: These components focus on real-time data processing and pattern recognition used to identify anomalies or patterns indicative of fraudulent activities in financial transactions. 4. **Workflow**: Outlines the series of steps, including decisions and actions, that need to be followed within the FraudView system when dealing with alerts related to suspicious activity. 5. **Use Cases**: Describes various scenarios where FraudView can be applied for detecting or managing fraud in different contexts such as customer service interactions, financial transactions, etc. 6. **Chapter 2: Installation and Configuration** covers the setup process of FraudView including environment verification, installation steps, troubleshooting procedures, user permissions assignment, configuration details of specific utilities like ArcSight ESM Console Utility Files, and developing FlexConnectors for event generation. The text does not provide detailed technical information or code snippets but instead offers a structured guide on how to install, configure, and operate FraudView in an organizational setting. Each section seems to be tailored for either IT administrators who will set up the software or security analysts who would use it to detect fraud. The provided text appears to be a section of a larger document, likely a user guide or manual for ArcSight FraudView v1.0.1, a software tool used for fraud monitoring and analysis. Here's a summary of the topics covered in this segment:

• **Install the Risk Formula**: This involves installing various components that are essential for calculating risk factors in the system. These factors include Destination Risk Factor, Transaction Risk Factor, Account Severity Risk Factor, Device Risk Factor, and others.

• **Configure the Destination Risk Factor**: Settings related to where transactions occur need to be configured, such as IP addresses or domains involved in financial transactions.

• **Configure the Transaction Risk Factor**: This involves setting parameters for transaction types, amounts, frequency, etc., which helps in determining risk levels.

• **Configure the Account Severity Risk Factor**: Adjust settings related to account usage and behavior that could indicate higher fraud risks.

• **Configure the Device Risk Factor**: Parameters such as device type, location, and security features are configured here to assess potential risks associated with devices used for transactions.

• **Download and Install the Fraud Monitoring Dashboard**: This involves setting up a user interface where key fraud metrics and insights can be visualized and monitored in real time.

• **Configure FraudView Content**: Customizing what data is displayed, how it's presented, and who has access to which information within the FraudView platform.

• **Deploy FraudView Rules**: Setting up specific rules based on predefined criteria that help automatically detect and respond to potential fraud cases.

• **Configure Account Escalation**, **Configure Cases**, and **Configure Notifications** are all related to managing alerts and escalations in a timely manner, setting up case management for investigations, and defining how users will be notified of system events or suspicious activities.

• **Configure Pattern Discovery**: This involves using advanced algorithms and machine learning models to automatically identify patterns that might indicate fraudulent activity, based on historical data and user-defined parameters.

These sections provide a roadmap for setting up and configuring the various components needed to effectively use ArcSight FraudView v1.0.1 for fraud detection and monitoring tasks. This text appears to be a part of a larger document, possibly related to fraud detection and management systems. It consists of several chapters with titles such as "Configure FraudView Use Cases," "Configure Lists Using Console Entry Editor," "Chapter 3: Account Escalation," and "Chapter 4: FraudView Early Warning UseCases." Here's a summary of each chapter based on the provided text: 1. **Configure FraudView Use Cases**: This section discusses how to set up use cases for detecting fraud, including configuring lists using a console entry editor and importing CSV files for active lists. 2. **Chapter 3: Account Escalation**: Focuses on tracking accounts and escalating them based on certain criteria. It explains the process of adding or removing accounts from different active lists (watched, suspicious, investigate) and how to optionally configure account escalation settings manually or by customizing rules. 3. **FraudView Early Warning Use Cases**: Introduces early warning use cases related to fraud detection, specifically mentioning an access feature allowing users to view multiple accounts originating from a single IP address. Configuration details for this use case are also provided. Each chapter seems to be part of a guide or manual about using a specific software tool or system for detecting and managing fraudulent activities. The text does not provide full content beyond the titles and some bullet points, so further information would be needed to fully understand each topic in detail. The provided text appears to be a table or list where each entry corresponds to a "Use Case" related to fraud detection and security configurations within the software system named "ArcSight." Each use case has specific steps outlined for configuration, including identifying potential fraudulent activities. Here's a summary of each use case mentioned in the text: 1. **From OFAC Blacklisted Country Use Case** - This involves configuring settings to detect transactions or account creations from countries blacklisted by the Office of Foreign Assets Control (OFAC), which is used to manage U.S. sanctions against other countries.

• Configuration steps are detailed starting on page 60.

• Resources for this use case start on page 60.

2. **Account Created Using Fraudulent SSN Use Case** - This concerns detecting accounts created using Social Security Numbers (SSNs) that have been flagged as potentially fraudulent.

• Configuration steps are detailed starting on page 61.

• Resources for this use case start on page 61.

3. **Account Lockout Detected Use Case** - This involves configuring the system to recognize and respond to multiple failed login attempts, which might indicate a lockout due to potential hacking attempts or other fraudulent activities.

• Configuration steps are detailed starting on page 62.

• Resources for this use case start on page 62.

4. **Account Logon from RBN Use Case** - This relates to detecting logons from known malicious networks (RBN stands for "Real-time Blackhole List" which is a list of IP addresses used for distributing malware and other unwanted network traffic).

• Configuration steps are detailed starting on page 63.

• Resources for this use case start on page 63.

5. **Account Registration at Suspicious Time Use Case** - This involves configuring the system to identify unusual times when an account is being registered, which might be indicative of fraudulent activities.

• Configuration steps are detailed starting on page 63.

• Resources for this use case start on page 64.

6. **Account Registration From Country of Concern Use Case** - This involves configuring the system to monitor and flag account creations from countries considered a risk based on compliance or other concerns.

• Configuration steps are detailed starting on page 65.

• Resources for this use case start on page 65.

Each use case includes specific configuration details, which are crucial for setting up the software to effectively monitor and prevent fraud in real-time operations. The text you've provided appears to be a list of use cases and their associated configurations, along with some general resources. Here’s a summarized breakdown of the information presented in each section:

• **Account Registration from RBN Use Case**: This involves setting up an account through Remote Banking Network (RBN). Configuration settings include ensuring proper setup for accessing RBN services. Resources may include guides or documentation needed to register and configure an account with RBN.

• **Configure**: Details how to set up initial configurations for each use case, which is necessary to ensure the functionality of specific features related to money management and security checks in financial transactions.

• **Resources**: Supplementary material such as manuals, help guides, or FAQs that provide detailed information on how to perform tasks outlined in the configure section, including account registration details, login procedures for suspicious activities detection, etc.

• **Excessive Wire Transfers to Same Payee Use Case**: This use case involves frequent transfers to a single payee, which may raise concerns about money laundering or financial irregularities. Configuration settings might include monitoring thresholds and alerting mechanisms when such transactions exceed predefined limits. Resources here would likely provide guidance on how to configure these controls effectively.

• **Geographic Disparity of Account Access Use Case**: This involves users accessing their accounts from locations significantly different from where the account is registered or expected to be used. Configuration settings could include geo-location tracking and alerts for unexpected access points, with resources providing instructions on implementing such security measures.

Each use case has a corresponding number indicating its position in the document, likely serving as page numbers in a larger publication like an annual report or user manual. The text format follows a template that highlights key actions (configure) and provides supplemental information (resources). The provided text seems to be a documentation outline or a table of contents for a system, possibly related to financial transactions or user management. Here's the summarized content based on the titles given:

• **Resources**: Appears multiple times throughout the document, likely indicating that each section has associated resources or further details available.

• **Multiple Accounts Paying Same Payee Use Case**: Describes how to configure settings for accounts where users pay the same entity.

• Configure: Instructions on setting up these configurations.

• **Multiple Failed Logon Attempts Use Case**: Covers a feature related to handling multiple failed login attempts, with instructions under "Configure."

• **Multiple Password Resets Use Case**: Discusses managing multiple password resets, also offering configuration guidance.

• **Multiple Transactions by Same User Use Case**: Addresses the scenario of users making numerous transactions, providing setup details under "Configure."

• **Password Reset Not Preceded by Lockout Use Case**: Explains what happens when a user requests a password reset without prior lockout and how to configure this feature.

• **Payee Created and Paid - Same User Use Case**: Describes handling situations where the same user both creates and pays a payee, offering configuration options.

Each use case has a corresponding "Configure" section that outlines the steps needed to set up or manage the particular scenario described in the title. The numbered references (e.g., 70, 71) are likely page numbers where more detailed information can be found within the document. The provided text appears to be a section heading for a document related to fraud detection and analysis, possibly within the ArcSight Confidential series. Here's a summary of what seems to be covered in each subsection based on the headings: 1. **Payee Created and Paid - Suspicious Time Use Case**

• This involves configuring settings to monitor suspicious time patterns when creating or paying payees.

2. **Paying Suspicious Payee Use Case**

• Focuses on setting up configurations for detecting unusual activity when making payments to potentially fraudulent payees.

3. **Successful Login from Country of Concern Use Case**

• Describes how to configure the system to detect and analyze successful logins originating from countries considered suspicious or risky.

4. **Successful Login from Suspicious Address Use Case**

• This involves configuring the system to monitor and alert on successful logins that come from addresses known for fraudulent activities.

5. **Transaction Behavior Anomaly Use Case**

• Outlines how to set up detection of anomalous transaction patterns, which can be indicative of potential fraud or suspicious behavior.

6. **Transfers Just Under Violation Threshold**

• This section likely covers a use case related to configuring the system to detect and analyze transactions that are close to but do not quite exceed a threshold considered potentially fraudulent.

Each subsection is followed by a reference to configure settings and resources, which might include specific steps, templates, or additional information needed for implementing these fraud detection measures. The document seems to be part of a guide related to ArcSight FraudView version 1.0.1, providing detailed instructions on how to detect suspicious activities through various use cases. The provided text appears to be a section of a larger document or report that outlines various use cases related to thresholds and their configurations in different industries. Here's a summary of the information presented in each sub-section, focusing on the key points mentioned for each use case: 1. **Threshold Use Case**

• This involves setting a threshold value.

• Configuration instructions are provided under "Configure."

• Resources such as guidelines and reference materials are listed under "Resources."

2. **Transfers Over Violation Threshold Use Case**

• Similar structure to the Threshold Use Case, with specific focus on situations where transfer limits are exceeded.

• Configuration details are outlined in a section titled "Configure," followed by resources needed for implementation.

3. **Industry Specific—Credit Card Use Case**

• Focuses on credit card transactions involving foreign countries.

• Configuration settings and necessary resources are detailed under the respective headings.

4. **Industry Specific—Investment Banking Use Cases**

• Two specific use cases are outlined: Entitlements Violation and Excessive Wire Transfer Requests.

• Both involve configuring threshold values and specifying related resources.

5. **Penny Stock Transactions Use Case**

• This section is incomplete as indicated by the ellipsis, but it follows a similar structure to other use case descriptions in terms of configuration requirements and resource provisioning.

Each use case includes detailed steps for setting up thresholds and lists necessary resources or guidelines needed to execute these configurations effectively within specific industries. The text indicates that each subsection has its own unique context (e.g., credit card transactions, investment banking), but the general template for configuring thresholds is consistent across all sections. The provided text appears to be a section from an internal guide or document, likely related to configuring and managing trading violation rules in a software product called "ArcSight™ FraudView" version 1.0.1. Here is a summary of the content: The section discusses various use cases for configuring trading violations within the ArcSight™ FraudView application. Each use case pertains to setting specific thresholds that would trigger an alert or violation when met, such as dollar amounts per day (purchased and sold), single transaction values, and number of transactions per day. 1. **Configure** and **Resources** sections are repeated for each use case:

• **Trading Violation - Dollar Per Day Threshold - Purchased Use Case**: This involves setting a threshold for dollar amounts in purchases that would lead to an alert.

• Configure: Page 87-88

• Resources: Page 88

• **Trading Violation - Dollar Per Day Threshold - Sold Use Case**: Similar to the purchased use case, but for sales.

• Configure: Page 89

• Resources: Page 89

• **Trading Violation - Single Transaction Dollar Threshold Use Case**: This involves setting a threshold for individual transactions based on their dollar value.

• Configure: Page 90

• Resources: Page 91

• **Trading Violation - Single Transaction Units Threshold Use Case**: Involves setting a threshold based on the units of goods or services in single transactions.

• Configure: Page 91

• Resources: Page 92

• **Trading Violation - Transactions Per Day Threshold Use Case**: This involves setting a limit for the number of transactions that can occur within a day before triggering an alert.

• Configure: Page 92

• Resources: Page 92

Each use case provides specific configurations and resources needed to set up these trading violation rules, ensuring they are tailored to meet the needs of detecting fraudulent or anomalous trading activities based on predefined thresholds. This summary focuses on the content of a document or section titled "Trading Violation - Units Per Day Threshold Use Case," which seems to be part of a larger resource for FraudView, possibly within a financial monitoring system. Here's an overview based on the given text: 1. **Configure**: A crucial feature mentioned under the heading "Configure" is discussed in detail. This section likely outlines how to set up or configure specific parameters related to units per day thresholds used in trading violations analysis. 2. **Resources**: Following configuration, a list of resources such as Active Channels, Active Lists, Asset Ranges, Dashboards, Data Monitors, Destinations, Field Sets, Files, Filters, Profiles, Queries, and Query Viewers are listed under the heading "Resources." These appear to be tools or components used in managing and visualizing data related to trading violations. 3. **Appendix B: FraudView Resources By Type**: This appendix further categorizes resources by type, providing detailed descriptions of each resource from the previous section, such as how to manage Active Channels, Active Lists, Asset Ranges, Dashboards, Data Monitors, Destinations, Field Sets, Files, Filters, Profiles, and Queries. 4. **Active Channels, Active Lists**: These are specific types of lists used in managing active participants or assets within the trading system. Details on how to manage these lists would be detailed here. 5. **Asset Ranges**: This section likely deals with defining and managing ranges for various assets that are monitored under trading violations protocols. 6. **Dashboards, Data Monitors**: These provide visual interfaces summarizing key data points about trading activities, potentially allowing users to monitor performance or detect anomalies in real-time. 7. **Destinations, Field Sets**: Describes where and how the data collected is stored or used within the system. Field sets are presumably templates for organizing specific types of data fields. 8. **Files, Filters**: Files likely refer to digital storage units for holding electronic documents related to trading violations, while filters help in refining what information is displayed based on predefined criteria. 9. **Profiles, Queries, Query Viewers**: These components are involved in managing user-specific settings and the visual presentation of query results within the system. 10. **Reports**: Summarizes findings or data outputs from the configured parameters and resources, possibly for external stakeholders or internal audit purposes. The document appears to be a comprehensive guide on setting up and using tools within a FraudView module related to units per day thresholds in trading violations analysis, with detailed information provided on how each tool functions and how they interact within the larger system. This preface is for a guide about ArcSight™ FraudView v1.0.1, which is software to detect fraud in organizations. It's meant for people like administrators and security managers who need to plan, implement, maintain, and use this software. They should know basics about networks and network security and how to use the tools provided by FraudView. The guide has several chapters: 1. "FraudView Overview" explains what FraudView does to help with fraud issues in companies. 2. "Installation and Configuration" tells you how to set it up, like planning where to put it and actually installing it. 3. "Account Escalation" explains the process of dealing with situations that might lead to or involve fraud. 4. "FraudView Early Warning Use Cases" gives examples of real-life scenarios where FraudView can be used and how to set it up for those cases. There's also a list of resources (Appendix B) which categorizes all the information in ways like videos, guides, or FAQs about FraudView. And finally, there's an index at the end that helps you find things easily if you need to look something up later. The provided text is a guide for using the "ArcSight™ FraudView v1.0.1" software, which includes specific syntax conventions used throughout the document to help clarify instructions and explanations. Here's a summary of the main points from the preface section: 1. **Text Conventions**: A table outlines various text descriptions and examples of how they are used in the guide:

• **Bold**: Indicates on-screen elements that users should click, such as "Enter a value and click OK."

• **Code**: Used for inline code elements within paragraphs, like file names or script snippets.

• **Emphasis/Italics**: Indicates emphasis (e.g., "Do not perform this procedure until you have backed up your data") or to denote book titles (e.g., "For more information, see the ArcSight Administrator’s Guide.").

• **menu > submenu**: Right angle brackets are used to indicate steps in command sequences and help topic sequences.

• **| tab | subtab**: Vertical bars separate multi-level editor-tab sequences (e.g., "tab | subtab | subtab").

• **/ Forward slash /**: Indicates file paths or URI strings, such as "/Forward Reports/System Reports/Asset/All Assets".

• ****: Variables are denoted by text enclosed in angular brackets and may be emphasized (in italics). Examples include "" for a password variable.

• **{parameter1 | parameter2 | parameter3}**: Curly brackets enclose multiple parameters, at least one of which must be provided. This is used flexibly depending on the context.

• ****: Square brackets indicate optional parameters or values (e.g., "<--cli_restrict 1="1">").

2. **Represents a Caution**: The text includes a symbol for caution, which advises that ignoring certain pieces of information in the document might lead to issues (not explicitly stated but implied by "may cause"). This preface sets the stage for understanding how to navigate and interpret specific instructions within the ArcSight™ FraudView v1.0.1 documentation, emphasizing the importance of following prescribed steps and using provided variables correctly. This text discusses various documentation resources provided by ArcSight for their product, ArcSight Enterprise Security Manager (ESM). The primary purpose of these documents is to provide users with tips, notes, and comprehensive guides on how to effectively use the software. Key among them are the "ArcSight ESM Concepts," which serve as an introduction to the inner workings of ArcSight ESM; "Release Notes," detailing new features, updates, known issues, and technical support information; and "Installation & Configuration Guide," explaining in detail how to install and set up various components such as databases, managers, consoles, and SmartConnectors. Additionally, there are guides tailored for specific user roles—Administrators and Reviewers—highlighting their respective functionalities and features. Lastly, the text mentions that printable versions of online help can also be accessed through the ArcSight Console. The ArcSight Confidential series of guides, including "ArcSight™ FraudView v1.0.1 Guide," is designed to provide comprehensive information about the ArcSight fraud detection and prevention system. Here's a summary of its main components and functions:

• **Document Titles and Descriptions:**

• **ArcSight Pattern Discovery™:** This guide explains how to utilize ArcSight Pattern Discovery for detecting specific, complex patterns in data that might not be immediately recognizable through standard tools.

• **ArcSight FlexConnector Configuration Guide:** It provides detailed information on how to design, create, and install custom SmartConnectors using the ArcSight platform.

• **ArcSight Web User’s Guide:** This is a user-focused manual providing reference information from the ArcSight Web online Help system, intended for users who require direct access to guidance without extensive documentation.

• **Glossary in the ArcSight™ ESM Reference Guide:** A detailed glossary within this guide serves as a resource to clarify various terms and acronyms used throughout the series and other related documents.

• **ArcSight FraudView Overview:**

• "ArcSight™ FraudView" is designed to assist organizations in identifying, responding to, and preventing fraudulent activities across multiple channels or business lines. It can detect fraud not only in internet-facing customer applications but also in internal systems, using a multi-stage analysis of transactions (events) from various sources.

• The system analyzes cross-channel data to identify fraudulent behavior in three stages:

• **Pre-authentication (Account Takeover):** This stage focuses on detecting attempts to access accounts without proper authentication, including activities like phishing and brute-force password guessing that might indicate an account takeover attempt.

• **Post-authentication:** This stage involves more advanced fraud detection techniques as the system has already authenticated the user but continues to monitor for anomalies in behavior indicative of potential fraudulent activity.

• The guide highlights how FraudView can be adapted to detect various types of fraud, including access via internet portals, call center systems, and social engineering against insiders. It emphasizes that fraudsters often attempt multiple approaches to defraud an organization without being limited by a single method.

Overall, these guides are intended for both technical and non-technical users to help them effectively implement, configure, and use ArcSight FraudView to safeguard their organizations from various forms of fraudulent activities. The article discusses a multi-stage approach to detecting fraudulent activities in transactions, implemented by ArcSight™ FraudView. This method comprises three main detection stages and can be customized with business rules specific to the organization's needs. The first stage involves detecting authentication anomalies and failures, focusing on irregular or suspicious geo-location of transaction origination and patterns that deviate from normal behavior. The second stage, Post-authentication or Transactional Fraud Detection, targets fraudulent activity post-user authentication by looking for misuse, irregular patterns, and policy violations. This includes money being moved to suspicious locations and transactions that don't align with typical activities. The third stage is focused on detecting the creation of fraudulent accounts solely for fraudulent purposes. It involves monitoring account attributes or actions during creation for any signs of illegitimacy when considered collectively rather than individually. In addition to these stages, FraudView can be augmented with custom business rules and tailored resources according to specific organizational policies. The article outlines the various components of ArcSight™ FraudView including "Early Warning Account Escalation," "Escalating Risk Model," "Real-Time Correlation Engine," and more. The document discusses "FraudView," which includes features such as "Early Warning Account Escalation." This feature involves monitoring accounts suspected of exhibiting suspicious behavior and escalating the level of scrutiny if necessary. It uses early-warning rules, correlation mechanisms, and three levels of tracking lists to identify potential fraudulent activity across various accounts. The process starts with adding an account to the "Watched Accounts" list upon initial detection of low-level suspicious behavior, which then moves up through levels based on increasing concerns until it reaches investigation if necessary. This system helps in identifying a small number of potentially fraudulent accounts. ArcSight™ FraudView is a tool designed to detect financial fraud by analyzing large pools of account transactions among various platforms. It allows analysts to prioritize and investigate accounts flagged as suspicious, based on their Investigate List. Account statuses are displayed in real-time through dashboards, and detailed reports can be generated for escalated risks. The FraudView system uses a dynamic risk model that continuously evolves; incoming transactions are evaluated against this model to determine their significance. This model can be customized with attributes from external sources such as blacklists or security monitoring instances, enhancing its ability to assess risks effectively. Components of the risk model include a correlation engine and a trending engine, which work together to detect fraudulent activities by adding relevant transaction attributes back into the model when suspicious activity is detected. FraudView uses a risk engine to monitor each account and assess deviations from normal behavior by assigning higher risk scores to transactions that stand out as unusual or suspicious. The system also includes a Pattern Discovery module capable of detecting patterns of activity, distinguishing between normal and fraudulent actions, which can influence future transaction risk assessments. During processing, every transaction is evaluated against four default indicators: Destination Risk (considering payment country, foreign country, top loss maker, and suspicious payee), Transaction Risk (evaluating the type of transaction and its associated risk level), Device Risk (taking into account geographic location, system information, suspicious IP address, and attack history), and Account Risk (assessing the account's escalation status on a watched or investigate list). This comprehensive approach to risk modeling enables FraudView to provide real-time monitoring and assessment of financial transactions. FraudView is a system designed to monitor and assess transactions, particularly focusing on real-time risk assessment through advanced correlation engines. It operates by adding accounts from countries considered high-risk to a watch list, which automatically raises the transaction's risk score. Unlike traditional models that recalculate at fixed intervals, FraudView updates risks in real-time, enhancing analyst responsiveness and potentially automating responses. The platform uses ArcSight™'s multi-dimensional correlation engine to evaluate transactions against pre-defined fraud detection rules continuously. Analysts can customize these rules without coding expertise, with the system operating in both real-time and forensic modes for flexibility. In forensic mode, it evaluates historical data against current rules to detect previously unrecognized patterns of compromise. Correlation rules within FraudView are device-independent, capable of analyzing data from various sources like call centers and internet portals, enhancing cross-channel fraud detection. These rules can trigger specific actions such as notifications or workflow tickets when activated. Additionally, the system features an advanced pattern detection engine that identifies patterns in transaction data, enabling proactive risk management based on identified behavioral traits rather than just individual events. In summary, FraudView leverages real-time correlation and advanced pattern discovery to improve fraud detection by continuously updating risk assessments and responding promptly with customizable rules and automated workflows. FraudView is a fraud detection tool that uses advanced data mining techniques and a correlation engine to identify patterns in transaction data. It has predefined Pattern Discovery profiles for specific types of fraudulent activities like payment activity, country access, and account access. These profiles help find patterns normally attributed to normal events but can be used by analysts to detect potential fraud. Once identified, the tool can save these patterns as common or potentially fraudulent, creating rules to automatically detect further instances in real-time if they are deemed potentially fraudulent. FraudView includes various components such as predefined Pattern Discovery profiles and a built-in workflow for operationalizing the fraud detection program. This workflow involves event annotation where multiple analysts collaborate without duplicating efforts, supports escalation of individual transactions for deeper investigation, and allows viewing events in real-time or past data sets for forensic analysis. The tool aims to help users effectively use its Pattern Discovery feature and customize profiles through ArcSight Pattern Discovery™ Guide. This document outlines a system called ArcSight FraudView, which is designed to help analysts identify and investigate suspicious transactions quickly. It features an annotation tool that allows analysts to mark transactions as "of interest," making it easy for other team members to follow up on these investigations. The system can automatically create cases when specific rules are triggered, allowing for case management with escalation paths if needed. Case metrics like time to resolution and analyst performance can be reported operationally. Additionally, the system integrates with external case management solutions and has a built-in notification engine that alerts relevant parties about rule firings, including configurable escalation procedures. ArcSight FraudView is particularly useful for detecting fraud by analyzing access patterns from IP addresses and account activities linked to OFAC blacklisted countries. This document outlines several use cases focused on detecting fraudulent activities related to Social Security Numbers (SSN), account lockouts, successful logons from Russian Business Network (RBN) assets, suspicious account registrations at unusual times, registrations from countries of concern, and accounts created using public email addresses. Each use case serves a specific purpose: 1. **Fraudulent SSN Use Case**: This involves identifying attempts to open an account with a fraudulent SSN. 2. **Account Lockout Detected Use Case**: It aims to identify when account lockouts occur due to suspicious activities. 3. **Account Logon from RBN Use Case**: This use case detects successful logons from assets within the Russian Business Network address ranges, which are categorized in specific ArcSight groups and categories. 4. **Account Registration at Suspicious Time Use Case**: This is designed to detect accounts created during unusual or suspicious times of day, specifically between 8:00 p.m. and 6:00 a.m. on weekdays, as well as all day on weekends. The device receipt time of the event must meet the criteria specified in the Suspicious Time of Day filter for detection. 5. **Account Registration From Country of Concern Use Case**: This use case identifies account creations originating from countries considered to be hotbeds of fraud based on historical data. 6. **Account Registration from RBN Use Case**: It focuses on detecting successful account creations from assets categorized in the Russian Business Network, as defined by specific ArcSight groups and categories. 7. **Account Registration Using Public Email Use Case**: This aims to identify accounts created using public email addresses, which are often associated with less secure or fraudulent activities. Each use case provides a method for identifying potential fraudulent activity based on unique criteria related to the type of fraud being detected. This document outlines several use cases for identifying potential fraudulent activities in ArcSight FraudView v1.0.1. The use cases include: 1. **Brute Force Login Success**: Detects when an account successfully logs in after a brute force attack within one minute of the attack. 2. **Excessive Wire Transfers to Same Payee**: Identifies when three or more payments are made from the same account to a specific payee within five minutes. 3. **Geographic Disparity of Account Access**: Monitors if an account is accessed from more than one country within an hour, indicating potential fraud. 4. **Login from Known Fraudulent Address**: Detects when an account has been accessed from a known fraudulent IP address, suggesting compromised credentials. 5. **Multiple Accounts Paying Same Payee**: Identifies when three different accounts pay the same payee within five minutes, which may indicate money laundering or collusion. 6. **Multiple Failed Logon Attempts**: Detects multiple failed login attempts to the same account within one minute, indicating potential hacking attempts. 7. **Multiple Password Resets**: Monitors when a password has been reset three times for the same account within twenty-four hours, which could signal unauthorized access or fraud. 8. **Multiple Transactions by Same User**: Detects when a single account makes five transactions (payments or wire transfers) within one minute, potentially indicating fraudulent activity. The provided text summarizes various use cases and their purposes from a guide titled "ArcSight FraudView v1.0.1 Guide." Here's a consolidated summary of each use case: 1. **Password Reset Not Preceded by Lockout**: This use case aims to identify instances where a password reset occurs without any preceding lockout event, possibly indicating an unauthorized access attempt or compromised account. 2. **Payee Created and Paid - Same User**: The purpose of this use case is to detect when a payee is created and subsequently paid by the same user within the same transaction or time frame, which could indicate fraudulent activity such as creating fictitious payees for illicit payments. 3. **Payee Created and Paid - Suspicious Time**: This use case identifies situations where a payee is both created and paid by the same user within two minutes during a suspicious time of day, suggesting potential fraud or manipulation in transactions. 4. **Paying Suspicious Payee**: The purpose of this use case is to detect payments issued to suspected fraudulent payees, indicating possible financial misappropriation. 5. **Successful Login from Country of Concern**: This use case identifies successful logins that originate from countries considered a risk or concern for fraud or suspicious activities. 6. **Successful Login from Suspicious Address**: This use case detects successful logins from IP addresses associated with suspicious activity, which could be indicative of unauthorized access or malicious intent. 7. **Transaction Behavior Anomaly**: The purpose of this use case is to identify anomalies in the transaction behavior of accounts with a low number of weekly transactions (typically 10 or fewer). Specifically, it checks if the sum of today's transactions exceeds three times the total transaction amount from the previous week or if the number of transactions executed today is more than three times the number of transactions from the entire previous week. 8. **Transfers Just Under Violation Threshold**: This use case monitors wire transfers that are slightly below a predefined violation threshold, potentially signaling an attempt to circumvent detection mechanisms for suspicious activities. Each of these use cases serves as a tool in fraud prevention and detection, aiming to identify potential fraudulent behaviors by analyzing patterns and anomalies within financial transactions. The text provides an overview of various use cases supported by "FraudView" software, focusing on different aspects of financial transactions and activities that might indicate fraudulent behavior or non-compliance with regulations. Here's a summary of each use case mentioned in the document: 1. **Transfers Over Violation Threshold**: This use case is designed to detect when an account engages in three or more wire transfers for amounts exceeding the set violation threshold within a span of five minutes. The purpose is to identify potential fraudulent activities such as money laundering or rapid transactions aimed at evading detection. 2. **Card Used in Foreign Country**: This use case involves identifying credit card transactions that occur in a country different from where the account was originally created. This can indicate fraudulent behavior, such as theft of the card information or attempts to conduct transactions without authorization. 3. **Entitlements Violation Use Case**: It is intended to detect when an account engages in a transaction involving financial instruments (like bonds) that it is not legally entitled to trade. This helps prevent insider trading and other forms of unauthorized financial activity. 4. **Excessive Wire Transfer Requests**: The purpose of this use case is to identify instances where an account has executed more than three wire transfers with less than eight hours between each transaction. This might suggest rapid fire transactions that could be part of a fraudulent scheme or attempts at money laundering. 5. **Penny Stock Transactions**: This use case focuses on detecting any sell or purchase transaction involving over 100,000 units (such as stocks and options) where the unit price is less than $0.75 each. These transactions might indicate irregular trading patterns that could be linked to fraudulent activities like market manipulation. 6. **Trading Violation - Dollar Per Day Threshold - Purchased**: This use case monitors if a trader has exceeded the daily purchasing limit of 10,000,000 dollars. Exceeding this threshold might suggest aggressive trading strategies that could be indicative of fraudulent behavior or high-risk investment practices. 7. **Trading Violation - Dollar Per Day Threshold - Sold**: Similar to the above, but it monitors transactions where the trader has exceeded the daily selling limit of 10,000,000 dollars. This can help detect excessive trading and potential fraudulent activities in sales scenarios. These use cases are part of a broader set of tools designed by ArcSight™ FraudView to assist in detecting various forms of financial fraud and non-compliance across different industries including credit card transactions, investment banking, and more specialized areas such as penny stock trading. The provided text outlines four distinct use cases within the "Trading Violation" category of the FraudView product by ArcSight, designed to identify potential trading violations committed by traders in financial markets. Each use case serves a specific purpose and has its own set of parameters for evaluation: 1. **Single Transaction Dollar Threshold**: This use case is intended to detect if a trader has exceeded the dollar limit for a single transaction, which is preset at $500,000. It evaluates whether the value of a trade exceeds this threshold, potentially indicating suspicious trading activity. 2. **Single Transaction Units Threshold**: Focused on assessing transactions involving specific asset types like stocks, bonds, and options, this use case checks if the number of units (such as shares or contracts) traded in one transaction has exceeded 500,000 units. This helps identify possible trading irregularities beyond just monetary values. 3. **Transactions Per Day Threshold**: Designed to monitor the frequency of transactions conducted by a trader within a single day. The threshold here is set at 100 transactions per day, which could signal either normal activity or potential manipulation of transaction logs or actual trading activities. 4. **Units Per Day Threshold**: This use case specifically targets traders who engage in multiple transactions involving the same asset type daily. It checks if a trader has exceeded the limit for trading units per day, where the threshold is also set at 500,000 units across all relevant asset types. Each of these use cases contributes to maintaining regulatory compliance and ensuring fair practices within financial markets by identifying potential trading violations early on. The text then shifts focus to a chapter titled "Chapter 2: Installation and Configuration," detailing the steps necessary for installing and setting up FraudView, including verifying the environment, installing the software, configuring event field aliases, developing FlexConnectors for generating events, installing risk formulas, and downloading/installing a fraud monitoring dashboard. This setup is crucial for effectively deploying and operating the trading violation detection tool within an organization's infrastructure. This summary outlines the process for installing the ArcSight ESM product version v4.5 SP1, ensuring it meets all prerequisite requirements as detailed in the installation guide. It also addresses the specific steps to install FraudView within the ArcSight environment. The document provides a clear and sequential set of instructions aimed at facilitating the setup and integration of the FraudView solution package into the existing ArcSight ESM infrastructure. Key points from the text are: 1. **Prerequisites**: Before installing the software, ensure it meets all prerequisites for your operating system as outlined in the official documentation. 2. **Compliance Insight Packages**: Do not install Compliance Insight Packages on an ArcSight Manager; follow separate installation procedures specific to each package type. 3. **FraudView Installation**: Download the FraudView solution bundle from the provided link, ensuring compatibility with the version installed and matching the specified build number found in the release notes. 4. **Downloading and Importing**: Use Internet Explorer or a compatible browser to download the ARB file; if it converts to ZIP, rename it back to ARB before importing. Log into the ArcSight ESM Console with administrative privileges, navigate to the Packages tab, import the package bundle file, and follow progress updates during installation. 5. **Checkbox Selection**: During the install process, ensure the FraudView 1.0.1 checkbox is selected for inclusion in the installation. Proceed through the dialogs, checking the Progress tab for any errors or issues during the setup phase. The summarized text outlines a process for installing and configuring ArcSight FraudView v1.0.1 within an organization's system. Here are the key steps and considerations mentioned in the original content: 1. **Installation Process**:

• Open the ArcSight ESM Console and navigate to the "Install" section.

• Complete the installation process by following any on-screen prompts or dialogs, which include an Importing Packages dialog.

• After completion, check the "Results" tab of the Installing Packages dialog for a summary report indicating successful installation.

2. **Verification**:

• To ensure that the content is accessible in the Navigator panel, expand the ArcSight Solutions/FraudView 1.0.1 group after installation.

3. **Troubleshooting**:

• If the installation does not succeed, contact ArcSight technical support via their support website: https://support.arcsight.com.

4. **User Permissions**:

• Default user groups can view FraudView content, while users in the ArcSight Administrators and Analyzer Administrators user groups have read and write access to it. Adjust these permissions based on your organization's setup.

5. **Assigning User Permissions**:

• Log into the ArcSight ESM Console with an administrative account.

• For each of the listed resource types (Active channels, Active lists, Cases, Dashboards, Data monitors, Field Sets, Filters, Queries, Reports, Rules, Session Lists, Trends), adjust user permissions in the Navigator panel under the ArcSight Solutions/FraudView 1.0 path.

This summary provides a clear and concise overview of how to install and configure FraudView within an organization's infrastructure, ensuring proper access and administrative control for specific resources. To install ArcSight ESM Console utility files from a ZIP archive, follow these steps: 1. **Access and Edit Access Control List (ACL)**:

• Click on "FraudView 1.0" group in the interface.

• Select "Edit Access Control" to open the ACL editor in the Inspect/Edit panel.

• In the ACL editor, choose which user groups should have specific permissions for the FraudView active channels and click OK.

2. **Install Utility Files from ZIP**:

• You can either download and install these files individually or use a batch process by downloading the "FraudView_Console_Update.zip" file.

• If you choose to download the zip, follow these steps:

• Log into the ArcSight ESM Console with an administrative account.

• Download the "FraudView_Console_Update.zip" file from the Resources tab in the Navigator panel under "ArcSight Solutions/FraudView 1.0/Console group".

• Right-click on the zip file and select the "Download" option. Browse to a temporary directory location, such as your Desktop, and click Save. A copy of the file will be saved to your local file system.

• Log out of the ArcSight ESM Console.

• On the system running the ArcSight ESM Console, navigate to the directory containing the original "security_event_strings.properties" file. For example, on Windows, this would be: `C:\arcsight\Console\current\i18n\common`.

• Rename the existing "security_event_strings.properties" file to another name such as "security_event_strings.properties.original".

• Extract the contents of the "FraudView_Console_Update.zip" into the current directory where you renamed the original file. This will replace the necessary files with those from the zip archive.

The article discusses the configuration of the ArcSight ESM Console, specifically addressing how to set up Event Field Aliases using a file named "security_event_strings.properties." This file is provided with FraudView and maps specific event field labels in the ArcSight ESM schema to financial transaction-related terms. For instance, before installing this file, the attribute labeled "Attacker User Name" appears as "Account Id" after its installation. Table2-1 provides a summary of these new FraudView event labels, their underlying attributes and group names from the security_event_strings.properties file, along with the original labels displayed in the ArcSight ESM Console prior to the fraudview integration. The provided text outlines a procedure for installing a properties file on an ArcSight Manager in order to view and use FraudView event field labels within the ArcSight ESM Console. Here's a summarized version of the steps involved: 1. Log into the ArcSight ESM Console with an account having administrative privileges. 2. Navigate to the directory where the properties file is located, specifically under "ArcSight Solutions/FraudView 1.0/Manager/i18n/common group." 3. Download the security_event_strings.properties file by right-clicking and selecting 'Download'. 4. Save the downloaded file to a temporary directory on your local system (e.g., Desktop). 5. Exit any connected ArcSight ESM Consoles, then shut down the ArcSight Manager. 6. Locate the directory containing the default security_event_strings.properties file and navigate to it. 7. Follow these steps for importing an alias file into the ArcSight ESM Console: a. Log in with administrative privileges. b. From the Resources tab, go to Files and then to "ArcSight Solutions/FraudView 1.0/Manager." c. Navigate to the i18n directory and find the alias file you want to import. d. Right-click on the alias file and select 'Import'. e. Follow through with any prompts or necessary configurations, ensuring that the imported file is correctly linked for use in the ArcSight ESM Console. To import a `security_event_strings.properties` file into the ArcSight ESM Console, follow these steps: 1. **Log in to the ArcSight ESM Console** using an administrative account. 2. **Download the security_event_strings.properties file**:

• Navigate to `ArcSight Solutions/FraudView 1.0/Console/i18n/common`.

• Right-click on the file and select "Download". Choose a temporary directory, such as your desktop, to save the downloaded file.

3. **Log out of the ArcSight ESM Console**. 4. On the system running the ArcSight Manager:

• Rename the existing `security_event_strings.properties` file to another name (e.g., `security_event_strings.properties.original`).

• Copy the downloaded `security_event_strings.properties` file from the temporary directory into the `i18n/common` directory.

5. **Start the ArcSight Manager** and it will automatically detect the updated `security_event_strings.properties` file. These steps ensure that the alias file is properly imported into the ArcSight ESM Console for use in managing security events. ArcSight FraudView v1.0.1 requires administrative privileges to access the Inspect/Edit panel, where specific labels for event fields are displayed. To implement this tool, one must develop FlexConnectors capable of monitoring financial applications like money transfers and generating events related to these transactions. These FlexConnectors should follow guidelines in the ArcSight™ FlexConnector Developer’s Guide, ensuring parsers generate events with accurate field mappings, names, and categorizations. For each event type, there is a corresponding filter that matches its requirements; for instance, Wire Transfer events must be named "Wire Xfer Request." The text discusses how certain resources and filters in ArcSight Confidential's ArcSight™ FraudViewv1.0.1 must be customized for specific environments based on different requirements for Event Types. These include custom naming (e.g., Wire Transfer events named "Wire Xfer Request") and categorization (e.g., Account Access Attempt events with Category Behavior set to /Authentication/Verify and Category Device Group set to /Application/YOUR_APPLICATION_TYPE, where YOUR_APPLICATION_TYPE is customized). Additionally, for certain events like Account Access Failure, both naming and categorization must be specified. The text emphasizes the importance of generating events with category settings for better functionality and suggests referring to "Set the Category Device Group" on page 27 for more information. Table 2-1 outlines the expected Event Types that FraudView content expects from FlexConnector(s) monitoring financial applications, with each event type having specific requirements. This document outlines requirements and steps for generating specific types of events related to potential fraud or unauthorized access attempts within a monitored application. The primary focus is on setting up filters and using FlexConnectors to identify particular event types, such as failed logon attempts, which are indicative of possible fraudulent activities. For each type of event (e.g., failed logons), the document provides detailed instructions:

• **Event Type**: Specifies whether to use events generated by a specific application or to create new ones that describe failed access attempts.

• **Category Device Group**: Requires setting a unique string identifier for each application type being monitored, which helps in categorizing and filtering these events.

• **Country Code Mapping**: Mandates mapping the country code where the attempted access originated to the `attackerGeoCountryCode` field. This is crucial for geographical analysis of potential fraud attempts.

The document also provides a table (Table2-2) summarizing expected event types, their associated filter conditions, and requirements such as not null Account Id checks. It includes notes about default filters checking for non-null Account Ids unless specified otherwise for simplicity. This setup is crucial for early warning systems like FraudView to promptly detect and respond to potential threats by analyzing the patterns and characteristics of these events, which are often indicative of fraudulent activities. To configure ArcSight FraudView for monitoring account access attempts, follow these steps under the "Event Requirements" section in the guide. Ensure that you set up filters and FlexConnectors as specified to reflect successful or failed login attempts for specific applications. Here's a summarized version of what is required: 1. **Set Event Type Filters**:

• Filter by Account (Name = Login OR Name = Logon) to capture both successful and unsuccessful logon events. If the event names are already set as such, no further action may be necessary.

2. **Configure Category Device Group**:

• For failed attempts, set the Category Device Group to a unique string specific to the application type (e.g., /Application/YOUR_APPLICATION_TYPE).

• For successful attempts, also set the Category Device Group to reflect the application type.

3. **Map Country Code and IP Address**:

• Map the country code of the access attempt origin to the attackerGeoCountryCode field.

• Map the originating IP address to the attackerAddress field.

4. **Account ID Mapping**:

• Map the account that the access was directed at (e.g., Account Id) to the attackerUserName field for both successful and failed attempts.

5. **Outcome Specification**:

• In the Category Outcome, specify either /Success or /Failure based on whether you are looking to monitor successful or failed logon events.

6. **FlexConnector Configuration**:

• Use FlexConnectors to generate events that reflect account access attempts in monitored applications. If the event names do not change (Login or Logon), no updates may be required for the filter.

By following these steps, you can effectively configure ArcSight FraudView to monitor and analyze failed and successful logon attempts across various application types. ArcSight Confidential ArcSight™ FraudView v1.0.1 Guide provides a detailed guide on how to set up filters for monitoring and detecting fraudulent activities in applications. The setup involves creating or editing filters based on specific events, such as new account creation requests and lockouts. For each type of event, the guide recommends mapping certain fields from the source data to predefined fields in FraudView: 1. **New Account Creation Request**:

• Map the attacker's IP address (attackerAddress) to the "Event Source Address" field for tracking where the access attempt originated.

• Map the Social Security Number of the account owner to the "Social Security Number (deviceCustomString4)" field.

• Map the creation time of the account to the "Device Receipt Time" field.

• Map the email address of the account owner to the "Account Id (attackerUserName)" field.

2. **Account Lockout**:

• Generate events with names that reflect lockout actions in the monitored application.

• Map the locked-out account to the "Account Id (attackerUserName)" field.

3. **ATM Authentication**:

• Similar to Account Lockout, generate events named appropriately for ATM authentication activities.

The guide also emphasizes that by default, all filters check if the Account ID is not null, which should be considered in setting up filters unless explicitly stated otherwise. It suggests customizing the filter conditions according to the specific application being monitored, ensuring unique strings are used in Category Device Group and Event Type settings for differentiation between different types of applications or events. This setup helps in creating a more targeted monitoring system that can identify patterns associated with fraudulent activities efficiently within the specified application environments. This document provides instructions for configuring filters in ArcSight FraudView, specifically tailored for monitoring ATM authentication and credit card transactions. Here is a summary of the key points: 1. **ATM Authentication Filter Configuration:**

• The filter should be named after an event related to ATM authentication. If the default name "ATM Authentication" is used, no changes are needed; otherwise, set it accordingly.

• Map the country code where the access attempt originated to the "attackerGeoCountryCode" field.

2. **Credit Card Transaction Filter Configuration:**

• Generate transaction events named RETAIL TXN, ATM TXN REV, CREDIT VOUCHER, or ATM TXN. If these names are already used, no updates are required for the filter.

• Map the account making the payment to the "Account Id" (attackerUserName) field.

• Ensure the event name is not equal to "ANNUAL MEMBERSHIP FEE" or "INTEREST."

• Map the transaction amount to the "Currency Amount (devicecustomstring2)" field.

• Map the country code where the transaction was made to the "Payment Country" (targetNttdomain) field.

3. **Password Reset Filter Configuration:**

• Generate events with a name related to password resets. If the default name "Password Reset" is used, no changes are needed; otherwise, set it accordingly.

• Map the account initiating the transaction to the "Account Id" (attackerUserName) field.

4. **Payee Created Filter Configuration:**

• Generate events with a name related to payee creation. If the default name "Payee Created" is used, no changes are needed; otherwise, set it accordingly.

These filters help in monitoring specific actions and transactions within the application, ensuring that they align with defined criteria for fraud detection or other security measures. This document outlines the setup and conditions for specific filters within a monitoring system, known as FlexConnectors, designed to detect and analyze certain financial events in real-time. These filters are configured to monitor events related to creating new payees, issuing payments (like ACH transactions), and buying or selling products. **Payee Creation Filter:** 1. **Event Type**: The filter is triggered by events named Payee Created or New Payee Created. It checks that the Account Id is not NULL and maps this to the AttackerUserName field. Additionally, it ensures the Payee Company field (targetProcessName) is populated with the name of the payee, provided the event's Company is not NULL. 2. **Payment Issued Filter:**

• Event Type: Triggered by events named Payment Issued or New ACH Payment. It checks that both the Currency and Payee Company fields are not NULL and maps the Account Id (AttackerUserName) and Payee Company (targetProcessName) fields from the event. The amount paid is mapped to the Currency Amount (deviceCustomString2) field.

3. **Purchase Events Filter:**

• Event Type: Triggered by events named Buy. It checks that the Account Id is not NULL, maps it to the AttackerUserName field, and also processes the Currency Amount (deviceCustomString2) and Units fields based on the payment details of the purchase.

Each filter requires configuration adjustments if the default event names do not match those specified in the setup process. The filters are crucial for real-time monitoring and analysis of financial transactions within the application they are integrated into, ensuring compliance with established data mappings and integrity checks. This document provides instructions for configuring filters in ArcSight FraudView to detect specific financial events, such as sell actions and wire transfer requests. Key details include: 1. **Event Types**:

• **Sell Events**: The name of the event should reflect a sell action. By default, it supports Bond, Equity, Future, and Option types. The account making the sell should be mapped to the Account Id (attackerUserName) field, while the amount received is mapped to the Currency Amount (deviceCustomString2) field, and the number of units sold is mapped to the Units (deviceCustomNumber1) field.

• **Wire Transfer Events**: The name of the event should reflect a wire transfer request. The account making the payment (transfer) should be mapped to the Account Id (attackerUserName) field, while the name of the company which accepted the payment is mapped to the Payee Company (targetProcessName) field and the amount paid is mapped to the Currency Amount (deviceCustomString2) field.

2. **Default Filter Conditions**: By default, all filters check that the Account Id Is NOT NULL. This condition is not explicitly shown in the provided text for simplicity but should be considered when setting up the filter. 3. **General Event Requirements**: Only one event per type should be processed by the system to avoid duplication or false positives. RaudView is a system designed to generate only one event for each transaction, such as when a user logs into an account through a web portal. It ensures that only one "Account Access Attempt" event is created regardless of whether it's generated by the web application, back-end system, or both. This rule applies specifically to financial applications handling transactions like Credit Card Transactions, Payments Issued Transactions, Purchasing Transactions, and Wire Transfers. The name of the event must match the specified name in the Required Event Settings column. Additionally, if a Category Device Group is required for an Event Type as per Table2-2, FlexConnectors should set this group to reflect the monitored application(s), replacing "YOUR_APPLICATION_TYPE" with the specific financial application type or types being monitored. The article discusses configuring FraudView in a network security system by customizing FlexConnectors and setting the Geo Country Code, as well as installing the Risk Formula. It recommends creating multiple FlexConnectors with different Category Device Groups for specific applications like ATM and OnlineBanking, then applying customized Event Type filters to trigger events based on these settings. To implement this: 1. Develop two or more FlexConnectors, each assigned to a distinct Category Device Group (e.g., /Application/ATM and /Application/OnlineBanking). 2. Set up Event Type filters that will activate for either of the specified Category Device Groups. 3. Ensure only the relevant applications contributing to FraudView content generate events with the designated Category Device Group settings, maintaining uniqueness for these specific monitored applications. 4. If IP resolution confirms the originating country, set the Geo Country Code automatically within the event data. 5. Download and install the Risk Formula file provided separately on the ArcSight Manager installation. This formula includes filters that determine risk levels based on factors such as Destination Risk, Transaction Risk, Account Severity, and Device Risk. 6. Reference these Risk Modeling filters in the FraudView Risk formula to assign appropriate priority levels when processing financial transaction events through ArcSight ESM. The article discusses a method for assigning an overall priority rating to events based on various factors that contribute to their numeric value in a priority formula. Each factor contributes to this calculation, and all values range from 0 to 10, with higher numbers indicating greater importance or urgency. A high priority factor generally suggests a higher risk level; however, not every high-priority event is necessarily a threat. The score for a risk factor is cumulative and determined by the filters associated with that factor. For instance, if an event matches multiple filters (like both Suspicious Bank and Top Loss MCC in the Destination Risk factor), its score will be the sum of individual filter scores, with no value exceeding 10. If qualifying conditions exceed this limit for a risk factor, only the maximum possible score of 10 is considered. The overall risk formula is calculated based on the average score of four main factors: Destination Risk, Transaction Risk, Account Severity, and Device Risk. The Risk Score assigned to a transaction can be customized in the ThreateLevelFormula.xml file, which also provides more details on downloading, customizing, and installing the risk formula for further reference. The article discusses a priority formula for assessing risk factors in financial transactions, focusing on specific filters that impact the "Destination Risk" factor. These filters include checking if an event matches entries in the Suspicious Bank active list to add a score of 4, doing the same for the Suspicious Payment Country and adding another 4 points based on the Payee Company entry in the Suspicious Payee active list, or giving 6 points by matching the MCC Code with entries in the Top Loss Makers - MCC active list. Additionally, if a transaction occurs in a country different from where the account was created, it triggers an event that adds another 4 points to the Destination Risk factor. All these filters are part of the ArcSight Solutions/FraudView/Risk Modeling/Destination Risk group and can be configured by adding names of suspicious banks, countries, or payees to their respective active lists. For instance, the Suspicious Bank active list is located in ArcSight Solutions/FraudView/High Risk/Destination Risk, while the Countries of Concern and Top Loss Makers - MCC active lists are also managed within this framework for effective risk management in financial transactions. The text discusses several active lists and their maintenance within a system called ArcSight FraudView. Here's a summary of each list mentioned: 1. **Country of Concern Active List**: This list starts with initial values but requires regular updates. It is referenced for specific use cases related to successful logins from countries considered problematic or risky. For more details, refer to "Successful Login from Country of Concern Use Case" on page 78. 2. **Top Loss Makers - MCC Active List**: This list includes merchants known for having the highest amount of loss due to credit card transactions. The Merchant Category Code (MCC) is added to this list, which is located in a specific group within ArcSight Solutions called "FraudView/High Risk/Destination Risk." 3. **Account Country Active List**: This list contains Account Numbers linked with their respective Country Codes. Each entry includes the account number and the country where the account was created. The list is situated in the "ArcSight Solutions/FraudView/Book Keeping/Account Country" group. 4. **Suspicious Payee Active List**: Automatically populated by a rule, this list identifies payees that are considered suspicious based on various criteria not detailed in the text. Additionally, there's information about how Risk Modeling filters determine the score of the Transaction Risk factor in the priority formula:

• **High Risk Transaction**: If an event matches the High Risk Transaction filter, 10 points are added to its Transaction Risk factor score. This is based on whether the event name corresponds with any transaction types listed in the High Risk Transaction active list.

• **Medium Risk Transaction**: If an event matches the Medium Risk Transaction filter, 5 points are added to its Transaction Risk factor score. The criteria for matching against the Medium Risk Transaction active list is similar to that of High Risk Transactions.

• **Low Risk Transaction**: If an event matches the Low Risk Transaction filter, 2 points are added to its Transaction Risk factor score. This filter also checks if the event name corresponds with any transaction types listed in the Low Risk Transaction active list.

These lists and their associated filters play crucial roles in risk assessment and fraud detection within the ArcSight FraudView system. The document outlines how to configure risk factors for transaction analysis using ArcSight FraudView, focusing on high, medium, low-risk transactions and account severity scores. To include these risks in a priority Risk formula, active lists must be configured with specific names of transactions categorized by their risk levels. These are located within the group: 1. **High Risk Transaction Active List**: Add names of high-risk transaction entries to this list. 2. **Medium Risk Transaction Active List**: Add names of medium-risk transaction entries to this list. 3. **Low Risk Transaction Active List**: Add names of low-risk transaction entries to this list. These active lists are found in the group:

• ArcSight Solutions/FraudView/High Risk Attributes/Transaction Risk.

The scores associated with high, medium, and low risk transactions can be adjusted in the "ThreatLevelFormula.xml". However, for detailed information on downloading, customizing, and installing the Risk Formula, refer to another document. For account severity scoring, a set of filters determine the score based on three criteria:

• **Account in Investigate List**: If the Source User Name matches any Account Id in the Investigate List active list, 10 points are added to the Account Severity factor score.

• **Account in Suspicious List**: If the Source User Name matches any Account Id in the Suspicious Accounts active list, 5 points are added to the Account Severity factor score.

• **Account in Watched List**: If the Source User Name matches any Account Id in the Watched Accounts active list, 2 points are added to the Account Severity factor score.

These filters and their associated actions can help in assessing and prioritizing risks related to transactions and accounts as per the defined criteria within ArcSight FraudView. The document outlines configuration and usage guidelines for various risk factors within ArcSight Solutions, specifically focusing on FraudView, Risk Modeling, and Account Risk modules. Key points include: 1. **Account Severity Risk Factor**:

• Automatically populated lists such as Investigate List, Suspicious Accounts, and Watched Accounts are used to categorize accounts based on predefined rules.

• Initial population can be done using suspicious Account IDs.

• Adjustment of scores associated with account severities in the ThreatLevelFormula.xml is optional but recommended for customization.

2. **Device Risk Factor**:

• Determined by a set of ArcSight ESM System Core and Risk Modeling filters:

• Adding points to the Device Risk factor score based on matches with specific active lists:

• Attackers on Infiltrators List (6 points)

• Attackers on Hostile List (5 points)

• Attackers on Suspicious List (3 points)

• Attackers on Reconnaissance List (1 point)

• These filters check for matches between the Attacker Address and Attacker Zone of an event with entries in predefined active lists.

• All filters are System Core filters, indicating their fundamental role in risk assessment within the system.

This document provides detailed instructions for configuring and utilizing these risk factors to enhance security measures and incident response capabilities in ArcSight Solutions. The text describes how different types of events are assessed for risk based on specific criteria, using a scoring system that increases the "Device Risk factor" score by adding points to it. These criteria include matching event data with pre-defined filters like Country of Concern, Known Fraudulent Address, Known Hostile Address, OFAC Blacklist, and Suspicious Address. Each filter corresponds to a list or database maintained within ArcSight systems: 1. **Country of Concern**: If the source geographical country code of an event matches any entry in the "Countries of Concern" active list, it adds 4 points to the Device Risk factor score. This is checked against a predefined list for identifying potentially risky events based on their origin. 2. **Known Fraudulent Address**: If the attacker's address and zone match any entry in the "Known Fraudulent Address" active list, it increases the risk score by 10 points. This filter helps identify known malicious IP addresses or domains that are associated with fraudulent activities. 3. **Known Hostile Address**: Similar to Known Fraudulent Address, this adds 4 points if there's a match in any of the following System active lists: "Hostile List", "Infiltrators List", "Reconnaissance List", and "Suspicious List". These are part of the ArcSight System/Threat Tracking group and indicate potential hostile activities. 4. **OFAC Blacklist**: If the attacker's geographical country code matches any entry in the "OFAC Blacklisted Countries" active list, it adds 4 points to the risk score, aligning with sanctions imposed by organizations like OFAC (Office of Foreign Assets Control). 5. **Suspicious Address**: The originating IP address of an event that matches any entry in the "Suspicious Accounts" active list increases the risk factor by 4 points. This filter helps detect accounts associated with suspicious activities, which could be indicative of fraudulent or malicious behavior. These filters are part of either Core (System) or Risk Modeling components within ArcSight solutions:

• **Core/Threat Level Filters**: These include Country of Concern, Known Fraudulent Address, Known Hostile Address, and OFAC Blacklist. They are installed by default with ArcSight ESM.

• **Risk Modeling/Device Risk**: This includes all the filters mentioned above except for the Country of Concern, which is specifically in Core filters. These are part of the FraudView module and used for risk modeling based on identified threats.

The system checks these criteria to assess potential risks associated with various events, allowing for targeted action and improved security measures. This text is about configuring device risk factors using the ThreatLevelFormula.xml file in ArcSight, a security management tool. The process involves maintaining specific lists such as Country of Concern and OFAC Blacklisted Countries active lists, which should be updated regularly. These lists are populated by rules or can be manually added. Additionally, there is an option to download, customize, and install the FraudView ThreatLevelFormula.xml file, which contains the risk formula for assessing device risks. This file needs to be downloaded from the ArcSight ESM Console, customized if necessary, and installed on your ArcSight Manager installation. Instructions include logging in with administrative privileges, navigating to the specific directory, downloading the file, saving it to a temporary location, and optionally editing the file to adjust risk scores based on certain filters. For example, in the ThreatLevelFormula.xml file, adding a value of 4 to the Device Risk score is specified for events that match the OFAC Blacklist filter. This customization allows users to fine-tune how risks are assessed and prioritized within the ArcSight FraudView system. The provided text is an XML snippet from a resource management system, likely part of a software or hardware configuration involving fraud detection and monitoring tools. It seems to be discussing how to adjust settings in a risk model for transactions originating from countries on the OFAC blacklist, which could include sanctions lists maintained by the U.S. Department of Treasury's Office of Foreign Assets Control (OFAC). The instructions are intended for users who need to modify configuration settings within an ArcSight ESM (Extended Security Manager) system to prioritize events that may indicate fraudulent transactions from such countries. The text also provides a step-by-step guide on how to install and configure the Fraud Monitoring Dashboard, which is part of the ArcSight FraudView solution for detecting potential fraud in transaction activities. This involves downloading and installing specific files into designated directories, using administrative privileges within the ArcSight ESM Console. It's important to note that this tool should be used as a supplement and not as a replacement for an established ArcSight ESM deployment. Here is a summarized version of the information provided in the text: 1. Adjust the priority of events based on transaction origin countries using the OFAC blacklist by modifying the Value attribute in the Risk Modeling/Device Risk/OFAC Blacklist resource URI. 2. Follow specific steps to shut down and reconfigure an ArcSight Manager system, including navigating through directories to modify a default configuration file. 3. Install the Fraud Monitoring Dashboard from a specified path within the ArcSight ESM Console by downloading and installing a particular .jlx file. 4. The installation of the Fraud Monitoring Dashboard is optional but recommended for enhanced fraud detection capabilities. To update ArcSight ESM Console with Fraud Monitoring functionality, follow these steps after downloading and extracting FraudView_Console_Update.zip as described in the guide: 1. **Extract Files**: Unzip the FraudView_Console_Update.zip file to access the Fraud Monitoring.jlx file among other resources. 2. **Download Specific Files**: Right-click on the Fraud Monitoring.jlx file and select "Download" to save it locally. Download the security_event_strings.properties file as well. 3. **Navigate and Organize Files**:

• Browse to the ArcSight ESM Console installation directory, typically at C:\arcsight\Console\current\.

• Inside this directory, navigate to lib\resources\views.

• Create a new folder named "Fraud Monitoring" within lib\resources\views.

• Save the Fraud Monitoring.jlx file into this newly created Fraud Monitoring folder.

4. **Download Additional Files**: Download the Fraud Monitoring.properties and fraud.jpg files, placing them in the Fraud Monitoring folder. 5. **Exit ArcSight ESM Console** to proceed with configuration changes on the local system. 6. **Edit AST File**: Open the .ast file loca,ted in C:\arcsight\Console\current\ using a text editor. 7. **Update Property**: Ensure or add the property console.ui.imageEditor set to true within the AST file. 8. **Activate Channel**: From the ArcSight ESM Console, go to Active Channels and show the FraudView/Fraud Monitoring active channel. This will display non-correlated events over the last two hours. 9. (Continued) The guide does not mention further steps after activating the channel; however, continue monitoring and troubleshooting as necessary based on the displayed data. To summarize, you need to follow these steps in ArcSight™ FraudView v1.0.1: 1. Open the Viewer panel and go to "Image Viewer > Fraud Monitoring." 2. The viewer will show five graphical summary views of active channels. 3. To see detailed information about an active channel, double-click on its chart. For example, double-click a chart related to possible fraudulent activity. 4. The underlying active channel that provides the event data for the chart will be displayed in detail. This active channel shows all relevant events based on the associated filter. 5. The active channels summarized in the Fraud Monitoring Dashboard are filtered by specific criteria listed in Table2-3, which includes:

• Transactional Activity (shows transactional events from financial applications)

• All Fraud Correlation Events (shows possible fraudulent activities)

• Watched Account Additions (shows account additions to a watched list)

• Suspicious Account Additions (shows suspicious account additions or escalations)

• Fraudulent Accounts Investigate List (shows potential fraudulent account additions or escalations).

This guide outlines how to set up and configure FraudView for use in detecting fraud, including instructions for deploying rules, configuring account escalation, setting up cases, configuring notifications, pattern discovery, and defining use cases. To deploy FraudView rules, navigate to the Rules section within the Navigator panel, find the ArcSight Solutions/FraudView 1.0 group, right-click it, and select "Deploy Real-time Rule(s)". This action creates a new group that is linked to the original one, serving as a link for deploying FraudView rules. For more detailed information on this process, refer to the online help in the ArcSight Console. FraudView allows users to monitor suspicious account activity through custom escalating lists and rules. The configuration of these lists and rules can be tailored according to specific needs. Detailed instructions are provided under "Configure Account Escalation—Optional" for further customization. Cases within FraudView serve as trouble tickets, which can interact with third-party systems or be used in their default form. Users have the flexibility to add more groups to this system if required. Finally, configuring notifications involves setting up alerts based on specified conditions and sending them accordingly. Pattern discovery helps identify unusual patterns of behavior by comparing data against pre-defined criteria, while defining use cases allows users to customize rules for specific scenarios or threats. To enhance the ArcSight FraudView solution and improve its ability to detect fraudulent behavior, users are advised to modify the existing ArcSight FraudView rules. These modifications involve creating new case groups or customizing existing ones to better suit the specific types of suspicious activities they wish to track. By default, the rules within the FraudView Early Warning group do not directly alert about possible fraudulent actions; instead, they feed events into an account escalation process that monitors accounts for signs of suspicious behavior. This process utilizes a series of tracking lists and escalation rules to generate cases based on these indicators. The specific rules responsible for case generation are: 1. Add to Suspicious Accounts List 2. Add to Fraud Investigate List For more tailored detection, users can customize the rules that respond to particular suspicious behaviors. For instance, if excessive file transfers to the same payee indicate potential fraudulent activity, modify the Excessive Wire Transfers to Same Payee rule to include a case creation action. This customization allows for greater flexibility and specificity in alerting systems to specific types of risky behavior. In addition to generating cases, users can also configure notifications for suspicious activities as part of the account escalation process. The rules responsible for notification generation are: 1. Add to Suspicious Accounts List 2. Add to Fraud Investigate List For more detailed information on customizing these rules and configuring notifications, refer to specific sections within the documentation, such as "Customize Escalation Rules," which is located at page 47 of the provided material. This customization enables users to fine-tune their fraud detection strategy according to their organization's particular needs and risks. In order to enhance security and monitor specific activities within a system or network, such as excessive file transfers to the same payee, rules can be edited to generate notifications. This involves modifying the "Excessive Wire Transfers to Same Payee" rule to include an action that triggers a notification. Additionally, administrators can create destinations for these notifications in the ArcSight Console. For detailed guidance on configuring this and other related features like Pattern Discovery profiles and use cases, refer to the relevant sections of the ArcSight™ FraudView Guide, including the Notifications topic in the ArcSight Console online Help, as well as specialized guides like the ArcSight Pattern Discovery™ Guide and Chapter 4 of the ArcSight FraudView Early Warning Use Cases. This summary provides detailed instructions for managing lists within ArcSight ESM (Enterprise Security Manager) using the console entry editor and importing CSV files. 1. **Using Console Entry Editor:**

• Navigate to "Lists" in the Navigator panel, then select the "Active Lists" tab.

• Go to "ArcSight Solutions/FraudView."

• Right-click the list you want to populate and select "Show Entries." The list details will appear in the Viewer panel.

• For each entry you wish to add, click the "add icon" in the list header within the Inspect/Edit panel, enter required fields values, and click "Add."

2. **Importing a CSV File:**

• Ensure that the number of columns in your active list matches the number of comma-separated values in the imported CSV file.

• Right-click on an active list in the ArcSight ESM Console's resource tree, choose "Import CSV File."

• Browse to select the desired CSV file and click "Open." The Import Preview dialog will display the data from the CSV file.

• In the Import Preview dialog, click "OK" to add the entries from the CSV file to the active list.

These methods allow for managing lists efficiently within ArcSight ESM by either adding entries manually or importing them from a CSV file. The provided text discusses the process of tracking and escalating accounts exhibiting suspicious behavior in ArcSight™ FraudView. It explains how accounts are monitored using a set of active lists and rules called "account escalation." Accounts with suspicious behaviors are added to specific lists automatically based on predefined rules:

• **Watched Accounts**: These are for accounts that may be concerning or could become so if the behavior persists. They represent the lowest level of concern.

• **Suspicious Accounts**: These have a medium level of concern, indicating potential issues that need attention.

• **Investigate List**: The highest level of concern, these accounts require immediate investigation due to their suspicious behaviors.

The process involves adding and escalating suspicious accounts automatically using the following rules: 1. Add to Watched Accounts List 2. Add to Suspicious Accounts List 3. Add to Fraud Investigate List This system helps in monitoring and managing accounts with potential fraudulent activities efficiently, ensuring that they are tracked appropriately based on their level of concern. The process of escalating accounts from one tracking active list to another involves two main rules, which determine if an account should be moved between "Watched Accounts" and "Suspicious Accounts." Initially, an account is considered trusted until it exhibits any low level suspicious behavior, such as being created from a country of concern. **How Accounts Get on the Watched Accounts Active List:** 1. An event indicating low-level suspicious activity occurs for the account. For example, if an account is created from a country deemed a concern, this triggers specific rules to activate and add the account to the "Watched Accounts" list. 2. The rule that adds accounts to the "Watched Accounts" active list is triggered when any of the low-level suspicious rules are activated. In this case, it's the rule about registering an account from a country of concern which triggers upon detection. 3. Once triggered by one of these rules, the system places the specific account ID on the "Watched Accounts" active list. **How Accounts Get on the Suspicious Accounts Active List:** 1. An escalation occurs when three instances of low-level suspicious behavior are detected for an account. This is represented in Figure3-2 and described by Method 1, which involves: a. Identifying that there have been three separate occurrences of low-level suspicious activities all linked to the same account. b. The account's status then changes from "Watched Accounts" to "Suspicious Accounts." The process involves adding an account to either a Watched Accounts active list or a Suspicious Accounts active list based on specific rules triggered by events like excessive wire transfers within a short time frame. If the count of such events reaches three for an account, it is escalated from the Watched Accounts list to the Suspicious Accounts list. This occurs when certain medium-level suspicious behaviors are detected, as outlined in detailed steps and represented visually in Figure3-2. The rules that lead to this placement are listed in Table3-3 under the Add to Suspicious Accounts List active list. The text discusses the process of escalating accounts for possible fraudulent activities in a system, focusing on how account IDs are moved from one active list to another based on suspicious behavior detections. Step-by-step summary: 1. When an account shows signs of suspicious activity three times (as detected by specific rules), the Escalate Account - Suspicious to Possible Fraudulent rule is activated, and the account ID is added to the Investigate List from the Suspicious Accounts active list. 2. If high level suspicious behavior is identified for an account, it results in adding the account ID to the Investigate List active list through a series of triggered rules: first, a high-level suspicious activity event occurs (like a successful brute force login), which triggers the Brute Force Login Success rule; then, this rule triggers the Add to Fraud Investigate List rule. 3. The Add to Fraud Investigate List rule places the account ID on the Investigate List active list. 4. Additional information is provided about customizing the account escalation process: you can manually add or remove accounts from the watched, suspicious, and investigate lists, as well as customize the rules that trigger these actions. This customization is optional. The text also mentions that the key dynamic active lists involved in this process are Watched Accounts, Suspicious Accounts, and Investigate List. The text describes a process for managing accounts on different escalation lists within a system, such as those used in security or monitoring applications. The process involves using rules to automatically populate the lists with accounts that exhibit suspicious activity and meeting escalation conditions. Users can manually adjust an account's position between lists if needed, either by escalating (moving up) or de-escalating (moving down). To customize these lists: 1. Navigate to the specific list in the system. 2. Expand the relevant section of the solution path. 3. Right-click on the desired list and select "Show Entries." 4. Add or remove accounts by clicking the appropriate icon for addition or right-clicking a selected entry and choosing delete. 5. The default time-out period for removing an account from escalation lists is 7 days, but this can be adjusted in the active list editor if needed. 6. For special sensitivity, such as the Investigate List, no automatic timeout is applied, allowing manual management of entries by users. For customizing escalation rules:

• Users can adjust settings so that an account moves to the next level list after a predetermined number of instances (default 3) on the Watched Accounts or Suspicious Accounts lists.

• This rule setting can be modified in the conditions for these specific lists.

The document outlines procedures for escalating account status in a fraud detection system using ArcSight FraudView v1.0.1. It explains how to customize lists of rules that trigger an account's inclusion on various tracking lists such as Watched Accounts, Suspicious Accounts, or Investigate List based on organizational needs. For instance, if an organization wants to always investigate accounts when a payee is created and paid by the same user, they can remove a specific rule from the Suspicious Accounts list and add it to the Fraud Investigate List. The document provides detailed steps for adding or removing rules from these lists, including navigating through the system interfaces and editing active lists accordingly. It's important to ensure that each rule is only listed once across all Add to active lists to avoid unexpected results in the escalation process. The provided text is a guide for using ArcSight FraudView, a software tool designed to investigate and combat fraud in accounts. Here's a summary of the key points from the text: 1. **Account Escalation Process**: To use this process within ArcSight FraudView, navigate to "ArcSight Solutions/FraudView 1.0/Escalation" on the Investigate List. From there, follow these steps:

• Click on "Add to Fraud Investigate List active list."

• Right-click the active list and select "Show Entries."

• Right-click an entry in the active list and select "Delete."

2. **Resource Listings**: The guide includes tables summarizing various resources and rules:

• **Table 3-1** lists the resources that support the account escalation process, including Watched Accounts, Suspicious Accounts, and Investigate List. These are all types of active lists in ArcSight FraudView.

• **Table 3-2** details the rules that trigger an account ID to be added to the Watched Accounts active list.

• **Table 3-3** outlines the rules for adding accounts to the Suspicious Accounts active list.

• **Table 3-4** lists the rules for adding accounts to the Investigate List active list.

In summary, this guide provides a step-by-step method for escalating account investigation using ArcSight FraudView, along with an explanation of the resources and triggers involved in this process. The text outlines several functionalities within the ArcSight software related to managing and investigating potential fraudulent activities through the use of rule-based systems in the Solutions/FraudView module. Here's a summary of each point: 1. **Suspicious Accounts List**: This list automatically includes accounts triggered by rules in the ArcSight Active List, specifically within the Suspicious 1.0/Escalation/Configuration active list. The rule Add to Suspicious Accounts List immediately adds such accounts when specific conditions are met. 2. **Investigate List**: Similar functionality applies here as well, where accounts are added to the Investigate List if they meet certain criteria within the ArcSight Active List and the Solutions/FraudView module, specifically through the rule Add to Investigate List within the 1.0/Escalation/Configuration active list. 3. **Watched Accounts**: Triggered by rules defined in the Add to Watched Accounts List within the 1.0/Escalation/Configuration active list, this feature adds accounts that meet specific criteria to the ArcSight Suspicious Accounts active list if they trigger a rule defined in the module. 4. **Suspicious Accounts**: These are added to the Suspicious Accounts List when a triggering rule is defined within the Add to Suspect Accounts List section of the 1.0/Escalation/Configuration active list, also part of the Solutions/FraudView module. 5. **Investigate List (continued)**: When accounts meet certain criteria and are added to the Investigate List through the rule in the Add to Investigate List section under the 1.0/Escalation/Configuration active list, they contribute to this feature within the Solutions/FraudView module. 6. **Escalate Account Rules**: These rules serve to escalate the handling of accounts that have been repeatedly added to specific lists (Suspicious or Watched) multiple times. Specifically, after being on these lists three times, the rule will remove the account from one list and add it to another, either moving a suspicious account to the Investigate List or a watched account to the Suspicious Accounts List. 7. **Fraudulent Account List**: This feature in ArcSight is designed to show accounts that have been recently added to a FraudView watchlist within the last two hours. The active channel showcasing these accounts provides real-time monitoring and reporting of potential fraudulent activities, updated dynamically based on user configurations and data inputs. 8. **Dashboard for Escalation**: This dashboard visualizes accounts that have been escalated due to involvement in fraudulent activities as per the FraudView watchlist within the last two hours, providing a comprehensive overview of active investigations and escalations related to suspected fraud. Overall, these functionalities are part of an integrated security solution designed to assist in detecting and managing potential fraudulent activities by automatically tracking and analyzing account behaviors that might indicate suspicious or fraudulent behavior using rule-based systems and real-time monitoring tools within the ArcSight platform. The document provides an overview of how different types of accounts are monitored and escalated in the ArcSight FraudView system, which is part of the ArcSight™ FraudView v1.0.1 suite. The system uses a color-coded severity scale to indicate the level of risk associated with each account on three separate lists: Watched Accounts, Suspicious Accounts, and Investigate List. These lists are filtered by specific criteria related to activity and status: 1. **Watched Accounts List**: This list includes accounts that have been actively monitored for suspicious or fraudulent activities based on generated events in the system. The filter retrieves these from accounts listed as active in the Watched Accounts section. 2. **Suspicious Accounts List**: Similar to the Watched Accounts, this list comprises accounts suspected of engaging in potentially risky behaviors, such as suspicious activity patterns indicative of fraud or other malicious actions. Events related to these accounts are filtered from those marked as active in the Suspicious Accounts section. 3. **Investigate List**: This is the most critical list where accounts that have been flagged for a deeper investigation due to high risk levels based on specific criteria are included. The filter here targets events generated by accounts listed as active in the Investigate List, which could be related to fraudulent activities or other significant concerns. The system also includes filters designed to check each account's status within these lists: Watched List, Suspicious List, and Investigate List. These filters are used to determine if an account is at risk by applying a priority formula that assesses the Account Risk Model/Account Risk based on the specific list criteria in which it falls. Additionally, there are rules defined for identifying suspicious activity around account creation or access attempts, as triggered by certain events, which could lead to accounts being added to the Watched Accounts Active List according to the provided rule in the table. This setup is crucial for proactive risk management and fraud prevention within financial systems and regulatory environments that require monitoring of potentially fraudulent activities. The text provided is a summary of various rules and criteria used in fraud detection by the OFAC (Office of Foreign Assets Control) as part of ArcSight™ FraudView v1.0.1, which is a software solution for detecting financial fraud. These rules aim to identify suspicious activities such as account lockouts, fraudulent registrations, use of public email addresses, foreign transactions involving credit cards, excessive wire transfers, disparities in geographic access, and multiple failed login attempts. Each rule has specific criteria that trigger an alert or action based on the identified patterns of behavior indicative of potential fraud. These rules are crucial for preventing financial crimes by flagging suspicious activities before they escalate into significant losses. The ArcSight FraudView v1.0.1 Guide provides a comprehensive overview of various rules designed to detect and prevent fraudulent activities within an organization's financial transactions. These rules include: 1. **Fraud Early Warning Rule**: Identifies instances where a user initiates five transactions (such as payments or wire transfers) within one minute, triggering a warning for potential fraud. 2. **Password Reset Rule**: Monitors password resets and updates, keeping track of the active list with account information to detect suspicious activities. 3. **Payee Creation and Payment Rule**: Detects when a payee is created and paid by the same user within 2 minutes during unusual times of day, potentially indicating fraudulent behavior. 4. **Suspicious Payee Identification Rule**: Identifies payments made to known or suspected suspicious payees, utilizing an automatically populated list that may include multiple accounts of the paying user if they have transacted with the payee previously. 5. **Penny Stock Transactions Rule**: Alerts when a transaction involves more than 100,000 units (across various financial instruments like stocks, options, etc.) at a price below $0.75 per unit, which may suggest penny stock trading and is specific to investment banking. 6. **Confidential Trading Violation Rule**: Detects if a trader exceeds the daily purchasing threshold of $10,000,000 set by default for this purpose, indicating potentially unauthorized or risky trading behavior. These rules are part of ArcSight's suite designed to enhance security and compliance through automated monitoring and alerting mechanisms against fraudulent activities in financial transactions. The ArcSight FraudView rule set is designed to detect potential financial fraud in trading activities by evaluating various thresholds and anomalies, including dollar amounts per day, single transaction limits, asset type units per day, and weekly transaction volumes. These rules are intended to prevent traders from exceeding preset maximums for daily selling, single transactions, specific types of assets (such as stocks or bonds), and the total number of transactions in a given period. The purpose is to identify anomalies that may indicate fraudulent behavior, such as unauthorized trading beyond acceptable limits set by industry standards. The document outlines several rules used by ArcSight Confidential in identifying potential fraudulent activities, placing accounts on the Suspicious Accounts Active List. These rules include: 1. **Transfers Just Below Threshold**: This rule detects if at least three wire transfers, each below a specified threshold amount, are made between the same payer and payee within 5 minutes. It triggers an alert at level 1.0/Fraud Early Warning. 2. **Transfers Over Threshold**: This rule identifies wire transfer violations where the amount exceeds the set threshold. It also alerts at level 1.0/Fraud Early Warning. 3. **Account Logon from RBN**: Identifies logons to accounts originating from the RBN (Russian Business Network) address space, flagging an alert at level 1.0/Fraud Early Warning. 4. **Account Registration from RBN**: This rule detects the creation of accounts within the RBN address space and triggers an alert at level 1.0/Fraud Early Warning. 5. **Entitlements Violation**: Alerts when an account performs a transaction with a financial instrument to which it is not entitled, requiring the specific financial instrument to be defined in the active list, triggering alerts under Industry-Specific/Investment Banking. 6. **Excessive Wire Transfers to Same Payee**: This rule triggers if an account makes at least three payments within five minutes to the same payee, indicating potential fraudulent activity flagged at level 1.0/Fraud Early Warning. 7. **Login from Known Fraudulent IP Address**: Identifies logons from known fraudulent IP addresses and requires the active list of Known Fraudulent Addresses to be updated regularly, escalating alerts to level 1.0/Fraud Early Warning. 8. **Multiple Password Resets**: Triggers when an account's password is reset more than three times within a 24-hour period, escalating to level 1.0/Fraud Early Warning. The provided text outlines a series of rules implemented in ArcSight™ FraudView v1.0.1, designed to detect potential fraudulent activities such as password resets, payee creations by different users, logins from suspicious IP addresses, and accounts created with fraudulent SSNs. These rules are crucial for escalating the investigation level when placing accounts on an active list for further investigation. Key features of these rules include:

• **Password Reset Rule**: This identifies cases where a password reset occurs without preceding lockout, indicating potential fraud. It checks whether the account being reset is locked out and if not, flags it for review.

• **Payee Creation Rule**: Detects payees created by different users who are the same person as the creator. The rule ensures that only one user can manage a payee account and alerts when this condition is violated.

• **Suspicious IP Address Rule**: Triggers an alert if there's a successful login from an IP address known to be suspicious, based on predefined settings or manual addition of other known suspicious IPs.

• **Brute Force Attack Detection**: Identifies accounts accessed shortly after a suspected brute force attack, indicating possible unauthorized attempts to access the account.

• **Fraudulent SSN Rule**: Alerts when new accounts are created using fraudulent Social Security Numbers (SSNs), which are identified through predefined lists of fraudulent SSNs.

These rules collectively serve as early warning systems in FraudView, helping to promptly escalate cases requiring deeper investigation and action. The article describes an account escalation process used to monitor and respond to suspicious behavior in accounts. It involves a set of rules, such as Excessive Wire Transfers to Same Payee rule and Escalate Account - Suspicious to Possible Fraudulent rule, which detect abnormal activity like multiple wire transfers to the same payee within short time or accessing multiple accounts from one IP address. When these rules are triggered, they create correlation events that result in notifications and case creation to further investigate suspicious activities. The document outlines several use cases related to account management within a system, focusing on identifying and managing fraudulent activities. Here's a summary of each use case: 1. **Account Created Using Fraudulent SSN**: This use case is designed to detect attempts to open accounts using Social Security Numbers (SSNs) that are known to be fraudulent. It aims to prevent unauthorized account creations and protect against identity theft. 2. **Account Lockout Detected**: The purpose of this use case is to identify when accounts have been locked out due to suspicious activities or multiple failed login attempts. This helps in maintaining the security of the system by quickly detecting potential threats. 3. **Account Logon from RBN**: This use case focuses on successful account access events originating from assets classified as belonging to the Russian Business Network (RBN). It involves identifying and monitoring such accesses to detect any suspicious activity or unauthorized usage of network resources related to this specific category. 4. **Account Registration at Suspicious Time**: The purpose of this use case is to identify accounts created during unusual or suspicious times, defined as between 8:00 p.m. and 6:00 a.m. on weekdays, plus all day on weekends. This helps in detecting potential breaches during off-peak hours when there might be less system monitoring. 5. **Account Registration From Country of Concern**: This use case aims to detect account creations originating from countries known for high rates of fraud. It involves defining a list of concern countries based on historical data of fraudulent activities and alerts the relevant parties about potential risks associated with accounts registered in these areas. 6. **Account Registration from RBN**: Similar to the Logon use case, this one specifically targets account creations from assets categorized within the Russian Business Network. It involves monitoring such registrations for any indication of unauthorized access or misuse of network resources. These use cases are part of a broader security and fraud prevention strategy, designed to identify potential threats and mitigate risks associated with fraudulent activities in various aspects of digital account management. This document outlines several use cases designed to detect fraudulent activities in accounts, focusing on various aspects such as login attempts, excessive transfers, geographic disparities, and suspicious transactions. These include: 1. **Account Registration Using Public Email**: Intended to flag accounts created with email addresses from public domains like yahoo.com, gmail.com, hotmail.com, msn.com, and hushmail.com, which are often associated with less secure or shared email services. 2. **Brute Force Login Success**: A use case that triggers when an account successfully logs in following a suspected brute force attack within one minute after multiple failed login attempts. This detects compromised accounts or unauthorized access attempts. 3. **Excessive Wire Transfers to Same Payee**: Triggered by three or more payments made from the same account to a specific payee within five minutes, indicating potential fraudulent activity such as money laundering or payout fraud. 4. **Geographic Disparity of Account Access**: Identifies if an account has been accessed from more than one country within an hour, which might suggest multiple users or unauthorized access across different locations. 5. **Login from Known Fraudulent Address**: Activated when an account is accessed from a known IP address associated with fraudulent activity, indicating potential compromise of the account credentials. 6. **Multiple Accounts Paying Same Payee**: Triggers if three distinct accounts make payments to the same payee within five minutes, which could indicate collusion or fraudulent transactions among multiple accounts. 7. **Multiple Failed Logon Attempts**: Identifies patterns of three failed login attempts to a single account within one minute, suggesting potential hacking attempts or unauthorized access attempts. 8. **Multiple Password Resets**: Triggered by more than two password resets for the same account within 24 hours, which may indicate unauthorized activity or fraudulent actions like identity theft. These use cases are designed to provide early warnings of various types of fraud and suspicious activities, helping in the detection and prevention of financial crimes. These are descriptions of various "use cases" used in fraud detection systems. They include scenarios for password resets, creating payees, making suspicious payments, successful logins from certain countries or IP addresses, and detecting anomalies in transaction behavior. Each case has a specific purpose to help identify potential fraudulent activities. These are multiple use cases supported by FraudView, a software designed for detecting fraud in various industries. They include: 1. **Transfers Over Violation Threshold**: This use case identifies when three or more wire transfers for amounts exceeding the violation threshold occur within five minutes. It helps to detect potential fraudulent activity quickly. 2. **Card Used in Foreign Country**: This specific use case is targeted at credit card transactions that take place in a country different from where the account was originally created. It aids in preventing fraud related to unauthorized international usage of cards. 3. **Entitlements Violation Use Case**: This use case pertains to transactions involving financial instruments (like bonds) that an account is not legally entitled to trade, which can be indicative of fraudulent activity or mistaken trades. 4. **Excessive Wire Transfer Requests**: It monitors wire transfers with less than eight hours between each transaction and triggers alerts when more than three such requests are detected in a short period, potentially signaling fraudulent behavior. 5. **Penny Stock Transactions**: This use case is focused on transactions involving stocks or options where the volume exceeds 100,000 units and the price per unit is below $0.75 each. It helps to identify speculative or manipulative trading practices that might be indicative of fraud. 6. **Trading Violation - Dollar Per Day (Purchased)**: This use case tracks the dollar amount purchased in a single day by traders, generating alerts when this threshold is exceeded, which could suggest aggressive buying behavior potentially linked to fraudulent activities. Each use case serves a unique purpose within different industries and helps in flagging potential fraud based on specific patterns or thresholds related to transactions, wire transfers, and trading volumes. This document outlines various "Use Cases" for identifying potential trading violations and fraudulent activities using ArcSight™ FraudView v1.0.1, specifically focusing on thresholds related to single transactions in dollars or units, transaction frequency per day, and asset types traded. The purpose of these use cases is to help identify if a trader has exceeded predefined limits set by the system for each specific type of trading activity. For instance:

• **Trading Violation - Single Transaction Dollar Threshold**: This use case aims to detect if an individual transaction exceeds $500,000 in value. It involves checking transactions on a per-transaction basis and can be used to monitor high-value trades made by traders.

• **Trading Violation - Single Transaction Units Threshold**: This use case focuses on the units traded rather than dollar amounts, setting a limit of 500,000 units for various assets like stocks, bonds, and options. It is used to monitor unusual trading volumes in terms of these specific asset types.

• **Trading Violation - Transactions Per Day Threshold**: This use case checks if the number of transactions conducted by a trader exceeds 100 per day, which can indicate high activity or potential rule violations within a single trading session.

• **Units Per Day Threshold Use Case**: Similar to the above but with an emphasis on daily limits for specific asset types (e.g., stocks, bonds, and options). This use case helps in monitoring excessive trading volumes over 24 hours across various asset classes.

In addition, there's a focus on detecting fraud early through IP address usage:

• **Accessing Multiple Accounts from Single IP Use Case**: Designed to detect if three or more accounts are accessed within two minutes from the same IP address, which could be indicative of multiple users accessing one account and might suggest fraudulent activities.

To implement these use cases, FlexConnector(s) must supply events such as Account Access Attempts, filtered by event type. The rule for accessing multiple accounts from a single IP triggers when appropriate conditions are met, adding the suspect IP address to a list of suspicious accounts for further investigation. This information discusses a rule in the ArcSight FraudView system that identifies when at least three accounts are accessed from the same IP address within two minutes. It is designed to help detect possible fraudulent activities by flagging suspicious access attempts involving accounts potentially involved in such activities. The rule requires specific filters and configurations for the FlexConnector, ensuring it matches certain event types (Account Access Attempt, Account Creation, Account Access Failure, and Account Access Success) with appropriate conditions set up within the Filters/Event Type section of the system. Additionally, there's a use case focused on identifying account activity from countries blacklisted by OFAC (Office of Foreign Asset Control), which is part of broader compliance measures to prevent transactions or activities involving entities listed as banned by this office due to their involvement in certain sanctions violations. This use case necessitates the supply of events related to these types, with corresponding filters and configurations set up accordingly. For detailed configuration guidelines and more information on these specific rules and uses within the system, refer to the provided URI links which are mentioned as part of this document's appendix or supplementary guidance sections for further assistance. The provided summary outlines the functionality of two filters within the ArcSight FraudView software, designed to detect and respond to account creations or access attempts from individuals residing in OFAC (Office of Foreign Assets Control) blacklisted countries. These filters are crucial for maintaining compliance with regulations regarding transactions involving sanctioned countries as per OFAC guidelines. 1. **Account Access Failure Filter**: This filter is specifically designed to identify instances where an attempt to access an account has failed due to the user's country being on the OFAC blacklist. The software uses this rule to ensure that events corresponding to such attempts are generated and properly recognized by the system, with relevant fields set according to the connector used. 2. **Account Access Success Filter**: In contrast to the Account Access Failure filter, this one is meant for detecting successful account accesses from users not residing in OFAC blacklisted countries. This ensures that only legitimate access attempts are processed without disruption, aligning with regulatory compliance requirements. Both filters rely on country codes listed in the OFAC Blacklisted Countries active list maintained by OFAC regulations and integrated into ArcSight FraudView to determine whether an account creation or access event should be flagged or allowed based on geographical restrictions. The resources supporting this use case include tables detailing various components such as rules, lists, and filters within the software, each serving a specific purpose in identifying and managing risks associated with transactions involving blacklisted countries. The text discusses a method for identifying attempts to open accounts with known fraudulent Social Security Numbers (SSN). To achieve this, you need to ensure that the connector generates and matches events according to specific conditions. Additionally, the connector must set certain event fields with appropriate values. The purpose of this use case is to detect unauthorized account openings using SSNs that are considered fraudulent. It relies on a predefined rule for creating accounts with fraudulent SSNs and requires FlexConnectors to provide Account Creation type events. The associated filter should also be configured correctly. For this, an active list of known fraudulent SSNs must be maintained manually. The resources required to implement this use case include the ArcSight FraudView v1.0 guide, which provides detailed information on how to configure and maintain filters related to account creation using fraudulent SSNs. The provided text outlines a use case for identifying account lockouts, focusing on configuring FlexConnectors to generate events and setting up filters to detect these events. Key points include: 1. **Triggering Rule**: To identify account lockouts, the Account Lockout Detected rule must be triggered by FlexConnectors supplying events of the Account Lockout type. This involves ensuring a corresponding event is generated by the connector and matched by appropriate filter conditions. 2. **Event Generation**: The connector should set specific values for certain event fields to ensure proper detection. 3. **Use Case Purpose**: The primary purpose is to identify account lockouts, which are based on the Account Lockout Detected rule. Locked-out accounts are added to an active list maintained by the system. 4. **Configuration Requirements**: FlexConnectors must provide events of the Account Lockout type. A filter associated with this event type needs to be configured to define account lockout conditions. 5. **Resources Table**: Lists resources such as rules, filters, and active lists that support this use case, including descriptions and URIs for reference. In summary, this text describes the setup and functionality of an account lockout detection mechanism within a security information management system, detailing how to configure connectors, set up event types, and utilize associated filters for effective monitoring and response to potential lockouts. The purpose of this use case is to identify successful access to assets categorized in the Russian Business Network (RBN) address ranges by using the Account Logon from RBN rule. To trigger this rule, FlexConnectors must supply events of the Account Access Success type. A corresponding filter should be configured for the Account Access Success event type. The RBN address ranges defined under the ArcSight Solutions/Fraud View/RBNet group need to be maintained periodically. Resources that support this use case include the Account Logon from RBN rule, which identifies logons to accounts from the RBN (Russian Business Network) address space. A filter for defining successful account access is also included, ensuring that a corresponding event is generated by the connector and matched by the conditions in this filter. Additionally, certain event fields must be set with specific values by the connector. The asset ranges defined as RBN183 Addresses are known to be used by Russian Business Network. The described use case pertains to identifying suspicious times during which account creations occur, using the Account Registration at Suspicious Time rule within the FlexConnector system. To implement this rule, users must configure a specific filter for detecting suspicious time periods, such as hours that are not typical for account registrations (e.g., late evenings or early mornings). This is achieved by customizing the Suspicious Time of Day filter, which evaluates events based on their receipt times against pre-defined conditions. The process involves using FlexConnectors to supply Account Creation type events, and these must be linked with a properly configured filter for event types associated with account registration. The configuration options allow users to redefine suspicious time periods by altering the Suspicious Time of Day filter settings, which relies on DayOfWeek and HourOfDay variables that determine if an event occurs during an unexpected part of the day or week. For instance, you can adjust the filter to include hours from 8:00 PM to 6:00 AM Monday through Friday, plus all day Saturday and Sunday. This use case is particularly relevant for preventing fraudulent account registrations by flagging suspicious activities that occur during non-standard business hours or days when such activity might be less expected. To support this process, the system relies on resources such as rules (which identify account creations at inappropriate times) and filters (to define suspicious periods). These are outlined in a table of supporting resources within the FlexConnector framework, which provides comprehensive guidance for setting up and using these features to enhance security measures against fraudulent activities. The Account Registration From Country of Concern use case aims to identify account creations originating from countries that have a history of high fraud rates. To implement this, at least one FlexConnector must provide events of the Account Creation type, and the associated filter should be configured correctly. Countries considered of concern are those where significant fraud has occurred in the past. The ISO Country Codes can be obtained from http://www.iso.org/iso/country_name_codes for maintaining an active list of concerned countries. This list is used to prioritize accounts based on a specific formula that includes country codes identified as high-risk due to fraud history. This document outlines a use case for identifying successful account creations from assets categorized as belonging to the Russian Business Network (RBN) address ranges, using ArcSight FraudView v1.0.1. The purpose of this use case is to detect such account creations within specified RBN asset ranges defined in the ArcSight Solutions/Fraud View/RBNet group and category. To implement this use case, FlexConnectors must supply events of the Account Creation type, and a corresponding filter should be configured for the Account Creation event type. Additionally, the Russian Business Network address ranges under the ArcSight Solutions/Fraud View/RBNet group need to be maintained regularly. This document also lists resources that support this use case. The Account Registration Using Public Email use case aims to identify accounts created with email addresses from public email providers like yahoo.com, gmail.com, hotmail.com, msn.com, and hushmail.com. To trigger this rule, FlexConnectors must supply events of the Account Creation type, and a corresponding filter should be configured for Account Creation events. The connector should also set specific event fields with certain values to ensure proper functionality. The Brute Force Login Success use case is designed to detect successful logins following a brute force attack, occurring one minute after the attack. This use case relies on the Brute Force Login Success rule and involves configuring FlexConnectors to generate events of the relevant type for detection. The Brute Force Login Success rule triggers when two specific events occur within one minute: a brute force login attempt and access of a financial application that successfully triggers the Account Access Success filter. Both events must be associated with the same account ID for the rule to activate. To configure this, FlexConnectors provide Account Access Success events, and an appropriate filter is set up for these events. An Intrusion Detection System (IDS) is necessary to supply events indicating a brute force login attempt; Smart Connectors should map the attacked account to the Account Id field. The resources needed for this use case include configuring rules, filters, IDS, and Smart Connectors in ArcSight FraudView version 1.0.1. The Excessive Wire Transfers to Same Payee use case in ArcSight FraudView aims to detect when a single bank account makes three or more payments to the same payee within five minutes, based on the rule defined for this purpose. To implement this, FlexConnectors must provide events of the Wire Transfer type, and there should be an associated filter configured for this event type. The rule is designed by ArcSight in their solution, specifically under the Fraud Early Warning module. On the other hand, the Geographic Disparity of Account Access use case focuses on identifying if a bank account has been accessed from more than one country within an hour. This involves implementing a rule called "Account Access from New Country" which will be triggered by events that meet this criterion. These rules and filters are part of ArcSight FraudView's functionality for early fraud detection, ensuring security measures against unauthorized access across geographical locations. The Geographic Disparity of Account Access rule in the FlexConnector system is designed to detect when an account has been accessed from more than one country within a specified timeframe, indicating potential fraudulent or disparate access patterns. To trigger this rule, events such as ATM Authentication and Account Access Success must be supplied by the FlexConnector(s), with specific filters configured for these event types. For proper processing of ATM authentication events, it is necessary to assign each ATM to a valid IP address, preferably not private IPs, and create location resources with the appropriate country field if using private IPs. These resources should be assigned to the ATM zones, asset ranges, or assets based on their geographical coverage. The rule operates by placing the Country Code of the account onto the Geographic Access Records for two specific conditions: either there is no entry in the active list for that account, or the country code associated with the account differs from that specified in the attackerGeoCountryCode field of the account login event. It will fire if an account is accessed from more than one country within a defined timeframe. This use case relies on resources listed in Table 4-12, which includes ArcSight's Geographic Access Records and FraudView Early Warning. These resources help track accounts that have been accessed from different countries within the hour, indicating potential fraudulent activities or disparate access patterns. The document discusses using the "Login from Known Fraudulent Address" use case in ArcSight™ FraudView to detect unauthorized access of accounts from known fraudulent IP addresses. To implement this, FlexConnectors must provide events of the "Account Access Success" type, and a corresponding filter should be configured for this event type. Additionally, an active list of known fraudulent IP addresses needs to be maintained. The resources required for this use case include rules and filters in ArcSight FraudView, specifically designed for identifying account access from fraudulent IP addresses. The document discusses the "Known Fraudulent IP Address Active List" in the context of cybersecurity and fraud prevention tools, specifically within the ArcSight™ FraudView product. This list contains known fraudulent IP addresses that are manually updated on a regular basis to ensure ongoing protection against malicious activity. These addresses are crucial for defining high-risk attributes in a priority formula used by the system. Additionally, there is information about another use case called "Multiple Accounts Paying Same Payee," which aims to detect if three different accounts make payments to the same payee within a five-minute window. This use case relies on specific rules and filters that need to be configured with FlexConnectors providing events of the Payment Issued type, along with appropriate event field configurations. The document also provides a table listing resources relevant to this use case, including the rule for identifying multiple accounts paying the same payee, which is part of the ArcSight™ FraudView 1.0/Fraud Early Warning system. The "Suspicious Payee" active list in this context is updated by the Multiple Accounts Paying Same Payee rule and serves as an indicator of suspicious activity within a payment processing environment. The article discusses two use cases related to fraud detection using ArcSight FraudView v1.0.1: the Same Payee rule and Multiple Failed Logon Attempts. The Same Payee rule involves adding suspicious payees manually to a list, which is part of the Priority Formula for identifying high-risk situations when multiple accounts pay a single entity. This filter identifies a payment issued event and ensures that it corresponds with an event generated by the connector, matching specific conditions in the filter setup. The Multiple Failed Logon Attempts use case aims to identify cases where three failed attempts to access the same account occur within one minute, based on the Multiple Failed Logon Attempts rule. The FlexConnector(s) must supply events of the Account Access Failure type, and a corresponding event should be generated by the connector with appropriate values set in specific event fields. Several resources support these use cases, including rules, filters, and an overview table listing relevant resources. The purpose of the Multiple Password Resets use case is to detect when a user has attempted to reset their password three times within a span of twenty-four hours, indicating potential unauthorized access or forgotten password attempts. This rule is based on the Multiple Password Resets rule and involves adding each reset attempt to an active list. To implement this, FlexConnector(s) must provide events of the Password Reset type, and a corresponding filter should be configured for these events. The resources required for this use case include ArcSight Rule, Filter, and Active List tools, which help in identifying password resets and updating the Password Reset active list with account information. This process ensures that if an account is added to the list three times within 24 hours, it triggers the rule indicating multiple unauthorized attempts at resetting the password. The Multiple Transactions by Same User use case is designed to identify when an account issues five transactions, such as payments or wire transfers, within a span of one minute. This rule is based on the Multiple Transactions by Same User from ArcSight Solutions/FraudView and aims to detect potential fraudulent activities. To activate this rule, FlexConnectors must provide events related to either Payment Issued or Wire Transfer. Proper configuration of filters for these event types is crucial to avoid inaccurate reporting. The use case will trigger a warning if more than one event is generated for any financial application action like Credit Card Transactions, Payments Issued, Purchasing Transactions, or Wire Transfers. The text discusses two main use cases related to event identification within a system for security purposes, specifically focusing on password resets and wire transfers. Firstly, the "Password Reset Not Preceded by Lockout" use case is designed to detect instances where a user's password has been reset without prior account locking due to failed login attempts. This is achieved through the implementation of a rule based on the Password Reset Not Preceded by Lockout rule, which requires FlexConnectors to supply events of the Account Lockout type and utilizes a specific filter for this event type. Additional configurations are necessary to ensure proper functionality. Secondly, the text addresses a "Wire Transfer" identification process within the same system framework. It emphasizes that connectors must be configured to set specific event fields when generating corresponding events for wire transfers, as these events need to meet particular criteria and conditions to be accurately identified and processed by the system filters. Both use cases highlight the importance of configuring appropriate filtering mechanisms and ensuring data integrity in the form of specific field values being set correctly by connectors. This is crucial for effective event detection and accurate handling within a security or monitoring framework, such as fraud prevention systems like ArcSight FraudView. The Payee Created and Paid - Same User use case is designed to detect instances where a payee is created and subsequently paid from the same account, which could indicate fraudulent activity. This rule operates based on two main components: the creation of a payee and the issuance of a payment. When a payee is created, it is added to a list of active payees along with the account ID that created it. Upon issuing a payment, the system checks if the account responsible for the payment matches the account that created the payee. To implement this rule, FlexConnectors must supply events of the Payment Issued type, and there should be an associated filter configured for this event in the system. The Payee Created and Paid - Same User rule is supported by resources such as ArcSight FraudView 1.0, which includes specific rules and filters to identify fraudulent activities based on these criteria. These resources are detailed in a table provided within the document, showing their descriptions and associated URIs for reference and implementation. The Payee Created and Paid - Suspicious Time use case in ArcSight FraudView aims to detect instances where a payee is both created and paid by the same user within two minutes, particularly during suspicious times of the day. This use case is based on the Payee Created and Paid - Suspicious Time rule, which requires FlexConnectors to supply events from two specific types: Payee Created and Payment Issued. The filter for these event types should be configured appropriately to support this detection. To customize the suspicious time period, users can adjust the Suspicious Time of Day filter using variables like DayOfWeek and HourOfDay. This allows tailoring the filter settings to better fit the organization's needs, such as redefining hours from 6:00 PM to 8:00 AM for all weekdays and weekends. Supporting resources for this use case include rules, filters, and other configurations that facilitate the detection of payee creation and payment by the same user during suspicious times. The document outlines a filter within ArcSight's FraudView solution designed to detect and identify potential fraudulent activities, specifically focusing on suspicious times of day for transactions to occur. This filter is intended to analyze patterns such as unusual or high-risk periods during the week or specific days when fraud might be more likely to take place. It also involves checking if events corresponding to payment issuance are generated by a connector and matched with predefined conditions. Another key use case discussed is related to detecting suspicious payees, where the filter helps in identifying events indicating that a payee has been created for a specific account. This is crucial for ensuring that all necessary events are generated via connectors and comply with specified event field values as per the filter's conditions. The system uses an active list of suspicious payees maintained by other rules to identify potentially risky payees, which may include manual additions of known suspicious parties. To implement these use cases, FlexConnectors supplying events of the Payment Issued type must be configured properly along with associated event filters. The document suggests that more detailed information can be found in a separate section titled "Payment Issued," presumably providing additional guidelines and settings for users to fine-tune their detection capabilities based on specific transaction patterns and risk assessments. The provided resources support the identification of suspicious payee and successful login from countries of concern cases using ArcSight FraudView v1.0. For identifying payments to suspicious payees, there are two main rules in use:

• **Paying Suspicious Payee Rule**: This rule identifies when a payment is issued to a payee marked as suspicious, either automatically via the Suspicious Payee active list populated by the Paying Same Payee rule or manually added by users. The list is updated based on transactions involving multiple accounts paying the same payee.

• **Multiple Accounts Paying Same Payee Rule**: This identifies when three different accounts pay a single payee within five minutes, automatically adding known suspicious payees to an active list that also serves as part of the priority formula.

Additionally, there are filters for identifying payment issuance events and successful logins from countries listed in the Countries of Concern active list. These use cases require FlexConnectors to supply Account Access Success type events. This passage discusses a method to detect successful logins originating from countries known for high fraud rates, as well as suspicious IP addresses, using specific ArcSight tools and resources. The first part details how the Countries of Concern active list should be updated with ISO Country Codes from reputable sources like the ISO website. The rule in question will identify successful logins from these concern countries through a Rule called "Successful Login from Country of Concern," utilizing the FraudView module within ArcSight, specifically designed to address fraud scenarios. The use case involves configuring specific filters and ensuring that an event corresponding to a successful login is generated by the connector. This setup allows for prioritizing high-risk transactions or devices based on predefined attributes like device risk. The passage concludes with a brief mention of another rule focused on identifying suspicious IP addresses during successful logins, which also relies on FlexConnectors providing relevant events and configuring them appropriately within ArcSight's FraudView module to enhance security measures against fraudulent activities. The text discusses a security mechanism used to detect and manage suspicious account access events, specifically focusing on successful logins from IP addresses identified as suspicious or known to be risky. Key points include: 1. **Suspicious IP Definitions**: There are two ways to define suspicious IP addresses - automatically through the "Accessing Multiple Accounts from single IP rule" which populates the Suspicious Addresses active list, and manually by adding other known suspicious IPs. 2. **Resources Involved**: The use case relies on ArcSight Solutions/FraudView version 1.0 for monitoring and identification of suspicious activities. Specific resources mentioned are "Successful Login from suspicious IP", "Suspicious Addresses active list", and a filter called "Account Access Success" used to define successful account access events. 3. **Automatic Population**: The Suspicious Addresses active list is automatically populated by the rule that identifies multiple accounts accessed from the same IP within two minutes, which then becomes known as a suspicious IP address. 4. **Maintenance of List**: Entries in the Suspicious Addresses active list do not expire and must be manually removed if no longer needed. This active list helps in managing risks associated with accessing multiple accounts from single IPs. 5. **Filter Configuration**: A filter named "Account Access Success" is used to define conditions for a successful account access event, ensuring that it aligns with the generated events by the connector. The configuration of this filter is crucial as any mismatch could affect detection accuracy. 6. **Documentation Reference**: For more detailed information on these processes and configurations, one should refer to "Account Access Success" documentation provided within ArcSight Solutions/FraudView manual or help section. The text outlines a comprehensive approach to security management using automated rules and filters, aimed at detecting and managing suspicious activities related to account access from multiple IPs. The Transaction Behavior Anomaly use case in ArcSight FraudView aims to detect anomalies in account transactions where accounts with a low number of weekly transactions (10 or less) exhibit specific behavior patterns. This is done by comparing the sum of today's transactions to the previous week's total transaction amount and the number of transactions executed today to the entire previous week's numbers. The use case relies on the Transaction Behavior Anomaly rule, which triggers off data from the Daily Transaction Statistics rule that analyzes daily transaction statistics. These rules utilize the Behavior Statistics active list for weekly transaction totals and the Daily Transaction Statistics active list for daily sums. To activate this rule, FlexConnectors must provide events of types such as Payment Issued, Wire Transfer, Purchase Events, or Credit Card Transaction; appropriate filters must also be configured for these event types. The provided text outlines the use case for identifying anomalies in credit card transactions using ArcSight™ FraudView v1.0.1. Key resources and functionalities are summarized below: 1. **Transaction Behavior Anomaly Use Case**: This rule identifies anomalies in transaction behavior by assessing two conditions. For accounts with 10 or more weekly transactions, it checks if today's transaction total exceeds 50% of the previous week’s total, or if today’s number of transactions is more than half of the entire previous week’s count. Accounts with fewer than 10 weekly transactions are evaluated based on whether today’s total exceeds three times the previous week’s total, or if the daily transaction count is more than triple the prior week’s count. 2. **Daily Transaction Statistics Rule**: This rule dynamically updates a list for each account every time a transaction occurs, tracking both the total number of transactions and the total amount transferred during that day. The list contains aggregated information about these statistics over time. 3. **Active List of Behavior Statistics**: It stores weekly transactional data including amounts and totals, populated by analyzing trends in transaction activity. This list is maintained within the FraudView system, specifically under the Book Keeping/Behavior Statistics module. 4. **Daily Transaction Amount Active List**: This active list keeps track of the total amount transferred per account on a daily basis and the number of transactions performed each day, updating automatically through the Daily Transaction Statistics rule. The data is stored within the FraudView system under the Book Keeping/Book Keeping module. 5. **Query for Transaction Trend Information**: A weekly query that summarizes transactional trends over a specified period is used to calculate various statistical measures and detect any anomalies or unusual patterns in transaction behavior. This information is crucial for understanding and preventing fraudulent activities related to credit card transactions. These functionalities collectively support the detection of potential fraudulent behaviors and aid in maintaining the integrity of financial transactions processed through credit cards. This document outlines various filters and behaviors in ArcSight FraudView, a system designed to detect financial fraud. The behavior trends include querying weekly transaction numbers and total transaction amounts stored in Trend ArcSight. Additionally, specific filters are described for identifying different types of events such as issued payments, wire transfers, purchase events, credit card transactions, and more. Each filter requires verification that corresponding events are generated by the connector and matched by predefined conditions, with potential adjustments to event fields if necessary. The document also covers a use case focused on detecting violations in just under the threshold for multiple wire transfers. The provided text outlines a specific use case in ArcSight FraudView for identifying potential fraudulent activities related to wire transfers. This use case is designed to detect situations where three or more wire transfer amounts exceed a predetermined violation threshold within a five-minute timeframe. The process involves configuring filters and rules, with the default range being between 5750 and 5999 units (which can be adjusted). ### Key Points: 1. **Trigger Condition**: The use case is triggered when FlexConnector(s) provide Wire Transfer events that are filtered through a specific filter setup within ArcSight FraudView. This involves setting up conditions for the Wire Transfer event type to ensure it aligns with the rule's requirements. 2. **Default Range**: By default, the Transfers Just Under Violation Threshold rule is set to detect amounts between 5750 and 5999 units. However, users can customize this range by modifying the Amount condition in the rule settings. 3. **Resources Required**: To implement this use case, specific resources are necessary:

• **Transfers Just Under Violation Threshold Rule**: This identifies wire transfers just beneath the violation threshold within a 5-minute window between the same payer and payee. It is provided by ArcSight Solutions/FraudView, version 1.0, specifically under Fraud Early Warning.

• **Wire Transfer Filter**: This filter is crucial for identifying wire transfer events accurately. It should be configured to ensure that corresponding event generation through connectors and matching specific field values as per the rule's conditions.

### Summary: The use case in ArcSight FraudView focuses on detecting potentially fraudulent activities involving multiple wire transfers exceeding a set violation threshold within a short time frame (five minutes). Key setup involves configuring filters and rules around Wire Transfer events, with adjustments available for specific amount ranges. The process relies heavily on FlexConnectors providing accurate event data and compliance with pre-defined filtering conditions. This passage discusses configuring and using specific rules within a system called FraudView to manage wire transfers, particularly in relation to exceeding violation thresholds. By default, if the amount transferred exceeds $6000, the rule for "Transfers Over Violation Threshold" will be triggered. Users can adjust this threshold by editing the rule's conditions. The passage also introduces two main features within this system: 1) The ability to identify wire transfer events that exceed a set violation threshold (supported by ArcSight Solutions/FraudView, version 1.0). This involves setting up rules and filters specific to Wire Transfer events. 2) A use case for identifying transactions involving foreign credit cards, which is triggered when the transaction occurs in a country different from where the account was created. To activate this rule, FlexConnectors must provide Credit Card Transaction type events, with associated event fields being correctly set. These features are designed to assist in preventing fraudulent activities and managing international card usage effectively. The document "ArcSight Confidential ArcSight™ FraudView v1.0.1 Guide" outlines a use case for identifying credit card transactions occurring in foreign countries, which requires configuring the "Credit Card Transaction" event type and maintaining an "Account Country active list." This list should include account numbers and their associated country codes. The primary resource involved in this use case is the rule that identifies when a credit card transaction occurs from a different country than where the account was created. This rule uses the Account Number and Country Code information manually defined in the Account Country active list to determine if a foreign transaction has taken place. Other supporting resources include the Active List, which stores these details, and filters used to identify foreign transactions: the Transaction in Foreign Country filter that also utilizes this list for risk modeling purposes. To ensure proper functionality, it is essential that the connector generates corresponding events and matches them with the appropriate conditions, while setting specific event fields as required. This setup helps in identifying and managing credit card fraud involving transactions from foreign countries effectively. The Entitlements Violation use case in FraudView is designed to detect when an account engages in a transaction with financial instruments it's not authorized to trade, such as bonds, equities, futures, or options. To trigger this rule, FlexConnectors must provide Purchase Events type events, and the associated filter should be configured correctly for these events. The use case relies on active lists containing accounts entitled to access specific financial instruments: Entitlements - Bonds, Entitlements - Equities, Entitlements - Futures, and Entitlements - Options. These lists store trader account IDs that are allowed to trade specified bonds, equities, futures, or options. FraudView's rule "Entitlements Violation" identifies such unauthorized transactions by comparing the accounts involved in these financial instrument-related activities against the defined active lists. This document discusses a system for identifying fraudulent activities in investment banking related to trading equities and futures, particularly focusing on excessive wire transfer requests. It involves using ArcSight FraudView 1.0 software which tracks trader entitlements such as accounts allowed to trade stocks, options, and futures. The software includes filters that detect suspicious financial transactions like purchase events of assets like stocks or options. The system identifies potential fraud through the "Excessive Wire Transfer Requests" use case. This involves monitoring wire transfers between accounts to identify patterns where an account makes more than three such transfers within less than eight hours, indicating possible fraudulent activity. The rule for excessive requests is based on the number of times an account appears on a special list updated every eight hours. To implement this system, specific connectors and filters need to be configured to handle Wire Transfer events and ensure they meet certain conditions set by the software's rules engine. This setup helps in detecting potential fraudulent behavior early through automated monitoring and alerting mechanisms built into the ArcSight FraudView platform. The provided text outlines a set of resources that support an excessive wire transfer requests use case, which involves identifying accounts that have executed more than 3 wire transfer requests within two days. This is facilitated through three primary resources: ArcSight (an enterprise security management software), FlexConnector(s) for event generation and matching conditions, and specific filters for event identification. Additionally, it discusses a Penny Stock Transactions use case aimed at detecting transactions of over 100,000 units with a price below $0.75 each, triggered by rules related to Purchase Events or Sell Events in FlexConnectors. The configuration for this rule requires customization based on specific thresholds set in the rule itself. This table outlines various resources that support a specific use case for identifying penny stock transactions, which involves the purchase or sale of over 100,000 units (including stocks and options) at a price below $0.75 each. The table includes descriptions, types, and URIs for the following resources:

• **Penny Stock Transactions Rule**: This rule uses ArcSight's FraudView to identify transactions where more than 100,000 units are bought or sold with a unit price below $0.75. It is specific to investment banking and financial industries.

• **Sell Events Filter**: Identifies sell events of financial assets like stocks or options. The connector must generate a corresponding event that matches the conditions set in this filter, ensuring certain fields are populated correctly by the connector.

• **ArcSight Confidential - FraudView v1.0.1 Guide**: This guide provides detailed information about using ArcSight's FraudView to detect financial fraud and anomalies, including setting up filters for events like sell and purchase transactions specific to penny stock trading.

The use case focuses on identifying if a trader has exceeded the daily purchasing threshold of $10,000,000. This is triggered by configuring FlexConnectors to supply events of either Purchase Events or Sell Events, with appropriate filters applied to these event types. The configuration requires setting up specific rules and filters as outlined in the guide for effective use of the system's features aimed at detecting such trading violations. The provided text discusses two main aspects related to trading violations and their monitoring within a financial context: "Purchase Events" and "Sell Events." It begins by explaining the default settings for a rule named "Trading Violation - Dollar per day threshold - Purchased," which is triggered when amounts exceed 10,000,000 dollars. The text suggests that users can customize this threshold amount through specific rule editing. Next, the text provides information about resources crucial to implementing and managing these trading rules effectively. It includes a table listing various ArcSight-based resources that support this use case: 1. "Trading Violation - Dollar per day threshold - Purchased" rule, which identifies if a trader has exceeded a default daily purchasing limit of 10,000,000 dollars and can be customized. This is supported by the ArcSight FraudView product version 1.0/Industry type URI: Solutions/FraudView 1.0/Specific/Investment Banking/. 2. "Trading Statistics - Trader" rule, which tracks trade events using an active list to monitor aggregated numbers of trades, types of trade, and amount in units traded. This is supported by the ArcSight Confidential Guide version 88: Solutions/FraudView 1.0/Book Keeping/. 3. "Sell Events" filter, designed to identify sell events of financial assets like stocks or options, ensuring that corresponding events are generated by a connector and matched with specific conditions set within this filter. This is supported by the ArcSight FraudView version 1.0: Filters/Event Type/. 4. "Purchase Events" filter, which similarly identifies purchase events of financial assets such as stocks or options, requiring coordination with relevant connectors to ensure proper event generation and field value settings. This is also supported by the ArcSight Solutions/FraudView 1.0/Filters/Event Type/. In summary, this text provides a technical overview of how trading violations related to purchases exceeding a set threshold are monitored in financial transactions using specific software tools like ArcSight FraudView, detailing the role and support of different resources for identifying and managing such events. The Trading Violation - Dollar Per Day Threshold - Sold use case in FlexConnector is designed to detect if a trader has exceeded a daily selling threshold of $10,000,000. This use case relies on the Trading Violation - Dollar per day threshold - Sold rule and requires that events related to purchase or sell trades are generated by connectors and matched with specific filter conditions. The default trigger for this rule is amounts over $10,000,000, but users can customize the daily threshold through rule editing. Supporting resources include ArcSight Confidential (a version of FraudView) which identifies trade events and uses a trader statistics active list to track aggregated trades, helping in detecting potential trading violations. The provided text discusses several aspects related to financial asset trading and monitoring using software tools such as ArcSight. Here's a summary of the key points: 1. **Active List**: This feature in ArcSight stores account details, including the type of transactions (e.g., banking), aggregated amounts of traded assets, total monetary value per account, number of transactions per account, and the date of the last transaction. 2. **Sell Events Filter**: Identifies sell events such as stocks or options. It ensures that a corresponding event is generated by the connector and matches the conditions set in this filter. The connector may need to set specific event fields with particular values. 3. **Purchase Events Filter**: Similar to Sell Events, it identifies purchase events of financial assets like stocks or options. It also requires a corresponding event from the connector and matching conditions. 4. **Trading Violation - Single Transaction Dollar Threshold Use Case**: This use case aims to identify if a trader has exceeded the single-transaction dollar threshold set at $500,000. The trigger for this rule involves providing events of Purchase or Sell types through FlexConnectors, with associated filters already configured. These functionalities are designed to assist in detecting potential trading violations and ensuring compliance with transaction limits within financial asset trading scenarios. This summary outlines a specific use case in financial surveillance related to trading violations involving single transactions exceeding $500,000 or 500,000 units. The primary objective is to detect if a trader has exceeded the predefined transaction thresholds for both dollar and unit amounts. This is facilitated through customizing rules within the Trading Violation - Single Transaction Dollar Threshold rule by adjusting the TotalXactionAmt condition, as well as ensuring that corresponding events are generated and matched by connectors. The use case involves two main resources: 1) "Trading Violation - Single transaction dollar threshold rule" which identifies if a trader has exceeded the single-transaction dollar limit set at $500,000. This can be customized through editing the rule. 2) "Trading Violation - Single transaction units threshold rule" to identify if the trader has exceeded the limit of 500,000 units for specific asset types like stocks, bonds, and options. These resources are supported by specific filters in tools like ArcSight FraudView and require that FlexConnector(s) provide events meeting certain criteria to trigger the rule. The primary function is to ensure compliance with transaction limits and detect potential trading violations. This passage discusses two main types of events related to trading violations: Purchase Events and Sell Events. These are identified using specific filters, which should be configured accordingly. The default rule for a single transaction involving over 500,000 units of a particular asset type triggers a violation if exceeded. Users can customize this threshold by editing the rule. The passage also provides information on resources that support this use case, including a rule for identifying trading violations based on unit transactions and two filters: one for Sell Events and another for Purchase Events. These filters are part of ArcSight Confidential's FraudView v1.0.1 and are designed to identify specific financial events such as purchases or sales of assets like stocks or options. The table accompanying the text lists these resources with descriptions and URIs, indicating their role in supporting the Trading Violation - Single Transaction Units Threshold Use Case. The use case for identifying if a trader has exceeded the daily transaction threshold of 100 is based on the Trading Violation - Transactions per day threshold rule. To trigger this rule, FlexConnector(s) must supply events of either Purchase Events or Sell Events, with specific filters configured as required. By default, the rule triggers when a trader exceeds 100 transactions in a day; however, this can be customized by editing the DeviceCustomNumber3 condition to specify a different single transaction amount. This use case relies on two main resources: Trading Violation - Transactions per day threshold and Trader Statistics. The former identifies if a trader has exceeded the set threshold of 100 transactions in a day, while the latter tracks trade events, types, amounts, units, and keeps an active list of traders for further analysis. Overall, this use case is designed to help identify potential trading violations by tracking the number of daily transactions per trader and flagging those who exceed the set threshold of 100 transactions in a day, with customization options available for specific needs. This summary outlines several key aspects of a specific use case within ArcSight FraudView, focusing on identifying potential trading violations related to exceeding daily limits for asset types such as stocks or options. The primary purpose of this use case is to monitor traders who may be engaging in excessive trading activities beyond predefined unit thresholds. Key elements include:

• Identification of sell and purchase events involving financial assets like stocks or options, requiring that corresponding events are generated by a connector and matched against specific conditions set within the system.

• The necessity for connectors to set particular event fields with designated values.

• Implementation of a unit threshold rule (initially set at 500000 units), which can be customized as per user configuration.

• Integration of FlexConnectors for data input and use of specific filters designed for purchase and sell events.

• The table provided lists the resources necessary to support this use case, highlighting the components required for its implementation and operation within ArcSight FraudView.

This document outlines several key components of the ArcSight FraudView system, which is designed to detect and prevent fraudulent activities in trading environments such as those found in investment banking. The main features include: 1. **Per Day Threshold Use Case**: This rule is used to monitor if a trader has exceeded the predefined daily threshold for asset units, set at 500,000 by default. It helps identify potential violations and ensures compliance with trading limits. 2. **Resource Description**: The resources include:

• **Trading Statistics**: Tracks trade events, including type, amount, and unit details using the Trader Statistics active list.

• **Transaction Statistics**: Monitors account-level data such as aggregated asset amounts, monetary values, transaction counts, and the date of the last transaction through the Active List ArcSight resource.

• **Sell Events**: Identifies sell transactions of financial assets like stocks or options, ensuring that corresponding events are generated by the connector and matched with specified conditions.

• **Purchase Events**: Similar to Sell Events, this filter identifies purchase transactions of financial assets and ensures proper event generation and matching.

3. **Resource Types and URIs**: The resources are categorized under specific types such as Industry, Event Type, Book Keeping, etc., with unique URI references for identification and integration within the system. 4. **Appendix B: FraudView Resources By Type**: This appendix details all available FraudView resources by type, including active channels, lists, asset ranges, dashboards, data monitors, destinations, field sets, files, filters, and profiles. Each resource is crucial for different aspects of monitoring and detection within the investment banking trading environment, ensuring comprehensive fraud prevention strategies are in place. This document serves as a guide to understanding and utilizing the various tools and resources available within the ArcSight FraudView system, enabling effective management and mitigation of fraudulent activities in investment banking. The document "ArcSight Confidential" provides a guide for using ArcSight™ FraudView v1.0.1, focusing on specific resources and functionalities such as Active Channels, Active Lists, and other related features. Key points include:

• **Active Channels**:

1. **Accounts** - Displays accounts added to the FraudView watch list in the last two hours. 2. **Financial Transactions** - Shows buy and sell events from the last two hours. 3. **Fraud Early Warning** - Highlights correlated events within the last two hours, potentially indicating fraudulent activity. 4. **Fraud Live Channel** - Continuously shows events received in the last two hours, with a sliding window that always displays exactly the latest data, excluding events that triggered rules.

• **Active Lists**:

1. **Account Country Numbers** - Stores credit card account numbers and their creation country, requiring manual updates. 2. **Account Lockouts** - Populated by the account lockout rule, used to determine if a password reset is preceded by an account lockout. 3. **Investigate List** - Contains rule names that immediately add accounts generating these rules to the Investigate list. 4. **Suspicious Accounts List** - Also contains rule names for immediate addition of accounts to this list when specific conditions are met. 5. **Watched Accounts List** - Includes rule names for adding accounts to a watchlist as per certain rules. These resources and functionalities help in monitoring and detecting fraudulent activities efficiently using the ArcSight™ FraudView v1.0.1 tool. The document provides an overview of the functionalities and data storage mechanisms within ArcSight FraudView, version 1.0.1. The active list in question is used to store various types of information that are crucial for monitoring and detecting fraudulent activities. Here's a summary of each type of information stored in this active list: 1. **Fraudulent SSN (Social Security Number)**: This list serves as a repository for storing SSNs associated with potential fraud cases, requiring regular manual updates to maintain its accuracy and effectiveness in combating fraudulent activities. 2. **Daily Transaction Statistics**: It tracks the total amount transferred by each account on a daily basis along with the number of transactions performed by those accounts. This information is dynamically updated using specific rules within the system. 3. **Entitlements for Trading Bonds, Equities, Futures, and Options**: The list includes trader accounts that are legally allowed to engage in trading these financial instruments. This segregation helps in enforcing compliance and risk management policies related to investment banking activities. 4. **Country Codes of Concern**: This active list contains country codes where a significant number of fraud incidents have been reported or are known to be prevalent, which aids in prioritizing the response mechanisms based on the level of risk associated with each country. 5. **Aggregated Weekly ArcSight Statistics and Solutions/FraudView Amounts**: It compiles statistical information about account transactions and amounts, providing a trend analysis that helps in identifying any unusual patterns or escalations indicative of fraudulent activities. Each type of data is stored and maintained within the active list to support various aspects of fraud detection, risk assessment, and compliance monitoring across different sectors including investment banking and trading operations. The provided text outlines various lists and their functions within ArcSight's FraudView solution, categorized based on the risk level of transactions or devices they are associated with. These include: 1. **OFAC (Office of Foreign Assets Control)**: A blacklist that stores country codes for OFAC-banned countries. This list is crucial in prioritizing risks and is used in the Priority Formula under High Risk - Attributes/Device Risk. 2. **Active List**: Stores country codes from ArcSight, particularly relevant to high-risk transactions or devices identified as potentially involved in fraudulent activities (High Risk - Attributes/Transaction Risk). 3. **Known Fraudulent Addresses**: Contains IP addresses known for fraudulent activity and requires manual updating. It is part of the Priority Formula under High Risk - Attributes/Device Risk. 4. **Low Risk Transactions**: Lists transaction types with low risk that should be updated, impacting the Priority Formula under High Risk - Attributes/Transaction Risk. 5. **Medium Risk Transactions**: Similar to Low Risk Transactions but for medium-risk transactions, also contributing to the Priority Formula under High Risk - Attributes/Transaction Risk. 6. **High Risk Transactions**: Lists transaction types that inherently carry a high risk and are essential in the Priority Formula under High Risk - Attributes/Transaction Risk. 7. **Password Reset Lockout Rule**: An active list populated by Windows account lockout rules, used to determine if password resets precede an account lockout (Book Keeping). 8. **Payees List**: Stores information about created payees and the accounts that use them, relevant for Book Keeping activities in financial transactions. 9. **Suspicious Accounts**: Contains accounts with suspicious activity, potentially involved in fraudulent or risky behaviors but not explicitly linked to specific risk categories (not directly categorized in the provided text). Each list serves a distinct purpose within the broader fraud detection and prevention framework of ArcSight's FraudView solution, each contributing to different aspects of financial security and transaction monitoring based on their respective risk levels. The document outlines various active lists within the ArcSight FraudView solution, which are designed to detect and manage potential fraudulent activities by storing suspicious IP addresses, bank IDs, payees, Merchant Category Codes (MCCs), transaction statistics, and accounts suspected of involvement in fraudulent activities. These lists serve as part of the Risk/Priority Formula used to identify high-risk scenarios and escalate alerts accordingly. The document includes specific details on how each list is populated and maintained, emphasizing the manual addition of known suspicious items when automated rules alone are insufficient for detection. This document provides an overview of resources available within ArcSight™ FraudView v1.0.1, focusing on various types such as asset ranges, dashboards, and data monitors related to accounts and possible fraudulent activities. Key details include: 1. **Asset Ranges**: Defined IP Addresses used by Russian Solutions/FraudView/RBNet/Business Network, specifically RBNet1-RBNet183. 2. **Dashboards**:

• **Account Overview**: Displays accounts added to the FraudView watch lists with severity colors indicating their status.

• **Possible Fraudulent Accounts**: Shows information about accounts in the Investigate List active list.

• **Suspicious Account Overview**: Provides details on Suspicious Accounts in the Suspicious Accounts active list.

• **Watched Accounts Overview**: Displays information about Watched Accounts in the Watched Accounts active list.

3. **Data Monitors**:

• **Account Escalation**: Shows accounts added to FraudView watch lists, with colors indicating severity.

• **Last 20 Events for Investigate List, Suspicious Accounts, and Watched Accounts**: Provides a summary of the last 20 events generated by these active lists.

• **Possible Fraudulent Accounts Data Monitor**: Displays information about accounts in the Investigate List active list.

These resources are crucial for monitoring and investigating potential fraudulent activities within the organization's network, aligning with ArcSight™ FraudView v1.0.1 functionalities to detect and respond to financial fraud more efficiently. The document provides a comprehensive overview of various resources related to ArcSight's FraudView software, specifically designed for monitoring and detecting fraudulent activities in accounts. Key components include data monitors, notification destinations, field sets, files, archives, and filters. Here’s a summary: 1. **Suspicious Accounts Data Monitor**: Displays information about accounts added to the Suspicious Accounts list within ArcSight's FraudView solution. This helps in monitoring potentially fraudulent activities by highlighting these accounts for further investigation. 2. **Watched Accounts Data Monitor**: Similar to the Suspicious Accounts monitor, this data monitor shows details of accounts that have been added to the active list in the Watched Accounts section of the ArcSight FraudView solution. It aids in keeping an eye on potentially risky account activities. 3. **Fraud Analyst Notification Destination**: This is the default notification destination for the ArcSight FraudView package, intended to alert the admin user about potential fraudulent activities or incidents detected by the system. 4. **Financial Transactions and Files Field Sets**: These field sets are specific to the ArcSight FraudView solution and are used to categorize and analyze financial transactions and other related data that might indicate fraudulent behavior. 5. **Fraud Monitoring Files**: The document lists two files - one for a .jlx channel and another for a .pro channel, both of which pertain to fraud monitoring activities within the FraudView solution. These files are crucial for configuring and managing the detection processes. 6. **Fraud Console Update Archive**: Contains all necessary files required for updating the ArcSight console to be compatible with FraudView, facilitating smooth integration and functionality enhancement. 7. **ThreatLevelFormula and security_event strings File**: Define priority levels and specific field names used in the fraud monitoring process within the software. These are essential configuration settings that help tailor the system's response to different threat levels. 8. **ATM Filter**: This filter is designed to identify ATM-related transactions or activities, which can be indicative of fraudulent behavior, making it a crucial tool for risk assessment and prevention in financial services environments. Overall, these resources collectively support the functionality of ArcSight’s FraudView solution, enabling efficient monitoring, detection, and response to potential fraud incidents within accounts managed by the software. The text provides instructions for configuring filters in the ArcSight FraudView system to detect various authentication events related to account access, including attempts, failures, success, and creation events. These filters are designed to ensure that specific events are generated by a connector and matched with certain conditions. Additionally, it is suggested that these filters may require setting particular event fields to specific values in order to function effectively within the system. The document discusses various filters used in ArcSight FraudView, a software for detecting and preventing fraud, along with their functionalities and applications. Here are the summaries of each filter mentioned: 1. **Account in This filter** checks for accounts on active lists such as Investigate List, Suspicious List, and Watched List. These accounts are used by the Priority Formula to assess risk within the Risk Modeling/Account Risk category. 2. **Activity From This filter** retrieves events related to fraudulent accounts listed in the Investigate List, Suspicious Accounts List, and Watched Accounts List. These events are escalated for monitoring under Escalation Monitoring, indicating potential issues with these accounts. 3. **All Account Additions between watch lists** filters collect all escalation events across different watch lists, facilitating a comprehensive view of account additions within the FraudView system. 4. **All Fraud Correlation events** not under the Book Keeping group are retrieved to identify and manage fraud occurrences in the Solutions/FraudView environment. 5. **Amount Null This filter** checks if the Currency Amount field is empty, which could be indicative of certain anomalies or errors within financial transactions. 6. **Brute Force This filter** identifies events that may suggest brute force attacks, which are common types of fraud attempts and need to be monitored closely in security systems like ArcSight FraudView. These filters play crucial roles in maintaining the integrity and security of the data processed through the ArcSight FraudView system by ensuring that suspicious activities and potential threats are promptly detected and addressed according to predefined risk models and escalation protocols. The text provides an overview of various filters within ArcSight FraudView v1.0, each designed for specific fraud detection and analysis tasks: 1. **Login Force Filter**: Identifies brute-force login attempts typically logged by an IDS (Intrusion Detection System). 2. **Buy or Sell Patterns Filter**: This filter identifies buy or sell events based on predefined patterns and supports the By-Sell Patterns pattern, useful for financial fraud detection. 3. **Country of Concern Filter**: Checks if a connection is made from a country listed in the active Countries of Concern list, crucial for risk modeling to determine device risk. 4. **Credit Card Transaction Filter**: Used to identify credit card transaction events, ensuring that corresponding events are generated by the connector and matched with specific conditions set in this filter. 5. **CurrencyNull Filter**: Checks whether a currency amount is associated with an account listed in the active Account Statistics list, useful for financial transactions monitoring. 6. **Fraudulent Account Filter**: Retrieves events indicating that an account has been added or escalated to the Investigate List, important for correlation and investigation. 7. **GeoNotNull Filter**: Ensures that accounts have a country code associated with them in the Geographic Access Records active list, useful for tracking geographical access patterns. 8. **High Risk Transaction Filter**: Checks if a transaction type is on the High Risk Transaction active list, which influences risk assessment according to the Priority Formula. Each filter serves a distinct purpose within the fraud detection ecosystem of ArcSight FraudView v1.0, ensuring comprehensive coverage against potential fraudulent activities across various contexts and applications. The provided text outlines various filters used in risk modeling within ArcSight, focusing on different aspects such as IP address reputation, transaction types, geographical locations (through country Geo codes), password reset events, and payee creation events. Each filter plays a crucial role in determining risk levels for devices or transactions based on specific criteria from pre-defined lists or events: 1. **Known Address Filter**: This checks if the IP address of a connection is listed as fraudulent by ArcSight FraudView. It helps to identify potentially risky connections and is used in the Priority Formula to assess device risk. 2. **Known Hostile Address Filter**: Similar to the Known Address Filter but goes further to check against ArcSight System/Threat Tracking lists, which include threats tracked under various active lists. This aids in identifying hostile IP addresses associated with potential threats. 3. **Low Risk Transaction Filter**: It identifies transactions that are on a list of low-risk transactions, helping to assess the risk level of such transactions. 4. **Medium Risk Transaction Filter**: This filter is used for transactions identified as medium-risk based on their type, contributing to an overall assessment of transaction risks. 5. **OFAC Blacklist Filter**: It checks if the country associated with a connection contains a Geo code that has been blacklisted by OFAC (Office of Foreign Assets Control). This helps in assessing device risk by considering the geographical location of the IP address involved. 6. **Password Reset Filter**: Used to define and detect events related to password resets for certain accounts. It requires specific conditions from connectors to be met, ensuring that these events are accurately captured and processed. 7. **Payee Created Filter**: Identifies events where a payee has been created for an account. This involves checking whether the corresponding event is generated by the connector and matches the set filter conditions. These filters collectively contribute to a comprehensive risk management framework within ArcSight, ensuring that various aspects of potential fraudulent activities or risky transactions are effectively identified and acted upon based on predefined risk levels. The provided text discusses various filters used within ArcSight FraudView, a software tool designed for detecting and preventing fraud through patterns of behavior that may indicate fraudulent activities. These filters are categorized by their purpose and include identification of payment, purchase, sell events, suspicious accounts, and IP addresses associated with financial transactions or user connections. The filter named "Payment" is used to identify when payees are created or payments are issued, ensuring that the corresponding event is generated by the connector and matches specified conditions. The "Purchase Events" and "Sell Events" filters are designed to detect purchase and sale activities involving financial assets like stocks or options, also requiring event generation by the connector and adherence to predefined criteria. Another type of filter, "Suspicious Account," triggers when an account is added to or escalated in status within the active list for suspicious accounts. This helps in correlation with other events that may indicate fraudulent activity. The "Suspicious Address" filter checks if an IP address associated with a connection has been flagged as suspicious and is used by the system to assess device risk according to priority criteria. Lastly, there's a mention of a "Suspicious Bank Id" filter which focuses on identifying bank Ids that have been flagged as potentially risky or involved in fraudulent activities, though this specific description lacks details about how it works or what role it plays within the broader system functions. Overall, these filters are crucial for proactive monitoring and early detection of various types of fraud, ensuring that financial transactions and account activities comply with established security measures and policies. ArcSight FraudView is a software tool designed to help organizations identify potential fraudulent activities within their transactions, focusing on suspicious payees, country codes in payment concerns, times of day for transaction occurrences, Merchant Category Codes (MCC), foreign transactions by account numbers, and transactional activity. It uses specific filters like Suspicious Payee, Payment Countries of Concern, Time of Day, Top Loss MCC, Foreign Transaction by Country, Transaction Count Associated with an Account, and Transactional Activity to assess risk levels based on the 1.0/Risk Modeling/Destination Risk formula. The tool helps in managing financial risks associated with various types of transactions within the organization. The text provides an overview of various filters, profiles, and their functionalities within the ArcSight FraudView system, a platform for detecting fraud and suspicious activities in complex environments like investment banking and brokerage. Key points include: 1. **Filters**:

• **Watched This filter** detects when accounts are added to the Watched List in Solutions/FraudView. It is used for escalation monitoring of events.

• **Wire Transfer Exists filter** checks if wire transfer events associated with specific accounts exist on the active list, ensuring they meet certain conditions and that the connector generates corresponding events.

2. **Profiles**:

• **Account Activity profile** identifies unusual patterns in account activities by analyzing at least two elements observed within the last 24 hours.

• **Accounts and Amounts profile** detects patterns associated with credit card transactions, requiring at least two elements to be present over the past 15 days.

• **Buy-Sell Patterns profile** uncovers buy-sell trading patterns using at least three elements observed within a 24-hour period.

• **Countries and Amounts profiles** are similar in functionality to detect credit card transactions, requiring two or more elements observed over the last 15 days.

• **MCC profile** focuses on detecting specific financial transaction types related to merchant category codes (MCC), with a requirement of at least two elements observed within the same timeframe as other profiles.

These features are designed to assist in fraud detection and prevention by analyzing patterns and activities that may indicate fraudulent behavior or suspicious transactions across different sectors including investment banking, brokerage, and credit card processing. The provided text discusses various queries and functionalities within the ArcSight™ FraudView v1.0.1 software, focusing on detecting patterns, summarizing account activity, querying transaction trends, and escalation model correlation events. Key points include: 1. **Detection of Patterns**:

• **Payment Profile** is designed to identify anomalies by analyzing non-ArcSight events with at least three elements that have occurred at least twice in the last day.

• Another profile targets matching payment activities, requiring a minimum of three elements and observed at least twice within the same timeframe.

2. **Summarization Queries**:

• **Account Activity** queries provide summaries for different transaction types, account IDs, and payee companies. They are accessible through specific URIs under Solutions/FraudView 1.0.

• **Payment Totals** query sums the total monetary amounts transacted by each account in the last 24 hours.

• **Behavior Trend** overview summarizes transaction information over a week, useful for trend analysis.

3. **Escalation Model Correlation**:

• **Fraud Correlation Event Trend** retrieves the number of times tracked rules have fired within the last day. This is crucial for monitoring active escalations.

• **Investigation Reports** retrieve events or payment activities related to a specific account, with details accessible via runtime specification in the report setup.

These queries and functionalities collectively aim to enhance fraud detection and investigation capabilities by providing insights into complex transaction patterns and trends within organizational data, leveraging ArcSight's FraudView tools. The provided information outlines several queries available within the ArcSight FraudView 1.0 interface, focusing on different aspects of financial transaction monitoring and analysis for possible fraudulent activities. Here's a summary of each query: 1. **Payments AccountId Field**: This query allows users to view the Payment account ID field at runtime, providing details about transactions involving specific accounts. 2. **Top 10 Fraud Violations - Escalation Model Active Lists**: Displays the number of times rules tracked in the escalation model have fired over the last week, indicating potential fraudulent activity related to account violations. 3. **Suspicious Accounts - Possible Fraudulent Activity**: Retrieves events where accounts are suspected of being involved in possible fraudulent activities during the last week, highlighting suspicious transactions. 4. **Top 10 Traders - Traded Amounts (Buy/Sell) - Currency**: Lists the top 10 traders based on buy and sell transaction amounts in a specific currency over a week's period. 5. **Top 10 Traders - Units Bought or Sold**: Identifies the top 10 traders by the number of asset units bought or sold during the same timeframe as above. 6. **Total Transactions per Account Per Day**: Sums up all transactions for each account on a daily basis, providing an overview of transaction activity. 7. **Trader Currency Trend by Day**: Shows the amount bought and sold by a specified trader in currency terms over a week's period, breaking it down day-by-day. 8. **Trader Units Trend by Day**: Details the number of asset units bought or sold by each trader on an account-per-day basis over the course of a week. 9. **Transaction Statistics - Total Traded Amount and Units per Trader Per Day**: Provides a summary statistic for transactions, including total numbers of transactions, total traded amounts, and total units traded per trader on a daily basis. These queries are part of the ArcSight FraudView 1.0 interface, designed to assist in monitoring financial transactions for signs of fraudulent activity by providing detailed insights into transaction patterns and suspicious activities across various accounts and traders. In the past 24 hours, using the ArcSight FraudView 1.0 solution, you can access various query viewers and reports to analyze payment activities, fraudulent account detection, and overall suspicious transaction patterns across multiple accounts. Key features include:

• **Query Viewers**: These allow you to drill down from general transactions to specific payees paid by a selected account. The amounts in these detailed views may not sum up to the total shown due to the inclusion of non-payee transactions. There are four types of query viewers:

• **Payees by Account**: Displays all the payees that were paid by each account, ordered by payment details and time. This viewer refreshes every 15 minutes.

• **Transactions per Account**: Shows the total count of transactions for each account, with an option to drill down into the total amount transacted.

• **Fraudulent Accounts (Cases)**: Lists all cases related to possible fraudulent accounts, ordered by stage and time.

• **Tickets**: Displays all active cases regarding potential fraudulent accounts as per the ArcSight Solutions/FraudView 1.0.

• **Reports**: These provide a detailed summary of account activities:

• **Account Detail Report** (last 24 hours): Shows all events for the specified account ID.

• **Payment Activity Report**: Focuses on specific accounts entered in the Payment AccountId field, displaying payment details.

• **Investigation Summary Report**: Provides a summary of activities over the last 24 hours for a given account ID.

• **Overview and Total Amount Report**: Displays the number of transactions and total amount for every account within the last 24 hours.

• **Early Warning Violations Report**: Shows how many times active escalation model rules have fired in the last 24 hours, indicating potential fraud alerts.

• **Top 10 Suspicious Accounts Report**: Lists the 10 accounts with suspicious general activities based on ArcSight Solutions/FraudView 1.0 data.

These tools help in monitoring and detecting fraudulent activities efficiently by providing detailed insights into transaction patterns and account behaviors over the past day. The ArcSight™ FraudView v1.0.1 Guide provides detailed reports on various aspects of fraudulent activities and potential fraud events within a trading environment, including trader information, traded asset units, correlation event escalation, account access patterns, and more. Key highlights include: 1. **Top 10 Traders by Trade Amounts**: This report ranks the top 10 traders based on their buy or sell transactions over a week, showing amounts in terms of currency exchange. 2. **Trader Units Trend**: Displays daily trends in the number of asset units bought or sold for specific traders throughout a week. 3. **Rule Escalation Events**: Shows how often rules tracked in an escalation model have fired within the last week. 4. **Multiple Account Access from Single IP**: A rule that triggers when at least three accounts are accessed from a single IP address within two minutes, indicating potential fraudulent activity. 5. **Access From Different Countries**: Another rule identifies account access attempts from two different countries within an hour, which can be indicative of suspicious behavior. 6. **Account Creation and Access Attempts from OFAC Blacklisted Countries**: This rule detects instances where accounts are created or accessed from blacklisted countries by the Office of Foreign Asset Control (OFAC), which could signify fraudulent activities related to sanctions evasion. These reports help in identifying potential fraud patterns, monitoring suspicious activity, and enforcing compliance with regulations such as those set forth by OFAC. The provided text describes various rules used by ArcSight's Account Lockouts and FraudView solutions, which are designed to detect and prevent fraudulent activities such as unauthorized logon attempts, account creations from specific countries or IP ranges, use of public email addresses, suspicious registration times, creation using fraudulent Social Security Numbers (SSNs), and triggering escalation actions like adding accounts to investigation lists if certain conditions are met. These rules help in identifying potential fraud scenarios by analyzing various aspects such as login activities, registration details, and the origin of account creations. The detected information is then used to manage account lockouts and alert users about suspicious activities through predefined escalation paths involving different solution modules like Investigate List, Suspicious Accounts List, and Watched Accounts List within the FraudView framework. The provided document, referenced as "ArcSight Confidential ArcSight™ FraudView v1.0.1 Guide," outlines various rules and resources within the ArcSight FraudView software focused on detecting and preventing fraud in different sectors such as banking and investment, credit card transactions, and more. Key features include: 1. **Brute Force Login Detection**: This rule detects when an account is accessed immediately following a brute force attack, aiming to prevent unauthorized access. 2. **Foreign Transaction Rule**: Identifies foreign transactions from countries different than where the account was created, necessitating manual definition of account numbers and their originating country in an active list. 3. **Daily Transaction Statistics**: Automatically updates daily transaction totals for each account based on total number of transactions and amount processed. 4. **Entitlements Violation Rule**: Detects unauthorized financial transactions by comparing the type of instrument used with what is explicitly defined as entitled for that account in an active list specific to financial instruments. 5. **Escalation Rules**: Specifically designed to handle cases where an account is repeatedly added to lists indicating potential fraud, such as Suspicious Accounts or Watched Accounts. The third instance triggers removal from the initial list and addition to another list (Investigate or Suspicious Account) for further investigation. 6. **Excessive Wire Transfer Rule**: Monitors accounts that execute more than three wire transfers within two days, potentially indicative of fraudulent activity in this sector. Each rule is associated with a specific category and type, such as "Specific/Credit Card" or "Industry/Banking," providing targeted fraud detection for various aspects of financial transactions and account management. The document outlines several rules within ArcSight FraudView v1.0.1 designed to detect and prevent fraudulent activities in banking transactions. These include:

• **Excessive Wire Transfers**: This rule triggers when an account makes at least three wire transfers to the same payee within five minutes, indicating potential excessive or suspicious activity.

• **Geographic Disparity**: It alerts if an account is accessed from more than one country in under an hour, which could be a sign of fraud.

• **Login from Known Fraudulent IP Address**: This rule detects access to the account from a known malicious IP address, helping to prevent fraudulent use of stolen credentials.

• **Multiple Accounts Paying Same Payee**: Identifies instances where multiple accounts send payments or wire transfers to the same payee within five minutes, which might suggest collusion or unauthorized usage.

• **Multiple Failed Logon Attempts**: Triggers when there are three consecutive failed login attempts within one minute across different accounts, potentially indicating an automated attack or fraudulent attempt.

• **Password Resets and Lockouts**: Rules that monitor password resets and require a lockout preceding any reset to prevent unauthorized access. Additionally, it monitors the creation of payees and updates related lists accordingly.

These rules are part of ArcSight FraudView's functionality to help financial institutions identify and mitigate potential fraudulent activities by monitoring unusual patterns in banking transactions. The provided text outlines a series of rules and processes within ArcSight for detecting potential fraudulent activities in various contexts, including bookkeeping, payment processing, suspicious transactions, and login behavior from specific countries or IP addresses. Here's a summary of each rule: 1. **Payee Created Rule**: This rule identifies when a payee is created by the same user who will be paying for it. If a payee is created by the user responsible for payment within 2 minutes and during suspicious times, the rule adds this payee to a list associated with users who have created such payees. 2. **Paying Suspicious Payee Rule**: This rule identifies payments made to payees listed as suspicious based on previous transactions or manual entry. The list of suspicious payees is populated by other rules and requires manual additions for known entities. 3. **Penny Stock Transactions Rule**: This rule detects any purchase or sale of over 100,000 units at a price below $0.75 each, which could indicate fraudulent activities in the investment banking sector. 4. **Successful Login from Country of Concern Rule**: Identifies successful logins originating from countries listed as potentially risky and defined in the active list. This helps to monitor unauthorized access attempts from high-risk areas. 5. **Successful Login from Suspicious IP Address Rule**: Detects successful logins from IP addresses known for suspicious activities, which are added to a separate active list populated by another rule about accessing multiple accounts from a single IP address. These rules collectively aim to provide an early warning system against fraud and suspicious activities across different domains of financial transactions and access controls. The provided summary outlines the functionalities and characteristics of specific rules within version 1.0.1 of the udView, which is a part of ArcSight under the FraudView Resources category. This rule set focuses on identifying potential trading violations such as exceeding daily purchasing or selling thresholds in dollar amounts, single transaction values (in both dollars and asset units), and the number of transactions per day or unit. These rules are designed to monitor trader activities within investment banking sectors, aiming to detect fraudulent behaviors by analyzing statistical data aggregated through ArcSight's Trader Statistics active list. Each rule has default parameters set for thresholds which can be adjusted based on specific industry standards or organizational policies. The document outlines several rules and trends within the ArcSight FraudView software to detect and warn of potential fraud in financial transactions. Here's a summary based on the information provided: 1. **Fraud Early Warning**: This involves monitoring transactions for anomalies, such as comparing today’s transaction amounts or volumes with those from the entire previous week, especially for accounts with less than 10 weekly transactions. For such cases, thresholds are set to trigger warnings if today's transaction sums exceed three times last week's totals or if the number of transactions exceeds three times the average weekly volume. 2. **Transfers Just This rule applies specifically to wire transfers and identifies violations when there are at least three transfers between the same payer and payee within a 5-minute window, which is considered a threshold for potential fraud detection. 3. **Transfers Over Violation Threshold**: This rule triggers an alert if a wire transfer exceeds the specified violation threshold. 4. **Trends and Statistics**: The software includes several trends to analyze account activities:

• **Account Activity Trend**: Summarizes account activity for each event type, including account ID, payee company, and financial instrument, updating every hour.

• **Behavior Trends**: Tracks the weekly number of transactions and their total amount, recording these statistics actively.

• **Fraud Correlation Events**: Stores information about accounts involved in escalating fraud alerts across different rules for future reference and analysis.

• **Transaction Statistics**: Captures daily transaction data including amounts traded, executed transactions, and units traded for each account.

These features collectively aim to provide a comprehensive early warning system and analytical toolset for detecting and preventing fraudulent activities within financial transactions managed by the ArcSight FraudView software. The document provides a comprehensive guide to ArcSight FraudView v1.0.1, focusing on various resources and functionalities for fraud detection and monitoring. Key features include:

• **Event Types**: It lists specific event types such as Account Access Attempt (21), Account Access Failure (22), Account Access Success (23), Account Creation (24), and more. Each type is associated with a filter number, which aids in identifying relevant data for analysis.

• **Filters**: There are numerous filters provided to narrow down the scope of the events, such as Account Registration Using Public Email (filter 67) and Accessing Multiple Accounts from Single IP (filter 59). These filters help in focusing on specific patterns or anomalies indicative of fraudulent activities.

• **Use Cases**: The guide includes use cases that illustrate how these event types and filters can be applied to real scenarios, such as the Account Registration Using Public Email use case which involves reviewing accounts registered with public emails for potential fraud.

• **Reports and Profiles**: It mentions various reports (e.g., Accounts Overview Report) and profiles (e.g., Account Activity profile) that are generated from the data processed through these filters and event types, providing a detailed view of account activities and risks.

• **Risk Factors**: Key risk factors such as Account Severity and Country Risk are highlighted, with specific fields indicating potential issues like financial transactions or access attempts from blacklisted countries.

• **Alerts and Actions**: The guide also outlines actions that can be taken based on the detected anomalies, including adding accounts to fraud lists, creating escalations for account management, and monitoring suspicious activities through early warning systems.

• **Configuration**: Instructions are given for configuring these features by importing CSV files or setting up rules as needed.

Overall, this guide is a detailed manual for using ArcSight FraudView to detect and respond to fraudulent activities in accounts and financial transactions efficiently. The provided text appears to be a series of entries from a document or dashboard related to cybersecurity and fraud monitoring. Here is a summary of the key points:

• **Account Escalation Overview**: Includes data monitor for suspicious transactions and possible fraudulent accounts.

• **Countries of Concern**: Lists specific countries with potential issues related to account registration, such as being on OFAC Blacklist or having problematic SSNs.

• **Daily Transaction Statistics**: Shows statistics for high-risk transactions like logon from RBN, transaction amounts, and suspicious account additions.

• **Entitlements**: Specifically mentions bonds, equities, futures, and options related to accounts in investigate, suspicious, and watched lists.

• **Fraudulent SSN**: Rules and use cases for identifying fraudulent SSNs associated with accounts.

• **Geographic Access Records**: Indicates potential access from risky locations based on account logon data.

• **High Risk Transaction**: Specific transactions that are flagged as high risk due to their nature or location.

• **Low/Medium/High Risk Transaction**: Categories used to classify the level of risk associated with a transaction.

• **OFAC Blacklist Countries**: Lists countries known for having accounts blacklisted by OFAC.

• **Password Reset**: Details related to password resets and potential security issues.

• **Payees Created by User**: Indicates user actions creating payee records which might be suspicious or fraudulent.

• **Possible Fraudulent Activity**: Covers patterns of possible fraudulent activities, such as reconnaissance and infiltration lists.

• **Suspicious Account Additions**: Accounts added to investigate or monitor lists due to suspicious activity.

These entries suggest a focus on monitoring and escala,ting potential fraud in accounts based on various indicators, including transaction types, risky locations, and user actions. This text seems to be a list of terms and abbreviations related to financial fraud detection and management systems, possibly from banking or financial institutions. Here's a breakdown of the key points mentioned in the text: 1. **Suspicious Accounts**: Lists numbers (e.g., 32, 37, 43) associated with different metrics like suspicious addresses, bank details, and payment country occurrences. 2. **Suspicious Addresses**: Includes specific numbers like 79, 98, which might represent counts or codes related to address verification. 3. **Card Used in Foreign Country** rule: Mentioned with numbers such as 51, 84, 112, possibly indicating the application of certain rules based on card usage outside the home country. 4. **Suspicious Bank**: Refers to instances where banks are flagged for suspicious activities, indicated by numbers like 30 and 98. 5. **Top Loss Makers - MCC**: A term related to financial fraud involving specific merchant categories (MCC), with the number 30 associated with FraudView and other metrics. 6. **Transaction in Foreign Country Notifications**: Indicates a system for notifying about transactions taking place outside the usual jurisdiction, possibly linked to suspicious activities. 7. **Activity From Suspicious Accounts filter**, **Country of Concern active list**: Terms related to filtering and monitoring accounts potentially involved in fraudulent activities or originating from certain countries. 8. **Add to Fraud Investigate List** rule: Specifies rules for investigations related to fraud, using numbers like 49 and 111. 9. **Credit Card Transaction event type** and **filter**: Terms related to specific events or transactions involving credit cards that might be flagged as suspicious. 10. **Daily Transaction Statistics** active list: Refers to statistical data on daily financial transactions, possibly monitored for anomalies. 11. **RBNet** (Risk Based Netting) terms: This seems to refer to a risk management system where numbers like 163 and 18 are mentioned alongside other specifications. The text appears to be part of a documentation or internal terminology used within a financial institution for managing and detecting fraudulent activities through various digital tools and metrics. The abbreviations and acronyms might need further clarification based on specific contexts in which they are used, such as within an organization's fraud detection software or database systems. The provided text appears to be a list of entries from a document titled "ArcSight™ FraudView v1.0.1 Guide," which seems to be a guide or documentation for a software product related to fraud detection and analysis, possibly within the field of information security or financial services. Here is a summary of some key terms and their context:

• **Asset Criticality Field**: A parameter in the system that indicates the level of importance or risk associated with an asset. This might be used to prioritize monitoring or auditing actions based on perceived threat levels.

• **Possible Fraudulent Account Events** and **Suspicious Accounts**: These refer to events or accounts identified by the system as potentially fraudulent, which would require further investigation and potential action from fraud analysts or security personnel.

• **User Permissions**: This refers to the access controls set for different users within the system, determining what actions they can perform, such as viewing certain logs or triggering alerts.

• **ATM Authentication event type** and **Fraud Analysts**: These terms relate to specific types of events related to Automated Teller Machine (ATM) transactions that may indicate fraudulent activity. Fraud analysts are responsible for investigating and taking action on suspected fraud cases.

• **Behavior Statistics**, **Behavior Trend query**, and **Device Risk Factor filter**: These refer to monitoring and evaluating system behaviors, such as user activities or device usage patterns, to detect potential anomalies indicative of malicious behavior or security breaches. The risk factor is used to assess the severity of these behaviors.

• **Financial Instrument** and **Entitlements**: Terms related to financial management within an organization, possibly including stocks, bonds, options, futures, etc., which are managed through digital entitlements systems that may be monitored for compliance or suspicious activities.

• **Violations - Today report**, **Early Warning Violations**, and **Financial Instrument** violations: These refer to specific reports or rules triggered by the system due to potential rule violations related to financial activities or user behaviors, indicating a need for immediate attention from fraud analysts or other relevant personnel.

The text also includes references to specific fields such as Device Custom Strings and Flex Strings, which are likely customizable parameters within the software that can be configured according to different organizational needs or compliance requirements. The alphabetical listing at the end of the text seems to indicate a directory structure or indexed reference system for quick lookup within the guide. Overall, this document appears to be designed for use in an environment where real-time monitoring and analysis of potential fraud is crucial, such as in financial institutions, banking sectors, or organizations managing sensitive financial information. The terms used are technical and specific to the software's functionality for detecting and preventing fraudulent activities within its systems. This document appears to be a collection of data fields and related information organized under various categories, primarily focused on financial transactions and security events within an organization. Here's a summarized breakdown based on the provided text: 1. **Instrument Type** - A reference number indicating a specific type of instrument or device used in transactions (e.g., 15). 2. **Escalation Rules**:

• **Account Escalation**: There are several rules for escalating account status based on suspicious activity, possible fraudulent activities, and other criteria:

• **Model Confidence** - Rule based on model confidence level indicating potential fraud (e.g., rule modelconfidence 16).

• **Suspicious to Possible Fraudulent** - Specific rules related to transitioning from suspicion to probable fraud (e.g., rules 43, 49).

3. **Event Fields**:

• **Payment Country** - Indicates the country involved in a payment transaction.

• **Priority** and **Severity** - Parameters used for categorizing events based on their criticality or risk level (e.g., priority 16, severity 15).

4. **Event Types**:

• Various types of security-related events are listed such as Account Access Attempt (21), Account Creation (24), and ATM Authentication (24). Each type has specific attributes like Relevance, Risk Evaluation, etc.

5. **Threat Levels** and **Use Cases**:

• Specific rules related to excessive wire transfer requests or transfers to the same payee are detailed under threat levels and use cases. For example:

• **Excessive Wire Transfer Requests use case 86** - Indicates a threat level based on specific conditions involving multiple transactions to the same payee.

6. **Field Sets and Files**:

• A list of field sets, files, and properties related to fraud monitoring, such as **Fraud Monitoring.properties**, which contains detailed configurations for monitoring fraudulent activities.

7. **Financial Transactions** are listed under categories like Payment Issued (26), Purchase Events (26), etc., each with its own attributes including Payee Account, Payer Account, and related details. 8. **Fields**: Detailed breakdown of individual fields used across various sections, such as **Account Access Attempt**, which has sub-fields indicating different aspects like Account Risk and Alternate Country. This document appears to be part of a larger system for managing financial transactions and detecting fraudulent activities within an organization, providing detailed metadata about each transaction or event that could trigger alerts based on predefined rules. The text provides a detailed overview of various security and fraud-related events as tracked by different systems and tools such as ArcSight FraudView. Here's a summary of the key points mentioned in the text: 1. **Account Lockouts**: Indicates that certain accounts have been locked out, with details including an attacker username (for 63) and userid (for 16). 2. **Activity From Suspicious Accounts** and **Fraudulent Accounts**: Refers to activities occurring on these accounts, such as transactions in different currencies and suspicious account additions. 3. **All Fraud Correlation Events**: Includes events linked to fraudulent social security numbers (SSN) and other fraud-related activities. 4. **Geographic Disparity of Account Access** rules are implemented to mitigate risks associated with unauthorized access, while brute force login attempts and device risk factors are also monitored for high-risk transactions. 5. **High Risk Transaction**: Includes various filters and active lists indicating potential fraudulent activities like credit card fraud and suspicious SSN usage. 6. **ATM Authentication**, **GeoNotNull Filter**, **HourOfDay Variable**, and other specific security measures are detailed to detect and prevent fraudulent activities. 7. **Suspicious Account Correlation Events** involve investigations into linked events that may suggest fraudulent behavior. 8. **Payment Activity** includes various aspects such as payment issued, payee created, and instrument type-related issues, all pointing towards potential fraud or suspicious activities. 9. **OFAC Blacklist**: Lists countries of concern related to sanctions compliance, affecting the security policies enforced within the system. 10. **Investigate List** is actively managed for any anomalies that may indicate fraudulent activities or unauthorized access attempts. The text also mentions specific tools and updates like ArcSight FraudView version 1.0.1 and a software package update (FraudView_Console_Update.zip file), highlighting the continuous efforts to improve security measures and prevent fraud through technological advancements and system updates. The report titled "Payments query 108" and "Suspicious Address33 105" highlights various suspicious activities in financial transactions. Key findings include:

• **Suspicious Bank**: There are reports of suspicious bank activity with a total count of 105, indicating potential fraudulent behavior.

• **Suspicious Payee**: The number of suspicious payees is also high at 105 K, suggesting involvement in fraudulent transactions.

• **Known Fraudulent Addresses**: A list of known fraudulent addresses includes numbers 32, 70, and 97, which are associated with suspicious activities.

• **Fraudulent Payment Country**: The country where the payment is made from is marked as potentially fraudulent for 105 transactions.

• **Transactional Activity**: There are indications of transactional activity in foreign countries (84) and within the country (106), suggesting a pattern of suspicious financial dealings.

• **Null Transactions/Units**: Both null transactions (106) and units (106) indicate potential issues with transaction completeness, which could be indicative of fraudulent activities.

• **Wire Transfer Issues**: There are concerns about wire transfers, with 106 indicating the involvement of suspicious accounts, and a total count of last 20 possible fraudulent account events monitored.

• **Financial Instrument Lockouts**: Accounts have been locked out (lockouts) due to issues related to financial instruments (field 15), specifically linked to known fraudulent addresses or use cases.

• **Low Risk Transaction Filters**: Some transactions are flagged as low risk but still require monitoring, particularly those using active lists and filters that point to suspected fraudulent activities.

• **Flex String Issues**: The flex string fields have potential issues related to the MCC (Merchant Category Code) code field, indicating a need for further investigation based on the formula and risk level specified.

• **Fraud Analyst Correlation**: Medium risk transactions are correlated with possible fraudulent events, suggesting a trend in fraudulent activities that require monitoring through early warning systems and correlation queries.

• **Multiple Accounts Paying Same Payee Rule**: This rule is used to monitor multiple accounts paying the same payee, which is indicative of potential fraud involving multiple entities colluding for financial gain.

• **Multiple Failed Logon Attempts**: The use case involves checking for multiple failed logon attempts on an account, which could be a sign of unauthorized access or fraudulent activity.

Overall, these findings suggest that the transactions and accounts are under scrutiny due to potential involvement in fraudulent activities, requiring further investigation and monitoring by financial institutions and fraud analysts. This document appears to be a documentation or summary of various financial transaction rules, filters, and reports related to user behavior in financial transactions. Here is a condensed version of the key points mentioned in bullet points from the text:

• **User Rule 51, 73, 113**: Refers to specific rules relating to password reset process, possibly indicating that these are sequential steps or stages within a larger system for handling user account security.

• **Transaction Risk Factor 31**: Indicates the risk associated with transactions based on certain factors such as transaction type, amount, frequency, etc.

• **Multiple Transactions by Same User use case 73 profiles**: This suggests that there is a feature or setting in place to manage and profile users who engage in multiple transactions to detect potential misuse or fraudulent activities.

• **Account Activity107**: Indicates the activity log for user accounts, which could be used for monitoring and auditing purposes.

• **Accounts and Amounts107**: A reference to financial account details including transaction amounts, possibly indicating a feature that tracks and reports on monetary flows across various accounts.

• **OFAC Blacklist Countries active list 33**: Lists the countries included in an OFAC blacklist which might be used for compliance checks or preventing transactions with sanctioned entities.

• **Protect 724 Community13**: Refers to a community feature that may help users protect their accounts and transaction activities, possibly offering tips or tools to prevent fraud.

• **OFAC Blacklist filter 33 104**: Filters related to the OFAC blacklist which could be used to block transactions involving blacklisted countries.

• **Purchase Events event type 26**: Refers to specific events triggered by purchase activities, possibly indicating a feature for monitoring and analyzing such events.

• **OFAC Blacklisted Countries active list 60**: Another reference to the OFAC blacklist where certain countries are added to an active list to prevent transactions from or to these locations.

• **Alphabetical listing 107**: A function that lists items in alphabetical order, which could be applied to accounts, users, payees, etc., for easier management and identification.

• **Notifications Buy - Sell Patterns 107**: Notifications related to patterns indicating potential fraudulent activities such as suspicious buying or selling behaviors.

• **Configuring 39 Countries 107**: Feature that allows configuration of which countries are included in the system, possibly for compliance with local regulations.

The document seems to be focused on managing and monitoring financial transactions, particularly focusing on risk assessment through various rules, filters, and reports related to user behavior, transaction patterns, account activity, OFAC blacklist compliance, and potential fraudulent activities. The text provides a list of terms and their associated numbers, all related to financial or accounting contexts. Here's the summary of each entry in alphabetical order:

• **Accessing Multiple Accounts from single IP** (59, 79) - Refers to the rule about accessing multiple accounts using the same internet protocol address.

• **Account Access** (f) - Mentioned without specific numbers, possibly a placeholder for future details or another section heading.

• **Account Investigation** (109) - Refers to procedures related to investigating account issues or suspicious activities.

• **Accounts Overview Report** (109) - A report that provides an overview of accounts and their transactions.

• **ArcSight Confidential ArcSight™ FraudViewv1.0.1 Guide** (121) - Indicates a guide for the software product, possibly referring to how fraud is viewed or managed using this software.

• **Early Warning Violations - Today** (109) - Refers to violations detected in account activities today.

• **Payer Account field** (16) - A specific field related to payer accounts.

• **Payment Activity filter** (71, 74, 75, 76, 78, 81, 105) - Filters used in monitoring payment activities.

• **Reconnaissance List active list** (32) - A type of list used in reconnaissance operations for detecting fraudulent activities.

• **Risk Evaluation field** (16) - Refers to the field related to evaluating risks in financial evaluations.

• **Trader Currency Trend by Day** (110) - Trends observed in trader currency on a daily basis, possibly indicating suspicious activity.

• **Trader Units Trend by Day** (110) - Trends in trading units over time, suggesting monitoring for unusual patterns.

• **Transactions per Account** (109) - The number of transactions associated with each account.

• **Violation Threshold** (52, 81, 114) - A threshold set to trigger an action or alert regarding potential violations in transaction behavior.

The text outlines various suspicious activities detected in a system related to account management and transactions, possibly as part of an anti-fraud or cybersecurity monitoring process. These include: 1. **Transfers Over Violation Threshold**: There were significant number of wire transfers that exceeded certain threshold which could be indicative of fraudulent activity. 2. **Account Creation and Registration Issues**:

• Fraudulent SSN used during account creation, indicating potential identity theft or misuse.

• Account registration from a country considered as a concern for security reasons.

• Suspicious logons (from RBN) detected during account registrations.

• Registration at unusual times which might suggest automated attacks or compromised systems.

3. **Security Event Detection**:

• Lockouts and failed login attempts were recorded, indicating possible brute force attacks on the accounts.

• Use of public email addresses for registration could be a sign of phishing or unauthorized access.

4. **Fraud Investigation and Suspicion Levels**: Actions such as adding to fraud investigation lists or suspicious account lists indicate proactive steps taken by the system to manage potential fraudulent activities. 5. **Device and User Attribute Violations**:

• Usage of devices not configured properly, which could be a part of broader security breaches.

• Excessive requests for wire transfers might signal orchestrated financial fraud schemes.

6. **Security Event Attributes**: The text mentions specific attributes like `securityevent.attribute` that are used to categorize and prioritize these events based on their criticality or nature, which aids in decision-making processes related to account management and security alerts. This summary highlights the various indicators of potential threats detected through automated monitoring systems, emphasizing the importance of such mechanisms in protecting digital assets from fraudulent activities. This text appears to be a list of security events and attributes related to various suspicious activities in an unspecified system or network environment. Here's a summary of the key points: 1. **Security Events and Attributes**:

• **Excessive Wire Transfers to Same Payee**: Triggers when there are multiple wire transfers going to the same payee, with attributes associated like `flexstring2` (field 16) and `modelconfidence` (also field 16).

• **Geographic Disparity of Account Access**: Indicates variations in access locations from known IP addresses or accounts, linked to `priority` (field 16).

• **Login from Known Fraudulent Address**: Triggered by logins from IPs commonly associated with fraud, affecting `priority` and `relevance`.

• **Multiple Accounts Paying Same Payee**: Multiple accounts are linked to transactions with the same payee, impacting both account behavior and potential threat categorization.

• **Multiple Failed Logon Attempts** and **Multiple Password Resets**: Both of these are associated with specific user activities and system interactions.

• **Password Reset Not Preceded by Lockout**: Indicates a security protocol breach where users can reset passwords without prior lockouts, affecting `targetntdomain` (field 16).

• **Payee Created and Paid - Same User**: Events related to creating payees linked to transactions by the same user.

• **Penny Stock Transactions**: Specific trading activities flagged as suspicious, possibly involving high-risk securities.

• **Successful Login from Suspicious Address**: Logins originating from IP addresses considered risky trigger various alerts and attribute fields like `relevance` and `severity`.

• **Trading Violation - Dollar per day threshold**: Exceeding daily transaction limits for trading can lead to violations flagged by social security numbers (SSN) linked to transactions.

2. **Event Filters and Sessions**:

• **Sell Events filter**: Involves specific criteria related to selling events, possibly filtered by certain conditions or parameters.

• **Session Lists**: Includes details on user sessions, potentially indicating multiple failed login attempts or suspicious activities.

3. **Attributes Linked to Specific Fields**:

• Various attributes like `flexstring2`, `modelconfidence`, `priority`, `relevance`, `severity`, `targetntdomain`, `targetprocessname`, and `targetuserid` are linked to different security events, each with specific field numbers that correlate directly to the data structure where these alerts are stored or processed.

4. **Severity Levels**:

• Several events have a default severity level of 15, indicating medium-high priority for investigation, except for some which might be more urgent (severity 16).

This list provides an overview of potential security threats and alerts that can be generated based on anomalous activities within the system. Each event is linked to specific fields in a data structure or database where detailed information about the incident can be retrieved for further analysis. The provided text appears to be a list of terms and their associated numbers, likely part of a documentation or codebase for detecting potential trading violations. Each term is followed by several numbers, which could represent references to rules, use cases, filters, or other identifiers related to suspicious activities in financial transactions. Here's a summary of the key points from the text: 1. **Use Cases and Rules:**

• **Successful Login from Country of Concern (use case 78)** and **Suspicious Address (use case 79)** are related to rules for trading violations based on transaction units or transactions per day thresholds.

• Specific use cases include:

• Trading Violation - Single Transaction Units Threshold rule (52, 113, etc.)

• Transactions Per Day Threshold rule (54, 79, 114)

• Units Per Day Threshold rule (52, 93, 114)

• **Transaction Behavior Anomaly** rules are linked to specific use cases and transactions.

2. **Data Monitoring and Filters:**

• **Suspicious Account Additions active list (37)**, **Filter (37)**, and **Overview dashboard (99, case 92)** are part of monitoring suspicious accounts.

• **Active Lists**: These include:

• Suspicious Accounts (active list 32, data monitor 100, filter 37)

• Susppicious Addresses (active list 79, filter 33)

• Suspicious Bank active list (30), Transaction in Foreign Country active list (30)

• **Payee and Payment Filters**: These include:

• Suspicious Payee filter (105)

• Transaction Risk factor (31)

• Suspicious Time of Day filter (64, 76)

3. **Transaction Statistics:**

• **Transactional Activity active list (37)** and its associated filters (37, 106).

• **Transaction Statistics**: This includes:

• Active lists (89, 90, 93, 94, 98)

• Filters (105)

• Queries and trends (115)

4. **Specific Violation Thresholds:**

• **Transfers Just Under Violation Threshold** rule (53), use case (82).

The text seems to be describing a system or process used for detecting financial transaction anomalies, where each term represents a specific feature or action within the system related to suspicious activities. The numbers likely serve as identifiers or references to configurations, rules, and data points in a database or software application designed to monitor and analyze such transactions. The text provides a detailed overview of various aspects related to potential fraudulent activities and system violations within an organization. Some key points include the use of specific fields (like field 16, Units16) in queries for possible fraudulent accounts, suspicious trader behavior analysis, and the detection of rule violations such as excessive wire transfer requests, brute force login attempts, and unauthorized access from OFAC blacklisted countries. The system uses a "Threat Level Formula" to assess the severity of these threats, which is influenced by account activity (rule 30) and trends observed in behavior patterns. The formula is detailed in the "ThreatLevelFormula.xml" file, where it's linked to specific behaviors like excessive wire transfer requests or unauthorized access from blacklisted countries. The organization also employs a trouble-ticket system for managing potential fraudulent accounts, with queries that help identify suspicious activities such as transactions and account creations using fraudulent Social Security Numbers (SSN). These fraudulent activities are correlated across various events in the "Fraud Correlation Events." For traders specifically, there are detailed reports on currency trading trends by day, unit trends by day, and statistics related to their registration details. Violations within these trader activities include card use in foreign countries, excessive wire transfer requests to the same payee, and violations of daily dollar thresholds for both purchasing and selling activities. Overall, this text outlines a comprehensive approach to monitoring potential fraudulent activities using various data fields and rules that are dynamically assessed and reported based on predefined criteria and trends observed over time. This document, titled "ArcSight™ FraudView v1.0.1 Guide," is a comprehensive guide designed to assist users in monitoring and detecting fraudulent activities within their systems using the ArcSight™ FraudView software. The guide provides detailed information on various use cases and filters that can be utilized to identify potential fraud patterns such as: 1. Geographic Disparity of Account Access (case 89): This involves transactions where access is granted from a known location associated with fraudulent activity, prompting a closer examination through the ArcSight™ FraudView software. 2. Trading Violation - Single transaction dollar threshold (case 89): When suspicious single transactions exceed a predetermined dollar amount, this triggers an alert that requires further investigation across multiple accounts and payees. 3. Multiple Accounts Paying Same Payee: This case involves instances where the same payee is paid by numerous different accounts which might indicate fraudulent behavior or collusion among users. 4. Penny Stock Transactions (case 87): Alerts are triggered when transactions involve penny stocks, which can be a sign of potential market manipulation or insider trading that requires scrutiny. 5. Successful Login from Known Fraudulent Address: This use case involves logins coming from IP addresses associated with fraudulent activities and thus necessitates an investigation to determine the legitimacy of such access. 6. Multiple Failed Logon Attempts (case 70): When multiple failed login attempts are made by different users, it can be a sign of potential insider threats or unauthorized access attempts that require monitoring through this software. Additionally, the guide covers other critical fraud detection areas including:

• Password reset not preceded by lockout (case 74)

• Payee created and paid - same user (case 75), with further scrutiny based on suspicious time of creation or day of the week when payments are made.

• Paying Suspicious Payee (case 77): This involves paying vendors or recipients that raise suspicion, warranting a review through this software to detect any fraudulent activities related to these payees.

• Successful login from countries of concern (case 78) and suspicious addresses (case 79), which are crucial for understanding the geographical distribution of access attempts.

• Multiple Transactions by Same User (case 73): Investigate transactions conducted by a single user across multiple accounts, potentially indicative of fraudulent activity or compromised credentials.

• Trading Violation - Dollar Per Day Threshold: Alerts triggered when daily trading volumes exceed pre-defined limits, which could indicate market manipulation or unauthorized trading activities.

• Penny Stock Transactions (case 87): Transactions involving penny stocks are monitored for signs of potential fraud or insider trading.

This guide provides a detailed overview and instructions on how to use the ArcSight™ FraudView software's features to proactively detect various types of fraudulent behaviors, ensuring that organizations can respond swiftly to potential threats and protect their interests effectively.

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.