Limit access to incidents and investigations in Cortex XSOAR, using role-based access control (RBAC).
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
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
All team members have read and write permissions. If you add team members, but their roles have read-only permission, the user still has read and write permission and can access the investigation.
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.