ArcSight ESP PS Implementation Guide

Summary:

This text appears to be a part of a larger documentation on using ArcSight for monitoring and analyzing system activities, specifically focusing on two use cases related to logon violations and financial transactions within an organization. The provided information is structured around detailed descriptions of each use case, including the objectives, criteria for triggering alerts, visualization tools used, and active lists utilized. ### Use Case 06: Windows DMZ Logon Violation - **Objective**: To detect unauthorized logons to a DMZ domain by users who are not part of the authorized list `Domain_Admins`. - **Filter Criteria**: The logon type (local console, network, RDP) should be considered. This is specified under "Device Custom Number1". - **Alert Mechanism**: If detected, an alert is sent via email, Active Channel for triage, and Dashboard visualization. - **Velocity Template Usage**: Customizable templates (`Email.vm` and `emessage.vm`) are used to format the alert message. The content of this message appears in the ArcSight "Message" field which is then included in the email notification. - **Active List**: `Domain_Admins` - a list of authorized administrators who should have access. ### Use Case 08: IBank Destination Account - Add to List - **Objective**: To monitor and alert on excessive transfers from the IBank system beyond a predefined threshold, set by "Device Custom Number1" (initially 10). - **Active Lists**: - **IBank Destination Accounts Summary**: Contains details of all monitored destination accounts. - **IBank Destination Accounts Whitelist - dstUserId**: A whitelist for authorized destination account IDs. - **Alert Criteria**: Transfers exceeding the threshold trigger an alert, with the threshold adjustable based on specific needs. - **Visualization**: Visual graphs and tables within queries provide visual representations of transfer data, aiding in real-time monitoring and analysis. ### Summary and Additional Queries The text also outlines several additional queries and reports related to the IBank system: 1. **Query Viewer – IBank Top 10 Destinations**: A graphical representation or subset of top 10 destination accounts based on recent transfers. 2. **Query Viewer – IBank Top 100 Destinations - Table**: A detailed table format listing all top 100 destinations with transaction details. 3. **Report - IBank Top 100 Destinations**: Comprehensive historical and financial records of transfers to the top destinations, useful for trend analysis and strategic insights. 4. **Dashboard – Use Case 08: Multiple Destinations**: A centralized dashboard section for visualizations related to multiple transfer destinations. 5. **Active Channel – Alert Triage**: Alerts personnel or departments about detected issues or anomalies in the transaction data, requiring immediate attention based on set criteria. ### Purpose and Functionality These tools serve to enhance understanding of financial transactions within the banking system, identify potential risks such as fraud or errors through pattern analysis, and ensure compliance with internal controls and regulatory requirements. The visualizations and reports help monitor real-time activities, while alerts provide immediate attention mechanisms for critical events.

Details:

The document titled "HP Enterprise Security Global Services BCA IBank Application Use Cases Configuration Guide" is a technical guide prepared by Thoman Foong and Ray Cotten for the HP enterprise security team. It outlines use cases specific to the IBank application, detailing rules, active lists, filters, assets, dashboards, data monitors, and global variables necessary for configuration and monitoring of security measures against signature-based attacks, IP address anomalies, and threshold violations in financial transactions. The document is dated March 21, 2014, and includes detailed descriptions of each use case along with associated queries and reports to assist in the implementation and analysis of these cases within the IBank application environment. This text appears to be related to the description and components of use cases in a security system, possibly ArcSight ESM (Enterprise Security Manager). The summary can be broken down as follows: 1. **Use Case #04 - IBank customer PC infected**

• Involves detecting an infection on an IBank customer's PC.

• Two rules are defined for this use case, one to pinpoint violations and add them to a list, and another for notification of the violation.

• An active list for pinpoint notifications is also mentioned.

2. **Use Case #05 - Multiple login from Single IP Address**

• Covers scenarios where multiple logins are attempted from the same IP address on IBank systems.

• Specific rules, filters, data monitors, and a dashboard related to this use case are detailed.

• Active channels for alert triage are also discussed.

3. **Use Case #06 - OS Login (Other than Domain_Admins) to Web or DB**

• Focuses on unauthorized logins from outside the domain administrators to web or database servers.

• Includes rules, filters, data monitors, a dashboard, and velocity macros for this use case.

• Active lists and alert triage channels are also part of the description.

4. **Use Case #08 - Multiple transfer out to same external account number**

• Deals with cases where there are multiple transfers to the same external account number in IBank transactions.

• Involves rules for adding violations to a list, active lists, queries for detailed analysis, and a dashboard.

