Overview of the IBM Security QRadar SOAR
The SOAR Platform orchestrates and automates the people, processes, and technology that is associated with incident response. These SOAR Platform solutions streamline incident and privacy response management to provide an automatic, fast, and flexible way for organizations to react to events and incidents. It is available for cloud or on-premises environments based on your business needs,
You can integrate the SOAR Platform into your environment so that it automatically shares data with other tools. You can even automate actions that are run by the other tools, such as a search of impacted systems when a malware incident is recorded.
The following image shows how the SOAR Platform can be integrated into a security environment:
User roles and personas for the SOAR Platform
There are five general user roles for the SOAR Platform: site manager, SOAR administrator, playbook designer, incident management team, and and app developers. While there can be overlap between these roles, the roles are distinct for the purposes of defining the functions of the SOAR Platform.
| User role | Area of responsibility |
|---|---|
| Site manager (Applies to on-premises installations only.) |
Responsible for installing and maintaining the SOAR Platform environment, and for verifying that all system and network prerequisites are met. |
| System administrator |
Responsible for configuring and maintaining the administrative portion of the SOAR organization. The role is an IT administrator, responsible for managing users and user permissions, authentication methods, IP blocks, and downloading and installing apps. When multiple SOAR organizations exist, the system administrator also manages configuration imports and exports. |
| Playbook designer |
Responsible for designing, implementing, and maintaining the rules, conditions, workflows, and incident layouts that control the flow of responses to incidents. An advanced playbook designer is knowledgeable with the Python language and can write scripts to help with advanced incident response. The designer determines which apps, if any, are needed to extend the capabilities of the SOAR Platform. |
| Incident management team |
Responsible for case management, also known as incident response, such as responding to assigned tasks, monitoring incidents, and analyzing statistics. |
| App developer | Responsible for writing SOAR Platform apps to access and return external data, interact or integrate with other security systems, and for writing utilities that run a specific action. |
Use cases and benefits of SOAR
The SOAR Platform is customizable and can be tailored to meet several use cases.
- Monitoring and Escalation. The SOAR Platform allows incidents, including relevant data, to be entered by users or systems that are integrated with the SOAR Platform. You can then monitor the status from the start to the resolution of the incident. Data can include artifacts such as IP addresses, file hashes, URLs, user names, and system names. All data is associated with an incident.
- Identification and Enrichment. Automatic threat intelligence lookups, workflows, and menu-driven actions can deliver valuable context and reduce time to identify scope and impact, which enables a rapid, decisive response. Trigger sandbox evaluation and build rules to act on the results. Search logs and endpoints and make decisions based on the data. Include CMDB and directory information to help analysts make accurate assessment of severity and impact. Pivot on these critical data elements to dynamically adjust the way that your team responds. Several cyberthreat sources are integrated into the product, and you can integrate your own threat services.
- Containment, Response, and Recovery. Based on trigger conditions, or based on manual actions, the system can send notifications or initiate external activities to contain and adjust your security posture as a part of your response playbook.
- Communication and Coordination. Includes use of custom actions, functions, and the REST API to integrate bidirectionally with your environment, including ticketing and service management, smart notifications, communication platforms, and other business applications. By integrating beyond the SOC, users can coordinate a fast and effective incident resolution from the platform.
Incidents and objects in SOAR
An incident is an event in which data or a system might be compromised.
The SOAR Platform allows users or systems that are integrated with the SOAR Platform to create incidents. You can then act on the incident and monitor its status from the start to the resolution.
The SOAR Platform uses objects to classify types of data. You select an object type when you create a rule, script, or workflow. The object type specifies which type of data you want to act on.
- Task. A unit of work to be accomplished by a user, device, or process. The SOAR Platform handles some tasks automatically. Members of the incident response team can be assigned tasks to accomplish manually and mark them as complete when done. Incident owners can track the progress of the various tasks.
- Note. Text added to an incident or task for clarification or additional information.
- Attachment. A file that is uploaded and attached to an incident or task.
- Artifact. Data that supports or relates to the incident. The SOAR Platform organizes artifacts by type, such as file name, MAC address, suspicious URL, MD5 and SHA1 file hashes, and more. An artifact can also have an attachment, such as an email, log file, or malware sample.
- Milestone. A date for an important event within the incident timeline.
- Data Table. Field values organized in a tabular format.
- Email Message. An email message sent to the SOAR Platform for analysis.
The task object can also have notes and attachments as child objects.
How SOAR playbooks are used
You use a SOAR playbook to define the response to incoming and changing events.
A customization is a tool within the playbook toolkit that can act upon, supplement or contain data. Customizations include functions, message destinations, tasks, notes, artifacts, and scripts.
- Playbook designer. A graphic-based tool that you use to define the conditions to trigger the playbook, and organize various customizations into a comprehensive set of actions.
- Rules and workflows, formerly referred to as dynamic playbooks. Use rules to define the conditions to trigger the playbook and the subsequent activities. Workflows are a graphically designed set of activities you use to create a complex set of actions by using various customizations.
The Playbook designer provides the ability to graphically design your conditions and subsequent activities. It uses all of the customizations in the playbook toolkit except rules and workflows, as it incorporates the capabilities of each.
Rules and workflows provide more flexibility in addressing use cases. You can define more advanced conditions. Workflows are triggered by rules. You can graphically design your activities by using customizations in the toolkit. Unlike the Playbook designer, playbooks that are built with rules and workflows are not shown graphically in the user interface.
Ideally, you design your playbook by using Playbook designer when possible, and use rules and workflows to address use cases not supported by the Playbook designer.
You build multiple playbooks for different scenarios. One playbook can trigger another playbook if the result of the first playbook matches the condition set by the second playbook.
Customization tools in playbooks
A customization is a tool in the playbook toolkit that can act on, supplement, or contain data. Customizations include functions, message destinations, tasks, notes, artifacts, and scripts.
- Incident Types. You can classify the various types of incidents your team addresses.
- Phases. Defines each stage of an incident response, essentially capturing the general intent of the response action.
- Tasks. Defines all the tasks that might need to be acted on by users, such as an analyst or incident responder. Tasks can be in the form of a set of instructions or advisories or an action that a responder selects.
- Layouts. Layouts visually present the incident.
- Fields and Data Tables. Fields capture data points for analysis review and to produce metrics. Data tables capture and organize field values in a spreadsheet table format.
- Scripts. You can implement more complex business logic by using Python. Scripts can be triggered by playbooks, rules, or workflows.
- Functions. An object that sends data to a remote function processor through a message destination. The function processor runs an activity then returns the results.
- Workflows. Graphically designed set of activities you use to create a complex set of operations.
- Rules. Define a set of activities that are triggered when conditions are met. An activity is an operation that the rule runs when the appropriate conditions are satisfied.
- Simulations. Hypothetical circumstances that can help your team to understand the impact of data loss situations and rehearse the response process. You can use simulations to create incidents for testing to see how each component of your playbook responds.
SOAR Breach response add-on and privacy
The SOAR Breach response add-on contains the privacy database and the breach notification rules. It generates data breach compliance tasks in incident task lists.
- Breach notification statutes (laws that are passed by a legislature and signed into law)
- Regulations (laws made by agencies)
- Trade organization bulletins
- Guidance documents, including penalties where applicable
If your organization does not subscribe to the SOAR Breach response add-on, you can still configure breach settings but breach-related tasks are not generated within a playbook.
SOAR organizations and MSSP
A SOAR organization is a self-contained area in the SOAR Platform for managing incidents.
A SOAR organization is a self-contained area within the SOAR Platform for managing incidents.
In a standard configuration, you can use a single SOAR organization for all your incidents. You can also have multiple organizations for separate business divisions, and one organization for development and test and another for production. Each organization is managed separately and users within a SOAR organization cannot view another organization. A user can be a member of multiple organizations but must log in to each one separately.
The Managed Security Service Providers (MSSP) add-on option, licensed separately, can manage multiple child organizations from a single global dashboard. Each child organization can be assigned to a different group, division, or company to meet their incident response requirements. A single global dashboard organization allows security analysts to analyze incident data from all the child organizations. Users within a child organization cannot view the other organizations. Users in the global dashboard organization can view and manage incidents from the organizations to which they have permissions.
SOAR apps and App Host
An app, formerly called extension or integration, is a collection of playbook components, code, or both that represent an end-to-end function and is deployed to the SOAR Platform.
Playbook components can include rules, workflows, Python scripts, custom fields, data tables, and message destinations. A code program can access and return external data, interact or integrate with other security systems, or be a utility that runs a specific action.
The app is available in two formats. One format supports the App Host Kubernetes-based container environments. The other format supports the previously available extension format, which requires an integration server. An integration server is the system that you use to deploy apps in the extension format to the SOAR Platform.
Apps are also available in the form of plug-ins that escalate incidents to the SOAR Platform and use the REST API directly. You do not need an App Host or integration server for these plug-ins.
You can download and install container-based apps directly from the SOAR Platform Apps tab, as described in the Apps section of the System Administrator Guide. You use an integration server to deploy extension-based apps, as described in the Integration Server Guide.
You can view a wide variety of apps available on the IBM App Exchange. The apps that you use depend on your use case and your specific security systems.