Limit access to investigations using access control - Administrator Guide - 8.5 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR On-prem Documentation
Product
Cortex XSOAR
Version
8.5
Creation date
2024-03-10
Last date published
2024-11-28
Category
Administrator Guide
Solution
On-prem
Abstract

Limit access to incidents and investigations in Cortex XSOAR.

In any SOC team, there are various roles and responsibilities. For example, you may have specific teams to deal with threats, such as threat intelligence researchers, security analysts (Tier 1), senior analysts (Tier 2), SOC leads, SOC managers, and SIEM engineers. Administrators can exclude access to incident actions and investigations using role-based permissions. For example, you may want to limit the ability to change the incident status or manage the Work Plan. For more information, see Role-based permissions.

You can limit access to investigations, by doing the following:

  • Restrict an investigation

  • Limit investigations according to specific user roles

  • Give read-only access to certain user roles

Restrict an investigation

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

Restrict an incident 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. 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.

  1. Go to the Incidents page and select the incident you want to restrict.

  2. Select Actions → Restrict incident.

    To remove the restriction select Actions → Permit incident.

    Confirmation appears in the War Room.

    Note

    If using the CLI, run the /invesitgation_restrict id=<id number> or the /invesitgation_permit id=<id number> command.

Limit access to investigations according to specific roles

When you add a role to the incident, 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 XSOAR Read Only Roles field).

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.

  • 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.

  1. On the Incident page, open the incident to restrict access.

  2. Do one of the following:

    • If the Roles field is added to the incident layout, select the relevant role.

    • In the CLI, run !setIncident roles =<name of role> to set the role.

      You can also run the /incident_set command roles <name of role>, which has the same effect.

    The War Room entry confirms that the role has been updated.

Note

When you create or edit an incident, you can select the required Role.

You can add this field to the incidents table on the Incidents page (you can't add roles in the table).

Give access to Read-only roles

You can add a Read-only role to the incident, which restricts access to the incident. When granting read-only access, the user can view the incident but not edit it. 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.

Adding a team member overrides this restriction, 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.

  1. On the Incident page, open the incident to restrict access.

  2. Do one of the following:

    • If the XSOAR Read Only Roles field is added to the incident layout, select the relevant role.

    • In the CLI, you run !setIncident xsoarReadOnlyRoles=<name of role> to set the read-only role.

    The War Room entry confirms that the role has been updated.

Note

If added to the opening incident form, when editing or creating an incident, you can select the reqiuired XSOAR Read Only Roles.

You can add this field to the incidents table on the Incidents page (you can't add roles in the table).