5. **Components and What We See**

• Use Cases consist of collections of resources including dashboards.

• Dashboards are graphical displays of data from Data Monitors or Query Viewers.

Overall, these use cases seem to be part of an enterprise security management system designed to address specific security issues like unauthorized access, PC infections, and suspicious transactions in banking systems. The text provides an overview of various functionalities within a system related to data visualization and management using dashboards, reports, data monitors, field sets, and filters. Here's a summary of each section: 1. **Dashboards**: They can display data in multiple graphical formats like pie charts, bar charts, tables, and custom layouts. The usage includes loading and displaying the dashboard, inspecting events with features like zooming, using slideshows, or manipulating views. Dashboards also allow saving configurations for future use. 2. **Active Channels**: These provide a real-time streaming view of incoming events that can be filtered and customized in various ways. Usage involves creating channels, filtering content, customizing formats, and deleting channels as needed. 3. **Reports**: They can be generated in different formats with specific parameters to identify customer events over chosen durations, including automatic scheduling for delivery and archiving. 4. **Foundation Components**:

• **Data Monitors**: These are used to populate dashboards and can be customized by creating, editing, or deleting them as required. They help focus data views on particular contexts like customer accounts or vulnerabilities.

• **Field Sets**: Named subsets of available data fields that aid in focusing the view on specific aspects such as customer accounts or vulnerability issues, applicable across grids, event inspectors, and other field arrays within the system.

• **Filters**: These are used to exclude non-matching events at the Connector level and include only those that meet specified conditions for further processing by the Manager. Filters can be applied in a way that is exclusive (excluding unwanted events) or inclusive (selecting specific events).

Each of these components serves to enhance data management, visualization, and analysis within the system through tailored features designed to improve usability and efficiency. Summary: This text discusses various methods used in event processing systems such as filters, active lists, session lists, queries, rules, and query viewers. Filters are applied to meet specific conditions during the event lifecycle, preserving all events but not evaluating those that don't meet the criteria. Active lists create configurable tables for cross-referencing during correlation, with manual data entry also possible for verification. Session lists have additional fields like start time, end time, and creation time, and partition data into weekly segments to manage large datasets efficiently. Queries are used in trend tables and reports, conditioning requirements being applied to group and aggregate filtered events. Rules evaluate incoming events based on specific conditions and patterns, inferring their significance and initiating actions. Lastly, query viewers define and run SQL queries across various resources including trends, assets, cases, connectors, events, etc., enabling users to visualize data effectively. The provided text describes the functionality and components of a system related to security monitoring, specifically designed for detecting and analyzing network-based threats. Here's a summary of the key points: 1. **SQL Query and Logic**: The system includes an SQL query along with other logical processes that are used to establish baseline results, analyze historical data about network activity, and investigate specific aspects of the results by performing drill-down analysis. 2. **Query Viewer**: This feature allows users to view all fields specified in a selected or created SQL query. It provides a tool to visualize database query results within the application interface. 3. **Use Cases**:

• **Use Case #01: IBank Signature Based Attacks** focuses on detecting specific types of cyber attacks such as Man-In-The-Middle (MIM) and Cross-Site Scripting (XSS) using alerts from McAfee IDS. It involves filtering alerts related to the IBank assets and displaying them in a dashboard named "Use Case 01: IBank Signature Based Alerts."

• **Use Case #02: Login from different location (IP Address) in X amount of time** is designed to monitor both successful and failed logon activities on the IBank Application. The use case triggers alerts if users log in from two different locations within a short period, such as 20 minutes, distinguishing between cities or countries. This scenario is also displayed on a dashboard named "Use Case 02: IBank Geo Location Violations" and involves alerting through an active channel for immediate attention.

