SOAR platform organization settings
The Organization tab provides the details for your organization. You can define various settings, such as attachment and, if enabled, LDAP and two factor authentication. If enabled, you can also export and import various fields and customized settings.
SOAR platform organization details
The organization details for your organization are defined when IBM Security initializes your organization. To change this information contact IBM Security at https://ibm.com/mysupport.
Configuring SOAR organization settings
To open the Organization Settings window, select the drop-down menu under your user account name, and click .
The following table shows the organization settings that you can configure.
Setting | Description |
---|---|
Session Timeout |
Specifies the time, in minutes, that a session is allowed to be idle before it is logged out automatically. Users receive a warning before they are logged out. The time that the warning is sent is equal to 20% of the timeout setting. For example, if the session timeout is 5 minutes then the user receives a warning 1 minute before. |
Download Link Expiry |
Specifies the time, in days, to keep a generated download available on the Activity Dashboard page. For example, a download link might download a report. |
Incident Sequence Code Changed in 50.0 |
Determines the prefix that is used with the Sequence Code incident field. The field includes a prefix and index that increments for each new incident that is created within the organization. You can edit the prefix but not the index. Changes to the prefix are applied only to new incidents. If you are managing multiple organizations, you must use different prefixes for each organization to differentiate the incidents in reports. You cannot assign a prefix to an organization if it is already used by another organization. If you are using the MSSP add-on feature, this setting is not available in the Configuration or Global dashboard organizations. For new deployments of SOAR Platform incident sequence codes are disabled by default. If you upgraded to SOAR Platform V50, incident sequences codes remain enabled by default. Enabling or disabling the incident sequence codes applies to all organizations in your SOAR Platform deployment. Use the
resutil command to enable incident sequence codes, as
follows:
To disable incident sequence codes, use the following
command:
|
Attachments |
Controls whether users can upload attachments to the system. To allow files to be attached to incidents and tasks for your organization, switch the indicator to On. Consult your specific agreement for details on the limit to the amount of data that can be stored. |
Default Tasks |
When tasks are created, you can set them to be public or private by default, meaning that nonadministrative users need specific permission to view them. When set to Off, all tasks are created as public by default. Switch the indicator to On if you prefer to have tasks default to private. |
Final Phase required to close incidents |
Enable this setting to require that all incidents must be in its final phase before it can be closed. To be in the final phase, an incident must have all mandatory tasks in previous phases marked complete. When users attempt to close an incident before it is in the final phase, an error message is displayed. When this setting is set to Off, users can close an incident in any phase. |
Display date/time in UTC |
When enabled, all the time fields on the user interface are shown in Coordinated Universal Time
and the fields display a If this setting is not enabled, all time fields are displayed in local time. |
Incident Deletion |
When enabled, users with the Delete incident permission can delete incidents and simulations. Deleting an incident does not generate news feed or system notifications, although users might receive an email notification. When a user deletes an incident, the incident’s attachments, such as tasks and artifacts, are deleted, and all mention of the incident is removed from the news feed and system notifications. The SOAR Platform logs all deletions. |
LDAP Authentication |
If available, you can enable LDAP authentication to allow LDAP users to authenticate with their LDAP credentials. For more information, see LDAP authentication for SOAR. LDAP authentication is available only for an on-premises configuration. |
Two Factor Authentication |
If available, you can enable two-factor authentication to enhance your organization's security by adding a second layer of authentication to log in to the SOAR Platform. You select an authentication domain (if there is more than one), and determine the Cookie Lifetime. The setting determines the expiration, in days, for when a user needs to re-authenticate by using the two-factor authentication. Note: If you are a SaaS customer and two-factor authentication settings
are not available, contact IBM® Support to enable it.
For on-premises customers, you can enable it using the instructions in the Installation Guide. |
Migrating SOAR settings
Use the Migrate Settings capability to import and export settings from one organization to another. For example, when your test environment passes the acceptance criteria, you can export the organization settings from the test environment to production.
The Migrate Settings are available on the Administrator Settings window. You can run imports and exports, and you can also see the history of both actions.
Exports
When you export settings, the settings are stored in JSON format to a .resz file, which is a .res file within a .zip file.
Incident types, artifact types, fields, data table definitions, and roles are always included in the exported file, even when you choose not to include other settings. Some settings, such as users and LDAP groups, are not exported.
The Export History shows information about each of the previous exports, including a link to the export file that was created.
Settings | Description |
---|---|
Common Layouts |
Common layouts are layouts that are the same for all users in the organization. The following layouts are common: New Incident Wizard, Incident tab, and Close incident. Each organization can have only one layout for each type. Common layouts are automatically included in the export if you also include shared layouts. |
Shared Layouts |
Shared layouts are created by users and shared with the organization. They include layouts such as dashboards, report templates, and incident views, including preset filters and tab layouts. You can have an unlimited number of shared layouts within an organization. If you include shared layouts in your export, you must also include the common layouts. Note: This setting applies only to stand-alone organizations. In configuration and provider
organizations, you cannot export shared layouts.
|
Rules, Scripts, Destinations, Functions, Workflows, Playbooks and Case Matching Profiles |
If the organization has at least one installed app, you must include Rules, Scripts, Message Destinations, Functions, Workflows and Playbooks in the export settings. If you do not export these settings, the app might not function correctly when it is imported into another organization. |
Phases and Tasks |
Phases define each stage of the incident response, and each phase contains tasks that must be completed before the incident can progress to the next stage. Phases and tasks are automatically included in the export if you also include rules and workflows. |
Administrator Settings | The following settings are included when you export the Administrator
Settings.
|
Imports
Before you import, make sure that no users are currently logged in. In addition, make sure that all users referenced in any rule’s conditions exist in the recipient organization. If any do not exist, create them before you import.
You can include groups in the import, but you cannot import the users in a group. Importing and exporting users is not supported.
During an import, the following activities occur:
- All incident fields, types, and data table definitions are updated.
- Non-unique task names are reconciled.
Task names are not unique even within the same incident type. To mitigate non-unique task names, the SOAR Platform attempts to match tasks that use a unique ID, and then attempts to match by using the name and type. If only one attribute matches, the system overwrites the task. If more than one attribute matches, the system creates a new task and displays a warning.
- The message destination and type are checked.
Message destinations are not overwritten unless both the name and type match.
- The user list for message destinations is ignored.
For an updated message destination, the system ignores the updated user list and keeps the original user list intact. The user list is empty for a new message destination.
- Checks for rules that have a condition that refers to incident members.
For example, the system checks for a rule that is initiated only when the incident member list contains a specific user. In this case, the user is retained if the imported condition contains an exact match of the user. If it is not an exact match, a message is displayed that indicates the user was removed from the condition.
The Import History shows the changes between the existing settings and the imported settings, such as incident fields, layouts, and custom rules. The import does not delete items; therefore, the View page provides a list of items that are no longer used, which you can then remove manually.
You can import settings from the same version or previous major version of the SOAR Platform. For example, you can import settings from SOAR Platform 45.x into 46.x. Importing from earlier releases of the SOAR Platform, such as V44, is not supported.
If you import from a SOAR Platform that is configured for a different language, as determined by the locale setting, the imported language setting overwrites the existing language setting.