ArcSight FraudView Solution User Guide 1.0.0_1

Summary:

Based on the provided text excerpt from a document regarding surveillance and compliance checks within a financial or transactional context, here is a summary of the key points mentioned: 1. **Compliance Checks**: The document suggests various methods for checking if an account complies with rules and regulations, including "compliance checks" which could involve verifying transactions against each account (Query 60), screening for fraudulent SSNs used in account creation (Query 12), and other related activities. 2. **Transactional Anomalies**: Specific queries are highlighted to detect anomalies in transaction patterns: - **Total Transactions per Account Query** involves a check on the number of transactions against each account, potentially indicating irregularities or suspicious activity (Query 10). - **Trader Currency Trend by Day Query** analyzes the usage and trends in different currencies used by traders over time (Query 112), which could help identify potential fraudulent activities. 3. **Geographic Disparity of Account Access**: This refers to querying account access from various geographic locations, possibly to detect unauthorized transactions or suspicious activity that might not align with usual patterns (Query 16). 4. **Login-Related Anomalies**: Measures are suggested for dealing with multiple failed logon attempts and other login-related anomalies, which could be indicative of security breaches or fraudulent activities (Queries 67, 71, etc.). 5. **Specific Transaction Rules Violations**: The text mentions violations in specific transaction settings, such as excessive wire transfers to the same payee or transactions exceeding certain dollar thresholds, indicating potential fraud or non-compliance with regulations (Queries 80, 83, 90). 6. **Card Usage Abroad**: Transactions involving cards used in foreign countries could be related to card fraud or other illicit activities and require further investigation (Query 15). 7. **Entitlements Violation** and other specific transaction rules indicate potential compliance issues that need to be addressed, such as unauthorized transactions or settings that might facilitate fraudulent behavior. 8. **Fraudulent Activities Indicators**: The document mentions several indicators of suspicious activities: - **Suspicious Time75**: This refers to events with suspicious timing in transactions. - **Paying Suspicious Payee77**: Transactions where the payee is linked to questionable activity. - **Penny Stock Transactions 87**: Deals involving low-value stocks that might be used for fraudulent purposes. 9. **Geographic Risk of Fraud**: The document suggests monitoring successful logins from countries considered risky due to high fraud rates (Query 78). 10. **Financial Event Types**: Specific events and activities monitored by the system include: - **Penny Stock Transactions 87** - **Wire Transfer Exists filter 110** - **Trading Violation - Dollar Per Day Threshold - Purchased 89, Sold 88** - **Wire Transfer filter 68 74 81 82 83 87 110** - **Trading Violation - Single Transaction Dollar Threshold 90, 128** The document is part of a tool or guide used to monitor and detect fraud in financial transactions within an organization using ArcSight Confidential. It provides detailed methods for querying and monitoring specific events that might indicate fraudulent behavior among the accounts being watched.

Details:

The document "ArcSight™ Solution Guide FraudView v1.0 for ArcSight™ ESM v4.5 SP1" is a comprehensive guide provided by ArcSight, Inc., aimed at introducing and explaining the functionalities of their FraudView solution in conjunction with ArcSight Enterprise Security Manager (ESM) version 4.5 Service Pack 1. The document outlines key details about copyrights, trademarks, acknowledgments, revision history, intended audience, usage instructions, and text conventions within the guide. **Key Points from the Document:**

• **Document Overview:** The guide is designed for users who are looking to understand or implement the FraudView solution in conjunction with ArcSight ESM v4.5 SP1. It provides a detailed overview of the features, functionalities, and benefits that this combination offers to enhance security measures against fraud within an organization's network.

• **Revision History:** The document includes a section detailing version history which reflects updates from the initial release (v1.0) on September 17, 2009. This section is useful for tracking improvements and changes made in subsequent versions of the FraudView solution in relation to ArcSight ESM v4.5 SP1.

• **Customer Support:** For any assistance or questions regarding the use of the guide or the software itself, users are directed to contact ArcSight's customer support team via phone, email, and an online web portal.

• **Text Conventions:** The document adheres to specific text conventions that help in differentiating between different types of information such as warnings, tips, key terms, etc., which aids the reader in navigating through complex technical details efficiently.

**Chapter 1: FraudView Solution Overview** This chapter likely delves into the fundamental concepts and features of the FraudView solution, explaining how it integrates with ArcSight ESM v4.5 SP1 to detect and prevent fraud within an enterprise network environment. It might cover topics such as threat detection mechanisms, real-time alerts, automated investigations, and reporting capabilities that are unique to this specific combination of products from ArcSight. Overall, the "ArcSight™ Solution Guide FraudView v1.0 for ArcSight™ ESM v4.5 SP1" serves as a detailed user manual and reference guide, helping users to get the most out of their investment in both ArcSight's software products and the FraudView solution within the broader context of enterprise security management. This document outlines a comprehensive solution for fraud detection and analysis, titled "FraudView," which is designed to help organizations mitigate financial risks by escalating alerts related to suspicious activities. The solution comprises several key components that work together to identify potential fraudulent patterns and provide early warnings about escalated risk models. Here's an overview of the main elements discussed in the document: 1. **FraudView Solution Components**: This section introduces the broader framework provided by FraudView, which includes various tools and modules designed for different aspects of fraud detection and analysis. 2. **Early Warning Account Escalation**: A mechanism to proactively identify accounts that may be at risk due to fraudulent activities, allowing for early intervention and prevention. 3. **Escalating Risk Model**: An algorithm or model that helps in identifying the severity of risks associated with different transactions or events within a system. 4. **Real-Time Correlation Engine**: A technology component designed to analyze data in real-time to correlate suspicious patterns across various systems and detect potential frauds at an early stage. 5. **Pattern Discovery**: The process of uncovering previously unknown relationships and trends within the dataset, which is crucial for identifying anomalies that may indicate fraudulent activities. 6. **Workflow**: A sequence of steps or procedures followed to perform specific tasks in handling suspected fraud cases from initial detection through resolution. 7. **Use Cases**: Specific scenarios or examples demonstrating how FraudView can be applied to real-world problems, illustrating its effectiveness and practical applications. **Chapter 2: Solution Installation and Configuration** provides detailed steps for implementing the FraudView solution within an organization's infrastructure: 8. **Verify Environment**: Ensures that all necessary hardware, software, and network configurations are correctly set up to support the FraudView system. 9. **Install FraudView Solution**: A step-by-step guide on how to install the FraudView application onto the verified environment. 10. **Installation Troubleshooting**: Addresses common issues that may arise during installation and provides solutions to overcome these challenges. 11. **Assign User Permissions**: Sets up user roles and assigns specific permissions to ensure data security and access control within the FraudView system. 12. **Install ArcSight ESM Console Utility Files From ZIP**: Describes how to integrate utility files needed for the operation of the console with the FraudView solution. 13. **Configure Event Field Aliases**: Sets up aliases for event fields to enhance data handling efficiency and accuracy within the system. 14. **Develop FlexConnector(s) to Generate Events**: Explains how to create custom connectors that can generate events relevant to potential fraud scenarios, which are essential for feeding real-time data into the FraudView system. 15. **Set the Category Device Group**: Defines and assigns categories or groups of devices within the network environment that will use the FraudView solution for detecting fraudulent activities. This comprehensive guide aims to help organizations implement a robust fraud detection system, ensuring they can effectively manage risks associated with financial transactions and protect their assets from potential fraudulent threats. The text appears to be a table of contents for a guide related to fraud detection and management, specifically using the ArcSight FraudView solution. Here's a summarized breakdown of each section:

• **Code**: Section 28 - This likely refers to a unique identification or coding system used in the software or configuration process.

• **Modify the Priority Formula**: Section 28 - Describes how to adjust the formula used for prioritizing alerts based on risk factors.

• **Destination Risk Factor**: Section 30 - Discusses setting up a factor that evaluates the risk associated with the destination of transactions, which could be crucial in fraud detection by identifying potential risky destinations.

• **Configure the Destination Risk Factor**: Section 30 - Provides instructions for configuring this risk factor to enhance the system's ability to identify fraudulent activities based on where transactions are going.

• **Transaction Risk Factor**: Section 31 - Focuses on setting up a metric that assesses risks associated with individual transactions, which is essential in monitoring and detecting suspicious financial movements.

• **Configure the Transaction Risk Factor**: Section 31 - Provides detailed steps to configure transaction risk factors for more effective fraud detection.

• **Account Severity Risk Factor**: Section 32 - Introduces a factor that rates the severity of potential fraudulent accounts, which is crucial for proactive account monitoring and management.

• **Configure the Account Severity Risk Factor**: Section 32 - Offers guidance on setting up this risk factor to better manage and monitor high-risk accounts suspected of fraud or other illicit activities.

• **Device Risk Factor**: Section 32 - Addresses the setup of a metric that evaluates risks associated with devices used in transactions, which helps in identifying potential fraudulent use of devices.

• **Configure the Device Risk Factor**: Section 33 - Provides steps and instructions for configuring device risk factors to improve fraud detection through transaction devices.

• **Download and Install the Fraud Monitoring Dashboard**: Section 35 - Covers how to download and set up a dashboard that visually monitors and displays fraud alerts in real-time.

• **Configure FraudView Solution Content**: Section 38 - Discusses how to customize and configure the content displayed on the FraudView platform, ensuring it aligns with specific organizational needs for effective monitoring.

• **Deploy the FraudView Rules**: Section 39 - Explains the process of implementing rules within the FraudView system to automate and optimize fraud detection processes based on predefined criteria.

• **Configure Account Escalation** and **Configure Cases**: Sections 39 - These sections likely cover how to set up automatic escalations for cases involving suspicious accounts or transactions, as well as managing these cases more efficiently.

• **Configure Notifications**: Section 40 - Provides guidance on configuring notifications within the system to keep stakeholders informed about significant fraud alerts and updates related to risk factors.

This text appears to be a condensed summary or outline of a larger document, possibly related to fraud detection and management tools. Here's a breakdown of the main points covered in each chapter as per your provided text: **Chapter 3: Account Escalation**

• Discusses how accounts are tracked within the system.

• Explains the process of adding accounts to different active lists (Watched, Suspicious, Investigate) based on specific criteria or signals.

• Covers optional configuration for account escalation, including manual escalation and customizing escalation rules.

• Lists resources available for further reference.

**Chapter 4: FraudView Early Warning Use Cases**

• Introduces use cases related to early warning within the fraud detection system.

• Focuses on a specific use case where multiple accounts from a single IP address are accessed, and how to configure this feature.

• Provides resources for further understanding of these use cases.

The text does not provide full details of each chapter but gives a quick overview that can be used as a guide or reference when the complete document is available. This text appears to be part of a document or a series of notes related to security and compliance measures, specifically focusing on detecting and managing risks associated with various suspicious activities that might indicate fraudulent behavior or potential threats from OFAC (Office of Foreign Assets Control) blacklisted countries. Here's a summary of the content:

• **Account Activity From OFAC Blacklisted Country**: This section outlines different use cases where an account's activity originates from an OFAC blacklisted country. Each use case includes steps to configure and resources needed for further investigation or prevention measures.

• **Configure**: Instructions on how to set up alerts or restrictions based on the detected suspicious behavior.

• **Resources**: Tools, templates, or guidelines provided for handling such scenarios effectively.

• **Account Created Using Fraudulent SSN**: This section covers a use case where an account was created using a fraudulent Social Security Number (SSN). Similar to the previous section, it details how to configure and what resources are available for managing this type of risk.

• **Account Lockout Detected**: Use case focusing on when an account lockout is detected, indicating potential unauthorized attempts to access the account. It provides steps to configure and necessary resources for addressing this issue.

• **Account Logon from RBN**: This use case involves a logon attempt from a region considered suspicious based on known risky behavior (RBN stands for Risk Based Network). Configuration and resource details are provided here as well, emphasizing the need for swift action in such cases.

• **Account Registration at Suspicious Time**: Use case related to account registrations occurring during unusual or unexpected times, which could be a sign of fraudulent activity. Instructions on how to configure systems to detect these anomalies and where to find resources for assistance are outlined here.

• **Account Registration From Country of Concern**: Finally, this section deals with suspicious account registrations originating from countries that have shown signs of being involved in potential threats or problematic activities. Configuration tips and resource access points are provided to help address these concerns promptly.

