ArcSight ESM Express Various Use Cases
- Pavan Raja
- Apr 8, 2025
- 12 min read
Summary:
To summarize the provided text, we can break down the key points as follows:
### Anomaly Detection in ArcSight Platform 1. **Definition of Anomalies**: The platform identifies anomalies when event data does not follow expected patterns or deviates from normal behavior. This involves comparing current events against historical baselines measured using moving averages and statistical thresholds. 2. **Severity Levels**: Deviations are categorized into mild (±33 to 65) and severe (beyond ±66). Alerts are triggered based on these severity levels to signal potential issues in the data stream. 3. **Event Throughput Analysis**: Rules analyze event flow, with deviations within specified ranges considered normal and those beyond triggering alerts. 4. **Correlation Data Monitors**: These include Event Correlation (comparing event streams from different security systems) and Event Reconciliation (matching events across sensors). They generate correlation events when their conditions are met. 5. **Actions on Detection**: When anomalies are detected, the system automatically sends alerts to designated channels, indicating potential security issues or irregularities in the event stream.
### Data Monitors and Issues 1. **Firewalls**: A firewall is considered successful if it matches with an IDS attack; otherwise, it's considered normal. 2. **Moving Average Data Monitor**: Displays moving averages of events based on selected data fields, filtering out short-term fluctuations for better long-term trend visibility. 3. **Session Reconciliation Data Monitor**: Correlates events within a relevant time period (e.g., VPN login times) and includes session start/end parameters. The session list feature provides scalable collection of session data. 4. **Statistics Data Monitor**: Similar to Moving Average but includes statistical methods like average, standard deviation, skew, kurtosis in addition to moving averages. 5. **Issues**: Common issues include "Too few events" and "Outside normal temporal window." 6. **Solutions**: Use of filters (e.g., After Hours filter for fixed times or different filters for shift workers), active lists (to capture the first login of the day based on an active list) can help mitigate these issues. 7. **Product Integrations**: The text mentions integration with Qualys Vulnerability Scanner and other monitoring tools, specifically supporting platforms like Java 1.3, McAfee ePolicy Orchestrator (ePO), Imperva SecureSphere Web Application Firewall, Snort IDS, and Microsoft Systems Center Operations Manager for event collection through the Qualys SmartConnector. 8. **Software Packages**: Rity v1.1 SP1 with MOM 2005 supports syslog event import from Cisco PIX, ASA, or FWSM firewalls into the ArcSight System, enhancing network security event management. It also includes integration with Oracle Identity Management (LDP IAM solutions) for improved user identity and access management.
### Summary The document outlines a comprehensive framework for anomaly detection within a system using specific rules and data monitors in the ArcSight platform. Key features include detailed analysis of event throughput, session reconciliation, statistical monitoring, and actionable alerts based on severity levels. Integration capabilities with various third-party software products are also highlighted, emphasizing flexibility and scalability in security event management.
Details:
This document outlines several use cases for a SIEM/FIM Proof of Concept (POC) using ArcSight, prepared by Brian Wolff, Principal Sales Engineer at ArcSight. The primary focus is on demonstrating data pivoting through the analysis of log files from various systems and services. Here are the summarized use cases:
1. **Demonstrate everything done across multiple systems**: This involves using ArcSight standard replay files to load the console, right-click on the grid area, and choose "Event Graph" to visualize data across multiple systems. The goal is to demonstrate comprehensive activities performed in different systems.
2. **Simultaneous Logins using Time Proximity**: Similar to Use Case 1, this involves demonstrating simultaneous logins by analyzing log files with ArcSight's standard replay feature. By selecting the appropriate tab and data monitors, such as IdentityView v2.0 within the Shared Account module, users can track activities when multiple accounts are used closely in time.
3. **Track Activities when a generic service account is used for all users on target**: This use case specifically targets applications where a generic service account (likely "SYSTEMUSER") is utilized by all users to log into an application or service. The analysis involves using ArcSight's standard replay files, focusing on the MyLegacyApp Login Sessions within the IdentityView v2.0 module. By examining the ActorByIPOrAccount variable in relation to the login time, it becomes possible to trace back the initial activities performed by users through their log-ins and subsequent interactions with the application or service.
Each use case details how specific data monitors are utilized and provides a breakdown of the process used to track and correlate user activities based on defined triggers, field sets, global variables, and event definitions within the ArcSight platform. This approach leverages ArcSight's capabilities to pivot and analyze complex log data from multiple systems, enabling detailed investigation into system usage patterns and potential security issues.
The text provided outlines a process for detecting multiple simultaneous logins from different IP addresses using a test generator in a security monitoring environment, specifically within the ArcSight platform. Here’s a summary of the steps and considerations outlined:
### Objective
The goal is to create a rule that detects if an account (account being logged into) attempts to log in simultaneously from two or more distinct IP addresses. This detection helps in identifying potential unauthorized access attempts, especially when accounts are reused across different systems without proper security measures.
### Steps and Details
1. **Setup for Detection:**
Use a test generator setup to look for specific patterns or keywords in event messages. In this case, the active channel is set up to monitor the word "TEST" in the message column. A test event is generated to observe the results.
2. **Creating a Rule (TEST_MIP):**
The rule involves checking conditions related to IP addresses and user identities across multiple events triggered by the same account.
In the 'Conditions' section, specific fields such as Generator ID, Attacker Address, Target Address, and possibly Target User ID are used to match similar patterns observed during actual login attempts. This helps in distinguishing legitimate logins from potential unauthorized activities.
3. **Aggregation and Correlation:**
On the aggregation tab, criteria for unique attacker addresses but identical target addresses are set up to focus on distinct yet related events triggered by a single account trying to access multiple systems simultaneously.
In the 'Actions' tab, correlation rules with a 'On First Threshold' category are used to initiate actions based on the first detection of such patterns, which could be indicative of attempted unauthorized access or other malicious activities.
4. **Monitoring and Visualization:**
An active channel is created to visualize and monitor data related to events that match this rule, helping in real-time analysis and response. This includes setting up filters based on the detected events for better focus and management.
A 'Test' smart connector within ArcSight is configured specifically for testing purposes to validate whether the generated rule can effectively detect potential threats as defined by the setup criteria.
### Conclusion
This process leverages both proactive detection mechanisms (using a test generator) and reactive measures (setting up rules based on correlation of similar events across different IP addresses) to identify cases where an account is being attempted to be accessed from multiple locations simultaneously, which could signal compromised accounts or unauthorized access attempts. This setup ensures that security teams can quickly respond to suspicious activities by leveraging automated tools within the ArcSight platform.
The provided documentation outlines the setup and configuration for two specific use cases within a security system, focusing on user identification and address tracking. Here's a summary of both use cases based on the instructions given:
**Use Case 5 - Same IP using multiple Accounts (UC5)**
Rule "UC1 – Same Account 2 Source Addr" is copied to create "UC2 – Same IP Multiple Accounts."
The rule requires that for identical source addresses, unique target user IDs are aggregated.
For testing the ArcSight Smart Connector:
Set up a test event with fields: Name as "Test Alert Event," Category Object as "/Host/Operating System," Attacker Address as 10.1.1.1, and Target User ID as USER 1.
Within 30 seconds, change the Attacker Address to 10.1.1.2 and resend.
Enhancement: Add a "Trusted List" for addresses that should not trigger the rule without firing.
**Use Case 6 - Same Account from Different Geographical Locations (UC6)**
Rule based on user IDs with unique country codes is created by copying "UC3 – Same Account Diff GEO Codes."
This rule checks if a user logs in from different countries within a specified period.
For testing:
Set up a test event with fields: Name as "Test Alert Event," Category Object as "/Host/Operating System," Attacker Address as 206.116.23.54, and Target User ID as USER 2.
Within 30 seconds, change the Attacker Address to 199.2 for testing purposes.
An active list is maintained for user IDs with their respective country codes, which auto-expires every 4 hours.
Both use cases involve setting up rules based on specific criteria (same IP across multiple accounts and same account from different geographical locations) and configuring the system to test these rules using a smart connector in ArcSight. The documentation suggests enhancing security by adding trusted addresses and maintaining dynamic lists of user activities for enhanced monitoring and alerting.
The provided text seems to be related to network security monitoring, specifically within a SIEM (Security Information and Event Management) system like ArcSight. Here's a summary of the key points:
1. **Rule Enhancements**: Two rules were mentioned - UC1 for same account with multiple source addresses and UC3 for different geographical codes but same account. The text suggests enhancements to automatically escalate alerts, which includes setting up a workflow where if no response is received from the analyst within a specified time (e.g., 10 minutes), the alert should be sent to another level 2 analyst.
2. **Notifications**: Steps for configuring notifications include creating and assigning users to notification groups, configuring SMTP, SMPP, SNMP types, and setting escalation times based on response from analysts. The system allows granular control over when and how notifications are sent and includes mechanisms to eliminate false positives by checking white/black lists.
3. **Data Monitoring**: A feature was mentioned for creating a data monitor that tracks the number of different countries users log in from, which is particularly relevant for network security monitoring as it helps in understanding geographical distribution of login activities.
4. **Test Event Configuration**: For UC9 (testing alert events), specific fields such as Name, Category Object, Source Address, Source User ID, Target Address, and Target User ID were mentioned to be set during a test event. The text also highlighted that the difference between use cases 3 and 9 is in the variables being tested - Device Product and Target User ID.
5. **Dashboard/Reports**: Finally, there was a mention of reports which are views or summaries of data that can be printed or viewed in various formats within the ESM Console or ArcSight Web viewer. The text implied an expanded architecture for creating more complex multi-element reports in ArcSight ESM v4.0, suggesting capabilities for enhanced reporting and trend analysis.
This summary provides a high-level overview of how network security monitoring can be configured and enhanced through such tools like ArcSight, focusing on the aspects related to alerting, notifications, data monitoring, and detailed event testing.
This document outlines various aspects of an application, including its structure, functionalities, and how to extend it. The application is structured around several key components such as reports, access control lists (ACLs), hierarchical policies, correlations, user management, and extensibility features.
Reports can be generated based on different templates that are linked with one or more queries, which collect data from trends, session lists, active lists, cases, notifications, and assets. There are specific types of reports like "Executive" and "Delta" reports as examples, each following a predefined template but tailored to distinct purposes such as reviewing business role-attempted attacks or weekly firewall status updates.
The interface includes a navigator panel that displays hierarchical folders which can be customized according to the project's requirements by using ACLs to manage content visibility and permissions. The application supports features like grouping IP addresses/ranges by network segment (UC 15), monitoring applications and people/accounts (UC 16-17), applying specific correlation policies for investigations (UC 18), creating sub-administrators with delegated access controls (UC 19), provisioning new accounts via API/SDK or scripting (UC 20), adding log event-generating devices, managing policies, group/tag structures, and general settings (UC 21-22), accessing external data sets like blocklists or reputation services provided by third parties (UC 23), and extracting data from the system for further use (UC 24).
The application also supports extensibility through APIs/SDKs for new features such as provisioning accounts, adding devices that generate logs, configuring policies, updating lookups to include more external datasets, and enhancing user management capabilities by allowing creation of sub-administrators with specific access rights.
The text discusses several aspects related to security operations using the ESM (Extended Security Monitoring) Console, focusing on integration with Google Earth for visualization and alert triggering.
**Integration Commands:** These are tools that allow invoking scripts and tools from various parts of the ESM Console, providing snap-in views of other applications like ArcSight NSP and third-party integrations. This centralizes security operations by enabling quick access to commands, tools, and applications directly from the console.
**Google Earth Integration:** The text describes a specific integration where users can right-click on "Tools" in the Google Earth section within the Active Channel of the ESM Console. This setup allows for visualization using scripts and maps that could be particularly useful for analysis involving geographical data or event relations.
**Alert Triggering:** The use case UC 25, which is linked to previous use cases (UC 4-9), outlines steps for setting up automated alerts based on specific conditions within the ESM Console. This includes configuring rules and parameters to trigger immediate notifications when predefined criteria are met.
**Remediation Actions:** The text mentions "UC 27 - Remediation," which refers to ArcSight TRM (Threat Response Manager) materials for further actions related to investigations, including detailed investigative and remediation strategies as per the TRM guidelines.
Overall, these functionalities aim to enhance security operations by facilitating real-time monitoring, automated alerting, and data-driven decision making through integration with external tools like Google Earth and internal management systems such as ArcSight TRM.
The text discusses the capabilities of ESM (Enterprise Security Manager) and TRM (Threat Response Module) in real-time network security, where they work together to detect and respond to threats effectively with minimal impact upon a compromised network. Examples given include using ESM to select an IP address for investigation via TRM or automatically quarantining nodes based on rules triggered by ESM.
Additionally, it introduces the concept of writing custom parsers in Flex (a type of connector) for unique log formats, specifically mentioning that developers should refer to a "Flex Developers Guide" for detailed information and guidelines on how to write such parsers. This section is exemplified with a sample configuration file for a Log File FlexConnector, which includes settings like regex patterns, token names, types, formats, and event mappings as part of the configuration process.
The text provided outlines a framework for anomaly detection within a system using specific rules and data monitors in the ArcSight platform. Here's a summary of the key points:
1. **Anomaly Detection Criteria**: The system identifies deviations from normal behavior as anomalies when asset or event data does not conform to expected patterns (UC 29). This involves comparing current events against historical baselines (UC 30), which is typically measured using moving averages and statistical thresholds defined in the platform.
2. **Event Throughput Analysis**: The default system includes rules that analyze event flow, where mild deviations are considered within ±33 to 65 of a baseline, and severe deviations are beyond this range (±=>66). Alerts are triggered based on these severity levels to signal potential issues in the data stream.
3. **Correlation Data Monitors**: These tools help in evaluating event streams by calculating statistics, reconciling events, and determining moving averages. They operate similarly to rules but generate correlation events when their conditions are met. There are two types of correlation data monitors:
**Event Correlation**: This monitor compares flow volumes between different event streams (e.g., from a firewall and an IDS) to verify reports from multiple security systems.
**Event Reconciliation**: This monitor matches events across sensors, such as comparing all accepted traffic from a firewall with attack events reported by an IDS.
4. **Actions on Detection**: When anomalies are detected through these rules and data monitors, the system automatically sends alerts to designated channels, indicating potential security issues or irregularities in the event stream.
This setup aims to proactively identify abnormal patterns and inconsistencies in the event data, which can then be used for deeper analysis and response strategies within the cybersecurity operations center.
This document describes various data monitors and their functionalities within a system, including firewalls, IDS (Intrusion Detection System), Moving Average, Session Reconciliation, Statistics, and more. It also outlines specific issues with event monitoring such as "Too few events" and "Outside normal temporal window," along with potential solutions like using filters or active lists for logging in times. Additionally, it mentions a product integration related to Qualys vulnerability scanning.
1. Firewalls: A firewall is considered successful if it matches with an IDS attack; otherwise, it's considered normal.
2. Moving Average Data Monitor: Displays the moving average of events based on selected data fields, filtering out short-term fluctuations for better long-term trend visibility. It can also plot values using numeric fields in events.
3. Session Reconciliation Data Monitor: Correlates events within a relevant time period, such as VPN login times, with session start and end parameters set during creation. The session list feature provides scalable collection of session data.
4. Statistics Data Monitor: Similar to the Moving Average but includes additional statistical methods like average, standard deviation, skew, kurtosis, in addition to moving average.
5. Issues: "Too few events" (deviation up or down as a percentage) and "Outside normal temporal window."
6. Solutions: Use After Hours filter for fixed times, different filters for shift workers, active lists to capture the first login of the day, trends to monitor daily logins based on an active list.
7. Product Integrations: Qualys vulnerability scanning (UC 33 - QualysysGuard SaaS Vuln).
This document provides a series of user guides, each detailing the installation and configuration instructions for specific third-party software products to integrate with Qualys Vulnerability Scanner or other monitoring tools. The supported platforms include Java version 1.3 or later, and various versions of McAfee ePolicy Orchestrator (ePO), Imperva SecureSphere Web Application Firewall, Snort IDS, and Microsoft Systems Center Operations Manager are listed as compatible systems for event collection through the Qualys SmartConnector.
Rity v1.1 SP1 with MOM 2005 is a software package that enables users to import syslog events from Cisco PIX, ASA, or FWSM firewalls into the ArcSight System for better management and analysis of network security events. Additionally, it supports integration with Oracle Identity Management (or other similar LDP IAM solutions) to enhance user identity and access management capabilities within the system.
Comments