Console Monitoring Procedure
- Pavan Raja
- Apr 8, 2025
- 6 min read
Summary:
The "Console Monitoring Procedure" dated October 13, 2011, serves to update the traditional process found in the SOC Wiki by providing a more comprehensive method for security analysts using ArcSight's Enterprise Security Manager (ESM) platform to monitor and manage alerts effectively. This procedure aims to address challenges related to integrating hardware and software investments within businesses and focuses on workflow integration through ArcSight ESM.
The document outlines a mandatory procedure for monitoring the ArcSight SIEM console, detailing steps such as accessing the SOC Main Channel in ArcSight ESM, filtering alerts based on priority and received time, annotating events for further investigation, pausing active channels if necessary, and managing alerts according to their severity. The process includes handling actionable security incidents by following an Intrusion Analysis Procedure, dealing with false positives, and escalating assistance when required.
Additionally, the procedure suggests enhancing the Shift Turnover Log by including cases and escalations for better collaboration among analysts, even under high-volume conditions in the SOC Main Channel. The article emphasizes that this structured approach ensures thorough alert evaluation and proper management based on potential impact, whether through resolution, further investigation, or closure.
Details:
The "Console Monitoring Procedure" is a document dated October 13, 2011, that provides a method for security analysts to monitor and manage alerts through ArcSight's ESM (Enterprise Security Manager) platform. This procedure serves as an updated version of the process typically found in the SOC Wiki and aims to provide a more comprehensive approach to the decision-making process involved in monitoring consoles using ArcSight technology.
**Background:**
The document acknowledges that while there are business needs for hardware and software investments in ArcSight, clients often struggle with integrating these technologies into their processes (workflows). This document addresses this challenge by offering an approach to workflow integration through the use of ArcSight ESM to monitor security alerts. It departs from traditional bundled documents in the SOC Wiki by focusing on a more holistic decision-making process for analysts monitoring consoles and referencing supporting procedures.
**Procedure:**
The procedure starts with version management, stating that it is initially released as Version 1.1 during its roll-out. Key assumptions include access to ArcSight client compatible with the current version of ESM, established network access (either directly or through VPN), an active ESM user ID and password, and completion of relevant training or equivalent experience for the analyst.
The purpose of this document is to outline a mandatory procedure for monitoring the ArcSight SIEM console effectively. It includes detailed steps and guidelines that analysts must follow to ensure proper handling and management of alerts within the system.
In summary, the "Console Monitoring Procedure" provides a structured approach for security analysts using ArcSight technology to monitor and manage alerts in an efficient manner, ensuring alignment with business needs and workflow integration.
The procedure outlines how to access and use the SOC Main Channel in ArcSight ESM for a Security Operations Center, focusing on alert monitoring and triage. To begin, log into the ArcSight ESM console using provided credentials from your SOC Lead/Manager/ESM Administrator. If login issues arise, refer to infrastructure escalation procedures to contact security engineering.
Navigate to the SOC Main Channel by going through specific channels in the Navigator panel: Active Channels > Shared > All Active Channels > Public > SOC Main Channel. Double-click on this channel to open it within the Viewer panel where you will monitor and manage alerts. The SOC Main Channel is populated with relevant, actionable alerts based on predefined criteria.
For alert investigation, follow a critical, FIFO (first in, first out) approach using alert priority as the primary filter and manager received time as a secondary filter. Examine correlated events for context, source/attacker actions, destination/target systems, and applications or services used.
To annotate alerts for further investigation: right-click on the alerts and select "Annotate Events." In the pop-up window, choose an appropriate stage (e.g., SOC Investigating or SOC Triage), assign it to your user ID, and add a comment indicating the current stage of investigation (e.g., "Performing initial triage"). Ensure all events in the SOC Main Channel are annotated appropriately.
This text outlines a process for handling alerts in a security operation center (SOC). If there are concerns about events appearing too rapidly for investigation, pause the active channel by selecting 'Pause current active channel' at the top of the screen. After initial review, determine if the alert is actionable or a false positive:
**If it is an actionable Security Incident**: Proceed with the Intrusion Analysis Procedure to investigate further.
Follow the steps in the Intrusion Analysis Procedure.
If the analysis suggests the alert is not valid, proceed to False Positive and determine if it's a repeatable false positive (N).
If it's a false positive, proceed to Perform Non-Actionable Alert Closeout by marking the alert as reviewed at A1 stage.
If it's actionable, continue with the investigation.
After completing the Intrusion Analysis Procedure or deciding on False Positive (N), if all necessary information is available for further action, proceed to Perform Case Management Procedure and follow related steps to mark the alert as reviewed at A1.
**If it is not an actionable Security Incident**: Determine if the alert constitutes a false positive or does not meet the criteria for an actionable incident (N).
If non-actionable and not constituting a security issue, proceed to Perform Non-Actionable Alert Closeout by marking the alert as reviewed at A1 stage.
If it's determined that assistance is needed from a higher level analyst (L2), perform Incident Escalation to L2 Analyst.
This process outlines a structured approach for handling security alerts in an Information Security Operations Center (SOC). The goal is to ensure that each alert is appropriately evaluated, triaged, and managed according to its severity and potential impact. Here's a summarized breakdown of the steps involved:
1. **Initial Alert Handling**:
If an alert requires review by higher-level analysts or management, it should be escalated for further review. This involves clear documentation and proper hand-off procedures.
2. **Alert Tuning**:
Assess whether the alert can be tuned to better match current threat patterns. If it is a candidate for tuning, proceed to open a tuning case; otherwise, go directly to A1.
3. **Case Management**:
Check if there's an existing open tuning case in the system. If yes, add the new alerts to this case and follow the case management procedure. If not, proceed to perform a filter request procedure.
4. **Filter Request Procedure**:
Document the specific conditions that make an alert a candidate for filtering out based on its context and analysis results. This helps in refining the alerting system.
5. **A1 Step**:
At this stage, the alert is formally triaged, and it will be designated as one of four outcomes:
Added to Case (for actionable alerts leading to incident tickets).
Escalated (for alerts needing more investigation by L2 analysts).
False Positive (for non-actionable alerts that matched use case conditions but are not security issues).
Closed (for non-actionable alerts that do not constitute a security issue).
6. **Alert Review**:
Right-click the alert(s) and select "Mark as reviewed" to clear them from the active view, making it easier to monitor new events. This step is crucial for maintaining an efficient monitoring process.
7. **Return to SOC Main Channel**:
Once all necessary actions are taken, return to the main channel for SOC monitoring of any new alerts that may arise during this lifecycle cycle.
This structured approach ensures that each alert receives a thorough evaluation and is managed according to its potential impact on security posture, whether through resolution, further investigation, or closure based on its relevance and severity.
The article suggests enhancing the Shift Turnover Log by including cases and escalations to facilitate better collaboration among peer analysts. This involves capturing these details during the shift for easier review, although it may be challenging under high-volume conditions in the SOC Main Channel. If direct tracking is impractical due to volume, data can still be accessed post-shift through various platforms such as ArcSight Cases view, alert queries in ESM, and ticketing system queries related to .
Comments