Each use case is followed by a brief description on how to configure the system for alerting and managing risks associated with each specific scenario, along with links to relevant resources for further guidance or tools that can be utilized in such situations. The text provided appears to be a section header for a document or guide, possibly related to cybersecurity or fraud prevention measures. It outlines different use cases with corresponding "configure" sections and resources that need to be considered for each case. Here's a summary of what is being discussed in the numbered sections: 1. **Account Registration from RBN Use Case** - This involves setting up an account through Remote Banking Network (RBN) and configuring security measures to prevent unauthorized access or fraudulent activities. 2. **Configure Section**: Details on how to configure settings related to this use case, likely focusing on authentication methods, suspicious activity monitoring, etc. 3. **Resources**: Additional information or guidelines for implementing the configuration changes discussed in the "configure" section above. 4. **Account Registration Using Public Email Use Case** - Similar to the first use case but focuses on registering an account using a public email address. Configuration includes measures against unauthorized access and fraud prevention techniques. 5. **Configure Section**: Continuation of configuration settings for the second use case, emphasizing security enhancements like multi-factor authentication or monitoring tools. 6. **Resources**: Supplementary materials that help in understanding and implementing the security features specified in the configure section related to using a public email address for account registration. 7. **Brute Force Login Success Use Case** - This involves dealing with successful brute force attacks on login credentials, necessitating configuration changes to strengthen security measures against such attempts. 8. **Configure Section**: Configuration settings aimed at preventing or mitigating the effects of brute force attacks by enhancing authentication processes and implementing rate-limiting features. 9. **Resources**: Supplementary information that provides further insight into techniques for configuring systems to better handle brute force login attempts, including software tools or guidelines from cybersecurity experts. 10. **Excessive Wire Transfers to Same Payee Use Case** - Addresses the situation where there are unusually high numbers of wire transfers going to a single payee, requiring specific configuration settings to detect and prevent potential fraudulent transactions. 11. **Configure Section**: Configuration guidelines for systems that need to monitor such activities closely, potentially including fraud detection models or restrictions on large transactions without additional verifications. 12. **Resources**: Supplementary materials explaining how to set up these configurations in order to effectively manage high-volume wire transfers to a single payee, which is often linked to potential money laundering concerns. 13. **Geographic Disparity of Account Access Use Case** - This use case involves detecting access from unexpected geographical locations using an account, necessitating configuration adjustments to enhance security and prevent unauthorized activity. 14. **Configure Section**: Configuration settings related to restricting or monitoring login attempts based on the user's geographic location. 15. **Resources**: Supplementary materials that assist in configuring software to recognize unusual geolocation patterns and implement corresponding security measures. 16. **Login from Known Fraudulent Address Use Case** - Involves recognizing and responding to logins coming from addresses previously associated with fraudulent activities, requiring configuration settings to enhance network security. 17. **Configure Section**: Configuration adjustments for systems designed to block or closely monitor login attempts originating from known malicious IP addresses or suspicious networks. Each numbered section appears to be a subsection under the main heading "Resources," detailing specific use cases and how to configure them in response to potential risks such as unauthorized access, fraud, brute force attacks, geolocation anomalies, etc. The provided text appears to be a series of sections related to configuring various use cases within an application, possibly in the field of cybersecurity or access management. Each section corresponds to a specific scenario where users might need to configure settings or resources to manage potential threats or user behaviors. Here's a summary of each section and its purpose: 1. **Multiple Accounts Paying Same Payee Use Case**: This involves configuring settings to handle situations where multiple accounts are used to pay the same payee. The detailed configuration steps follow this general description, suggesting that users need to set up specific controls or alerts when such transactions occur. 2. **Multiple Failed Logon Attempts Use Case**: To prevent unauthorized access, it is crucial to configure settings for handling excessive failed logon attempts. This section discusses how to adjust the system's behavior in response to multiple login failures from the same user. 3. **Multiple Password Resets Use Case**: When users frequently reset their passwords, it can be a sign of potential issues like compromised accounts or unauthorized access attempts. Configuring settings here involves monitoring and controlling such activities to maintain account security. 4. **Multiple Transactions by Same User Use Case**: High frequency of transactions from the same user might indicate suspicious activity. The configuration section outlines how to set up alerts for unusually high numbers of transactions in a short period, potentially helping detect fraudulent or unauthorized transactions. 5. **Password Reset Not Preceded by Lockout Use Case**: This use case involves configuring settings where users can reset their passwords without going through the usual lockout process. Such scenarios need careful handling to avoid locking out legitimate users and must be closely monitored for security reasons. 6. **Payee Created and Paid - Same User Use Case**: For cases where a user both creates and pays using the same payee, it's important to configure settings that can detect such dual roles being used by a single individual, potentially signaling misuse of privileges or potential fraud. Each section provides a specific scenario with detailed instructions on how to configure resources within the system to handle these situations effectively. The provided text appears to be a table of contents or section headers for a document related to fraud detection and analysis, specifically using the ArcSight Confidential solution. Here's a summary of each section: 1. **Configure** - Instructions or setup details for implementing various use cases in the ArcSight Confidential solution. 2. **Resources** - Additional information or references needed for setting up and understanding the use cases. 3. **Payee Created and Paid - Suspicious Time Use Case** - A specific use case involving a payee that has suspicious activity related to time usage, likely in terms of payment processing delays or patterns. 4. **Paying Suspicious Payee Use Case** - Another use case focused on paying an entity (payee) that exhibits suspicious behavior indicative of potential fraudulent activities. 5. **Successful Login from Country of Concern Use Case** - A scenario where a successful login occurs from an IP address or location considered potentially risky, indicating possible unauthorized access or fraud. 6. **Successful Login from Suspicious Address Use Case** - Similar to the above but specifically for addresses that are flagged as suspicious based on past fraudulent activities or unusual activity patterns. 7. **Transaction Behavior Anomaly Use Case** - A use case focused on detecting anomalies in transaction behavior, which could be an indicator of potential fraud or suspicious activity. Each section number corresponds to a page number in the document where detailed information and setup procedures are explained under each specific use case scenario. The resources listed at the end of each section provide further guidance or references for users setting up these features within the ArcSight Confidential solution. This text appears to be a section from a larger document discussing various use cases and configurations for transfer controls in an unspecified context, likely related to financial or business operations. Here's a summary of the content:

• **Use Cases**:

• **Transfers Just Under Violation Threshold** and **Transfers Over Violation Threshold**: Both involve configuring settings and providing resources. The former is discussed under general industry use cases, while the latter is specific to investment banking.

• **Industry Specific—Credit Card**: Includes sub-use case "Card Used in Foreign Country" which also requires configuration and resource allocation similar to other use cases mentioned.

• **Industry Specific—Investment Banking**: Features a use case about **Entitlements Violation**, again requiring configuration and resources.

• **Excessive Wire Transfer Requests** and **Penny Stock Transactions**: These use specific terms for transactions that might be problematic under certain financial regulations, warranting their own sections within broader industry-specific guidelines.

• **Configuration and Resources**: Each use case has a section dedicated to explaining how to configure the system or process and what resources are needed based on potential risks identified by these use cases (e.g., near violations of thresholds might require closer monitoring).

Each numbered point corresponds to a specific page in the document where detailed information about setting up controls for different scenarios is outlined, including necessary configurations and available resources to manage each situation effectively. This text appears to be a part of a larger document, likely documentation for a software product or system related to financial trading and monitoring, specifically focusing on configuring settings for detecting potential violations such as dollar thresholds in transactions. The content is structured with headers like "Configure" and "Resources," which are repeated across multiple sections numbered 87 through 92. Each section seems to correspond to a specific use case detailing how to configure the system's parameters for monitoring trading activities, particularly focusing on thresholds related to transaction amounts and frequency. Here is a summary of each section:

• **Section 87:** This section introduces general topics under "Configure" and "Resources." It sets the stage for configuring settings in the software regarding trading violations.

• **Section 88 to 92 (repeated sections):** These are repeated sections that detail specific use cases, each corresponding to a different type of violation threshold detected by the system:

• **Trading Violation - Dollar Per Day Threshold - Purchased Use Case:** Instructions on configuring settings for monitoring dollar amounts in purchased transactions.

• **Trading Violation - Dollar Per Day Threshold - Sold Use Case:** Instructions on configuring settings for monitoring dollar amounts in sold transactions.

• **Trading Violation - Single Transaction Dollar Threshold Use Case:** Instructions on configuring settings to monitor individual transaction dollar thresholds.

• **Trading Violation - Single Transaction Units Threshold Use Case:** Instructions on configuring settings to monitor the units (quantity) of single transactions exceeding certain thresholds.

• **Trading Violation - Transactions Per Day Threshold Use Case:** Instructions on configuring settings for monitoring the number of transactions per day that exceed a specified threshold.

Each section "Configure" and "Resources" provides detailed steps or instructions on how to set up parameters in the system to detect trading violations related to dollar thresholds, single transaction amounts, and frequency of transactions. These sections are likely part of a larger document designed for users who need to implement monitoring and control measures within their financial trading operations using the software. The text provided outlines a structured approach to managing and configuring resources within the "FraudView Solution" system, focusing on units per day threshold trading violations. Here's a summary of the key sections and their contents:

• **Configure**: This section focuses on setting up or modifying configurations related to units per day in the context of trading violation thresholds. The specific details are not provided in this text snippet but would likely involve adjusting settings, alerts, or other parameters tied to these thresholds within the FraudView Solution system.

• **Resources**: This part of the document discusses various resources that can be managed and configured within the FraudView Solution:

• **Appendix A: Compare, Backup, and Uninstall Package** provides steps for managing a solution package by comparing it with another version, backing up the current setup, and uninstalling the solution if needed.

• **Compare**: This involves examining differences between versions of the package to understand what has changed since the last version.

• **Backup**: This step ensures that a copy of the current configuration is saved for future reference or rollback purposes.

• **Uninstall**: If necessary, this procedure removes the FraudView Solution from the system.

• **Appendix B: FraudView Solution Resources By Type** details various types of resources available in the solution including active channels, lists, asset ranges, dashboards, data monitors, destinations, field sets, and files. Each type is described with a focus on how they are used or configured within the FraudView ecosystem to support trading violation management.

• **Active Channels**: Lists of communication channels that can be monitored for violations.

• **Active Lists**: Specific lists of items or entities (assets) being tracked for compliance against trading rules.

• **Asset Ranges**: The range or scope of assets covered by the system, which is crucial for setting up alerts and monitoring parameters related to units per day.

• **Dashboards**: Visual interfaces that provide a summary view of key performance indicators relevant to trading violations.

• **Data Monitors**: Automated tools used to monitor data streams in real-time or near-real-time, ensuring compliance with unit thresholds.

• **Destinations**: Target locations where alerts or actions resulting from detected violations are sent (e.g., email addresses, specific database entries).

• **Field Sets**: Collections of fields that define the structure for data entry and reporting in relation to trading activities.

• **Files**: Electronic storage units used to store and organize documentation or datasets related to each asset being monitored under trading rules.

The document provides detailed procedures and classifications for these resources, ensuring a comprehensive approach to maintaining regulatory compliance and operational efficiency within the financial services sector where such thresholds are critical in detecting irregularities. The preface of a document provides an introduction to what is contained within the guide, typically explaining its purpose, intended audience, and how to navigate the content effectively. In this case, the preface outlines key topics such as "Who Should Read this Guide" and "How to Use this Guide." 1. **Who Should Read this Guide**: The guide is aimed at administrators and security managers who are tasked with planning, implementing, maintaining, and using ArcSight™ ESM with the FraudView solution to develop a comprehensive strategy against fraud in an organization. It specifies that users should have knowledge of basic network concepts and how to use ArcSight ESM tools for specific use cases. 2. **How to Use this Guide**: The preface suggests that this guide serves as a reference, presenting the concepts, contents, and implementation guidelines for the FraudView solution. A table is mentioned but not detailed here, possibly indicating it's included elsewhere in the document to assist readers in locating specific information they need based on their interests or roles within the organization. This document is a guide for the ArcSight FraudView solution, which aims to address fraud concerns in enterprise network environments. The guide includes various chapters and appendices that provide detailed information on different aspects of the solution, such as deployment planning, configuration instructions, account escalation processes, use cases, resource management, and backup/uninstall procedures. Key features are highlighted with bold text for easy navigation, and syntax conventions like italics, code tags, and right angle brackets are used to guide users through specific steps in commands or menus. The text provided is an overview of various components used in system reports and assets management, including variables, parameters, cautions, tips, notes, and documentation related to ArcSight ESM (Enterprise Security Manager). Here's a summary: 1. **Variables**: Text enclosed in angular brackets (< >) represents a variable that requires user input. Italics can be used to emphasize this requirement. For example, is a variable for which you need to supply a value. 2. **Parameters**: Curly brackets { } enclose multiple parameters where at least one must be provided by the user. Example: {--user_id_seq= | --user_login=} allows users to either provide a user ID or login name. 3. **Optional Parameters**: Square brackets [ ] are used for optional parameters, variables, or values. For example, the statement <--cli_restrict 1="1">

