A less-talked about challenge in cybersecurity is managing multiple alert queues. While the volume of alerts is acknowledged as an issue, an important step toward simplifying day-to-day life for security analysts is to consolidate alerts into a single queue. This is why security orchestration, automation, and response (SOAR) tools must offer native case management. When a SOAR security tool can offer robust case management capabilities, customers only have to work out of one platform, rather than half-a-dozen or more.
The importance of case management is well understood by the enterprises we work with. In fact, we’ve collected examples from real-world RFPs written by enterprise SOAR buyers, listed them below, and added examples of how the case management capabilities within Smart SOAR can meet their requirements.
Case Creation and Importing
Customer Requirement: Ability to triage and dismiss alerts within the system before creating them as a new case.
This is a unique request that many users do not consider right away, but an effective SOAR tool should be able to reduce the size of an analyst’s alert queue as well as consolidate it. With D3’s two-tiered automation design, events can be dismissed or correlated to existing cases before a new one is created.
Customer Requirement: Generate cases with prebuilt tasks corresponding to workflows defined in playbooks.
In Smart SOAR, all cases are assigned an Incident Type that determines which automated and manual tasks are included in the case. For example, here is a Brute Force incident with two pending tasks, both due in an hour:
- Review User Permissions, and
- Determine if Login Suspicious
Customer Requirement: Ability to ingest alerts from multiple data sources.
Within D3 Smart SOAR, there are hundreds of out-of-the-box integrations. Many are for data sources that are common to cybersecurity teams, such as Microsoft Sentinel, Office 365, and CrowdStrike. Integrations that have alerts required for ingestion have a task called a Fetch Event task. These tasks can be run on a schedule to query the data source for new alerts. Here, you can see a series of runs checking Office 365 for new suspicious emails:
Alternatively, alerts can be pushed to endpoints within D3 via webhook. Here is a record of three alerts pushed to D3 within the span of three hours:
Either way, all alerts are consolidated into a single queue for straightforward tracking and navigation.
Customer Requirement: Ability to manually create cases when needed.
Not all cases are created automatically using a scheduled fetch event command or a webhook. Some are created directly from within Smart SOAR. A user just defines the site to store the incident within, the incident type, the severity, playbook, owner, and timezone. Fields like title, description, and due date can be filled in afterwards:
Customer Requirement: Ability to correlate multiple alerts into a single case.
Within Smart SOAR, users can define specific correlation logic such as common hostnames, username, or time of occurrence. This correlation can execute automatically or can happen on-the-fly by analysts as they are reviewing a case.
Case Artifact and Data Management
Customer Requirement: Ability to add case-related artifacts, indicators of compromise, or observables (such as IP address, url/domain, file hash, email address, etc.) to cases.
All artifacts are stored within cases as entities that can be called on in playbooks, pushed to third party threat intelligence tools, linked to other cases, and assigned custom severities. For example, here you can see a malware incident with the file hash, filename, external IP, and URL as artifacts.
Customer Requirement: Ability to tag or label, and add description to case-related artifacts.
As artifacts are stored as their own entities, they can be updated and tagged as shown below. Here you can see specific MITRE tactics and techniques assigned to this file hash.
Customer Requirement: Ability to automatically generate case-related artifacts from new alerts.
Smart SOAR’s event field mapping is how artifacts within event raw data are automatically added as artifacts to a case. Here you can see field mapping for the filename, recipient and sender, all of which will be stored as artifacts once an email is ingested from Office 365.
Customer Requirement: Cases must allow analysts to attach files to cases for analysis and auditing.
Multiple file types including PDF, CSV, XLS, JSON, and more can be uploaded into cases. These files can be referenced within playbooks and are included in audit logs.
Case Correlation and Categorization
Customer Requirement: The case management system should have a normalized data structure.
All alerts ingested into Smart SOAR are normalized automatically. This simplifies playbook automation and user review. Field mapping for each data source is provided out of the box, and can be customized to alter the normalized data structure depending on unique requirements. All normalized fields are displayed in the case overview for easy review.
Customer Requirement: The case management should automatically correlate cases based on shared artifacts.
Linking cases is crucial to investigations. So, we created a dedicated playbook command for this purpose. With this command active, cases with related artifacts will be linked and accessible within the main incident overview.
Here you can see two brute-force incidents linked to a multiple failed log-in alert from Elasticsearch:
Customer Requirement: The case management system must allow cases to be categorized by multiple attributes, including attack type, attack vector, attack group, attack objective.
The queue of cases in the investigation dashboard can be customized depending on various fields listed above. Here, they’re grouped by MITRE Tactic and Technique, with any case that is ‘closed’ removed, and the remaining cases ordered by descending severity. These filtered views can be saved and used later and are unique to each user account, so everyone can have their own prioritized queue of alerts.
Case Task Management
Customer Requirement: Ability to view all tasks assigned to a user. Also include a pending task section so investigators know what needs to be done next as soon as they log in to the platform.
Another feature of the investigation dashboard is to display a list of pending tasks that are assigned to you in various cases.
Within cases themselves, pending tasks assigned to you and assigned to others are listed as well:
Customer Requirement: Case tasks must contain a free text field allowing analysts to document work done for the task.
Collaboration within tasks is important. Analysts can upload code and keep track of progress against tasks assigned to them within the free-form text editor of each task:
Customer Requirements: Customize case layout based on incident types.
Case overviews can be customized using playbook-like diagrams. Below is one for malware incidents, which has six sections: KPI Tracking, Hash Analysis, Asset Information, Microsoft Defender for Endpoint Instructions, Analyst notes, and Problem record.
This maps directly to the case overview:
This contrasts the Mimikatz incident type set up here which includes device details, hosts, and processes:
Customer Requirement: The case management system should allow for automations to be executed ad-hoc.
Within the case overview, new playbooks and single commands can be triggered if the user has the appropriate permissions. This gives investigators flexibility in terms of how they want to approach an incident. For example, core data enrichment tasks can be completed automatically, then type-specific containment actions can be triggered ad-hoc.
Case Tracking and Auditing
Customer Requirement: Record all actions within the system in an immutable audit log.
The Command Center within each case is an immutable record of all actions taken on a case. This includes automated playbook tasks, manual tasks, and edits made to case details, such as artifacts.
Customer Requirement: Highlight key information for fast review.
Within the command center, any record can be marked as a key finding can then be reviewed under the Key Findings tab of the case itself.
Key Findings
Case Closure and Reporting
Customer Requirement: Ability to close the case with disposition in order to indicate a conclusive positive or false positive.
Before closing a case, the user will be prompted with closure notes. The purpose of these notes is to indicate the conclusion that the investigation team came to, along with any additional notes, such as actions taken or decisions made.
Customer Requirement: The system should allow for bulk-closure of cases.
Within the investigation dashboard, various bulk actions can be taken on cases. These include: changing status, changing severity, and changing ownership. Incident closure notes can be written down and applied to all cases selected upon closure to avoid repetitive tasks.
Customer Requirement: The case management system should automatically generate a report containing the summary, actions taken, and related artifacts.
Any case within Smart SOAR can be exported as a standalone report. This report includes an executive summary, completed tasks, artifacts, and more. For MSSPs, this report can be white-labeled and shared with your clients.
User Management and Collaboration
Customer Requirement: The case management system should have role-based access control.
All users with Smart SOAR are assigned roles and groups. These roles have specific permissions and access to incidents can be assigned based on role or group. As an example, the user with the following permissions will be able to view any cases assigned to their group but will not be able to edit them.
Customer Requirement: The case management system should have the ability to have multiple users assigned to a case.
Although there will always be one owner of a case in Smart SOAR, multiple investigators can be added at any point. Further, their access to specific pending tasks and playbook results can be limited to Edit or Read-Only permissions.
Customer Requirement: The case management system should allow sharing info with external parties.
Smart SOAR is the only SOAR tool with a secondary investigation dashboard for external parties. This is typically used by Managed Security Service Providers (MSSPs) who need to send specific cases to their clients for review and response. Users with the Client role will be able to log into this investigation dashboard and review cases assigned to them.
Searchability and Data Storage
Customer Requirement: The cases should be queryable via API for use in external reporting and analytics software.
All commands within Smart SOAR can be executed via API. The command Search Incident is built specifically for this purpose. Users can call this command to retrieve a list of cases that match their search criteria.
Customer Requirement: Cases should be stored for 60-90 days.
Within Smart SOAR, the default retention period for cases is 90 days.
Customer Requirement: The case management system should have an indexable and searchable artifact storage.
All artifacts are searchable within Smart SOAR. In the below example, they are organized by type and sorted by descending number of cases in which they are seen.
Conclusion
Mature security teams are finding themselves with multiple alert queues, and each tool with a unique approach to case management. By centralizing those alerts inside of Smart SOAR, analysts and incident responders only need to understand one case structure and can rely on automation behind the scenes to keep all alert queues in sync.
Smart SOAR’s case management capabilities are robust and continually expanding. They are complemented with built-in reporting and analytics and a two-tiered automation design to offer a holistic incident response solution.
