SN12 Configuration of Internal Events
- Pavan Raja
- Apr 9
- 5 min read
Summary:
This document outlines the process for configuring an ArcSight Logger and Connector Appliance to forward internal events to the Enterprise Security Manager (ESM). Key components monitored include connector status, cache status, and system health statistics such as CPU usage and EPS. The setup involves uploading certificates, creating connectors, and forwarding audit and status monitor events through appliances or direct connections. Rules are in place for managing connector statuses within active lists, with actions triggered by changes in connectivity. This configuration aims to provide a clear visual indicator of connector performance via defined states (red for issues, yellow as warnings, and green when functioning). The document emphasizes the importance of dual-feeding connectors to both Logger and ESM for effective event filtering and troubleshooting.
Details:
The document discusses forward-looking statements regarding future operations, product development, capabilities, and availability dates. It acknowledges that these predictions are subject to substantial uncertainties and can change without prior notification. Key aspects covered include monitoring ArcSight infrastructure, internal events, configuration for forwarding these events, and connector monitoring content.
ArcSight Infrastructure Monitoring: This involves checking the availability, performance (CPU usage, memory usage), network metrics (EPS over time and traffic), and disk usage on Logger and ESM devices. It also covers monitoring individual components such as devices, connectors, appliances, and ESM itself through internal events for a centralized view and drill-down capabilities.
ArcSight Internal Events: These are events generated by ArcSight products internally and can be local or forwarded to the Event Management System (ESM). The two types include status monitor events that report system health statistics like CPU usage and EPS, and audit events which log actions such as user authentication and resource modifications. By product type, there are specific statistics tracked for connectors, devices, appliances in ESM, including detailed flow statistics, appliance CPU and disk statistics, and rules engine and event broker performance metrics.
Configuration for Forwarding: Internal events can be forwarded to ESM via several methods depending on the component being monitored (connector or device). For connectors, enabling status monitoring events is possible by modifying properties in the connector settings, while direct or indirect connections through appliances like Logger or Connector Appliance can also forward these events. The configuration steps involve selecting the appropriate options based on whether it's a single-tier or multi-tier setup where internal events are already present on ESM or need to be forwarded via connectors.
This document outlines the configuration and setup process for a connector appliance and logger to monitor internal events in ESM (Enterprise Security Manager). The primary objectives are to provide an overview of connector connection and cache status, allowing users to easily identify connectors that are down or experiencing caching issues.
The configuration involves several steps:
1. **Connector Appliance Configuration:**
Upload the Extended System Monitoring (ESM) certificate.
Associate the certificate with a container.
Add a syslog connector to forward status monitor events to ESM.
Enable device status monitoring and configure it according to specified intervals.
2. **Logger Configuration:**
Upload the ESM certificate.
Create a connector pointing to the ESM manager.
Add an ArcSight ESM (CEF) forwarder to forward audit events to the ESM destination.
For ESM, there are two scenarios: single-tier where no extra configuration is needed for internal events, and multi-tier where forwarding connectors need to be configured with parameters such as connector name, source manager details, and destination manager details.
The main features of this overview include monitoring the connection status and cache status of all connectors. The overall status will reflect the most significant state of the collection: green if all are up, yellow if at least one is down for less than 20 minutes, or red if any connector has been down for more than 20 minutes. Similarly, the cache status reflects different states (green for no caching or short-term, yellow for long-term, and red for events being dropped).
The content to monitor these statuses is organized into active lists within dashboards, with data monitors and rules set up to update entries based on connector down or up events. The final overview dashboard provides a single icon representing the overall state of connectors, facilitating easy identification of issues in the infrastructure.
The document outlines rules and actions for managing connector statuses within an active list system. Here's a summary of the key points:
1. **Connector Down**: If a connector is down or disconnected, it gets added to the "Connector Down" active list with a TTL of 20 minutes. After this time, if the connector remains down, another rule moves it to the "Connector Still Down" active list.
2. **Connector Still Down**: Once the TTL for the "Connector Down" list expires and the connector is still inactive, an internal audit event (activelist:104) is generated, which then triggers moving the connector to the "Connector Still Down" active list. A notification can be optionally configured here.
3. **Connector Up**: When a connector comes back online and sends events such as agent:030 (connector started) or agent:103 (reconnected), it is removed from both the "Connector Down" and "Connector Still Down" lists.
4. **Update Connector Connection Status**: This rule checks for audit events in the active lists that start with 'activelist:10', which indicate updates such as entries being added, removed, or expired. It calculates connector status based on counts from these lists (downCount and stillDownCount) and sets overall connection status to red if stillDownCount is greater than 0, yellow if downCount is greater than 0 but less than the total connectors, and green otherwise.
5. **Actions**: When updating the connector status, relevant fields in correlation events are set based on counts and conditions derived from these lists:
deviceCustomNumber1 (Down Count), deviceCustomNumber2 (Still Down Count) represent the numeric states.
deviceCustomString1 (Connector Connection Status) indicates if the status is red, yellow, or green according to the calculated connectorStatus.
6. **Configuration**: Options include modifying TTLs for active lists, adding connectors to a black list that bypasses tracking, and enabling notifications based on status changes.
7. **Example Scenarios**: Demonstrate how different scenarios (e.g., shutdown, heartbeat timeout) affect the connector's position in the active lists and correspondingly change its displayed connection status.
This system is designed to dynamically track and report the connectivity of connectors, providing clear visual indicators through defined states (red for issues, yellow as a warning, and green when functioning correctly).
The text discusses a method for monitoring connectors using a Logger, which is designed to track connections behind it as well. It emphasizes the importance of dual-feeding connectors to both the Logger and Event Sensing Module (ESM) to filter out connector events while still receiving heartbeat events from ESM. For troubleshooting, if there are issues with statuses or incorrect active lists, remove connectors from "Connector Down" or "Connector Still Down" lists automatically updated by the "Update Connector Connection Status" rule.
The text also covers discussions about ArcSight internal events, configuration, and forwarding. It introduces a use case for connector monitoring that utilizes these internal events to monitor connectors. The document encourages reviewing new content in ESM v5.0 SP2 and suggests leveraging this information to develop tailored content addressing specific use cases.
Comments