is an optional parameter that provides information about restricting CLI usage. 4. **Documentation and Examples**: The text includes examples to illustrate how these components are used in system reports and assets management within ArcSight ESM. It also mentions the availability of documentation such as "ESM 101: Concepts for ESM" which explains the fundamental concepts of ArcSight ESM, its roadmap based on user roles, and release notes detailing new features or updates along with known issues. 5. **Documentation Access**: The document provides a link to access more detailed documentation about ArcSight ESM, including product manuals and guides that help users understand how to effectively utilize the software's features for their specific needs in security operations. The ArcSight™ FraudView solution is designed to help organizations detect, respond, and prevent fraudulent activities across various channels or lines of business. It can identify fraudulent activity in a wide range of applications, including both internal systems used by the organization and customer-facing platforms. Fraudsters do not stick to one method when attempting to defraud an organization; they often use multiple approaches to gain unauthorized access or manipulate account details. For instance, they might first try to access an account in order to commit fraud. The ArcSight™ FraudView solution is intended to assist organizations in identifying such fraudulent activities effectively. This text discusses the process of fraud detection in an online system known as "FraudView." It explains how, when internet-facing systems cannot be accessed, users may try to use phone call centers or social engineering techniques to access accounts. The FraudView solution monitors various transactions and applications for anomalies that could indicate fraudulent activity. This includes pre-authentication (Account Takeover) where it detects attempts to gain unauthorized access before authentication is even attempted. It also involves post-authentication detection of suspicious transaction patterns, and the creation of accounts solely for fraudulent purposes in a stage called "Fraudulent account creation." Overall, FraudView's approach is cross-channel analysis aimed at identifying and preventing fraud through early detection mechanisms. The text describes how ArcSight's FraudView solution uses a multi-stage approach to detect fraud by analyzing various attributes of accounts and transactions. This method allows for multiple stages of detection, with potentially missed fraud being detected in subsequent stages. Each stage involves unique components such as early warning account escalation rules, an escalating risk model, real-time correlation engine, pattern discovery, workflow management, and use cases. The FraudView solution includes the ability to monitor accounts showing suspicious behavior through a process called account escalation, which provides an early warning system of possible fraudulent activities by assigning higher priority to transactions from suspicious accounts. Account escalation is facilitated by a set of early-warning rules that identify insignificant but potentially suspicious behaviors when viewed collectively across multiple instances for the same account. The solution also involves creating feedback loops and using different levels of tracking lists to manage potential fraudulent behavior, ultimately aiming to detect fraud at various stages within an organization's detection process. The FraudView solution uses a methodology for tracking accounts based on their behavior, starting with adding them to a "Watched Accounts" list upon first detection of suspicious activity. If no further suspicious activity is detected within a configurable timeframe, the account expires off this list; otherwise, it is escalated to the "Suspicious Accounts" list and then potentially moved to an "Investigate List" if high-concern suspicious behavior is identified. Directly adding accounts to these lists is also possible based on medium or high concern suspicions. The solution employs a risk model that evaluates incoming transactions for significance and can be customized in real-time. This system helps analysts identify potential fraudulent accounts efficiently while prioritizing investigations of the most suspicious flagged accounts, tracked through dashboards and status reports displayed in real-time. The risk model in ArcSight™ ESM plays a crucial role in evaluating and managing risks within a business environment. It allows for the import of attributes from external sources such as blacklists or security monitoring tools like ArcSight™ ESM itself. This enables the assessment of risks against lists of known hostile IP addresses, devices, suspicious payees, countries, or fraudulent tax identification numbers. The risk model is managed by several components including a correlation engine, trending engine, and Pattern Discovery module. The correlation engine adds attributes to the risk model when suspicious activities are detected, such as issuing payments deemed suspicious, adding both the payer and payee to the model. This increases the risk score for any subsequent transactions involving these accounts. The trending engine compiles statistics about each monitored account, which is also added to the model. If an account shows unusual behavior beyond its normal activity (e.g., unusually high transaction amounts), it will be assigned a higher risk score. The Pattern Discovery module helps identify patterns of activity that can be marked as either normal or fraudulent and considers their attributes for future risk scoring in transactions. As transactions are processed by the FraudView solution, they undergo evaluation against the risk engine using various indicators such as wire transfers, authentications, account administration activities, ATM withdrawals, and payee modifications. Each transaction is evaluated against four default indicators, contributing to the overall risk assessment process within the organization. This summary describes how the FraudView solution assesses risk through various indicators such as destination, transaction, device, and account risks. It uses a customizable real-time approach to elevate risk scores for transactions, adding accounts of concern to a watch list, which affects subsequent transactions' risk levels. The solution leverages ArcSight™ ESM’s multi-dimensional correlation engine to evaluate transactions in real-time against pre-defined fraud detection rules and allows analysts to create new rules for enhanced detection capabilities without coding knowledge. The article discusses how ical transactions can be evaluated against current rules, utilizing historical datasets to detect similar fraud patterns. Correlation rules are device-independent and capable of correlating data from various systems or applications across different channels. These rules can trigger actions such as sending notifications or opening workflow tickets based on the configuration. The FraudView solution employs ArcSight ESM's advanced pattern detection engine to identify patterns in transaction data using sophisticated data mining techniques. This allows for the discovery of patterns between various attributes, like Event Name, Event Type, Source Country, and IP address. Once a pattern is identified, it can be saved as either common or potentially fraudulent, with potentially fraudulent patterns automatically triggering rules for real-time detection through correlation engine capabilities. The solution also includes predefined Pattern Discovery profiles to help identify specific transaction data patterns. Administrators can create their own Pattern Discovery profiles if needed. These profiles help the pattern discovery engine find normal patterns in event data that you consider usual. Part of this process is setting a baseline of normal activity so unusual patterns stand out. To use Pattern Discovery effectively and learn how to customize included profiles, refer to the ArcSight Pattern Discovery™ Guide. The predefined profiles with the FraudView solution are listed on page 111 under "Profiles." ArcSight ESM with the FraudView solution has a workflow that includes event annotation, case management, and notification. Event annotation allows multiple analysts to work together efficiently without duplicating efforts, and it supports escalation of individual transactions for further investigation. Analysts can view real-time events or past data in forensic mode. If they find several transactions interesting, they can annotate them so other analysts know they are investigating them; if needed, the events can be assigned to a second tier investigator through annotation. The built-in case management system automatically creates cases when rules are triggered and allows manual creation of new cases as a result of investigations. Cases can be assigned to any user within the system and tracked until resolution. Case metrics can then be reported for operation metrics such as time to resolution, open vs. closed, and individual analyst performance. This text is about a system called "ArcSight Confidential" which helps identify potential fraud by analyzing various use cases such as accessing multiple accounts from a single IP, detecting account activity from OFAC blacklisted countries, identifying fraudulent SSNs used to create accounts, and tracking successful logons from specific Russian Business Network (RBN) asset ranges. The system integrates with common case management solutions and has a notification engine that alerts analysts or managers if certain rules are triggered, with an escalation process for unresponsiveness. This helps maintain 24/7 visibility without constant employee monitoring and supports rule-based fraud early warning use cases. The provided text discusses several use cases related to detecting suspicious activities in the context of fraud prevention and security measures for accounts, including time-based registration detection, country of origin identification, RBN (Russian Business Network) asset range analysis, public email provider usage, brute force login success monitoring, and excessive wire transfers to the same payee. Each use case serves a specific purpose aimed at identifying unusual activities that may indicate fraudulent or suspicious behavior: 1. **Account Registration Suspicious Time**: This use case is designed to detect accounts created during abnormal times by comparing the registration time with pre-defined times (8:00 p.m. to 6:00 a.m. on weekdays and all day Saturday and Sunday) set in the Suspicious Time of Day filter. 2. **Account Registration From Country of Concern**: This use case identifies account creations originating from countries known for high fraud rates, using a list of such countries defined by historical data of fraudulent activities. 3. **Account Registration from RBN Use Case**: Specifically targets accounts created from assets categorized in the Russian Business Network (RBN) address ranges, which are detected and flagged based on their location within these specific IP blocks identified through ArcSight Solutions/FraudView/RBNet groupings. 4. **Account Registration Using Public Email**: This use case focuses on identifying accounts created with email addresses from popular public email providers like Yahoo, Gmail, Hotmail, MSN, and Hushmail. It helps in monitoring activities that might be indicative of suspicious registrations or potential fraud associated with these services. 5. **Brute Force Login Success Use Case**: Monitors successful logins one minute after a brute force attack to detect and alert on such attempts, which can indicate compromised accounts or targeted attacks. 6. **Excessive Wire Transfers to Same Payee Use Case**: This use case is intended to uncover patterns of transactions where the same account makes three or more payments to the same payee within a five-minute window, potentially signaling unauthorized access or fraudulent activities. These use cases are part of a broader security strategy that uses advanced analytics and predefined criteria to identify potential threats and anomalies in financial transactions, helping organizations prevent fraud and protect their assets. The provided summaries are incorrect and do not accurately reflect the purposes of each "use case" mentioned in the text. Here are the correct interpretations based on the content: 1. **Geographic Disparity of Account Access** - This use case aims to determine if an account has been accessed from more than one country within a single hour, which can be used for fraud detection and prevention. 2. **Login from Known Fraudulent Address** - The purpose of this use case is to detect when an account has been accessed from a known fraudulent IP address, indicating potential security breaches or unauthorized access attempts. 3. **Multiple Accounts Paying Same Payee** - This use case identifies situations where three different accounts are paying the same payee within five minutes, which could be indicative of collusion or other fraudulent activities. 4. **Multiple Failed Logon Attempts** - The purpose is to detect when there have been three consecutive failed attempts to access an account within a minute, suggesting potential brute-force attacks or unauthorized attempts to gain entry. 5. **Multiple Password Resets** - This use case identifies instances where the password has been reset multiple times (three times) for the same account within twenty-four hours, which might indicate compromised accounts or hacking attempts. 6. **Multiple Transactions by Same User** - The purpose is to identify when a single account conducts five transactions (including payments or wire transfers) within one minute, possibly indicating transactional fraud or high-frequency trading patterns. 7. **Password Reset Not Preceded by Lockout** - This use case identifies instances where a password reset occurs without the account being locked out first, which can be used to detect unauthorized access attempts and potential security vulnerabilities. 8. **Payee Created and Paid - Same User** - The purpose is to identify when a payee is both created and paid by the same user within a short timeframe, potentially indicating fraudulent activities such as internal theft or collusion. 9. **Payee Created and Paid - Suspicious Time** - This use case identifies situations where a payee is created and paid by the same user within two minutes during a time considered suspicious (without specifying what "suspicious" means), which could be indicative of fraudulent activities occurring under unusual circumstances. 10. **Paying Suspicious Payee** - The purpose is to identify when payments are made to a payee that has been flagged as potentially suspicious, which can help in detecting and preventing fraudulent transactions or illicit financial flows. The provided information outlines various use cases and purposes within the ArcSight™ FraudView v1.0 Solution Guide, focusing on fraud detection in different scenarios such as successful logins from suspicious IP addresses, transaction behavior anomalies, transfers under or over violation thresholds, and credit card transactions in foreign countries. These use cases are designed to help identify potential fraudulent activities by analyzing patterns of behavior that deviate from normal operations, thereby aiding in the prevention of financial loss and maintaining the integrity of transactions. This document outlines various use cases focused on detecting trading violations within financial institutions. Each use case serves a specific purpose to identify inappropriate or excessive trading activities by traders. Here's a summary of each use case mentioned in the text: 1. **Entitlements Violation**: This use case aims to detect when an account engages in transactions involving financial instruments (like bonds) that it is not authorized to trade. It helps maintain compliance and proper authorization levels for trades. 2. **Excessive Wire Transfer Requests**: The purpose of this use case is to flag accounts that have made more than three wire transfer requests within less than eight hours, potentially indicating irregular or high-frequency trading activities. 3. **Penny Stock Transactions**: This use case identifies transactions involving the sale or purchase of over 100,000 units (such as stocks and options) at a price below $0.75 each. It is used to monitor speculative trading behavior that might be indicative of risky investments. 4. **Trading Violation - Dollar Per Day - Purchased**: This use case monitors traders who have exceeded the daily purchasing limit set at 10,000,000 dollars. It helps prevent excessive spending and maintain financial discipline in trading activities. 5. **Trading Violation - Dollar Per Day - Sold**: Similar to the above, this use case identifies when a trader exceeds the daily selling threshold of 10,000,000 dollars, ensuring proper balance between buying and selling activities. 6. **Trading Violation - Single Transaction Dollar Threshold**: It detects if a single transaction involving more than 500,000 dollars has occurred, which is used to monitor large transactions that might be indicative of manipulative or suspicious trading practices. 7. **Trading Violation - Single Transaction Units Threshold**: This use case identifies when a single transaction exceeds the threshold of 500,000 units in various asset types like stocks and options. It helps maintain control over significant unit transactions to prevent abnormal trading patterns. Each of these use cases is designed to monitor specific trading behaviors that might indicate potential violations or risky practices within financial institutions. The provided text discusses the use cases for "Transactions Per Day" and "Units Per Day" thresholds within the FraudView solution, which are designed to identify trading violations such as exceeding daily transaction limits set by traders. It also provides information on installing and configuring the FraudView solution, including verifying the environment, installing the solution, developing FlexConnectors, modifying priority formulas, and downloading a dashboard for monitoring fraud. The text confirms that the solution is supported on ArcSight ESM v4.5 SP1 or later and must be the only installed solution or CIP (Compliance Insight Package) on an ArcSight ESM Manager. The summary of the provided text describes the process for installing the FraudView package on the ArcSight ESM (Extended Security Management) Console. Here's a breakdown of the steps involved: 1. **Download the FraudView Package:**

• Use your ArcSight login credentials to download the FraudView package bundle from the ArcSight software download site. The specific file format is specified, typically ending in .arb with a build number (e.g., ).

• If downloaded as a ZIP file by Internet Explorer, rename it back to an ARB file before proceeding.

2. **Log into the Console:**

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

3. **Navigate and Import the Package:**

• Click on the Packages tab in the Navigator panel.

• Click the import button ( ).

• In the Open dialog, browse to select the downloaded ARB file and click Open. The progress of the import is displayed in the Progress tab of the Importing Packages dialog.

4. **Complete the Installation:**

• When the import is complete, ensure the FraudView 1.0 checkbox is selected in the Packages for Installation dialog.

• Click Next to start the installation process, which will display progress in the Progress tab of the Installing Packages dialog.

• Once installed, review the Summary Report on the Results tab of the Installing Packages dialog and click OK.

5. **Verify the Installation:**

• In the Importing Packages dialog, click OK.

• Verify the installation by expanding the ArcSight Solutions/FraudView 1.0 group in the Navigator panel to ensure content is accessible.

6. **Troubleshooting:**

• If the installation was not successful, refer to ArcSight technical support for further assistance.

ArcSight, a product by SolarWinds, provides support through its website at https://support.arcsight.com, which offers resources such as incident reporting, a knowledge base, software downloads, and assistance via a new customer forum. Additionally, there is a Protect 724 Community available at https://protect724.arcsight.com, designed for customers to exchange tips and tricks related to ArcSight. To manage user permissions within the ArcSight environment specifically for the FraudView solution, follow these steps:

• Ensure that your organization has properly set up user groups and assigned users to them.

• Log into the ArcSight ESM Console using 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, and trends), adjust user permissions by:

• Navigating to ArcSight Solutions/FraudView 1.0 in the Navigator panel.

• Right-clicking on the FraudView 1.0 group and selecting "Edit Access Control" to open the ACL editor in the Inspect/Edit panel.

• In the ACL editor, select the user groups you want to grant access or permissions to, and click OK.

Lastly, for installing ArcSight ESM Console Utility Files from a ZIP file related to FraudView, follow the instructions provided by downloading and either individually or in batch, the mentioned files from the designated location. The document outlines the process for installing utility files into the ArcSight ESM Console, specifically designed for fraud monitoring. The steps include logging into the console with administrative privileges, downloading a zip file containing update files, and extracting them to the appropriate directory. Additionally, it mentions configuring event field aliases as part of the installation. The provided text discusses the mapping of ArcSight ESM event fields to reflect financial transactions, specifically within the context of the FraudView solution. Initially, in the absence of the FraudView solution, certain event fields were labeled inaccurately or ambiguously. For instance, the attribute "securityevent.attribute.attackerusername" was labeled as "Attacker User Name." Upon installation of the FraudView solution and its accompanying security_event_strings.properties file, these labels are updated to more accurately reflect financial transaction-related data. A table (Table2-1) is provided that lists the original ArcSight ESM Console labels, the underlying attributes from the security_event_strings.properties file, and the new labels after the FraudView solution is installed. Key examples of these mappings include:

• "Attacker User Name" being mapped to "Account Id."

• "Relevance" being mapped to "Account Risk."

• "Flex String1" being mapped to "Alternate Country."

• "Device Custom String2" being mapped to "Currency Amount."

• "Asset Criticality" being mapped to "Destination Risk."

• "Severity" remains unchanged but is now more specifically defined.

• "Device Custom String1" becomes "Financial Instrument," and its type is mapped under "Instrument Type."

• "Flex String2" is labeled as "MCC Code."

• "Target User Id" represents "Payee Account."

• "Target Process Name" represents "Payee Company."

This table serves to clarify the mislabeling issues in the ArcSight ESM Console and provides a standardized mapping for financial transaction-related data using the FraudView solution. To install the properties file on the ArcSight ESM Manager: 1. Log into the ArcSight ESM Console with an account that has administrative privileges. 2. From the Resources tab in the Navigator panel, go to Files and navigate to ArcSight Solutions/FraudView 1.0/Manager/i18n/common group. 3. Right-click the security_event_strings.properties file and select the Download option. 4. Browse for a temporary directory location such as the Desktop. 5. Click Save. A copy of the file is saved to the local file system. 6. Exit from any ArcSight ESM Consoles connecting to the ArcSight ESM Manager. 7. Shutdown the ArcSight ESM Manager. 8. On the system running the ArcSight ESM Manager, go to the directory location where the default security_event_strings.properties file is stored. For example, if you installed the ArcSight ESM Manager into the default directory on Windows, the file is stored in: C:\arcsight\Manager\i18n\common. 9. On the system running the ArcSight ESM Manager, rename the existing security_event_strings.properties file to a temporary name (e.g., "security_event_strings_old.properties"). To import the alias file into the ArcSight ESM Console: 1. Log into the ArcSight ESM Console with an account that has administrative privileges. 2. From the Resources tab in the Navigator panel, go to Files and navigate to ArcSight Solutions/FraudView 1.0/Manager/i18n/common group. 3. Right-click on the empty space and select Upload File from the context menu. 4. Browse for the downloaded properties file (security_event_strings.properties) saved earlier. 5. Click Open to upload the file. The file should now be listed in the Files section under ArcSight Solutions/FraudView 1.0/Manager/i18n/common group. 6. Right-click on the security_event_strings.properties file and select Import. 7. In the Import dialog box, click Next. 8. Click Finish to complete the import process. The FraudView solution event fields will now be available in the ArcSight ESM Console for configuring alerts or other use cases based on these events. The provided text outlines a process for importing an alias file into the ArcSight ESM Console, specifically related to the FraudView solution. Here's a summarized version of the steps: 1. **Download the security_event_strings.properties File**:

• If not already downloaded from the "FraudView_Console_Update.zip", follow these sub-steps:

a. Navigate to Files in the ArcSight ESM Console. b. Go to ArcSight Solutions/FraudView 1.0/Console/i18n/common group. c. Right-click on security_event_strings.properties and select Download. d. Save it to a temporary directory, such as the Desktop. 2. **Log in to ArcSight ESM Console**:

• Use an account with administrative privileges.

3. **Import the Alias File**:

• Go to Inspect/Edit panel.

4. **Verify or Modify Existing File**:

• Rename the existing security_event_strings.properties file to security_event_strings.properties.original.

• Copy the downloaded file into the common directory.

