Conducting a SIEM use case development workshop

Software

It will be helpful to have an instance of the Splunk platform available for use prior to this session, with Splunk Enterprise Security, Splunk Security Essentials, and Enterprise Security Content Updates installed.

Required stakeholders

• Key business stakeholders to be available only for the first and last sessions
  • Security program leadership, up to the CISO level (the higher the better)
• Representatives of each of the following communities within the organization
  • Splunk administration
  • Splunk Enterprise Security administration
  • Splunk content developer
  • Project leadership
• Security program leadership (one or more from each team)
  • Security engineering (administration of security solutions)
  • Security operations
  • Security threat management
    • Internal/insider
    • External
  • Internal compliance/regulatory
• Test/acceptance lead
• Representatives of each of the following to be available by email/phone to respond to questions related to your environment
  • Server engineering (each OS)
  • Network engineering
  • Desktop engineering
  • Applicable data source owners

Required documentation

Before you begin, ensure that everyone involves has access to and has reviewed the following:

• All applicable internal policies and supporting standards such as:
  • Information resource classification
  • Information retention and destruction
  • Infrastructure logging and configuration
  • Database logging and configuration
  • Application logging and configuration
• Inventory of standards with requirements for logging and monitoring applicable to your business
• Internal audit/self-assessment for applicable security standards such as PCI/SOX/HIPAA inclusive current draft reports
• External audit/self-assessment for applicable security standards such as PCI/SOX/HIPAA
• Inventory of existing (implemented use cases) using the provided template
• Inventory of existing (implemented data sources) using the provided template

Architecture workshop (If SIEM replacement):

An architecture workshop can add on an additional week of discussions and documentation. This is beyond the scope of this article, but will involve the following activities at a minimum:

• Document requirements in architectural recommendations 
• Discuss retention strategy in alignment with audit and compliance requirements
• Review time and size-based retention capabilities
• Review data archiving and restoration requirements
• Review access control requirements
• Identify technology add-ons required
• Identify Splunk apps applicable to use cases
• Identify data enrichment requirements based on use cases and data sources
• Document anticipated tasks, estimated duration, prerequisites, and dependencies in the implementation plan
• Review clustering, high availability, and disaster recovery needs
• Review instances that integrate with the Splunk Cloud Platform
• Review and document configuration management
• Review and document data collection infrastructure

You should also develop a recommended architecture diagram, as well as any system dependencies, within the execution planning section of this SIEM workshop.

Finally, if you are a new customer who is replacing of any of the following SIEM software with Splunk Enterprise Security, review the following technical considerations as part of your architecture work:

• IBM QRadar
• LogRhythm
• Exabeam

Opening session

The opening session should set the tone for the use case workshop. This is where you gather valuable information about your security operations center, which will drive the content for the final deliverable. Your key stakeholders and leadership should be actively involved, as these are the people who will drive strategy and outcomes within your organization. Some of the things you want to discover during this session are:

1. What is your primary mission? Are you trying to solve for insider threat, corporate security monitoring, OT security, supply chain, or something else entirely?
2. Identify some of your short-term and long-term monitoring goals.
3. What are some of your biggest risks and threats to the organization? What keeps you up at night?
4. What is the current profile of your SOC? Consider size, geographic footprint, operating model, and anything else you deem relevant.
5. What are your current pain points from a monitoring perspective? Alert fatigue? Compliance/reporting requirements? Reactive alerting?
6. What are your current pain points from an incident response perspective? This could be manual identification and remediation processes, SLAs, and more. This is a good opportunity for a discussion on response planning utilizing PICERL with investigations aligned to MITRE tactics.

Recommendation development

The use case recommendation should be aligned with your strategic and tactical objectives, and should be justified as such within the executive summary of the document. At a minimum, the following details should be included in your recommendations.

1. Executive summary discussing the following:
   1. Overview of engagement (who, what, when, where)
   2. Identified success criteria or objectives as discussed in opening session
   3. Justification for the use case recommendation
2. Use case recommendation, to include the following details:
   1. Use case title
   2. Use case description
   3. Required data source category (email, authentication, etc.)
   4. Adaptive response action (risk, notable, or both)
   5. Entity protected (account, host, network)
   6. MITRE tactic (investigation technique)
   7. MITRE technique ID (T-number)
3. Data source requirements
   1. Data source category (corresponding data model)
   2. Vendor (technology provider)
   3. Product
   4. Event type (message tracking, successful authentication, etc.)
   5. Scope of deployment (servers, workstations, ingress/egress, etc.)
   6. Onboarding status (is it onboarded, CIM compliant, etc.)
   7. Recommended onboarding method (UF, SC4S, HEC, REST, etc.)
4. Enrichment requirements
   1. Category (assets/identities, use case enrichment, threat intelligence, etc.)
   2. Supporting data source (Data source name, or manual if a user created list)
   3. Corresponding use cases (assets/identities will correspond to 'All')
5. Response plan recommendation
   1. Response title (identification, containment, eradication, recovery)
      1. Identification. Additional information required to make a determination of an alert or notable
      2. Containment. Required actions to minimize impact of a detection determination
      3. Eradication. Removal of the risk to the entities
      4. Recovery. Restoration of normal activities
   2. Required inputs. Example: domain, URL
   3. Required integrations. Example: VirusTotal
   4. Asset owners. Example: MS Office 365 - Jane Doe
   5. Corresponding processes (What are we automating that is now manual?). Provide a recommendation without documented plans (SOAR workbooks).

Recommendation gaps

After delivery of initial recommendation, remove any use cases deemed out of scope and identify any additional use cases you want to include in implementation. Ensure you capture all of the required information as described in the recommendations section above for each use case. This session might need to be continued in a later session, the time set aside to review tabled items. The outcome of this session should be a final list of detections and supporting data sources/enrichment, and response plans.

Execution planning

The execution planning phase should include a discussion on all of the required logistics for realization of prescribed use cases and response plans. If you haven't gathered this information already, do it at this stage. The following items should be captured during this session and incorporated into the final deliverable. Response plans should be developed in parallel with the use case development.

Architecture workshop

If you are replacing another SIEM, you should have completed your architecture workshop at this point and develop a recommended architecture diagram that includes any system dependencies.

Review tabled items

This session is meant to be an 'as-needed' session to cover any items that were tabled throughout the working sessions. Schedule this on an as-needed basis. It can include any or all of the following:

• Continuation of architecture workshop (if in scope)
• Additional use cases
• Threat intelligence discussion
• Overflow on any other topics

Documentation development

At a minimum, an entire day should be spent developing the final documentation. The SIEM Workshop Use Case Recommendations template will help you get started.

Deliverable readout

The final deliverable readout should be presented to your entire team, including leadership. The following points should be discussed:

• Recap of workshop goals, as initially agreed upon
• Layout of the deliverable documents and what is included
• Overview of the recommendation. You don't need to review every single detection/use case/response plan, but rather discuss metrics/types of use cases captured to address specific goals.
• High level review of architecture plan, if applicable
• Answer any questions
• Validate that team expectations were met for workshop and identify any follow up requirements