Various Use Cases 1

Summary:

The provided text discusses several cybersecurity and data monitoring concepts related to an organization's infrastructure. Here is a breakdown of these concepts: 1. **Firewall Accept with IDS Match vs. Normal Connection**: This scenario involves assessing whether a firewall accepts a connection that matches with an alert from an Intrusion Detection System (IDS). If the firewall accepts the connection but there is no corresponding IDS alert, this is considered abnormal and requires investigation to ensure security protocols are functioning correctly. 2. **Moving Average Data Monitor**: This tool helps in detecting anomalies by analyzing deviations within a data series over time. It uses moving averages to identify mild or severe deviations from expected values, triggering alerts based on severity levels for immediate action. 3. **Session Reconciliation Data Monitor**: This monitor is used to correlate events that occur within the same session, such as login activities where both start and end parameters are considered. It helps in identifying potential security breaches by tracking IP addresses or other relevant data points during a specific time period. 4. **Statistics Data Monitor**: Extends the capabilities of the Moving Average Data Monitor by allowing users to select various statistical methods (beyond just moving averages) such as average, standard deviation, skew, and kurtosis. This provides a more comprehensive analysis of the data series. 5. **UC 31 - Too Few Events (Compared to Baseline)**: This issue arises when there are fewer events than expected in relation to the baseline or historical norm. Potential solutions include using an After Hours filter or updating average daily login times based on user behavior patterns. 6. **UC 32 - Outside Normal Temporal Window**: Refers to events that occur outside the typical timeframe for specific activities. This might require adjustments to temporal filters, consideration of different shift patterns, or review of normal operating procedures. 7. **Product Integrations**: The document mentions integrating Qualys Vulnerability Scanner with various security products including McAfee ePolicy Orchestrator (ePO), Imperva SecureSphere Web Application Firewall, Snort IDS, and Microsoft Systems Center Operations Manager Audit Collection Services (ACS). These integrations are crucial for enhancing the overall security posture of an organization by providing a unified view of vulnerabilities across different platforms. 8. **rity v1.1 SP1 with MOM 2005**: This update focuses on improving support for Cisco ASA/FWSM firewalls and Oracle Identity Management solutions through enhanced integration capabilities provided by the ArcSight SmartConnector. This connector allows data to be imported from Cisco PIX, ASA, or FWSM devices into the ArcSight system, facilitating better management and monitoring of network security events. In summary, these concepts are part of a comprehensive approach to securing an organization's digital assets through real-time monitoring, proactive identification of anomalies, and robust integration with leading security technologies.

Details:

The provided document outlines several use cases for ArcSight's SIEM/FIM POC, focusing on data pivoting and specific log tracking scenarios. Here’s a summary of each use case: 1. **Demonstrate everything done across multiple systems** (UC 1) - This involves using standard replay files in ArcSight to load the console. The user is instructed to right-click on the grid area and choose "Event Graph" for data visualization. The purpose is to demonstrate how activities from various systems are correlated, leveraging features such as ActorByIPOrAccount.FullName to trace IP addresses at the time of login events. 2. **Simultaneous Logins using Time Proximity** (UC 2) - Similar to UC1, this use case also utilizes ArcSight’s standard replay files and graphical interface for event analysis. The focus is on visualizing simultaneous logins by mapping these activities based on their proximity in time, similar to UC1 but with a specific emphasis on timing correlation of login events. 3. **Track Activities when a generic service account is used for all users on target** (UC 3) - In this scenario, ArcSight’s standard replay files are again employed to analyze activities related to logins through a legacy application interface. The use case highlights the identification of user activity using a generic service account, indicated by SYSTEMUSER in login sessions. Key data is pivoted based on IP addresses at the time of login requests, as captured by variables like ActorByIPOrAccount.FullName. **Data Pivoting and Visualization:**

• **Filtering and Field Selection**: For UC 1 and UC 2, there’s a description of using filters to restrict data presentation (e.g., MyLegacyApp Events) and selecting specific fields for display related to the login activities.

• **Global Variables**: In UC 3, global variables such as AttributableActor.FullName and AttributableActor.Department are used to retrieve information from active identity management lists, providing additional context about the users’ attributes during their interactions with the legacy application.