5. **Start the ArcSight ESM Manager** if not already running. By following these steps, you ensure that the FraudView solution-specific labels are correctly displayed for event fields in the ArcSight ESM Console. The FraudView solution is designed to monitor financial transactions by triggering alerts through FlexConnectors developed for specific financial applications like money transfers. These FlexConnectors are crucial in generating events related to such transactions. Additionally, it's necessary to configure an Intrusion Detection System (IDS) to detect Brute Force Login attempts, which will also trigger events. Developers need to determine the desired use cases for implementing the FraudView solution and then create FlexConnectors that generate required types of events based on these use cases. The event requirements vary by specific use case and can be found in the "FraudView Early Warning Use Cases" document, including details from Table2-2. To develop FlexConnectors, follow the instructions provided in the ArcSight™ FlexConnector Developer’s Guide. The parsers within these FlexConnectors must be written to ensure proper field mappings, event naming, and categorizations are applied according to the standards expected by FraudView solution resources. Each Event Type has a corresponding filter that includes conditions tailored to match the requirements of that specific type of event. For instance, Wire Transfer events need to be named "Wire Xfer Request," and only Wire Transfer filters with this condition will return such events. Only those rules matching the appropriate Event Type criteria are able to process related events. The text discusses the need to customize Event Type filters for specific environments in tools like ArcSight Confidential and FraudView. Different event types have unique requirements including proper naming, appropriate categorization, and other specifications based on their nature (e.g., Wire Transfer events must be named "Wire Xfer Request"). For certain events such as Account Access Attempts and Account Access Failures, specific categorization settings are necessary to ensure correct handling by the system. These include setting categories like /Authentication/Verify for behavior and /Application/YOUR_APPLICATION_TYPE for device group, where YOUR_APPLICATION_TYPE should be tailored according to the financial application being monitored. It is recommended to configure events with category settings as a best practice. The table provided (Table2-1) outlines the expected event types from FlexConnectors monitoring financial applications, detailing required naming and categorization along with other requirements like field settings. This summary outlines the steps and conditions required when using a specific feature within a fraud detection tool called FraudView. The process involves setting up filters for different types of access attempts, particularly focusing on failed logons that indicate potential fraudulent activity. Here's how it breaks down: 1. **Event Generation**: For cases where there are account access attempts or authentication failures related to the application being monitored, FlexConnectors should be configured to generate events specifically named "Failed Logon" if not already named so. These filters require that Account Id is NOT NULL and use a unique string in Category Device Group to reflect the type of application (specified as YOUR_APPLICATION_TYPE). 2. **Filter Conditions**: The filter conditions for these failed access attempts include checking the category behavior related to authentication, specifying the outcome as failure, and ensuring that the event categories are aligned with those set in the Required Event Settings column. 3. **Geo Country Code Mapping**: The geographical location from where the access attempt originated must be mapped to the attackerGeoCountryCode field. This mapping is crucial for geo-specific analysis within the fraud detection framework. 4. **Table Reference**: For detailed instructions and additional context, refer to specific sections of the document labeled "FraudView Early Warning Use Cases" (page 55) and "Setting the Geo Country Code" (page 28), where these procedures are thoroughly explained. This setup is designed to help in early detection of potential fraudulent activities related to unauthorized access attempts, ensuring that specific application types can be monitored effectively for signs of intrusion or suspicious behavior. This passage describes how to set up a FlexConnector in ArcSight FraudView to filter and generate events for successful account access attempts in monitored applications. Key points include: 1. **Filter Conditions**: The default condition filters out accounts with NULL Account Id, then checks if the event type is Login or Logon (unless specified otherwise). Additional conditions involve mapping fields like Country Code, IP address, and Application Type to specific fields such as attackerGeoCountryCode and attackerAddress. 2. **Event Generation**: Events should be named appropriately reflecting successful account access attempts in the monitored application. If no custom name is used for events, they may retain default names like Login or Logon. 3. **Category Device Group**: Set a unique string that reflects the type of application to ensure proper event categorization and mapping to specific fields. 4. **Mapping Specifics**: The Country Code should be mapped to attackerGeoCountryCode, while the IP address from the machine where the access attempt originated is mapped to attackerAddress. 5. **Default Configuration**: By default, the filter checks that Account Id is not NULL, which may require adjustment based on specific event naming or behavior. 6. **FlexConnector Setup**: The FlexConnector should be configured to generate events reflecting successful account accesses in a monitored application, with appropriate mapping of fields and setting of Category Device Group as per application type. This document is a guide for installing and configuring the ArcSight™ FraudView solution, version 1.0, focusing on specific filter conditions related to detecting potential fraudulent activities such as new account creation requests and account lockouts. The primary objective of these filters is to monitor and analyze events that might indicate fraudulent behavior within an application. For setting up filters for a "New Account Creation Request," the following steps are recommended: 1. Ensure all filters check that the Account Id is not null by default, which will be monitored unless specified otherwise for simplicity. 2. Name the event(s) related to new account creation as "New Account Creation Request." 3. Map the Social Security Number of the account owner to the deviceCustomString4 field and record the time of account creation in the deviceReceiptTime field. 4. Map the email address of the account owner to the attackerUserName field. For setting up filters for an "Account Lockout," follow these steps: 1. Name the event(s) related to account lockouts as "Account Lockout." 2. Map the locked-out account to the attackerUserName field. In both cases, using a unique string in the Category Device Group that reflects the type of application providing events is crucial for proper functioning of the FraudView solution. This helps in differentiating between various types of accounts and login attempts within the system. This summary provides detailed instructions for setting up filters within ArcSight's FraudView solution to monitor specific events and transactions, particularly focusing on financial activities such as ATM withdrawals, credit card transactions, password resets, and payee creations. The setup involves mapping various fields from different types of events to appropriate fields in the system, including the Account Id (attackerUserName), Currency Amount (devicecustomstring2), Payment Country (targetNttdomain), and Attacker Geo Country Code. It is important to ensure that event names are correctly specified within each filter to avoid unnecessary updates. The instructions provided apply generally across various transaction types such as RETAIL TXN, ATM TXN REV, CREDIT VOUCHER, and ATM TXN, unless the specific event type already has a predefined name in which case no changes are necessary. This summary outlines the process for creating and configuring filters in ArcSight FraudView v1.0 to monitor specific events such as "Payee Created" and "Payment Issued." For a Payee Created event, the filter should be edited with the same name, checking that the Account Id is not NULL and the Company of the payee is not NULL. The Account Id should map to the attackerUserName field, and the payee's name should map to the targetProcessName field. For a Payment Issued event, the filter should be edited with the same name, ensuring that the Currency Amount, Payee Company, and Event Type are not NULL. The issuing account should map to the attackerUserName field, while the payee's name maps to the targetProcessName field, and the amount paid maps to the deviceCustomString2 field. For a Purchase Events filter, edit it with the same name if needed and ensure that Account Id (attackerUserName), Currency Amount (deviceCustomString2), Units (deviceCustomNumber1) are not NULL. The account making the purchase should map to the attackerUserName field, and the amount paid maps to the deviceCustomString2 field. These filters help in identifying specific events within a monitored application by mapping relevant data fields from different systems into a centralized platform for analysis and response. This summary outlines the setup and mapping requirements for generating sell events and wire transfer request events in ArcSight's FraudView solution. For Sell Events, you need to map the financial instrument type to the Instrument Type (deviceCustomeString5) field. By default, this includes Bond, Equity, Future, and Option types. You should name the event as "Sell" or update the filter if it's named differently. Map the account making the sell to the Account Id (attackerUserName) field and the amount received to the Currency Amount (deviceCustomString2) field. The number of units sold should be mapped to the Units (deviceCustomNumber1) field. For Wire Transfer Request Events, name your event as "Wire Xfer Request" or update the filter if it's already named correctly. Map the account making the payment (transfer) to the Account Id (attackerUserName) field and the name of the company which accepted the payment to the Payee Company (targetProcessName) field. The amount paid should be mapped to the Currency Amount (deviceCustomString2) field. It's important that only one event per type is processed by FraudView, as multiple events can lead to system overload and incorrect processing. This summary explains how to ensure only one event is generated for each transaction in a financial application, such as logging into an account or making transactions like credit card payments, issuing payments, purchasing goods, or wire transfers. It advises matching the name of the event exactly with what's specified in the Required Event Settings column and that if multiple events are generated, it could lead to inaccurate reporting due to the use case "Multiple Transactions by Same User." Additionally, it emphasizes setting a Category Device Group for an event type as required by specifying the monitored application(s), which should be reflected in the event's Category Device Group settings. For example, all FlexConnectors monitoring financial applications like Banking should have their events set to /Application/Banking. The article discusses two methods for generating events with specific category device groups within the FlexConnector framework of ArcSight ESM (Enterprise Security Manager) to support the FraudView solution. Firstly, it suggests creating multiple FlexConnectors that generate events with different Category Device Groups such as /Application/ATM and /Application/OnlineBanking. Customize Event Type filters for these groups to fire appropriately. This ensures only the relevant monitored applications supply events to the FraudView solution content, ensuring a unique category setting specific to those applications. Secondly, it mentions setting Geo Country Code automatically by ArcSight ESM if the IP address can be resolved to its originating country. For detailed information on this feature, refer to the relevant section in the ArcSight Console online Help manual. Additionally, the article introduces modifications to the priority formula within the FraudView solution for financial transaction event prioritization based on a separate file that should be downloaded and installed onto the ArcSight ESM Manager. The Risk Modeling filters referenced in this formula determine how financial transactions are assigned their respective priority levels during processing by ArcSight ESM. The FraudView solution uses a priority formula that considers four main factors to determine the urgency of an event: Destination Risk, Transaction Risk, Account Severity, and Device Risk. Each factor is assessed on a scale from 0 to 10, with higher scores indicating increased risk. The overall priority rating is calculated by averaging the scores of these four factors. If a single event triggers multiple filters (like Suspicious Bank and Top Loss MCC for Destination Risk), its score can exceed 10, but only up to the maximum possible score of 10 for each factor will be considered in the final calculation. The average of these factor scores provides an overall priority rating that helps identify events with higher risk or potential threats to financial institutions. The ThreatLevelFormula.xml file within the FraudView solution allows for configuring different priority factors, even though these factors serve distinct purposes compared to their ArcSight ESM counterparts. In this context, the formula used is (AssetCriticality + ModelConfidence + Relevance + Severity)/4. The Destination Risk factor in the FraudView solution utilizes the ArcSight ESM Asset Criticality factor to calculate its score. This is determined through a set of risk modeling filters: 1. Suspicious Bank: Adds 4 points if the event's Target User Privileges match entries in the Suspicious Bank active list. 2. Suspicious Payment Country: Adds 4 points if the event's Payment Country matches entries in the Countries of Concern active list. 3. Suspicious Payee: Adds 4 points if the event's Payee Company matches entries in the Suspicious Payee active list. 4. Top Loss MCC: Adds 6 points if the event's MCC Code (Merchant Category Code) matches entries in the Top Loss Makers - MCC active list. 5. Transaction in Foreign Country: Currently unmentioned, but could potentially be part of a future implementation or consideration for risk assessment. The provided information outlines how filters related to destination risk factors are configured within the ArcSight FraudView solution. This includes specific steps for enhancing the accuracy of risk assessments through active lists and configurations, as well as guidelines for maintaining these lists to ensure they remain up-to-date with relevant data. The filter in question operates by comparing the account ID and payment country from a transaction event against those recorded when the account was first created, assessing if there's a discrepancy between where the transaction took place and where the account originated. This comparison triggers an increase of 4 points to the destination risk factor score for the affected transaction. The configuration process involves several active lists maintained within specific groups: 1. **Suspicious Bank Active List**: Includes names of banks known for fraudulent activities, found in the group ArcSight Solutions/FraudView/High Risk/Destination Risk. 2. **Country of Concern Active List**: Initially populated but requires regular maintenance to ensure it includes current data relevant to concerns about fraudulent activity from certain countries. This list is located in the same group mentioned above. 3. **Top Loss Makers - MCC (Merchant Category Code) Active List**: Lists MCC codes associated with merchants known for incurring high loss rates due to credit card transactions, part of ArcSight Solutions/FraudView/High Risk/Destination Risk. 4. **Account Country Active List**: Contains account numbers and the corresponding country codes where these accounts were created, stored in ArcSight Solutions/FraudView/Book Keeping/Account Country. These lists are crucial for enhancing fraud detection capabilities as they provide contextual data to inform decision-making processes within the solution. Regular maintenance of this information is emphasized to adapt to changing patterns and minimize potential risks associated with fraudulent activities. To summarize the provided text regarding the Transaction Risk Factor in the context of risk modeling filters within ArcSight's FraudView, here is a concise breakdown: The text outlines how specific transaction types are categorized based on their level of risk. For each category (High, Medium, and Low), there are corresponding filters that assess whether an event matches predefined names from active lists. These lists include high-risk transactions, medium-risk transactions, and low-risk transactions, each associated with different score additions in the Transaction Risk factor formula. The process involves: 1. Configuring active lists within ArcSight Solutions to define what constitutes High, Medium, or Low risk based on transaction type names. 2. Implementing filters that assess if an event matches any of the defined high-, medium-, or low-risk transaction types listed in their respective active lists. 3. Assigning a score (10 for High, 5 for Medium, and 2 for Low) to each event based on its risk category. 4. These filters are part of the Risk Modeling group within ArcSight Solutions/FraudView/Risk Modeling/Transaction Risk. 5. The active lists used here are located in ArcSight Solutions/FraudView/High Risk Attributes/Transaction Risk, and adjusting score thresholds can be done through customizing the ThreatLevelFormula.xml file as per further instructions on downloading, customizing, and installing the priority formula. This setup is crucial for effectively implementing a risk scoring system within financial transaction monitoring systems to categorize potential fraudulent or high-risk transactions accurately. The FraudView solution employs specific criteria from ArcSight ESM, including Relevance factor for prioritization and Severity factor for risk assessment, to calculate Account Severity and Device Risk in its priority formula. This is based on predefined lists such as Investigate List, Suspicious Accounts, and Watched Accounts. Each of these lists has associated filters that assess whether an event's Source User Name matches any listed Account Ids:

• **Account in Investigate List**: If a match is found, the score for Account Severity increases by 10 points. This filter checks if the Source User Name corresponds to those on the active Investigate List.

• **Account in Suspicious List**: A match adds 5 points to the Account Severity score. It uses the Suspicious Accounts list's active entries to perform this check.

• **Account in Watched List**: A match increases the Account Severity by 2 points. The filter relies on the accounts listed in the Watched Accounts active list for verification.

These filters are grouped under "ArcSight Solutions/FraudView/Risk Modeling/Account Risk". You can customize these scores and lists as needed, though they are automatically populated with suspicious Account Ids initially or by rules. Adjusting the scores associated with account severities in the ThreatLevelFormula.xml is an optional but customizable feature. Similarly, Device Risk Factor in FraudView also leverages ArcSight ESM's Severity factor for risk assessment within its priority formula. This setup allows for a detailed and dynamic evaluation of risks based on user activities and device interactions as captured by the system. The article outlines how specific filters in a system contribute to determining the risk level (Device Risk Factor) of an event, which is crucial for prioritization within the system. These filters are designed to assess potential threats by comparing certain attributes of events with predefined lists such as Infiltrators, Hostile, Suspicious, Reconnaissance Lists, and Countries of Concern, as well as Known Fraudulent Addresses. Each filter has a distinct impact on the risk score:

• An event that matches the Attackers on Infiltrators List increases the risk by 6 points.

• Events matching the Attackers on Hostile List raise the risk by 5 points.

• For those matching the Attackers on Suspicious List, the risk is increased by 3 points.

• A match with the Attackers on Reconnaissance List adds 1 point to the risk score.

• An event that triggers the Country of Concern filter results in a 4-point increase in risk.

• Events flagged as Known Fraudulent Addresses have their risk level boosted by 10 points.

These filters help in identifying and prioritizing high-risk events, which are critical for effective threat management within the system. The article describes how certain events can increase a device's risk score based on predefined filters and lists, all part of ArcSight ESM's Device Risk Factor system. The "Known Hostile Address" filter adds 4 points to the risk score if the event's attacker address matches entries in the "Hostile List," "Infiltrators List," "Reconnaissance List," or "Suspicious List." These lists are part of the ArcSight System/Threat Tracking group. The "OFAC Blacklist" filter also adds 4 points if the event's attacker Geo Country Code matches any entry in the OFAC Blacklisted Countries active list, which is used for compliance with US economic sanctions against certain countries. The "Suspicious Address" filter increases the risk score by 4 when the originating IP address of an event appears on the Suspicious Accounts active list, potentially indicating suspicious activity. These filters are part of the ArcSight System/Core/Threat Level Filters (for core system filters) and ArcSight Solutions/FraudView/Risk Modeling/Device Risk (for risk modeling filters). The lists used by these filters are initially populated but should be regularly maintained to ensure accuracy, as indicated in related use cases. The article also mentions that the scores for device risks can be adjusted in the ThreatLevelFormula.xml file if desired, and provides additional information through specific use case documents referenced at the end of the article. To download and install or customize the FraudView solution-specific priority formula, follow these steps: 1. Log into the ArcSight ESM Console with an account that has administrative privileges. 2. In the Navigator panel, go to "Files" under "Resources," then navigate to "ArcSight Solutions/FraudView/Manager/config/server group." 3. Right-click on the "ThreatLevelFormula.xml" file and select the "Download" option. 4. Choose a temporary directory location such as your Desktop, then click "Save." A copy of the file will be saved to your local file system. 5. (Optional) Edit the "ThreatLevelFormula.xml" file by adjusting values added to a score factor when an event matches specific filters. For example, in the FraudView solution, increase the number in the "Value" attribute if events indicate transactions originating from countries on the OFAC blacklist. 6. The FraudView solution uses the Severity factor in the ThreatLevelFormula.xml file to calculate Device Risk. After customizing or installing the formula, exit any ArcSight ESM Consoles you are connected to. To the ArcSight ESM Manager, follow these steps to configure and install the FraudView solution's priority formula and optional Fraud Monitoring Dashboard: 1. Shut down the ArcSight ESM Manager if it is currently running. 2. Navigate to the directory where the default ThreatLevelFormula.xml file is stored on the system running the ArcSight ESM Manager. The path for this file, when installed in the default Windows directory, would be C:\arcsight\Manager\config\server. 3. Rename the existing ThreatLevelFormula.xml file to another name such as ThreatLevelFormula.xml.original. 4. Copy the downloaded ThreatLevelFormula.xml file from a temporary directory into the config\server directory on the system. 5. Start the ArcSight ESM Manager. 6. Once installed, the FraudView solution's priority formula will replace the normal ArcSight ESM event prioritization, affecting events only from financial application FlexConnectors. Ensure this is the only solution or CIP (Compliance Insight Package) on the manager. 7. Download and install the optional Fraud Monitoring Dashboard:

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

• In the Navigator panel, go to Files under the Resources tab and navigate to /ArcSight Solutions/FraudView 1.0/Console/lib/resources/views/Fraud Monitoring group.

• Download and install the Fraud Monitoring.jlx file. This completes the installation of both the priority formula and the optional dashboard.

To install and configure the "Fraud Monitoring" feature in the ArcSight ESM Console, follow these steps after downloading necessary files from ZIP (page 14): 1. **Download the `Fraud Monitoring.jlx` file** by right-clicking on it and selecting the Download option. Also download the `security_event_strings.properties` file. 2. **Locate the ArcSight ESM Console installation directory**: It is typically at `C:\arcsight\Console\current\lib\resources\views`. 3. **Create a new folder** named "Fraud Monitoring" and save the downloaded files (including `Fraud Monitoring.jlx`) into this folder. This can be done by:

• Clicking on the Create New Folder icon in the Save file content as dialog, entering "Fraud Monitoring" as the name of the folder, and then saving it.

4. **Download** the `Fraud Monitoring.properties` and `fraud.jpg` files into this newly created "Fraud Monitoring" folder. 5. **Exit from the ArcSight ESM Console**. 6. **Open the `.ast` file in a text editor**, located at `C:\arcsight\Console\current`. 7. **Update or add the property** `console.ui.imageEditor` to be set as `true`. Ensure this is done by searching for it and making sure its value is true if already present, otherwise adding it with the same value. 8. **Navigate to Active Channels** in the ArcSight Solutions/FraudView 1.0 section, right-click on "ArcSight Solutions/FraudView 1.0/Fraud Monitoring" and select Show Active Channel. This will display all events received except correlated ones for the last two hours. 9. **Access the Image Viewer** from the bottom left corner of the Viewer panel and select "Image Viewer > Fraud Monitoring". The document "FraudViewv1.0 ArcSight Confidential2 Solution Installation and Configuration" outlines the setup, configuration, and usage of the FraudView solution within the ArcSight platform. Key points include: 1. **Dashboard Overview**: The Fraud Monitoring Dashboard presents five graphical views of active channels that summarize event data. 2. **Drill-Down Functionality**: To access detailed information about a specific active channel (e.g., to investigate possible fraudulent activity), double-click on the relevant chart. This action reveals the underlying active channel supplying event data for further analysis. 3. **Active Channels and Filters**: The charts in the Fraud Monitoring Dashboard are based on predefined filters, as outlined in Table 2-3. Each active channel corresponds to a specific filter:

• **Transactional Activity**: Focuses on transactions from financial applications.

• **Possible Fraudulent Activity**: Covers all possible fraudulent events identified by fraud correlation.

• **Watched Account Additions**: Highlights accounts added to the watched list.

• **Suspicious Account Additions**: Shows accounts escalated as suspicious or added under this category.

• **Fraudulent Accounts Investigate List**: Includes accounts that have been flagged as potentially fraudulent.

4. **Configure FraudView Solution Content**: This section provides guidance on how to enable and configure the content for the FraudView solution, ensuring it can effectively monitor and detect fraud within financial applications and systems. Overall, this document serves as a guide to setting up and using the FraudView solution in an ArcSight environment, focusing on its functionality and configuration options related to monitoring potential fraudulent activities. This document provides a guide for configuring and deploying the FraudView solution within the ArcSight platform. The topics covered include: 1. Deploying FraudView Rules: To enable processing of FraudView events, the rules must be deployed to the Real-time Rules group. This involves navigating to the appropriate group in the Navigator panel, right-clicking, and selecting 'Deploy Real-time Rule(s)'. A new linked group will be created for managing these rules. 2. Configuring Account Escalation: The solution allows customization of escalating tracking lists and rules to monitor suspicious account behavior. Configuration is optional and detailed instructions can be found in a separate section titled "Configure Account Escalation—Optional" on page 47. 3. Configuring Cases: FraudView integrates with ArcSight's case management system, which can either be used as-is or integrated with third-party systems. The solution includes the ArcSight Solutions/FraudView 1.0 group for storing generated cases, and users can add additional groups to differentiate between different types of cases if needed. 4. Configuring Notifications: This feature allows users to set up notifications based on specific conditions or events within the FraudView solution. The configuration is detailed on page 40. 5. Configuring Pattern Discovery: This involves setting up rules for detecting patterns in data that are indicative of potential fraud, as described on page 41. 6. Configuring FraudView Use Cases: Custom use cases can be created and configured within the solution to handle specific scenarios or situations related to fraudulent activities. These configurations are detailed starting from page 41. To enhance ArcSight Solutions/FraudView 1.0's functionality by adding more groups and customizing case generation, follow these steps: 1. **Add New Groups**: Include additional groups to expand the capabilities of the system. This will enable you to integrate with other relevant systems or modules that might be useful for fraud detection. 2. **Modify ArcSight ESM Rules**: For new groups added, modify the rules in the ArcSight Event Management System (ESM) that create cases. These rules should be updated to use your newly defined case groups. This ensures that all generated cases are properly categorized and can be managed more effectively within these groups. 3. **Edit FraudView Rules**: If you want to specifically track certain suspicious activities, such as excessive file transfers or wire transfers to the same payee, edit the relevant rules (like "Excessive Wire Transfers to Same Payee") to include actions that create cases automatically. This customization allows for real-time tracking of these specific behaviors. 4. **Customize Rule Triggers**: You can also adjust which rules are triggered based on suspicious behavior. Refer to the documentation provided in “Customize Escalation Rules” (mentioned elsewhere) for detailed instructions on how to configure and implement these customizations. This customization feature helps in fine-tuning the detection algorithms according to your organization's specific fraudulent patterns or activities. 5. **Configure Notifications**: For notifications related to possible fraudulent behavior, customize them by editing rules that are triggered based on suspicious behaviors like adding transactions to the Suspicious Accounts List or Fraud Investigate List. This customization helps in promptly alerting relevant stakeholders about potential fraud incidents as they occur. By following these steps and leveraging the flexibility of case generation and notification settings within ArcSight Solutions/FraudView 1.0, you can significantly improve your organization's ability to detect and respond to fraudulent activities efficiently and effectively. The document outlines configuring notifications in ArcSight's FraudView solution to detect specific behaviors such as excessive file transfers to the same payee and involves creating rules with actions that send notifications. These notifications are sent to designated destinations, which could be users or systems configured for notification purposes. This configuration is optional but can help in monitoring unusual patterns within transaction data by utilizing Pattern Discovery profiles, which are used to identify specific patterns based on predefined or custom settings. The effectiveness of these configurations depends on understanding the normal activity baseline and using detailed guides provided in the ArcSight Console online Help and ArcSight Pattern Discovery™ Guide. Additionally, some use cases might require configuration of active lists for full functionality, as outlined in the FraudView Early Warning Use Cases chapter. ArcSight ESM (Extended Security Management) allows users to manage security events by adding them to lists for analysis and response. There are two methods to add entries to an active list in ArcSight: one-by-one using the List Entry editor, or in bulk from a CSV file. **Adding Entries One-by-One:** 1. **Navigate to Lists**: In the ArcSight ESM Console, go to the "Lists" section in the Navigator panel. 2. **Select Active Lists**: Switch to the "Active Lists" tab. 3. **Locate the List**: Navigate to "ArcSight Solutions/FraudView". 4. **Show Entries**: Right-click the list you want to populate and select "Show Entries". The list details will appear in the Viewer panel. 5. **Add Entries**: For each entry, perform these steps:

• Click the add icon in the list header.

• In the Inspect/Edit panel of the Entry editor, enter required fields for the list and click "Add".

**Adding Entries in Bulk from a CSV File:** 1. **Import CSV File**: Right-click on the active list in the ArcSight ESM Console's Active Lists resource tree and choose "Import CSV File". 2. **File Browser**: A file browser will appear, allowing you to select the desired CSV file. 3. **Preview Data**: The Import Preview dialog will display the data from the CSV file that will be imported into the active list. 4. **Add Entries**: Confirm and add the entries from the selected CSV file to the active list. Note: Only active lists can be populated using a CSV file, while session lists must be added one-by-one manually. To import new entries from a CSV file into an existing list in the Import Preview dialog, follow these steps: 1. Open the Import Preview dialog and click OK. This will append the new entries from the file to the existing entries in your active list. 2. Verify that the imported entries are as expected by right-clicking the active list you just populated with the CSV file and selecting "Show Entries." This will display the newly added data from the CSV file in the Viewer panel, showing it as details of your active list. 3. In ArcSight™ FraudView v1.0, accounts exhibiting suspicious behavior are tracked using tracking lists: if an account is identified as exhibiting such behavior, it can be placed into an account monitoring active list or escalated (moved) to a higher level of concern, depending on the severity of the behavior. 4. The solution provides three levels of account escalation lists: Watched Accounts (lowest level), Suspicious Accounts (medium level), and Investigate List (highest level). These lists are populated automatically by specific rules, such as Add to Watched Accounts List or Add to Suspicious Accounts List. The process involves adding accounts to a fraud investigation list based on their activity. Initially, it assumes that an account is trusted until suspicious behavior is detected. This behavior can be as simple as creating an account from a country of concern. Once such behavior is identified through specific events or rules (like the Account Registration From Country of Concern rule), the account gets added to the Watched Accounts active list. For escalating accounts, if three instances of low-level suspicious behavior are detected for an account, it moves up the list from the Watched Accounts to the Suspicious Accounts active list. This progression helps in identifying potentially fraudulent activities more efficiently by following a predetermined set of rules and procedures that trigger when certain conditions are met. The complete listing of these rules is provided in Table3-2, which outlines all the scenarios where an account ID might be added to the Watched or Suspicious Accounts active lists based on suspicious activity thresholds. The text provides a detailed explanation of how accounts are identified and placed on different lists within a system for monitoring suspicious activities. Here's the summary of the process described: 1. **Account Escalation:**

• If an account is detected to have committed three instances of medium-level suspicious behavior, it gets escalated. This involves placing the account ID in the "Suspicious Accounts active list."

2. **Medium Level Suspicious Behavior:**

• When a medium level of suspicious activity is detected for an account, the following steps occur:

• An event indicating the suspicious activity occurs (e.g., excessive wire transfers to the same payee within five minutes).

• The "Add to Suspicious Accounts List" rule is triggered based on this event or any other medium-level suspicious rules that are activated.

• When the trigger happens, the account ID is added to the "Suspicious Accounts active list."

3. **How Accounts Get On the Investigate List Active List:**

• If an account has three instances of medium-level suspicious behavior detected, it gets escalated and its account ID is added to the "Investigate List active list."

