Definition of Use Case v1.1_1

Summary:

The article provided serves as a high-level overview of how Asset 2 might be prioritized for investigation within a security incident management framework using ArcSight. Here's an elaboration on the scenario involving Asset 2 and its implications based on Rule 1 and Rule 3 triggers, along with some additional considerations: ### Scenario Breakdown **Triggering Rules:** - **Rule 1:** Bad password used in an environment impacting a desk directly (High priority impact = 3 + Confidential classification = 2), resulting in a combined score of 5. - **Rule 3:** Bad password used in an environment impacting revenue (High priority impact = 3 + Secret classification = 3), resulting in a combined score of 6. **Investigation and Severity Assessment:** Given that both rules are triggered within the same timeframe, Rule 3 takes precedence over Rule 1 due to its higher severity score (6 vs. 5). This prioritization is based on predefined criteria for "Operational Impact" and "Security Classification," as outlined in the scenario. The high-priority impact value of 3 and the more severe classification from Rule 3 indicate a higher urgency for investigation. ### Case Management in ArcSight **Case Creation and Assignment:** When both rules are triggered, an incident case is automatically created within ArcSight. This case contains information about the incidents linked to these events. Administrators control access to various tools like dashboards and data monitors through Access Control Lists (ACLs). The case is assigned to analysts or operations who investigate based on severity and enterprise policies. **Case Severity:** Case severity is determined by the consequence severity values found in the classification section of each rule, which contribute to a combined score used for prioritization. In this scenario, Rule 3’s higher score (6) suggests that it carries more severe consequences, leading to its priority over Rule 1 in case management. ### Notifications and User Management **Notification Methods:** The article mentions various methods for notifying users about triggered events, including Console, Email, Pager, and Cell Phone, depending on their accessibility preferences. Users can choose the method that suits them best. Notification statuses include Pending, Undelivered, Acknowledged, Not Acknowledged, Resolved, or Informational, with overdue notifications automatically reclassified as "Not Acknowledged." **User Types and Access Control:** The document outlines different user types within HP ArcSight, each with specific privileges. Normal users can access the console and tools, while management tools have more extensive network management capabilities. Forwarding Connectors operate under role-based permissions, and Archive Utilities use an archive utility with controlled ACLs. Connector Installers are specifically for adding SmartConnectors to the system. ### Conclusion The scenario in Asset 2 highlights how ArcSight's case management functions can prioritize incidents based on severity scores, ensuring that high-priority impacts like operational loss due to bad password usage are addressed promptly. The integration of multiple rules and their respective classifications allows for a comprehensive assessment of risks, which is crucial in maintaining security and operational integrity within an organization. This approach not only enhances the efficiency of incident response but also ensures compliance with enterprise policies regarding data sensitivity and criticality. By carefully managing user access and implementing robust notification procedures, organizations can effectively respond to potential threats and mitigate their impact on business operations.

Details:

This document outlines a comprehensive framework for defining, documenting, and managing HP ArcSight Event of Interest (EOI) use cases. It includes detailed procedures and standards for version control, circulation, and artifact management within the EOI workflow. The primary goal is to standardize the documentation process for future workshops and ensure clear understanding among team members regarding terminology and workflows associated with SIEM-based EOI solutions. An Event of Interest (EOI) use case initially starts as a requirement to collect individual logs from various networks, operating systems, applications, or specialist devices. These logs are then correlated logically to create more meaningful EOIs for security purposes. In its simplest form, this use case involves monitoring user accounts that have left the organization or been temporarily suspended, ensuring they do not have further access to company systems such as Windows domain, VPN, or privileged internet accessible web applications. The process typically includes understanding log dependencies and interviewing application owners about their system functionalities. For instance, in an interview with the Information Technology Systems (ITS) department for a hypothetical ERP system used by HR: 1. The ERP system stores detailed employee information including contractors, sharing a common user name field with Active Directory as "firstname.lastname" or "firstname.lastnamen". It also has an active status field to indicate whether a user is active, suspended, or terminated. 2. The user value in the ERP system for Darren Humphries is "darren.humphries03", and his corresponding active status is "suspended". 3. Active Directory uses the same user account with the unique identifier "firstname.lastnamen", but there's no automatic synchronization between the ERP and Active Directory systems. The company relies on manual verification to match accounts. This manual joining of data from different sources forms part of the EOI use case, aiming to enhance security by preventing unauthorized access post-termination or suspension. The document outlines a process for managing an employee's access within an organization, particularly focusing on disabling or deleting user accounts in Active Directory when their status in ERP (Enterprise Resource Planning) is marked as suspended. This process involves several steps and components: 1. **Collection of Logs**: Gather information from both the ERP system (containing details about the user and their status) and Windows Active Directory (showing authentication logs for the user). Specifically, look for event ID 680 in Windows events, which indicates account login attempts. 2. **User Account Status Check**: If the ERP shows that a user's status is "suspended," this should trigger the process to disable their Active Directory account. 3. **Impact on Access**: Since the organization uses single sign-on for both VPN and web applications, disabling an Active Directory account will result in immediate loss of access to all company applications (both internet facing and internal) due to authentication requirements based on Active Directory data. 4. **Documentation and Workflow**: The document aims to simplify the process by defining clear steps and artifacts needed (like gathering logs from ERP and Active Directory). It also sets a foundation for how this use case can be adapted or mapped within the HP ArcSight tooling workflow, ensuring it aligns with organizational practices and security measures. 5. **HP EOI Use Case Workflow**: This section provides a structured approach to handling such use cases in the context of HP ArcSight, detailing each step from identification to resolution, ensuring that the process is efficient and effective for user management within the organization. In summary, this document provides a detailed procedure for managing employee access rights, particularly during suspension, using standard tools like ERP and Active Directory. It also emphasizes integration with organizational IT systems (like ArcSight) to maintain security and compliance standards. The article emphasizes the importance of using ArcSight workflow tools within an organization to effectively manage Event of Incidents (EOI). To accomplish this, it suggests that the management of EOI should follow a structured approach by aligning with the organization's incident management process. This involves defining a RACI matrix for all stakeholders involved in handling incidents across operating systems, applications, network devices, and specialist system owners. The main objective is to transform millions of daily events into meaningful and manageable Event of Incidents (EOI) through sorting, enrichment, and filtering processes. HP ArcSight assists in achieving this by employing three methods: Standard Content, Customer Use Cases, and Pattern Discovery. Standard Content involves configuring EOI that includes common information for most customers, such as bad login attempts or suspicion scanning reports. It also encompasses a list of standard content to support these configurations. Customer Use Cases are specific use cases developed during the project use case workshop which include requirements not covered by the standard content. These capture unique situations and needs in an organization's incident handling process. Pattern Discovery is a licensed feature that enhances HP ArcSight capabilities beyond static use cases, automatically detecting subtle patterns such as day-zero attacks, low-and-slow attacks, creating rules based on these patterns, discovering normal baselines, and maintaining a history of threat patterns. This method provides additional benefits over traditional static use cases, making it a valuable tool for organizations looking to proactively manage their cybersecurity risks. In order to successfully implement and utilize HP ArcSight ESM, it is crucial to define standard content thoroughly, particularly regarding the sixteen workflow artifacts. These artifacts encompass various elements such as log sources, reporting dashboards, event monitors, and more. While some of these artifacts can be preconfigured (e.g., top 10 suspicious IP addresses, predefined reporting, and dashboards), others necessitate customer input due to their specific requirements (e.g., asset list information including classification and notification settings). For instance, regarding the configuration of an investigation case in response to detected events, this aspect remains undefined; it requires further clarification and specification. Similarly, for each use case involving EOI (Event-Oriented Intelligence), all workflow artifacts must be defined comprehensively, with orange ones already established but requiring corresponding silver-grey artifacts to complete their functionality. The document outlines the significance of log sources, which are integral components in HP ArcSight ESM as they generate events from diverse locations such as operating systems, applications, network devices, or specialist tools and applications. Log collection is facilitated through specialized HP ArcSight SmartConnectors, either by push (syslog) or pull mechanisms from non-standard log sources, necessitating the development of Flex Connectors when standard connectors are not applicable. These connectors play a pivotal role in data ingestion based on preprogrammed parsers that understand common event formats specific to various log types. This text discusses the importance of converting non-standard log formats into Common Event Format (CEF) for processing by HP ArcSight. It explains that if logs do not meet specific requirements for collection via SmartConnectors, they are considered non-standard and need to be parsed using Flex Connectors. An example given is Oracle databases, where the standard SmartCollector relies on the Oracle audit log; without it, a flex connector must be used to parse data into CEF. The text also highlights that providing raw data samples from non-standard log sources is crucial for evaluating if an Event of Interest (EOI) use case can be achieved and suggests that HP should review this during workshops. It mentions that correlation rules are used to define specific outcomes, incorporating additional logs like time-based parameters. Finally, it uses the example of ERP user statuses to illustrate how rule names consist of components such as ERP user values/usernames and their corresponding active statuses for defining a rule within HP ArcSight. To build an active list of all ERP users who are suspended, we first need to define what constitutes the active list in this context. In our case, it's a simple list titled "Suspended_terminated_users" which includes user names and their statuses (e.g., darren.humphres03 is Suspended; Joe.blogs is Terminated). This active list is maintained through log collection, stored in memory to use hardware resources efficiently. If a suspended or terminated user's name appears in the event logs, we want to be notified as an Event of Interest (EOI). Aggregation thresholds are crucial for triggering rules based on the number of occurrences within a specified time frame. These thresholds help reduce false positives and avoid false negatives while ensuring that security operations teams handle only relevant alerts. Assets in this context refer to any network endpoints with IP addresses, MAC addresses, hostnames, or external IDs. They are considered significant enough for detailed correlation and reporting. The passage describes how actions related to rules can be triggered based on specific events or stages. When an "Event of Interest" (EOI) is triggered, various actions can be taken depending on the stage and context. These actions include setting event field values, sending information to a monitoring system, notifying users, executing commands, and exporting data to external systems. The passage also mentions different thresholds for triggering these actions, such as "On First Event," "On Subsequent Events," and "On Every Event." The text provides an explanation of different triggering options in a rule system, along with definitions and examples related to asset classifications. It also outlines how consequences are determined through severity values based on specific conditions. Here's a summary: 1. **Triggering Options**:

• **On First Threshold**: Triggers only the first time that the rule conditions and threshold settings are met.

• **On Subsequent Thresholds**: Triggers every time the rule conditions and threshold settings are met, starting from the second occurrence.

• **On Every Threshold**: Triggers each time the rule conditions and threshold settings are met without any restrictions on the number of times they occur.

2. **Asset Classification Details**:

• **Asset One** is a financial application storing sensitive data:

• **Classification**: `/All Asset/Business Impact/Analysis/Business Role/Revenue`

• **Operations Classification**: `4- Immediate impact`

• **Security Classification**: `4- Top Secret`

• **Desktop Machines** are general use computers in the enterprise:

• **Classification**: `/All Asset/Business Impact/general Desktop`

• **Operations Classification**: `1- no immediate impact`

• **Security Classification**: `1- unclassified`

3. **EOI Severity Values**:

• **Rule 1** (Three bad login attempts): Consequence severity = `2-marginal`

• **Rule 2** (Unknown user accesses point of sales application): Consequence severity = `4-catastrophic`

• **Rule 3** (Antivirus detected as compromised): Consequence severity = `3-critical`

The text provides a detailed breakdown of how these rules and classifications interact in a security context, emphasizing the importance of accurate classification for effective rule application. The document discusses the application of two rules (Rule 1 and Rule 3) to two assets: Asset 1, a financial point-of-sale system, and Asset 2, a desktop application. Both rules are evaluated based on their respective classifications determined by factors such as login attempts, antivirus detections, operations classification, security classification, and business impact scores. For **Asset 1 (Financial Point-of-Sale System)**:

• Rule 1: Three bad login attempts resulted in a marginal score of 2, with an immediate operational impact (classification 4). The highest possible security classification is also top secret (also classified as 4). It belongs to the broader category affecting revenue.

• Rule 3: Antivirus detected indicated a critical issue (score 3), maintaining high operational and security classifications at 4 each. It too falls under the general business impact, but with an emphasis on revenue impact since it scores over 10.

For **Asset 2 (Desktop Application)**:

• Rule 1: Three bad login attempts led to a marginal score of 2, placing it in the general desktop category as indicated by its classification across different aspects. It has no immediate operational or security impacts (both classified as 1).

• Rule 3: The antivirus detected criticality is reflected with a score of 3, but this does not significantly change its low operational and security classifications. It remains unclassified and without immediate impact on operations.

