Incident Access Control Configuration

Configure incident access control in Cortex XSOAR 6.12.

In any SOC team there are a number of different roles and responsibilities. For example, you have specific teams to deal with specific threats, such as threat intelligence researchers, security analysts (Tier 1), senior analysts (Tier 2), SOC leads, SOC manager, SIEM engineers, etc. After you start ingesting incidents into Cortex XSOAR, you should consider how you want to investigate the incidents that are being ingested. You have various options to limit access to incidents and investigations.

Note

If no role is set for the incident, all users with read/write permissions for incidents can access and edit the incident. In order to access an incident, you must be assigned the same role that is assigned to the incident, even if you are the creator of the incident.

• Exclude access to incident actions and investigations according to roles, such as SIEM engineers. This enables you to limit role permission levels in investigations, data and chats in the War Room and restrict batch table actions in the Incidents page.
• Restrict an Investigation to only team members. For example, if an incident contains sensitive data, and you only want specific users to investigate the incident, you can mark the incident as restricted. Other users cannot view or access the incident. Team members are added automatically when you send them a notification in the CLI or add them from the gear button. You can remove the restricted investigation at any time.

  Note

  When an incident is restricted with a read-only role, existing team members automatically get read-only access. Their permissions are adjusted, allowing them to continue viewing the incident, though they will not have write permissions.
• Limit Access to Investigations using RBAC.

  • Limit investigations according to specific roles. By adding a role to the investigation, you restrict access to all roles, other than those you have specifically added. For example, after an investigation is closed, add administrators or those with specialty roles, so only they can reopen or link incidents.

    The added roles have read and write permission, but all other roles do not have access (unless you have added them in the read-only field).

    You can limit the investigation by either adding a role in the Roles field to the Incident Summary page, use the incident_set roles command, or run the command in a playbook. If using the Roles field in the Incident Summary page, you need to add the field when you Customize Incident Layouts.

    Note

    If you add a role, but the incident has been restricted to team members, and the user is not a team member, the user cannot access the incident regardless of the role. For example, if you restrict the incident to User A and User B team members who are Tier 1 analysts but then try to add Tier 2 analysts (none of whom are team members) to the list of roles, a Tier 2 analyst cannot access the incident.
  • Give read-only access to certain roles. For example, when an incident is in triage (phase 1), you may want all Tier-2 analysts to have read-only access, so that Tier-1 can edit the incident. When the phase changes to phase 2, Tier-1 has read-only access.

    You add roles in the XSOAR Read-Only field in the Incident Summary page, use the incident_set roles command, or add the command to a playbook.

    If using the XSOAR Read-Only field in the Incident Summary page, you need to add the field when customizing incident layouts. You can change the XSOAR Read-Only field manually or automate the process by creating a custom incident field using incident field trigger scripts, or create a script and adding a new field button.

    When granting read-only access, the user can view the incident but not edit. Adding a team member overrides the XSOAR read only role, so if you add User A, (Tier 1) as a team member, even if you assign Tier-1 as a Read only role, the user still has Read/Write access. You need to remove the user as a Team Member.

    Note

    If you assign a role (read and write permission) and assign the same role as read only, the user still has read/write permission. You need to remove the assigned role. If you restrict the incident, the read-only role does not override the restriction. In other words, team members permission takes precedence.

Limit Access to Investigations using RBAC

You can limit access to the investigations using RBAC by either assigning a specific role to the incident (read and write access to the investigation) or by assigning a role with read only permission. This procedure uses the incident_set command to limit investigation permissions but you can also add the Role and XSOAR Read Only rules fields to the Incident Summary page when customizing incident layouts. You can also add these columns to the Incidents table in the Incidents page.

1. In the Incident page, select the incident you want to restrict access.
2. Restrict the incident to a role.

   1. In the CLI, type the following command:

      /incident_set roles=<select role>
   2. To check that the role was assigned to the incident, click the War Room tab.
3. Restrict the incident to a read-only role.

   1. In the CLI, type the following command:

      !setIncident xsoarReadOnlyRoles=<select role>
   2. To check that the role was assigned to the incident, click the War Room tab.
4. (Optional) For automations:

   • Use the setIncident command in a playbook.
   • Specify the roles that you want to have access to the incident investigation.

Restrict an Investigation

You can restrict an investigation to the incident owner and the team associated with the investigation.

1. Do one of the following:

   • Open the incident and select Actions → Restrict incident.

     To remove the restriction select Actions → Permit incident.
   • In the CLI, type /investigation_restrict id=`` ``id_ number
2. (Optional) For Automation do the following:

   • Use the restrictInvestigation command in a playbook.
   • Specify the incident ID of the incident for which you want to restrict access.
   • Set the Restrict argument to True to restrict the incident.
   • Set the Restrict argument to False to remove restricted from the incident.