These processes are outlined in detail with specific rules and events that lead to placing accounts on various lists for further investigation or monitoring. The text outlines a process for handling suspicious accounts within a system, detailing how low and high levels of suspicion can lead to an account being placed on the Investigate List. Here's a summary of the key points: For medium-level suspicions detected in three separate instances under the same account ID (step a), a rule triggers escalation from Suspicious Accounts to Possible Fraudulent, which then moves the account to the Investigate List (steps b and c). When high-level suspicious behavior is detected, specific events such as brute force login attempts trigger rules that add the account ID to the Investigate List (step a). These actions are outlined in steps b and c. The process involves using predefined rules which, when triggered by suspicious activities, place an account on the Investigate List. This list represents accounts under investigation for potential fraudulent or suspicious activity. Users can customize the active lists and rules used in this escalation process, although it is not mandatory (section "Configure Account Escalation—Optional"). In summary, the text describes a systematic approach to handling suspected fraudulent activities by escalating account status from Suspicious to Investigate based on detected suspicious behaviors or events. The document outlines procedures for managing accounts on three distinct lists used in monitoring suspicious activities within a system: Watched Accounts, Suspicious Accounts, and Investigate List. These lists are dynamically populated based on predefined rules triggered by suspicious activity events that meet specific escalation conditions. Manual adjustments can be made to these lists as needed; for instance, an account may be manually moved from the Watched Accounts list to the Suspicious Accounts list if deemed appropriate after investigation. To customize entries in Account Escalation lists: 1. Navigate to the Resources tab and select Lists under ArcSight Solutions/FraudView 1.0/Escalation. 2. Expand the relevant group for the specific list you wish to modify. 3. Right-click on the active list and choose Show Entries. 4. Add or remove accounts by clicking the Add Entry icon for additions or right-clicking an entry in the Viewer and selecting Delete for removals. 5. Accounts remain inactive on a list for 7 days after which they are automatically removed if no suspicious activity is detected; however, you can adjust this default period under TTL Days in the active list editor. 6. For the Investigate List specifically, there's no automatic timeout, allowing manual management of entries. Additionally, customizing account escalation rules includes modifying the conditions for moving accounts between lists: 1. By default, an account must appear on either the Watched Accounts or Suspicious Accounts list three times to be moved to the next level list (e.g., from Suspicious Accounts to Investigate List). 2. The number of required appearances can be adjusted according to specific needs. This manual management allows for more tailored and dynamic responses to suspicious activities, ensuring that each account's placement on these lists is appropriate based on its involvement in potentially suspicious activity patterns. The document outlines how to customize account escalation in ArcSight by changing the value of "Units" for specific rules within certain conditions, thereby modifying which accounts are added to different active lists. These lists include Watched Accounts, Suspicious Accounts, and Investigate List. By editing the entries in the appropriate Add to active list, users can customize the rules that trigger these actions based on their organization's needs. For instance, a rule about creating and paying a payee by the same user could be moved between lists depending on the severity of the action being monitored. Each rule should only appear once across all Add to active lists to avoid inconsistent escalation processes. The document provides detailed steps for adding or removing rules from these lists, ensuring that each step is clearly defined and instructions are unambiguous. The text provides a guide on how to manage lists related to account escalation within the ArcSight FraudView solution. Here's a summary of the steps and resources mentioned: 1. **Navigate to the Active List**: To modify or view specific lists, navigate to the appropriate active list for editing. For example, go to the "ArcSight Solutions/FraudView 1.0/Escalation" section and select the "Add to Fraud Investigate List" active list. 2. **Show Entries**: Right-click on the active list and choose 'Show Entries' to view all entries in that list. 3. **Delete an Entry**: To remove an entry from the active list, right-click on it and select 'Delete'. 4. **Resource Tables**: The document includes tables summarizing resources and rules related to account escalation:

• **Table 3-1** lists resources that support the account escalation process.

• **Table 3-2** details the rules triggering placement on the "Watched Accounts" active list.

• **Table 3-3** outlines the rules for placing accounts on the "Suspicious Accounts" active list.

• **Table 3-4** lists the rules governing inclusion in the "Investigate List" active list.

These tables provide a comprehensive overview of the resources and criteria used to manage different levels of account scrutiny within the ArcSight FraudView system. The document describes a system for monitoring and managing suspicious or fraudulent accounts using software from ArcSight (now part of Dell) and its module called FraudView. The system has several features to help users identify, track, and escalate potentially risky accounts: 1. **Active List Configuration**: Users can define rules that automatically add account information to either a Suspicious Accounts List or an Investigate List whenever certain conditions are met. These lists include rule names associated with ArcSight's Solutions/FraudView module. 2. **Escalation Rules**: There are specific rules defined within the system for escalating accounts:

• **From Suspicious to Fraudulent**: When an account is added three times to the Suspicious Accounts List, it gets removed from this list and added to the Fraudulent Investigate List.

• **From Watched to Suspicious**: Similarly, if an account is added three times to the Watched Accounts List, it moves from there to the Suspicious Account List.

3. **FraudList Channel**: This channel displays accounts that have been recently added to a FraudView watch list within the last two hours. The dashboard for this feature provides visibility into these accounts in real-time. The document is part of ArcSight's documentation, aimed at helping users understand and configure their fraud detection system effectively. The document provides an overview of a system called ArcSight, specifically its FraudView module, which is used to monitor and escalate accounts added to watch lists for potential fraud. The different colors in the FraudView dashboard correspond to varying levels of severity on the watch lists. Key features include: 1. **Data Monitor**: Displays accounts that have been added to the FraudView watch lists, with each account color-coded according to its severity level. 2. **Activity Filters**:

• **Fraudulent Accounts**: Retrieves events from accounts in the active list suspected of fraudulent activities.

• **Suspicious Accounts**: Retrieves events from accounts in the active list that exhibit suspicious behavior.

• **Investigate List**: Checks for accounts listed under Investigation, used to determine risk through a priority formula.

• **Suspicious List**: Also uses a priority formula to assess account risks based on entries in the Suspicious Accounts List.

• **Watched List**: Utilizes the same risk determination method as Investigate List and Suspicious List but applies to the Watched Accounts List.

3. **Account Filters**:

• **Investigate List Filter**: Checks for accounts listed under Investigation, impacting account risk modeling through a priority formula.

• **Suspicious List Filter**: Similar function to Investigate List Filter but pertains specifically to accounts in the Suspicious Accounts List.

• **Watched List Filter**: A filter that operates on the Watched Accounts List, also affecting risk assessment via the priority formula.

4. **Risk Modeling and Account Risk Assessment**:

• The filters mentioned above are crucial for determining account risks using a priority formula in both Investigate and Suspicious Lists, as well as Watched Lists. This is essential for effective fraud detection and prevention within the system.

This document outlines how accounts are monitored and assessed for risk levels based on their involvement with different lists and activities within the ArcSight FraudView module. The provided text outlines several rules and their functionalities in the context of security monitoring using the ArcSight platform, specifically within the FraudView module. These rules are designed to detect suspicious activities such as accessing blacklisted countries, account lockouts, creation at unusual times, registration from concerned countries with public email addresses, foreign credit card transactions, excessive wire transfers, and access disparities across multiple countries in a single hour. Each rule is associated with specific indicators like "fraud early warning" or "suspicious time," and results are saved to active lists for further investigation. The text provides an overview of various rules and their functions within the ArcSight FraudView solution, designed to detect potential fraud, suspicious activities, and violations across multiple accounts. Here's a summary: 1. **Multiple Transactions by Same User** - This rule triggers when an account issues five transactions (like payments or wire transfers) within one minute, indicating possible fraudulent activity. 2. **Password Reset Rule** - It identifies password resets and updates the list with account information, helping to monitor suspicious activities related to password changes. 3. **Payee Created and Paid Rule** - This rule detects when a payee is created and paid by the same user within 2 minutes during unusual hours of the day, potentially indicating fraudulent actions. 4. **Suspicious Payee Payments Rule** - It identifies payments to suspicious payees defined in the active list, which is populated by other rules like "Paying Same Payee" rule and includes known suspicious payees manually added. 5. **Penny Stock Transactions Rule** - This rule flags sell or purchase of more than 100,000 units at a price less than $0.75 each, which might indicate penny stock trading or other investment anomalies. 6. **Country of Concern Login Rule** - It detects successful logins from countries listed in the Countries of Concern list, helping to monitor transactions potentially linked to those regions. 7. **Trading Violation Rule** - This rule identifies if a trader exceeds the daily purchasing limit set at $10 million, which could signal unauthorized trading or other financial irregularities. These rules collectively aim to prevent fraud and suspicious activities across various aspects of account management and transactions, using predefined criteria to identify potential threats in real-time scenarios. This text outlines several rules and thresholds set by Rule ArcSight under the Solutions/FraudView module for identifying potential fraudulent trading activities in banking and trading scenarios. The default settings are as follows: 1. **Daily Selling Violation**: If a trader exceeds $10,000,000 in daily sales, this rule will trigger an alert indicating potential fraud. 2. **Single Transaction Violation**: If a single transaction exceeds $500,000, Rule ArcSight will issue an alert for exceeding the specific/investment banking/trading threshold. 3. **Single Transaction Asset Violation**: If the value of assets traded in a single transaction exceeds $500,000 units (stocks, bonds, options, etc.), this rule will identify potential fraud and trigger an alert. 4. **Transaction Per Day Violation**: The daily threshold for transactions is set at 100, triggering alerts if exceeded. 5. **Daily Asset Type Unit Violation**: If the number of asset type units traded per day exceeds $500,000, Rule ArcSight will flag this as a potential violation. 6. **Weekly Transaction Anomaly Violation**: For accounts with 10 or more weekly transactions, today's transaction sum should not exceed 50% of the previous week's total, or the number of transactions executed today should not be more than 50% of the entire previous week's count. If an account has fewer than 10 weekly transactions, the rule triggers if today's transactions are three times greater than the previous week's transactions in either value or quantity. These rules and thresholds aim to detect fraudulent trading behaviors by setting specific monetary limits for each type of transaction and volume, helping to prevent financial loss and maintain integrity within the trading industry. The document outlines a set of rules and their descriptions, primarily designed for detecting fraudulent activities within financial transactions using the ArcSight™ Solution Guide FraudView version 1.0. These rules focus on various aspects such as wire transfer violations, unauthorized logons from specific IP ranges, registration of accounts from certain networks, entitlement violations, and excessive transfers to the same payee. Each rule is associated with a resource description, type URI, and specified threshold or condition for triggering an alert. For example: 1. **Transfers Just Below the Violation Threshold** - Triggered when at least three wire transfers within 5 minutes occur between the same payer and payee. 2. **Transfers Over the Violation Threshold** - Triggered if a wire transfer exceeds the specified financial threshold. 3. **Account Logon from RBN Address Space** - Identifies unauthorized logons to accounts originating from the Russian Business Network (RBN) address space. 4. **Account Registration from RBN Address Space** - Detects registration of new accounts within the RBN address space, potentially indicative of fraudulent activity. 5. **Entitlements Violation** - Triggered when an account performs a transaction with financial instruments to which it is not entitled, requiring active lists for specific financial instruments to be defined and updated. 6. **Excessive Wire Transfers to the Same Payee** - Alerts if an account makes at least three payments within five minutes to the same payee, indicating potential fraudulent behavior. 7. **Login from Known Fraudulent IP Address** - Triggered when an account is accessed from a known fraudulent IP address, requiring an active list of such addresses to be regularly updated for effective monitoring. The provided text outlines a series of rules and descriptions related to password resets, payee creation and payment, login IP address analysis, brute force attacks on accounts, and fraudulent SSNs within the ArcSight™ Solution Guide - FraudView v1.0. These rules are designed to detect potential fraud or suspicious activities by identifying patterns such as multiple failed attempts at resetting a password (which could indicate an automated attack), payees created and paid by the same user without proper authorization, logins from known suspicious IP addresses, and accounts potentially created using fraudulent SSNs. When these conditions are met, the affected accounts are flagged for further investigation on the "Investigate List." This system is intended to help organizations proactively identify and respond to potential fraud scenarios before significant financial loss occurs. In this chapter, we delve into the foundational early warning rule-based use cases that form the backbone of the FraudView solution. These use cases are designed to monitor and escalate suspicious account behavior by utilizing a set of rules based on predefined tracking lists. One such use case is the "Excessive Wire Transfers to Same Payee," which triggers when three wire transfers occur within five minutes to the same payee from the same account. Upon activation, it creates a correlation event that triggers another rule, the "Add to Suspicious Accounts List." This rule places an Account ID on the active list and escalates the status of this account due to its repeated entries in the suspicious accounts list. The next rule in the sequence is the "Escalate Account - Suspicious to Possible Fraudulent" rule. It activates when an account, specifically with the ID 23489, appears on the active suspicious accounts list three times. This escalation leads to the creation of a case and the dispatching of a notification, indicating the possible fraudulent nature of the account activity. The chapter further explains that this rule-based system is supported by FraudView and serves as an early warning mechanism for potential fraudulent activities in financial transactions. The use cases are outlined in detail within Chapter 3, titled "Account Escalation," which can be accessed for more information on page 43. OFAC (Office of Foreign Asset Control) has developed several use cases aimed at combating financial crimes, including fraudulent activities and illicit transactions with blacklisted countries. Here's a summary of each use case as described in the provided pages: 1. **Account Created Using Fraudulent SSN**: This use case focuses on identifying attempts to open bank accounts using Social Security Numbers (SSNs) that are known to be fraudulent. It aims to prevent unauthorized access and potential financial fraud by detecting false applications. 2. **Account Lockout Detected**: This use case is designed to detect when an account has been locked out due to suspicious activity, indicating a possible breach of security or multiple failed login attempts which might suggest fraudulent activities. 3. **Account Logon from RBN**: Specifically targeting assets categorized in the Russian Business Network (RBN) address ranges, this use case monitors successful logons to identify potential cyber-enabled financial crimes facilitated by the network. 4. **Account Registration at Suspicious Time**: This use case is intended to detect accounts created outside of normal business hours, specifically between 8:00 p.m. and 6:00 a.m. on weekdays, as well as all day on weekends. It aims to flag unusual activity that could be indicative of fraudulent account creations. 5. **Account Registration From Country of Concern**: This use case identifies accounts created in countries where significant fraud has been historically reported. These "countries of concern" are defined based on the nature and volume of previous fraud incidents, ensuring proactive monitoring for potential future fraudulent activities originating from such regions. 6. **Account Registration from RBN**: Similar to the Logon use case, this focuses on account creations that originate from assets within the Russian Business Network address ranges. It helps in tracking and detecting financial crimes conducted through or involving entities linked to the RBN. Each of these use cases serves a critical role in preventing financial fraud by monitoring specific patterns and activities associated with potential fraudulent transactions, helping organizations comply with regulations set forth by OFAC and other regulatory bodies aimed at combating illicit financial practices. This summary outlines various use cases related to fraud detection in the ArcSight Solutions/FraudView module, specifically categorized under the "Russian Business Network" asset category. The purpose of each case is described as follows: 1. **Account Registration Using Public Email**: Identifies accounts created with email addresses from public providers like yahoo.com, gmail.com, hotmail.com, msn.com, and hushmail.com. This helps in identifying potentially fraudulent registrations. 2. **Brute Force Login Success**: Detects successful logins after a brute force attack within one minute. This is crucial for detecting unauthorized access attempts that might not immediately fail but could be indicative of fraud or breach attempts. 3. **Excessive Wire Transfers to Same Payee**: Monitors and alerts when three or more payments are made from the same account to the same payee within five minutes. This helps in identifying potential fraudulent transactions. 4. **Geographic Disparity of Account Access**: Alerts if an account is accessed from more than one country within an hour, which may indicate unauthorized access or geographical fraud. 5. **Login from Known Fraudulent Address**: Identifies when an account has been accessed from a known fraudulent IP address, helping to detect compromised accounts used in phishing or other fraudulent activities. 6. **Multiple Accounts Paying Same Payee**: Detects instances where three different accounts pay the same payee within five minutes, which could be indicative of collusion or fraud. 7. **Multiple Failed Logon Attempts**: Monitors and alerts when there are three consecutive failed login attempts to the same account within one minute, signaling potential hacking attempts or unauthorized access attempts. 8. **Multiple Password Resets**: Identifies instances where a password has been reset more than once for the same account, which might suggest multiple failed login attempts or fraudulent activities. These use cases are part of a broader suite designed to detect and prevent various forms of fraud in financial transactions and account accesses, particularly those that may involve unauthorized access and fraudulent activities related to compromised accounts. The provided summaries are brief overviews of various use cases related to fraud detection and security analysis in financial systems. Here's a consolidated summary based on the descriptions given: 1. **Multiple Transactions by Same User**: This use case is designed to detect when an account makes five or more transactions, payments, or wire transfers within a single minute. The purpose is to prevent fraudulent activities such as money laundering or large-scale financial fraud. 2. **Password Reset Not Preceded by Lockout**: This use case aims to identify instances where a password reset occurs without the user being locked out first. It could indicate potential unauthorized access attempts, which might be indicative of account takeover or hacking attempts. 3. **Payee Created and Paid - Same User**: The purpose of this use case is to detect when a payee is both created and paid by the same user within the same transaction. This can help in detecting fraudulent activities where someone creates a fictitious payee for unauthorized payments, potentially leading to financial loss. 4. **Payee Created and Paid - Suspicious Time**: This use case identifies cases where a payee is created and paid by the same user within two minutes during a suspicious time of day. The purpose is to identify potential fraudulent activities that might occur under unusual circumstances. 5. **Paying Suspicious Payee**: The purpose of this use case is to detect payments made to suspected fraudulent or high-risk payees. It helps in preventing financial losses by identifying and flagging transactions with suspicious payees. 6. **Successful Login from Country of Concern**: This use case identifies successful logins that originate from countries considered a risk for potential fraud or unauthorized access, helping in monitoring and securing such activities. 7. **Successful Login from Suspicious Address**: The purpose of this use case is to detect successful logins coming from IP addresses typically associated with suspicious activity. It contributes to the overall security by flagging risky login attempts from unknown or unusual locations. 8. **Transaction Behavior Anomaly**: This use case focuses on identifying anomalies in transaction behavior for accounts with a limited number of weekly transactions (usually 10 or less). The specific anomaly criteria include whether the sum of today's transactions exceeds three times the average amount from the previous week, and whether the number of transactions executed today is unusually high compared to previous weeks. This helps in detecting potential fraudulent activitie,s that might not be immediately apparent through other means. These use cases are part of a larger set aimed at enhancing fraud detection and prevention mechanisms within financial systems, ensuring robust security measures against various types of financial crimes. The document outlines specific use cases within the FraudView solution designed for various industries, including Credit Card and Investment Banking. These use cases aim to detect anomalies or suspicious activities based on predefined criteria related to transaction volume, amounts, timing, and types (e.g., foreign transactions, unauthorized financial instrument trades). Specifics include:

• **Transfers Just Under Violation Threshold** detects three or more wire transfers under a specific threshold within five minutes.

• **Transfers Over Violation Threshold** identifies when three or more wire transfers exceed the same threshold within five minutes.

• **Card Used in Foreign Country** is designed to identify credit card transactions occurring in a country different from where the account was originally created.

• **Entitlements Violation** aims to detect unauthorized trading of financial instruments (e.g., bonds) by an account.

• **Excessive Wire Transfer Requests** focuses on identifying instances when an account has executed more than three wire transfers with less than eight hours between transactions.

• **Penny Stock Transactions** is used to identify sell or purchase activities exceeding 100,000 units (like stocks and options) if the price per unit is below $0.75 each.

• **Trading Violation - Dollar Per Day - Purchased** detects when a trader exceeds the daily purchasing threshold of 10,000,000 dollars.

These use cases are tailored to specific industries and aim to detect potential fraudulent activities or unusual patterns in financial transactions. The documents outline several "Trading Violation" use cases designed to identify potential trading violations such as exceeding daily transaction limits or unit thresholds for specific asset types like stocks, bonds, and options. These use cases include: 1. **Dollar Per Day Threshold - Sold**: This use case checks if a trader has sold more than $10,000,000 worth of assets in a single day. 2. **Single Transaction Dollar Threshold**: Identifies if a trader has made a transaction exceeding $500,000 in value. 3. **Single Transaction Units Threshold**: Detects if a trader has traded more than 500,000 units of an asset type such as stocks, bonds, or options within a single transaction. 4. **Transactions Per Day Threshold**: Monitors the number of transactions made by a trader in a day and alerts when this exceeds 100. 5. **Units Per Day Threshold**: Alerts if the total number of units traded (per asset type) surpasses the daily threshold set for that specific asset class. These use cases are part of the Fraud Early Warning series within the ArcSight solution, which also includes:

• **Accessing Multiple Accounts from Single IP**: This use case is triggered when three or more accounts are accessed from a single IP address within two minutes, based on a predefined rule that checks for suspicious activity.

The use case for accessing multiple accounts from a single IP address involves using FlexConnectors to supply events of the "Account Access Attempt" type. A filter must be configured for this event, which will identify when at least three accounts are accessed from an IP address within two minutes. This can help in identifying suspicious activity related to fraudulent activities by populating an active list with potentially involved accounts. The resources required for this use case include ArcSight Rule and filters. The "Accessing Multiple Accounts from Single IP" rule is part of the ArcSight Solutions/FraudView 1.0, specifically designed to detect when at least three accounts are accessed from a single IP within two minutes, indicating suspicious activity. The filter used for this purpose is called the Account Access Attempt event type. It must be properly configured to ensure that corresponding events are generated by the connector and matched with specific conditions. The connector should also set certain fields in these events with particular values to facilitate proper filtering. In addition, there's a use case related to identifying account activity from OFAC (Office of Foreign Asset Control) blacklisted countries. This involves triggering a rule based on the Account Activity From OFAC Blacklisted Country rule, where FlexConnectors supply events of either "Account Access Attempt," "Account Creation," or "Account Access Fail" types. These events are used to detect account activity from countries that have been banned by OFAC. This summary outlines the use case for identifying account creation and access attempts from OFAC (Office of Foreign Asset Control) blacklisted countries, specifically focusing on maintaining an active list of these blacklisted countries and configuring filters to detect related events. The resources supporting this use case are detailed in a table, which includes descriptions and URIs for ArcSight solutions that identify rule-based patterns associated with account activity from OFAC blacklisted countries. These include rules for detecting access attempts, creation events, failures, and successes, along with corresponding filters and event types to ensure proper detection and matching of such activities based on specific conditions and field values set by the connector. The text discusses the use of an Account Filter in ArcSight to define and identify specific types of account accesses, such as access failures and successful accesses. It outlines how to ensure that corresponding events are generated by a connector and matched by filter conditions. Additionally, it addresses a use case for identifying attempts to open accounts with known fraudulent Social Security Numbers (SSNs), which involves configuring FlexConnectors to supply Account Creation events and setting up appropriate filters. The text also mentions the importance of maintaining an active list of fraudulent SSNs and provides a table listing resources relevant to this use case. The provided text discusses the use case for detecting account lockouts using ArcSight's FraudView solution. Here's a summarized version of the key points: 1. **Active List Usage**: A fraudulent Active List in ArcSight's FraudView is used to store Social Security Numbers (SSNs) that are associated with potential fraud cases. This list must be manually maintained and regularly updated due to its high risk nature. 2. **Account Creation Filter**: An Account Creation filter is employed to define the creation of an account event, ensuring that a corresponding event is generated by the connector and matched by specified conditions. The connector should also set certain event fields with specific values. 3. **Account Lockout Detection Use Case**: The purpose of this use case is to identify when accounts are locked out. It relies on the Account Lockout Detected rule, which adds locked-out account IDs to the active list called Account Lockouts. 4. **Triggering the Rule**: To activate the Account Lockout Detected rule, FlexConnectors must supply events of the Account Lockout type. A corresponding filter for this event type must also be configured. 5. **Resources Support**: The use case relies on several resources including rules and filters to identify account lockouts and populate the active list. These include the Account Lockout rule, which identifies locked accounts, and an Active List called Account Lockouts that is used to determine if a password reset is preceded by an account lockout. 6. **Filter Configuration**: A specific filter known as the Account Lockout filter is used to define the criteria for detecting an account lockout event. This involves ensuring that events are generated appropriately and matched with specified conditions. In summary, this use case in ArcSight's FraudView focuses on identifying and managing locked accounts through a series of rules, filters, and active lists designed to detect and respond to potential fraudulent activities related to account lockouts. The Account Logon from RBN use case is designed to identify successful account access events originating from assets within the Russian Business Network (RBN) address ranges. This is achieved by configuring a rule that triggers when FlexConnectors provide events of the Account Access Success type, and ensuring that the associated filter is properly configured. The RBN address ranges are defined in specific groups within ArcSight Solutions/Fraud View, with the Russian Business Network category responsible for categorizing these assets. These ranges must be maintained periodically to ensure accuracy. The rule itself is based on the Account Logon from RBN and serves as a crucial component of fraud detection strategies aimed at monitoring access from known RBN addresses. To configure this use case effectively, it's essential that FlexConnectors supply events of the Account Access Success type. Additionally, proper configuration of the filter associated with this event type is necessary to ensure accuracy in identifying successful accesses. The resources required for this implementation are outlined in Table 4-5, which includes descriptions and URIs of relevant components such as rules, filters, and asset ranges that define RBN addresses. This setup supports a comprehensive approach to managing risks associated with unauthorized access attempts from the identified Russian Business Network address space. The article discusses a use case designed to detect accounts created at unusual or suspicious times, based on the Account Registration at Suspicious Time rule. By default, this involves creating an account between 8:00 p.m. and 6:00 a.m. on weekdays, plus all day Saturday and Sunday. The device receipt time of the event is compared against these conditions to identify suspicious activity. To implement this use case, FlexConnector(s) must provide events of the Account Creation type, with an associated filter configured for the Account Creation event type. Customization of the Suspicious Time of Day filter allows redefining the suspicious period using variables like DayOfWeek and HourOfDay. This filter is crucial for identifying suspicious times during weekdays or specific days. The resources supporting this use case include a rule in ArcSight Solutions/FraudView 1.0/Fraud Early Warning that identifies accounts created at suspicious times, and a Suspicious Time of Day filter used to identify such times throughout the week or on particular days. The Account Registration From Country of Concern use case is designed to identify account creations originating from countries known for high fraud rates. It utilizes a rule that requires at least one FlexConnector to supply events of the Account Creation type, and it necessitates configuring a filter associated with this event type. This use case relies on a list of ISO country codes maintained by the International Organization for Standardization (ISO), which can be found at http://www.iso.org/iso/country_name_codes. The rule in question identifies accounts being created from countries listed in the Countries of Concern active list, thereby assisting in fraud prevention and early detection efforts. The Account Registration from RBN use case in ArcSight aims to identify successful account creations originating from assets within the Russian Business Network (RBN) address ranges. To achieve this, it uses a FlexConnector(s) that supply events of the Account Creation type and a specific filter associated with this event type. This filter should be properly configured to ensure proper detection of RBN-related account creations. Additionally, the RBN address ranges defined under the ArcSight Solutions/Fraud View/RBNet group must be updated periodically for accurate results. Supporting resources for this use case are listed in a table, including rules and filters designed to identify such events. The provided text outlines a method for defining an account creation event filter within ArcSight, specifically for identifying accounts created using public email addresses from popular providers like Yahoo, Gmail, Hotmail, MSN, and Hushmail. This process involves configuring a FlexConnector to generate Account Creation events and setting up a corresponding filter with specific conditions to ensure the rule's applicability. The use case is designed to detect such accounts during registration for early warning in fraud prevention systems. Supporting resources are listed, including the Rule, Filter, and Event Type definitions needed to implement this functionality within ArcSight's FraudView solution version 1.0. The Brute Force Login Success use case is designed to detect successful logins that occur within one minute after a brute force attack. It involves two main events: the occurrence of a successful brute force login and a subsequent successful account access to a financial application, which triggers an Account Access Success filter. To activate this rule, FlexConnector(s) must provide events of the Account Access Success type, while configuring a filter for these events is also necessary. Additionally, an Intrusion Detection System (IDS) should be set up to report brute force login attempts. The Smart Connector, which collects events from the IDS, needs to map the attacked account to the Account Id (attackerUserName) field. This use case relies on resources such as ArcSight Confidential and ArcSight™ Solution Guide FraudView v1.0 to identify patterns of fraudulent activity related to brute force attacks. The text provides a summary of how to use filters for identifying and defining successful account access, detecting brute force login attempts, and managing excessive wire transfers in the context of an IDS (Intrusion Detection System). It outlines specific steps and configurations required for different scenarios such as "Brute Force This filter" for identifying potential login brute force attacks, "Account Access Filter" for defining successful account access events, and a use case named "Excessive Wire Transfers to Same Payee." The Brute Force filter is used to detect potential login attempts that could indicate a security breach. The Account Access filter ensures that only successful accesses are logged by verifying that corresponding event fields meet certain conditions. For the Excessive Wire Transfers use case, it requires FlexConnectors to provide Wire Transfer events and correlates these with specific filters for accurate identification. This setup involves configuring rules and filters in both ArcSight solutions and ensuring proper field settings within connectors. The resources listed include a rule (Excessive Wire Transfers to Same Payee) designed to identify multiple payments made from an account to the same payee within a short time frame, along with a filter specific to wire transfer events for further analysis. This information is crucial for enhancing security measures and preventing fraudulent activities in financial transactions by providing actionable insights into suspicious patterns detected through these automated processes. The Geographic Disparity of Account Access use case aims to detect if an account has been accessed from multiple countries within a single hour. It updates the Geographic Access Records with the Country Code for each login event, based on specific conditions. If there's no existing entry for the account or the country code in the record differs from that in the attackerGeoCountryCode field of the login event, the rule is triggered. To implement this use case, FlexConnectors must provide events such as ATM Authentication and Account Access Success. These events require specific filters to be configured. Additionally, for processing ATM authentication events:

• Each ATM must have a valid IP address assigned.

• Private IP addresses need location resources with the appropriate country field linked to ATM zones, asset ranges, or assets.