4. **Global Variables**: These are variables that can be used across different parts of the system, such as in dashboards or data monitors specific to each use case. For example, they include filters for city violations and country violations related to user login activities. 5. **Dashboard Visualizations**: The results from the queries and alerts generated by these use cases are visualized on a dashboard interface that is tailored to provide real-time insights into potential security threats or unusual patterns in user activity. 6. **Data Monitors**: These monitors specifically track top users logging in from multiple cities or countries, providing actionable data for further investigation and response strategies related to the IBank Application's cybersecurity. Overall, this system is designed to provide real-time monitoring and analysis of network security events, with specific focus on detecting signature-based attacks and unauthorized logins from different locations, all presented through a user-friendly dashboard interface. The provided text outlines a series of use cases and the associated rules, queries, reports, and other components used in an IBank system to monitor various activities. Here's a summary of each use case: 1. **Close to the threshold limit for 3 consecutive days**: This use case monitors successful transfers from IBank that are close to the daily transfer limit (286M IDR) over three consecutive days. It involves creating a list, querying thresholds, and generating detailed and summary reports. The data is visualized on a dashboard related to threshold met over three days. 2. **IBank customer PC infected**: This use case involves IBM Pinpoint sending daily lists of infected host computers and user IDs. A flex connector reads this list and filters activity from these user IDs, alerting triage for further action. 3. **Multiple login from a single IP address**: The use case tracks multiple usernames logging in from the same IP address. It uses a whitelist to filter out false positives from common locations like schools and libraries. Visualization of this data is done on a dashboard specific to multiple logons from a single IP. 4. **Unused placeholder for Use Case #06**: This line suggests that there was an intention to describe another use case, but it is not detailed in the provided text. Each use case has its own active list (e.g., IBank Daily Transfer Summary List, Pinpoint Notification List) and is associated with specific queries, reports, and visualizations on a dashboard or within a report viewer. These tools help in real-time monitoring and analysis of the financial transactions and system activities to ensure compliance and security measures are upheld. The provided information outlines two specific use cases within ArcSight for different scenarios, each with its own rule and associated active lists, templates, and channels for alerts. ### Use Case 06: Windows DMZ Logon Violation

• **Objective**: This use case is triggered when a user logs into the DMZ Domain but is not on the authorized list of Domain_Admins.

• **Filter Criteria**: The logon type should be either local console (Logon Type 2) or network (Logon Type 3), and RDP (Logon Type 10). This is specified under "Device Custom Number1".

• **Alert Mechanism**: If the user is not authorized, an alert will be sent via email, Active Channel (Alert Triage), and Dashboard.

• **Velocity Template Usage**: Velocity templates are used to customize email notifications. The primary template file `Email.vm` and secondary template file `emessage.vm` located in `/Manager/config/notifications` can be customized for specific alert messages. Any content written to the ArcSight "Message" field will appear in the email notification.

• **Active List**: The list of authorized users (specifically, Domain_Admins) is crucial for this use case.

### Use Case 08: IBank Destination Account - Add to List

• **Objective**: This use case monitors successful transfers from IBank and alerts if the number of transfers exceeds a predefined threshold set by "Device Custom Number1" (initially set at 10, but adjustable).

• **Active Lists**: Two active lists are involved:

1. **IBank Destination Accounts Summary** - which likely includes details about all destination accounts being monitored. 2. **IBank Destination Accounts Whitelist - dstUserId** - a whitelist of authorized destination account IDs.

• **Alert Criteria**: Transfers above the threshold (initially 10) are considered high and trigger an alert. The threshold can be adjusted based on specific needs.

• **Visualization**: A graph in the query "IBank Multiple Transfers to same destination - Top 10 - Graph" helps visualize the data related to these transfers.

In summary, both use cases leverage ArcSight's capabilities for custom alerting and visualization by using predefined templates and active lists tailored to specific business processes (e.g., user access permissions in a network environment vs. financial transactions). The initial query pertains to a specific report in the banking system, "IBank," which focuses on analyzing multiple transfers made to the same destination. This involves creating several visual representations and reports from different angles within the IBank platform itself. These include: 1. **Query Viewer – IBank Top 10 Destinations**: A graphical representation or a subset of data showing the top 10 most frequently transferred destinations based on recent transfers. 2. **Query Viewer – IBank Top 100 Destinations - Table**: A detailed table format that lists all the top 100 destination accounts along with their transaction details, useful for more granular analysis. 3. **Report - IBank Top 100 Destinations**: This is a comprehensive report generated from historical data and financial records of transfers to these top destinations, providing insights into trends, amounts transferred, and other relevant metrics over time or across different branches/departments. 4. **Dashboard – Use Case 08: Multiple Destinations**: A dedicated section within the dashboard that centralizes all visualizations related to multiple transfer destinations, aiding in real-time monitoring of these transactions for risk assessment and operational efficiency. 5. **Active Channel – Alert Triage**: This part of the system alerts the relevant personnel or departments about potential issues or anomalies detected during the analysis of multiple destination transfers, requiring immediate attention or triage based on predefined criteria or thresholds set by financial regulations and internal controls. The purpose of these tools is to help in understanding where most transactions are going within the banking operations, identifying patterns that could be indicative of fraud, operational errors, strategic shifts in client base, or other pertinent issues affecting the bank's finances or compliance posture.

Disclaimer:

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