Vodafone Jaguar - Detailed Assessment Report
- Pavan Raja
- Apr 9
- 17 min read
Summary:
This summary provides a detailed overview of the figures and tables mentioned in the text, indicating that they are part of a larger document discussing various aspects related to security and system configurations. These visual aids serve as graphical representations or data summaries intended to aid in understanding the processes, findings, and content within the report. The figures and tables cover different stages of event processing in systems like ESM (Event Management Systems), storage requirements for logs and events, configuration settings, and more. They are crucial components that help users navigate through complex information efficiently by providing visual context and supporting quantitative data.
Details:
The "Vodafone Detailed Technical State Assessment" report, conducted by HP's security consulting practice in January and February 2014, aimed to evaluate both technical and organizational aspects of Vodafone's security infrastructure. This report summarizes key findings from the assessment focusing on the technical side. The objectives included analyzing the current ArcSight infrastructure, identifying issues with event throughput and storage settings, assessing logger content, and evaluating use cases related to triage methodologies. Recommendations were made for quick fixes as well as more strategic changes aimed at improving system performance and efficiency.
The document outlines efforts to streamline and improve an ArcSight infrastructure within a larger system called GSOC (Global Security Operations Center). The main goals are to identify "quick wins" by simplifying settings and configurations to reduce complexity, and to prepare detailed documentation of the current state for future technical improvements. Key steps included analyzing past assessments, identifying unnecessary event feeds, pinpointing technical issues with the infrastructure, and assessing efficiency and accuracy in output from a SIEM (Security Information and Event Management) system.
During this process, several findings were noted:
1. The overall ArcSight infrastructure is solid but has grown complex due to uncontrolled expansion, leading to configuration weaknesses and lack of global strategy.
2. Missing contextual information such as data models affects analysis accuracy.
3. Regular content development (use case reviews and developments) and log integration driven by business use cases are necessary for better performance.
4. Major improvements in log source preparation and standardization for local markets are needed to enhance the on-boarding process.
This report provides an analysis of Vodafone's ArcSight environment, focusing on its technical aspects as part of the Global Security Operations Center (GSCOC). The ArcSight environment comprises multiple instances of ArcSight Event Management System (ESM), Logger, and SmartConnectors across various locations. Events generated by local markets are sent to central ESM systems for analysis and preparation for triage by VF's GSOC level 1 and level 2 analyst teams.
The main objectives of this assessment were centered around use cases and event reduction. To achieve these goals, specific detailed investigations were conducted:
Identifying top event senders per ESM, devices not feeding any use cases, unnecessary use cases, and events that are no longer required.
Analyzing the quality of aggregated firewall events and checking for messages types that serve no purpose.
Investigating storage concepts, additional content, critical system settings, and performance issues related to event volumes entering the ESM and Logger systems, as well as addressing any storage capacity problems.
Overall, this report aims to improve the efficiency and effectiveness of Vodafone's ArcSight environment by reducing redundant use cases and events through detailed analysis and targeted investigations.
The investigation focuses on understanding how efficient the ArcSight solutions are across different levels, particularly looking at the performance and throughput rates of events handled by various systems like Event Management Systems (ESMs). This includes examining the use case development approach, proactive threat investigations, documentation practices, and efficiency in event reduction. Additionally, it examines local market usage of specific use cases and data flow between markets and ESMs.
Findings from this investigation are summarized in a "Current State Assessment Overview" which details performance metrics such as EPS (Events Per Second) for each ESM under review. Observations show significant variations among the systems, with some having much higher throughput rates compared to others. For instance, while ESM 02 processes around 12,000 EPS, ESM 03 handles approximately 10,000 EPS, and ESM 04 manages roughly 6,500 EPS, there is a notable outlier with much lower performance, specifically ESM 01 which only processes about 32 EPS. The report suggests that this low rate in ESM 01 might be due to its architectural position as a "manager of managers" within the system architecture.
In summary, this investigation provides insights into the operational efficiency and effectiveness of the ArcSight solutions across various components of the organization, highlighting both strengths and potential areas for improvement based on performance metrics and architectural roles.
The summarized text provides an overview of how event rates are handled by different Loggers (LOGGER 01 to LOGGER 04) and their corresponding Enhanced Security Management Systems (ESMs) in a data processing environment.
For instance, Logger 01 has fewer events due to its location in the system architecture which places it on the master tier, where it receives only correlated events for archiving from ESM 01. This is different from Loggers 02, 03, and 04 that are part of a lower tier, receiving direct dual-feed from connectors without event forwarding mechanisms implemented.
The text also highlights the difference in event rates between Loggers and their corresponding ESMs due to various filters applied at connector levels which forward events to both Logger and ESM. The filter complexity affects how many events each system receives, with different configurations leading to varied throughputs. Lastly, it briefly mentions the usage of Smart Connectors like ESM 02, which handles a large number of active connectors efficiently based on performance KPIs shown in a table format.
The passages provide information about three different systems (ESM 03, ESM 04, and ESM 121) that manage and process events from various connectors. Each system has a different number of active and inactive connectors, but they all demonstrate the effectiveness of event reduction through filtering and aggregation processes. The passages also clarify that the differences in event rates between "after aggregation" and "sent to manager" are due to timing behaviors of visualization content and these differences are considered valid.
For example:
ESM 03 has 60 active connectors, with 3 inactive ones; it shows good performance in reducing events through its processing stages.
ESM 04 consists of 34 active and 2 inactive connectors; similarly, it effectively reduces event rates as part of its processing pipeline.
ESM 121 comprises 7 active connectors; the passage highlights its ability to reduce event volumes during the processing phase.
Each system is designed with mechanisms for filtering and aggregating events, which helps in reducing the overall number of events that are processed further, thus improving efficiency and performance. The transition from after aggregation to being sent to a manager typically involves visual content timing differences, but this aspect is not questioned as it contributes positively to the system's functionality.
The document discusses the performance and usage of connectors in a system known as ESM 01, which acts as a "manager of manager" instance handling events from multiple active connectors. The event processing efficiency is analyzed through key performance indicators (KPIs), showing an average reduction rate of 71.73% due to filtering and aggregation during the event-chain process. Poor filter out rates are noted for ESM 03 and ESM 121, warranting further investigation as per recommendations in another chapter.
Additionally, the document provides snapshots of current database usage on specific instances (ESM 02, 03, and 04), highlighting that event data/index contains actual events sent to each instance, while system data/index holds all configurations. These screenshots are represented visually through tables or graphs as mentioned in the context provided.
The provided information outlines the storage and archive requirements for various systems, particularly focusing on Oracle table spaces usage in database environments, logger storage settings, and overall system configurations across multiple ESM (Enterprise Systems Management) instances.
**Database Volume Status:**
**ESM 04**: Shows a significant reduction in available space for event data, with only 25% of the allocated storage left (~550,000 GB). This situation might necessitate attention and planning for future growth or expansion.
**ESM 121** and **ESM 01**: Display normal usage levels within their respective database configurations.
**System Data/Index:**
Contains all system configurations necessary for the proper functioning of each ESM instance, ensuring optimal performance and management.
**Event Data/Index:**
Represents the actual events transmitted to the ESM, reflecting the operational activity and data flow within these systems.
**ESM Storage Requirements Overview (Table):**
Provides a summary of additional storage requirements for archive purposes across various ESMs.
**Logger Storage Settings:**
Adheres to best practice approaches including multiple storage groups and logger archiving features if online retention is inadequate, with full text indexing enabled based on search needs.
**Figures Illustrating Logger Storage Status and Usage:**
**Logger 01**: Displays the storage status and its utilization of the archiving feature.
**Logger 02**: Also shows similar metrics but specific to this logger instance.
This summary highlights key aspects such as storage allocation, event handling, configuration management, and archival strategies across different systems within a corporate IT environment.
The provided text discusses various aspects of storage management, archiving, and event rates for Loggers 02, 03, and 04 (avglog31p.dc-ratingen.de), which are part of a larger system managed by Vodafone's ESM infrastructure.
**Storage Management:**
**Logger Storage Groups: Used Statistics** indicates that the correlation tier loggers are nearing full storage capacity, with urgent attention recommended due to almost running out of space. Most incoming events are being directed to default storage groups because no specific rules have been configured for custom groups.
**Indexing Issues**: On Loggers 02 and 03, past indexing problems were encountered; immediate attention is required to resolve these issues. Recommended settings for indexing are applied on every Logger, including these two loggers.
**Archiving Feature Usage:**
Figures illustrating the storage status and usage of the archiving feature are provided for Loggers 02, 03, and 04. These figures show how data is archived according to the settings configured for each logger.
**Event Rates and Reduction Potential:**
A detailed discussion on reducing the event load sent to ESMs includes principles that should be understood before implementing strategies for reduction.
The text mentions average event reduction success rates achieved by Vodafone’s ESM infrastructure through various stages of event handling, based on representative time windows during normal working days. These values can vary throughout the week and day.
**Figure : Event Reduction Chain:**
This figure is not described in detail here but presumably shows a visual representation of how events are processed and potentially reduced at different stages within the ESM infrastructure.
Overall, the text provides insights into how storage settings, archiving mechanisms, and event handling are managed for specific loggers used by Vodafone as part of their larger system operations. It also highlights the need to optimize these processes based on current usage statistics and potential issues identified during operation.
The article discusses the efficiency in reducing events through specific rules targeting real events of interest (EOI). A table shows potential reduction based on a 30-minute test during normal business hours. However, it mentions that more reduction could have been achieved because all measures were conducted during business hours, which differs significantly throughout the day.
Regarding event rates, even with significant reductions, specific use cases are necessary due to the high volume of events (around 7,000 correlated EOI per day). Currently, around 150 incidents are created from events entering the main channel at GSOC each month, indicating a high rate of false positives (~50%).
Recommendations for reducing event load include removing unnecessary device feeds and adopting log levels according to specific use cases. The assessment identified 535 feeds, out of which around 116 are considered unnecessary based on their original purpose or outdated status. This suggests that approximately 22% of the overall device feeds can be removed. Additionally, log levels should be adjusted depending on the use case requirements for each device type.
This summary highlights an effective method for reducing the volume of events generated by systems, which can be particularly useful across various system types with configurable log levels. It emphasizes that deep use case analysis is often needed to determine appropriate log levels; however, it suggests that "debug" or "informational" logs are unlikely to be required for current or future use cases.
The proposed solution involves creating a table of recommended log level configurations and then focusing on filtering out top unused message signatures from systems like firewalls. These messages typically include frequent but not essential notifications such as “failed”, “success”, or “denied” transactions. Filtering these unnecessary messages can significantly reduce the volume of events delivered by the system.
To implement this method, a list of top message types is compiled for each specific system (like firewalls), identifying and removing unused or irrelevant messages. This process requires in-depth knowledge about existing use cases and their related log requirements. Additional filtering is also recommended based on the firewall product and vendor to further refine the logs.
Lastly, this summary introduces a proactive approach by a dedicated team, referred to as the "Threat Investigation Team," which collects information from publicly available sources in the internet to address threats not covered by existing use case-based configurations. This research is crucial for identifying potential risks that may not be accounted for in predefined threat models or detection mechanisms.
Overall, this approach aims to enhance system efficiency and effectiveness through targeted log filtering and proactive threat analysis, ensuring that only relevant information is captured and managed effectively.
GSOC (Global Security Operations Center) is a part of Vodafone's security team that focuses on identifying and responding to potential cyber threats. The process involves several steps including reading known security news, participating in hacking community forums and blogs, collecting data from publicly available successful attacks against others, researching new use case ideas based on findings, creating tickets for potential incidents using SCITT (custom application), and managing incident tickets through a false positive identification process.
According to GSOC's estimation, about 50% of the created tickets are identified as false positives during the management phase. On average, they handle between 150-200 incident tickets per month. The primary sources for these incidents come from ArcSight rules and proactive investigations based on events detected by ArcSight Event Manager (ESM). ESM devices such as ESM 02, ESM 03, ESM 04, and ESM 121 are the main contributors to the top event sources, with firewalls being the most common device type.
The provided text discusses the content and features of an Event Source Mapping system used in the context of ESM 121, focusing on how it handles reporting, device integration, use case mapping, and top firing rules. Here's a summary of key points from the text:
1. **Logger Content**: The logger content is primarily for reporting purposes, with each logger potentially having its own template that may not align with a standardized reporting concept across all loggers.
2. **Report Content**: Specific reports generated by different loggers (e.g., Logger 01, Logger 02, Logger 03, and Logger 04) are shown without a unified agreed-upon format or concept.
3. **Devices at Markets**: Over 530 devices were detected across local markets during the assessment. These devices are integrated for various reasons including deeper event/incident analysis, reporting/dashboards, auditing requirements, and could be used in multiple use cases depending on their functionality. There are over 50 vendors contributing more than 130 products identified by ArcSight.
4. **Use Case Mapping**: The mapping of use cases within the ESM system is analyzed based on event consumption behavior. Depending on the type of events, filters can be set up to map available use cases across different local markets. This document contains information about which use cases are available where.
5. **Top Firing Rules**: A detailed breakdown of the number of triggers for top rules and those that have a high frequency of partial matching is provided. These rules help in focusing on specific incidents by reducing potential incident loads in the primary channel (GSOC 1st level). Partial matching rules, which only partially match conditions, are also discussed as strategies to improve performance in ESM systems.
Overall, this system appears to be a comprehensive tool designed for effective event management and analysis within an organization, with functionalities tailored towards improving incident response processes through better use of data from various sources.
The provided text discusses the triage methodology and current use cases in place at GSOC (Global Security Operations Center), focusing on how events are analyzed and categorized until an incident is created or not. The methodology involves analyzing events from their appearance in the ArcSight main channel, with potential re-triaging if new information becomes available during case analysis.
Key aspects of the triage approach include:
1. Well-documented processes and methodologies used by analysts for daily work.
2. Use cases are documented and explained, and there's a platform for collecting new use cases (Use case pin-board).
3. A detailed communication matrix is utilized for notification handling during triage.
4. There is a description on how to prioritize events into potential incidents based on their severity or relevance.
5. Analysts have flexibility in decision-making, and false positives are mainly due to lack of context when analyzing cases deeper.
6. All current use cases are considered necessary but some should be reviewed periodically for updates.
The text also mentions that the triage methodology is clear and understood by analysts, with processes and methodologies well documented and used during daily operations. Additionally, there is a platform for collecting new use cases, a detailed communication matrix for notifications, and a method to prioritize events into potential incidents based on their context and relevance.
The document discusses various aspects of using rules in a system, specifically focusing on their relevance to threat management and situational awareness within Vodafone's enterprise security model (ESM). It identifies that while the current use cases are predominantly technical, they lack business context. However, during triage investigations, additional information from a business perspective is added, enriching the rule outcomes.
The document recommends shifting the mindset when considering use cases and suggests creating more useful active use cases rather than numerous basic ones. It emphasizes that ArcSight should be utilized for complex correlations of high-level use cases rather than just alerting on base events. To enhance contextual information quality, detailed local market information during onboarding processes and consideration of HP Identity View integration with CMDBs are recommended.
To improve the quality of use cases, it is suggested to involve local markets in the case development process, consider a workflow or request portal for use cases, and categorize them based on their benefits and primary beneficiaries. Additionally, creating a quick win recommendations list that includes easy-to-handle findings with low effort requirements could be beneficial.
During an assessment, a list was created to identify and remove unnecessary devices as agreed upon with GSOC engineering. This list included detailed information about each device's usage. The assessment suggested adopting log levels on source devices appropriately and reaching out to device administrators in various local markets to adjust log settings by deactivating "debug" and "informational" levels.
Additionally, it was recommended to remove all Windows OS feeds since centralized logging through the Windows Auditing Collection System is already established for required events (Windows Security Event Log, Windows Audit Log). This means that there's no longer a need to feed these logs into another system like "Microsoft Audit Collection System." The assessment revealed seven current Windows source devices feeding into different ESM instances: VF-GRP-PCI, VF-UK-PCI, and VF-AU.
Performance analytics indicated poor filtering and aggregation performance in the connectors used by ESM 03 and ESM 121, while ESM 04 showed issues with aggregation performance. A table was provided to detail the top N connectors experiencing these problems.
Lastly, it was suggested that unnecessary message types be checked for, specifically focusing on "allow/deny" messages which are typically not required for all use cases. Other necessary message types should be confirmed based on specific use case requirements, and filtering out insignificant or unused message types could improve event processing efficiency.
The report involved creating top message type reports for each Electronic Support Measures (ESM) device to identify and eliminate unnecessary message signatures. It was observed that only a few types of messages accounted for almost all the messages, suggesting potential room for filtering out less critical ones. Additionally, log levels on devices should be adjusted by excluding "debug," "informational," and other use-case dependent levels. Unused rules and top firing rules were advised to be disabled or checked due to their resource consumption. Retention periods for events sent to the logger needed to be reviewed in terms of storage capacity. Indexing problems on Loggers 02/03 should also be addressed, with text indexing being considered after resolving storage issues. A regular use case workshop was recommended to model networks and integrate CMDB data for a comprehensive asset model. Documenting use cases and making logging guidelines part of the preparation checklists were emphasized before local markets are onboarded. Lastly, potential problems such as "cache overload" in flex connectors and unparsed events needed attention or solutions.
The document outlines a comprehensive improvement plan aimed at enhancing the efficiency and effectiveness of Global Security Operations Centers (GSOCs) by streamlining the process of on-boarding new devices, such as Cisco ASA and Juniper Firewall/VPN systems. Key improvements include:
1. Implementing contextual enhancements like asset modeling, device type collection, and user context to improve analysis and investigations. This approach not only aids in more efficient use cases but also enhances the service offering by focusing on specific business needs and increasing attractiveness to local markets.
2. Enhancing access to information about assets, networks, and users for better analysis and investigation. Since many local markets lack advanced asset management solutions, this involves getting involved in IP address management (IPAM) processes and requesting network plans that reflect layer 3 architecture.
3. Introducing a risk assessment as part of the on-boarding procedure to identify potential issues such as incident history and critical design flaws in network diagrams. This proactive approach helps in understanding and managing risks associated with new devices.
4. Ensuring access to important security management tools like firewalls, IPS (Intrusion Prevention Systems), vulnerability management systems, proxies, and IPAM during on-boarding. Highlighting the potential benefits of such access can help streamline investigation processes for better context analysis.
5. Standardization and documentation of proactive analysis are emphasized to ensure consistency in approach across different devices and use cases. This includes setting up a basic set of business-focused use cases aligned with threat management strategies, as well as incorporating detailed service catalogues into the information strategy during on-boarding.
The provided text appears to be a summary of a technical or engineering report, likely detailing the process and outcomes related to threat analysis within a cybersecurity framework. Here's a simplified breakdown of the content based on the titles given (which seem to be placeholders for sections or figures):
### Approaches
**Threat Analysis Process**: The text does not provide details about what "threat analysis" is, but it mentions that outcomes are handled in some way. This could imply discussions about how threats are identified, assessed, and managed within the system.
**Handling Outcomes**: Given the lack of direct information in the provided text, this might involve discussing how detected threats are mitigated or responded to, possibly involving strategies for incident response or continuous improvement based on threat intelligence updates.
**Feedback Loops**:
**From Threat Intelligence Efforts to Content Engineering**: This could describe how insights from threat intelligence (such as patterns or vulnerabilities) influence the configuration and updating of security features and applications.
**From Incidents/Lessons Learned to Content Engineering**: This might involve using post-incident analysis to refine future preventive measures, ensuring that system configurations are updated based on actual incidents experienced rather than theoretical threats.
### Appendix
**Pictures** includes references to figures from the report:
Figures ranging from Figure 1 to Figure 40 likely represent visual aids such as diagrams or charts that support the main text by providing graphical representations of data, processes, and outcomes discussed in the body of the document.
### Summary
The summary provided focuses on three key areas: how threats are analyzed, how outcomes are managed, and the feedback loops between threat intelligence updates and content engineering, as well as from incidents to enhance system configurations. The appendix lists figure numbers that correspond to graphical representations intended to aid in understanding these processes and findings.
This text provides a list of figures and tables from a document, presumably part of a larger report or study. Here's the summary based on the provided information:
Figures:
Figure 41: Report Content - Logger 03 (Page 35)
Figure 42: Top Firing Rules - ESM 02 (Page 36)
Figure 43: Partial Matches - ESM 02 (Page 37)
Figure 44: Top Firing Rules - ESM 03 (Page 37)
Figure 45: Partial Matching Rules - ESM 03 (Page 38)
Figure 46: Top Firing Rules - ESM 04 (Page 38)
Figure 47: Partial Matching Rules - ESM 04 (Page 39)
Figure 48: Top Firing Rules - ESM 121 (Page 39)
Figure 49: Partial Matching Rules - ESM 121 (Page 40)
Figure 50: Triage Methodology - High Level (Page 40)
Figure 4: Use Case Development – Suggested Basic Process (Page 42)
Figure 5: Use Case Categorization (Page 43)
Figure 51: Improvement Summary (Page 48)
Tables:
Table 1: Current Assessment - Work Items (Page 9)
Table 2: Event Processing through Stages - ESM 02 (Page 15)
Table 3: Event Processing through Stages - ESM 03 (Page 15)
Table 4: Event Processing through Stages - ESM 04 (Page 16)
Table 5: Event Processing through Stages - ESM 121 (Page 16)
Table 6: Event Processing through Stages - ESM 01 (Page 16)
Table 7: Connectors Currently Down (Page 17)
Table 8: ESM Storage Requirements Overview (Page 20)
Table 9: Logger Storage Groups: Used Statistics (Page 26)
Table 10: Log level configuration recommendation (Page 29)
Table 11: Top Event Sources Details - ESM 02 (Page 32)
Table 12: Top Event Sources Details - ESM 03 (Page 32)
Table 13: Top Event Sources Details - ESM 04 (Page 33)
Table 14: Top Event Sources Details - ESM 121 (Page 34)
Table 15: Connectors with poor filtering or aggregation (Page 45)
Table 16: Message Type Distribution - ESM 02 (Page 46)
Table 17: Message Type Distribution - ESM 03 (Page 46)
Table 18: Message Type Distribution - ESM 04 (Page 46)
These figures and tables are part of a larger document, likely detailing information about event management systems or similar technical subjects, as indicated by the context "ESM" which stands for Event Management System. Each figure is assigned to a specific page number in the report, presumably where it can be found within the document itself. The same applies to the tables, which also have their respective pages noted next to them.
Comments