The use case relies on several resources as outlined in Table 4-12, including ArcSight Solutions/FraudView 1.0/Fraud Early Warning and Ar. These resources support the detection of account access from multiple countries within an hour. The provided summary outlines the functionality and purpose of several components within the ArcSight™ FraudView solution, specifically designed for identifying and managing fraud scenarios involving account access from multiple countries and detecting access from known fraudulent IP addresses. 1. **Geographic Active List**: This feature tracks the country codes from which accounts are accessed, storing this information in a list that expires after one hour. It is initially populated when an account is first accessed and serves to monitor potential fraud by recording such accesses. 2. **ATM Authentication Filter**: This filter is used specifically to identify ATM authentication events. It ensures that the corresponding event is generated by the connector and matched with specific conditions in the filter setup, potentially requiring the connector to set certain event fields. 3. **Account Access Success Filter**: This filter helps define successful account access events. Similar to the ATM Authentication Filter, it requires a corresponding event from the connector and matches predefined conditions, possibly involving setting specific field values. 4. **Login from Known Fraudulent Address Use Case**: This use case aims to identify when an account has been accessed from a known fraudulent IP address. It relies on the Login from Known Fraudulent Address rule, which requires FlexConnectors to provide Account Access Success type events and involves configuring filters for this event type. 5. **Resources Supporting the Use Case**: The resources mentioned include specific filters (Geographic Active List, ATM Authentication Filter, Account Access Success Filter) and a use case (Login from Known Fraudulent Address). They are supported by the ArcSight™ FraudView solution to detect and prevent fraudulent activities related to account access. These features collectively aim to enhance security measures in detecting potential fraud through detailed monitoring of user activity across multiple accounts accessed from different countries or known fraudulent IP addresses, providing an early warning system for such incidents. The provided information outlines a cybersecurity use case related to detecting fraudulent activities, specifically unauthorized access to accounts from known fraudulent IP addresses and identifying suspicious payee transactions across multiple accounts. For detecting unauthorized logins from known fraudulent IP addresses, the system uses an "ArcSight Rule" named "Login from Known Fraudulent Address." This rule identifies when an account has been accessed from a known fraudulent IP address by utilizing an updated active list of known fraudulent IP addresses provided by ArcSight's Solutions/FraudView. The active list is manually updated and serves as part of the priority formula for risk assessment. Additionally, there's a use case focused on detecting when three different accounts pay the same payee within a five-minute window, which is facilitated through a "FlexConnector" that supplies events of the Payment Issued type. A filter associated with this event type must be configured to define successful account access and ensure certain event fields are set correctly. This setup aims to prevent unauthorized transactions by identifying and flagging suspicious payee activities across multiple accounts, enhancing security measures against fraudulent practices. The article discusses the use case for identifying multiple failed logon attempts, where it detects when three different accounts fail to access a single account within just one minute. This detection is facilitated by the "Multiple Failed Logon Attempts" rule and requires FlexConnectors to provide events of the Account Access Failure type. Additionally, there's a need to configure the filter associated with the Account Access Failure event type as per instructions provided in the article. The purpose of this use case, which is part of ArcSight Confidential (ArcSight™ Solution Guide FraudView v1.0), aims to identify patterns that could indicate suspicious activities such as fraudulent attempts or potential security breaches. The rule evaluates high-risk attributes and destinations when three distinct accounts fail access within a brief timeframe, updating the Multiple Active List accordingly. This list is used in conjunction with other factors in a priority formula and serves as a crucial component for early fraud detection systems. The article highlights that to activate the "Multiple Failed Logon Attempts" rule, FlexConnectors must supply events of the Account Access Failure type. Moreover, it recommends configuring the filter associated with this event type by setting specific values for certain fields in the events generated by the connector. The use case also mentions resources available (listed in a table) that support this particular use case to help identify and respond effectively to multiple failed logon attempts. In summary, the Multiple Failed Logon Attempts use case is designed to detect patterns of unsuccessful account access attempts within a short period, signaling potential security threats or fraudulent activities. It relies on specific rules and filters implemented in ArcSight Confidential (ArcSight™ Solution Guide FraudView v1.0) system for effective monitoring and early warning against fraud. The Multiple Password Resets use case is designed to detect when an account's password has been reset three times within a span of twenty-four hours. This is achieved through the application of the Multiple Password Resets rule, which operates by continuously adding or updating accounts in an active list upon each password reset. If an account appears in this list thrice with less than 24 hours elapsed between resets, the rule will be activated. To implement this use case, FlexConnectors must provide events of the "Password Reset" type, while a corresponding filter for this event type should also be configured. This involves ensuring that relevant events are generated by the connector and correctly matched by the specified conditions in the filter. Additional configurations may include setting certain event fields with specific values to facilitate effective monitoring and triggering mechanisms. The use case relies on resources such as rules (described under "Multiple Password Resets" in ArcSight Solutions/FraudView) and filters for password reset events, which are essential components in identifying potential fraudulent activities related to multiple password resets. These resources help maintain an active list of accounts that have undergone a password reset within the stipulated timeframe, facilitating early detection of suspicious patterns or instances of fraud. The document discusses two main use cases related to password reset and account lockout rules, as well as a method for identifying multiple transactions by the same user within a short time frame. 1. **Password Reset and Account Lockout Rules:** These rules are designed to ensure that specific event fields in connector sets have certain values. They involve an active list populated by ArcSight solutions, such as Solutions/FraudView, which is used to determine if a password reset has occurred after an account lockout. The purpose of these rules is to prevent unauthorized access by locking out accounts and requiring a password reset only when necessary. 2. **Multiple Transactions by Same User Use Case:** This use case aims to identify scenarios where a single account performs five transactions (such as payments or wire transfers) within one minute. It is based on the Multiple Transactions by Same User rule, which requires FlexConnectors to supply events of specific types – Payment Issued and Wire Transfer. Proper filtering must be configured for these event types. The use case generates only one event per financial application action to avoid inaccurate reporting, but multiple events should not occur. The document also provides a table listing the resources that support this use case, including the rule itself (Multiple Transactions by Same User) and related ArcSight documentation for further reference. The provided text outlines various use cases and filters related to security events in the ArcSight platform, specifically within the FraudView module of version 1.0. It covers three main topics: payment identification, wire transfer event detection, and password reset scenarios without preceding lockouts. 1. **Payment Identification**: This involves using a filter to identify when a payment has been issued. The process requires ensuring that an appropriate event is generated by the connector and matched by specific filter conditions. It also mentions that certain event fields must be set with particular values by the connector. 2. **Wire Transfer Event Detection**: A similar process applies for identifying wire transfer events, using a dedicated filter to match corresponding events generated by the connector. The connector should set necessary field values as well. 3. **Password Reset Not Preceded by Lockout Use Case**: This specific use case focuses on detecting password resets that do not occur following an account lockout. To activate this rule, FlexConnectors must provide events of the Account Lockout type, and a corresponding filter should be configured for the Account Lockout event type. 4. **Resources Table**: A table is provided listing resources that support each use case, which includes rules (like Password Reset Not Preceded by Lockout) and active lists (such as those determined by the Account Lockout rule. These lists are used to check if a password reset was preceded by an account lockout. This summary provides a concise overview of how these filters and rules function within the ArcSight FraudView environment, specifically tailored for detecting specific security-related events based on predefined conditions. The Payee Created and Paid - Same User use case in FraudView aims to detect instances where a payee is created by the same user who subsequently pays for goods or services using that payee's details. This functionality relies on two key components: a rule called Payee Created, which adds new payees along with their creating account ID to an active list, and another rule named Payee Created and Paid - Same User, which compares the account issuing a payment with the account that created the payee to ensure they match. To implement this use case, users must configure FlexConnectors to supply events of the Payment Issued type and set up filters for these events in the system. For detailed configuration instructions, refer to the section titled "Payment Issued" on page 26 of the ArcSight Confidential document. The resources required to support this use case are listed in Table 4-19, which includes descriptions of rules and their associated types and URIs as provided by ArcSight Solutions/FraudView 1.0. The Payee Created and Paid - Suspicious Time use case in ArcSight FraudView aims to identify when a payee is both created and paid by the same user within two minutes during a suspicious time of day, potentially indicating fraudulent activity. This use case relies on specific event types from FlexConnectors (Payee Created and Payment Issued) and uses custom filters based on DayOfWeek and HourOfDay variables to determine "suspicious" times. The Suspicious Time of Day filter allows customization for different days and hours, offering flexibility in identifying potential fraudulent scenarios. This table outlines resources that support a specific use case where a payee is created and paid within suspiciously short or restricted time frames, such as during unusual hours like weekends or late at night. The primary tool used to detect this behavior is ArcSight, with particular focus on the FraudView module. Key components of the solution include: 1. **Payee Created and Paid - Suspicious Time Use Case Rule**: This rule in ArcSight's FraudView module identifies transactions where a payee is created and paid by the same user within 2 minutes, particularly during hours considered suspicious based on historical patterns or typical business activity (e.g., weekends). 2. **Suspicious Time of Day Filter**: Designed to identify times when transactions are more likely to occur outside normal business hours, this filter helps in identifying potentially fraudulent activities by monitoring the day or week for transaction occurrences. 3. **Payment Issued Event Type and Connector Configuration**: The use case necessitates that a connector generates an event of the Payment Issued type. This requires configuring specific fields within the filter associated with this event to ensure accurate detection of suspicious payee transactions. 4. **Payee Created Filter**: This ArcSight feature identifies events related to creating a new payee for a particular account, setting up conditions that must be met by the connector and its generated events to support further analysis. The Paying Suspicious Payee use case is centered around identifying payments made to suspicious payees, which necessitates configuring FlexConnectors to provide Payment Issued event data and ensuring proper filtering mechanisms are in place to recognize such transactions accurately. The Suspicious Payee active list, managed by ArcSight FraudView v1.0, serves to detect suspicious payees automatically through rules like Multiple Accounts Paying Same Payee and manually via user input for other known suspicious payees. This list helps in identifying payments made to suspicious entities and flags potential fraudulent activities. Additionally, it includes a filter that detects when a payment is issued, which aids in monitoring transactions closely. The use case of Successful Login from Country of Concern focuses on recognizing successful logins originating from countries considered risky or problematic based on specific criteria, thereby enhancing security measures and risk assessment within the system. The use case described revolves around implementing a rule to identify successful logins originating from countries known for high fraud rates, as defined in the "Countries of Concern" active list. To activate this rule, FlexConnector(s) must provide events of the Account Access Success type. These events are filtered based on specific conditions set by an Account Access filter, which ensures that only successful login attempts are considered. The ISO Country Codes can be obtained from a provided URL for maintaining the "Countries of Concern" active list. This rule is crucial in fraud prevention as it helps identify and flag logins coming from countries where fraudulent activities are prevalent. This information aids in prioritizing risk assessment when using the Countries of Concern list to determine attributes like device risk level, which plays a part in the priority formula used for further analysis or actions. The filter associated with Account Access Success events must be properly configured to ensure accurate event detection and matching conditions. In summary, this use case leverages advanced filtering mechanisms within an enterprise security system to monitor and alert on potential fraudulent activities related to successful logins from high-risk countries as per the predefined list of concern, enhancing overall fraud prevention strategies. The "icious Address" use case is designed to detect successful logins that come from IPs considered suspicious, based on the "Successful Login from Suspicious Address" rule. To implement this, FlexConnectors must provide events of the Account Access Success type, with a filter configured for these events. Suspicious IP addresses are managed in the "Suspicious Addresses active list," which is updated automatically by the "Accessing Multiple Accounts from single IP" rule and can also be manually added to by users. This list helps identify known suspicious IPs that could potentially indicate fraudulent activity. The use case involves using resources like Rule ArcSight Solutions/FraudView, Early Warning/Suspicious IP Address 1.0/Fraud Early Warning, Active List ArcSight Solutions/FraudView, High Risk/Device Attributes/Device Risk, and others as listed in Table4-23. These resources support the identification of successful logins from suspicious IPs and help in managing a list of known suspicious addresses to prevent fraudulent activities. The document discusses a method for identifying anomalies in transaction behavior related to account access, specifically designed to detect unusual patterns in accounts with low weekly transaction volumes (10 or fewer transactions). This is achieved through the implementation of a Transaction Behavior Anomaly use case within ArcSight FraudView v1.0. Key aspects include:

• Establishing criteria for anomaly detection: The sum of today's transactions should exceed three times the total transaction amount from the previous week, and the number of transactions executed on that day must be more than triple the total number of transactions in the entire previous week.

• Data sources: This is based on data stored in the Behavior Statistics active list, which captures weekly transaction volumes and amounts, updated via a weekly running trend called the Behavior Trend.

• Rule application: The Transaction Behavior Anomaly rule triggers off data from the Daily Transaction Statistics rule, comparing daily sums of transactions to those stored in the Behavior Statistics active list. If anomalies are detected (as defined), alerts are triggered.

• Configuration requirements: For this use case, a FlexConnector must provide events with at least these specifications to initiate detection of potential transaction behavior anomalies.

This system is designed to proactively identify and respond to unusual transactional patterns associated with low volume accounts, helping in the early warning and prevention of fraudulent activities or other anomalous behaviors related to financial transactions. The provided text outlines a use case for detecting transaction behavior anomalies using ArcSight™ Solution Guide FraudView v1.0. Here's a summary of the key points: 1. **Event Types**: The system identifies transactions categorized as one of four types: Payment Issued, Wire Transfer, Purchase Events, and Credit Card Transaction. Each type has associated filters that need to be configured for effective monitoring. 2. **Rule Descriptions**:

• **Transaction Behavior Anomaly Rule**: This rule is designed to identify anomalies in transaction behavior for accounts with at least 10 weekly transactions. It checks if today's transaction total exceeds 50% of the previous week's total or if the number of transactions today is more than 50% of the entire previous week's count. For accounts with fewer than 10 weekly transactions, it applies stricter criteria: checking if today's total is more than triple the previous week's amount or transaction numbers are tripled compared to the whole previous week.

• **Daily Transaction Statistics Rule**: This rule updates a daily active list for each account, tracking the total number of transactions and their amounts every time a transaction occurs.

• **Active List (Behavior Statistics)**: This list stores aggregated weekly information about account transactions and amounts, populated by trend analysis.

3. **Daily Transaction Statistics Active List**: It keeps track of the total amount transferred daily by each account, updating this information with each transaction. 4. **Resource Table**: A table lists resources that support this use case, including specific rules and active lists used in the detection process. This summary captures the main functionalities and requirements for implementing a transaction behavior anomaly detection system using the ArcSight™ Solution Guide FraudView v1.0. The summary describes various filters and their functions within the ArcSight FraudView solution, which is designed to detect fraudulent activities in financial transactions. Here are the main points: 1. **Daily Transaction Statistics**: This feature provides real-time statistics on the number of transactions performed by each account during the current day, automatically updated by a predefined rule called the "Daily Transaction Statistics" rule. 2. **Behavior Trend Queries**: These queries summarize transaction trend information over a week's period and are used to calculate behavior trends. Results are written to the "Behavior Statistics active list." 3. **Payment Issued Filter**: This filter is designed to identify an event indicating that a payment has been issued. It requires that a corresponding event be generated by the connector, with specific values set for certain fields, and matched by the conditions in this filter. 4. **Wire Transfer Filter**: Used to identify wire transfer events, it also requires that a corresponding event is generated by the connector and matches the conditions specified in the filter. 5. **Purchase Events Filter**: This filter identifies purchase events of financial assets such as stocks or options. It necessitates that corresponding events be generated by the connector and conform to the criteria outlined in the filter. 6. **Credit Card Transaction Filter**: Identifies credit card transaction events, requiring that a corresponding event is produced by the connector and adheres to the specified conditions within the filter. Each of these filters plays a crucial role in detecting potential fraudulent activities by ensuring specific events are generated and matched according to predefined criteria. The article outlines a system for identifying potential fraudulent wire transfers by using specific rules and filters to detect when three or more transactions just under a violation threshold occur within five minutes. To implement this, FlexConnectors must provide events of the Wire Transfer type, and there should be a configured filter for this event type. The rule is set to trigger for amounts between 5750 and 5999 by default but can be customized if needed. The use case relies on resources such as rules and filters, which are detailed in the table below: | Resource | Description | Type URI | |