• **Aggregation and Session List**: Optional elements include setting up session lists for aggregation purposes, which can be useful in generating reports on overall user activity within the system.

These use cases demonstrate how ArcSight’s SIEM/FIM capabilities are applied to analyze network activities, especially focusing on tracing back login activities from generic accounts to broader system interactions and correlating these with IP addresses and other contextual information. This document outlines a procedure for setting up and testing a correlation rule in ArcSight to detect simultaneous logins from different IP addresses using the same account. The goal is to identify cases where an account is logged into from two or more distinct IP addresses within a short timeframe, which could indicate unauthorized access or misuse of credentials. **Step 1: Setting Up the Active Channel** The first step involves configuring the active channel in the test generator to look for specific words in the message column. This setup helps in generating and observing events that will be used to create the correlation rule. The active channel is set up to detect "TEST" in the message field. A test event is then generated, and its results are viewed on the active channel. **Step 2: Creating a Correlation Rule (TEST_MIP)** The next step involves creating a custom correlation rule named TEST_MIP. This rule will be configured to detect events where an account attempts to log in from multiple IP addresses within a short period, without specifying the exact time frame but indicating that the attacker's and target’s details should be considered unique based on their respective IP addresses. **Setting Up Conditions:**

• The condition is set up to check for unique Attacker Addresses while identical Target Addresses are identified. Additional conditions such as identical Target User ID might also be included if the rule aims to detect multiple logins from the same user across different systems but not necessarily the same IP address.

**Aggregation Tab and Action Tab:**

• In the aggregation tab, specific criteria for unique Attacker Addresses and identical Target Addresses are specified. This helps in narrowing down the events that meet these conditions.

• The action tab is configured to use the "On First Threshold" correlation category, which typically initiates a response or alert when the first threshold of matching conditions is met.

**Setting Up an Active Channel:**

• An active channel named "USE CASES" is created to monitor and visualize data related to events that have triggered the correlation rule. The time frame for evaluation is set to exclude only the last 10 minutes, ensuring continuous monitoring within a dynamic timeframe.

**Filtering Events:**

• A filter is configured in the active channel to display only those events which meet the criteria defined by the correlation rule. This helps in focusing on relevant incidents that need immediate attention.

**Configuring the ArcSight Smart Connector for Testing:**

• The final step involves setting up the ArcSight "Test" Smart Connector with specific fields such as Attacker Address, Target Address, and possibly other relevant details from the event data to simulate a test alert event during testing phases.

This detailed setup process ensures that the correlation rule is both effective in detecting suspicious activities and flexible enough to be adapted based on further analysis or changes in threat patterns. The provided text outlines a series of steps and configurations related to setting up and testing rules for detecting specific use cases in an ArcSight environment. Here's a summary of the key points: 1. **Use Case 1 - Same Account with Different Source Addresses:**

• A rule named "UC1 – Same Account 2 Source Addr" is created to detect events where the same user ID (USER 1 and USER 2) has different source IP addresses. The rule configuration involves setting the Attacker Address to specific IPs and configuring other fields as required for the rule.

2. **Use Case 5 - Same IP Using Multiple Accounts:**

• A new rule, "UC2 – Same IP Multiple Accounts," is created by copying the previous rule. It requires that the Target User ID be unique while the Source Addresses are identical. Configuration involves setting up a test event with specific fields and testing it in the ArcSight "Test" Smart Connector.

3. **Enhancement for Trusted List:**

• A suggestion to add a "Trusted List" where if the Attacker Address is on this list, the correlation rule would not fire. The example provided is 172.16.100.103 which does not trigger the rule.

4. **Use Case 6 - Same Account from Different Geographical Locations:**

• Rules can be set up to detect if a user logs into multiple different geographical locations within a short period, using active lists that track user IDs and country codes. The rule should check for unique country codes while the User ID remains the same. A new rule "UC3 – Same Account Diff GEO Codes" is created by copying an existing one, with adjustments to focus on country code differences.

5. **Configuration and Testing:**

• For each use case, specific fields need to be configured in a test event within the ArcSight environment before finalizing the rule setup. This includes setting the Category Object (e.g., /Host/Operating System), Attacker Address, Target User ID, and other relevant details as per the instructions provided.