The document then considers the scenario where multiple desktop assets show similar login attempts scores but Asset 1 has a higher single score compared to these multiple lower scores. The paper suggests that while Asset 1 should be given priority for investigation due to its higher numerical score, further consideration is needed to define how residual impact and classification of such events should be handled across multiple assets with varying scores. In conclusion, the document highlights discrepancies in classifications based on different factors and proposes a framework for evaluating these scenarios where multiple similar low-score incidents might not warrant as much priority compared to isolated high-score occurrences like in Asset 1's case. In this scenario involving ArcSight and security incident management, the focus is on investigating Asset 2 due to its high priority impact based on predefined criteria for "Operational Impact" and "Security Classification." If both Rule 1 (combining bad password with business impact/desk) and Rule 3 (combining bad password with business impact/revenue) trigger within a half-hour timeframe, the scenario would involve assessing each rule's severity. **Rule 1:** Bad password used in an environment that impacts a desk directly, which has a "High priority impact" (value 3) and is classified as "Confidential" (value 2), resulting in a combined score of (3 + 2) = 5 for Rule 1. **Rule 3:** Bad password used in an environment that impacts revenue, which has a "High priority impact" (value 3) and is classified as "Secret" (value 3), resulting in a combined score of (3 + 3) = 6 for Rule 3. Since both rules are triggered within the same time frame, but Rule 3 has a higher combined severity score (6) compared to Rule 1 (5), Asset 2 should be prioritized for investigation as per the guidelines that recommend investigating assets with higher priority impacts first. This approach leverages security knowledge and incident management principles to ensure critical issues are addressed promptly, thus mitigating potential risks effectively. The article discusses how ArcSight uses built-in tools for case history and management, where cases contain information about incidents with attached events. Administrators can control access to dashboards, query viewers, and data monitors by adjusting access control lists (ACLs). Cases are assigned to analysts or operations who investigate and resolve them based on severity and enterprise policies. Rules can automatically open a case when certain conditions are met, and cases can be assigned to groups of users with notifications about their access. Users can take action on the case, assign it to another user, or resolve it. Case management for EOI use case workflow should consider factors such as who will handle cases, resolution time in relation to KPIs, and if operational level agreements (OLAs) are necessary. Case severity is based on Event (EOI) consequence severity values found in the classification section, and cases can be exported to third-party systems like HP Openview for integration purposes. Notifications within EOI use case workflow involve defined methods of communication as messages sent and confirmed received until closure. The document outlines various methods to notify users about events triggered by an EOI (Event of Interest) rule, including sending notifications through various channels like Console, Email, Pager, and Cell Phone. Users can choose the preferred method based on their accessibility. Notifications can be categorized as Pending, Undelivered, Acknowledged, Not Acknowledged, Resolved, or Informational. The document also explains how to handle pending notifications that are not acknowledged within 24 hours, automatically reclassifying them as "Not Acknowledged." The document outlines the components and user types for HP ArcSight, a security information and event management (SIEM) tool used in an EOI (Event-driven Orderfulfillment Interface) use case workflow. Consoles are the primary tools utilized by end users to interact with HP ArcSight. There are two main consoles: 1. **ArcSight Web Console**: Offers full event monitoring and drill-down capabilities through a user-friendly interface, which can be branded with the company's logo. It does not require additional licenses as it is part of the base software package. 2. **ArcSight (Thick) Console**: A more feature-rich alternative to the Web console, requiring installation on users' PCs and purchased licenses. Users within the system include: 1. **Normal User**: Has full privileges to use both the ArcSight Console/Web client and all tools. This user type is applicable only to accounts that require access to the HP ArcSight Manager. 2. **Management Tool**: Can run specific management tools related to network management products, with limited privileges. 3. **Forwarding Connector**: Only has the necessary privileges for its designated role within the system. 4. **Archive Utility**: Utilizes the archive utility with controlled access to specific resources through Access Control Lists (ACLs). 5. **Connector Installer**: A specialized user type used solely for adding SmartConnectors to the system. 6. **Web User**: Can use the ArcSight Web client or Management Console, providing limited access compared to other user types. Additionally, considerations for user management and password policy requirements are emphasized in this document, ensuring secure authentication processes within HP ArcSight.

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.