Architecture
The SOAR integration server must be able to access the SOAR Platform and the hosts of the third-party applications that are integrated with the SOAR Platform. The SOAR Platform can reside in your own environment (known as an on-premises configuration) or within the IBM® cloud (also known as a SaaS configuration).
More specifically, the integration server communicates to a specific organization within the SOAR Platform. A SOAR organization is a self-contained area within the SOAR Platform for managing incidents.
Standard Deployment
In a standard configuration, there is typically a single SOAR organization for all incidents. There may be multiple organizations for separate business divisions, as well as one organization for development and test and another for production. However, each organization is managed separately and users within a SOAR organization cannot view another organization.
The following network diagram is an example of an integration server used for python-based apps and a SOAR Platform in a cloud configuration. Users access the platform from their web browsers.
SOAR platform with MSSP add-on
The SOAR Managed Security Service Provider (MSSP) add-on is an optional feature that allows you to manage multiple SOAR child organizations from a single configuration organization. Each child organization can be assigned to a different group, division, or company to meet their incident response requirements.
If deploying apps to a SOAR Platform with the MSSP add-on, you need to deploy the app to the configuration organization using the Resilient® Circuits customize command, as you would in the standard deployment. The difference is that you do not deploy an app to any child organization; instead, the system administrator pushes the app to the child organizations. You then create a separate integration server for each child organization to run the app in the child organization.
You still need to install the app package using the normal pip install command on each integration server whose child organization uses that package. And you need to configure the app.config file on each integration server.
On-premises SOAR platform
If you have a SOAR Platform in your environment, the integration server can be the same system as the one hosting the SOAR Platform.
However, IBM Security® recommends that you keep them on separate systems for the following reasons:
- Security
- Although all apps from the Community App Exchange are code-scanned and tested, it is a security measure to not allow apps access to the command line of the SOAR Platform host.
- Performance
- Although the apps are resource efficient, running them on the SOAR host might impact the available resources, especially if your apps are heavily using in-memory processing.
- Access
- The administrator of the integration server maintains, installs, and configures apps. This administrator does not necessarily require access to the SOAR Platform.
Supported app types
- Python-based and in the extension format (.tar.gz file). The SOAR Platform can be in an on-premises or cloud configuration.
- Java™-based custom actions. The SOAR Platform can be in an on-premises or cloud configuration.
- Custom threat services. The SOAR Platform must be on-premises.
There are also apps in the form of plug-ins, such as for Splunk and QRadar®, which escalate incidents to the SOAR Platform using the REST APIs. You do not need an integration server for these plug-ins.
If you have a package in a .res format, this means it contain components, such as scripts, workflows, and custom fields. You import these components into your SOAR Platform using the import feature described in the System Administrator Guide.