These steps are crucial for configuring and verifying rules tailored to specific security threats in a network monitoring system like ArcSight, ensuring that they only trigger when necessary based on pre-defined criteria related to user activity and IP addresses. The provided information outlines the steps involved in setting up and utilizing alerts within a system, specifically detailing enhancements related to alert escalation and notification configuration. Here's a summary of the key points: 1. **Alert Rules**: A rule was triggered with specific fields set for an event named "Test Alert Event". Initially, the source address was 206.116.23.54, targeting user App User 1 under Oracle product. Afterward, these were modified to 206.116.23.54 (source), App User 2 (target user ID), and SQL (device product). 2. **Alert Escalation**: The system allows for automatic escalation of alerts if no response is received from the analyst within a specified time frame, such as 10 minutes in this case. This feature ensures timely attention to critical alerts by passing them on to higher-level analysts. 3. **Notification Configuration**: Users can configure how and when they are notified about triggered rules. This includes setting up email (SMTP), Short Message Service Protocol (SMPP), or SNMP notifications, which can be customized based on user preferences and needs. 4. **Enhancements**: The SIEM (Security Information and Event Management) system has the capability to automatically escalate alerts when no response is received from an analyst within a set time period. This feature is crucial for maintaining an effective alerting workflow. 5. **Granular Control**: Users have fine-grained control over notification settings, including which rules should trigger notifications and how they are handled based on criteria like white/black lists to reduce false positives. 6. **Data Monitoring**: A data monitor was mentioned as a tool for tracking the geographical locations from where users log in, helping in understanding user behavior across different countries. 7. **Dashboard / Reports**: There's an emphasis on creating detailed reports that summarize data visually or numerically, which can be accessed through either the ESM Console or ArcSight Web viewer. These reports are designed to provide actionable insights for stakeholders. Overall, this setup focuses on enhancing security operations by automating alert escalation and improving communication channels between analysts and system alerts based on configurable rules. The text describes a system for generating reports that can include data from various sources such as trends, session lists, active lists, cases, notifications, and assets. These reports are created by binding queries with a report template, which allows them to be customized based on specific needs like hierarchical policy containers, access control lists (ACLs), and correlation rules. The system supports creating "Sub-Admins" for delegating access controls within their respective containers and has extensibility features allowing provisioning of new accounts via API/SDK, adding new log event-generating devices, manipulating policies, configuring group/tag structure, setting general settings with lookups to external data sets. This text discusses various aspects related to integrating tools, running scripts, creating graphs for reporting, setting up alerts, and utilizing external applications like Google Earth within the ESM Console. It covers different use cases such as triggering an alert or running a script through integration commands, which can be customized according to specific scenarios and contexts defined in ArcSight Event Management Suite (ESM). The text also explains how to set up reporting formats specifically for .csv files, ensuring customization is maintained even when using default settings. Furthermore, it highlights the capabilities of integration commands that allow for context-sensitive actions across local or remote systems, providing flexibility in command execution and data utilization through Velocity expressions. Lastly, it briefly mentions ArcSight Threat Response Manager (TRM), which focuses on comprehensive investigative and remediation measures to address threats effectively. The provided text discusses the capabilities of an Extended Security Module (ESM) and Threat Risk Management (TRM) system, which are designed to protect networks in real-time by detecting and mitigating threats effectively. Key features include the ability to select IP addresses for investigation or quarantine within the network using ESM combined with TRM's superior correlation capabilities. Examples of this functionality include: 1. Selecting an IP address in ESM and then investigating the associated node using TRM. 2. Selecting an IP address in ESM and subsequently quarantining the associated node using TRM. 3. Automatically quarantining a node if triggered by an ESM rule action through the use of the ArcSight TRM CounterAct Connector. Additionally, there's information about writing custom parsers for unique or specialized log formats within FlexConnectors, as well as sample configuration files to guide this process. The file reader properties shown in the example are part of a FlexConnector configuration file and illustrate how to parse specific details from network logs using regular expressions. The provided text discusses anomaly detection using moving average data monitors within a system designed for event flow analysis, likely part of an enterprise security infrastructure such as ArcSight. Here's a summary and breakdown of the key points: 1. **Anomaly Detection**: The system is designed to detect anomalies where asset or event data diverges from expected profiles (UC 29). This includes scenarios outlined in UC 30, which involves excessive events compared to established baselines. 2. **Moving Average Data Monitor**: Used for detecting deviations within the event stream. The default configuration of this monitor considers an anomaly if there's a deviation within the range of +/- 33 to 65 as mild and beyond +/- 66 as severe. Alerts are triggered based on these severity levels, directing actions to active channels. 3. **Correlation Data Monitors**: These monitors help in detecting anomalies by calculating statistics from event streams or reconciling them across different systems. They generate correlation events when specific conditions are met. Two types of correlation data monitors are mentioned:

• **Event Correlation**: Compares flow volumes between two distinct event streams to verify reports from separate security systems (e.g., firewall and IDS).

• **Event Reconciliation**: Matches each event from one stream with an event from another, typically used for comparing internal system events like traffic accepted by a firewall versus attack alerts from an IDS.

These tools and processes are part of a broader strategy to continuously monitor the security environment and respond effectively to potential threats or anomalies that might indicate breaches or other issues requiring immediate attention. The provided text discusses several cybersecurity and data monitoring concepts: 1. **Firewall Accept with IDS Match vs. Normal Connection**: This refers to the assessment of network security where a firewall's acceptance of an attack matched with an Intrusion Detection System (IDS) alert is considered a successful attack, while an acceptance without such an alert is deemed normal. 2. **Moving Average Data Monitor**: This tool displays the moving average of events based on selected data fields, which helps to smooth out short-term fluctuations and reveal long-term trends in the data. It can also plot values using various numeric fields from the events. 3. **Session Reconciliation Data Monitor**: This monitor correlates events that occur within a specific time period, such as a VPN login IP address. It includes session start and end parameters set during creation and offers scalability through its session list feature for collecting data effectively. 4. **Statistics Data Monitor**: Similar to the Moving Average Data Monitor but extends functionality by allowing users to select other statistical methods like average, standard deviation, skew, kurtosis, in addition to moving averages. 5. **UC 31 - Too Few Events (Compared to Baseline)**: This issue involves a deviation from the baseline or expected number of events, expressed as a percentage up or down. The text suggests potential solutions including using an After Hours filter and updating the average daily login times through active lists if needed. 6. **UC 32 - Outside Normal Temporal Window**: Refers to events occurring outside the typical timeframe for specific activities, possibly requiring adjustment of temporal filters or considering different shift patterns. 7. **Product Integrations** specifically mention a Qualys vulnerability scan, likely indicating integration with a security scanning tool to monitor and assess vulnerabilities in network-based applications. This text provides insights into various aspects of digital security infrastructure, including configuration, monitoring tools, and potential issues that may require resolution through strategic data analysis or manual adjustment based on specific user behaviors or patterns. This document provides guidance for installing the SmartConnector, a tool used to connect various security products with Qualys Vulnerability Scanner. The guide includes information on platforms and versions supported, as well as specific software such as McAfee ePolicy Orchestrator (ePO), Imperva SecureSphere Web Application Firewall, Snort IDS, and Microsoft Systems Center Operations Manager Audit Collection Services (ACS). Each section details the supported products, their versions, and any relevant beta or released configurations. The document refers to a version 1.1 Service Pack 1 update for a product called "rity v1.1 SP1" which is likely associated with Cisco ASA and FWSM Firewalls, as well as ArcSight SmartConnector. This connector allows users to import syslog events from Cisco PIX, ASA, or FWSM devices into the ArcSight System for monitoring and management purposes. The document also mentions a separate feature under UC 39, which is related to Oracle Identity Management (or other similar Lightweight Directory Proxy Application Protocol-based Identity Authentication Management solutions). This indicates that there might be an integration or support added in this update for these IAM systems within the ArcSight platform, potentially enhancing user authentication and access management capabilities. In summary, rity v1.1 SP1 with MOM 2005 introduces enhancements for Cisco ASA/FWSM firewalls and Oracle Identity Management solutions, providing better integration between network security devices and enterprise-level IAM systems through the ArcSight SmartConnector.

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.