Roles and Permissions

UTMStack v12 controls what each user can do with roles. A role is a named set of permissions, and a user can hold several roles. UTMStack ships three built-in roles, and you can create your own. This page lists every permission and what each built-in role includes.

Where to manage roles

Go to Configure > Team and open the Roles & permissions tab. The tab lists every role with its number of permissions and modules, and a Permission matrix that shows what each role can do, module by module.

To give a role to a user, see Users.

Built-in roles

The three built-in roles are the same in every tenant. They are marked System and cannot be edited or deleted.

What this means in practice:

• Analysts cannot change users, roles, settings, identity providers, correlation rules, pipelines, integrations, data sources, compliance or retention.

• Analysts can run commands on agent hosts through the Interactive Console, because it uses soar.write. They cannot start a response flow by hand: that needs soar.execute, which only the Administrator role has.

• The SOC-AI assistant and its Ask buttons appear in the interface only for users who hold socai.write, which among the built-in roles only Administrator has. See AI Providers.

Things that need the Administrator role itself

A few things are tied to the Administrator role, not to a permission. A custom role with the same permissions does not give them.

• The Configure menu (Data Sources, Integrations, Alerting Rules, Pipelines, Data Processing, Team and Settings) is shown only to users with the Administrator role.

• Viewing and regenerating the Connection Key.

• Setting Support access for a customer tenant (see Support Access).

• Operator-only pages and actions (the licence, data retention, the ThreatWinds switches, tenants) need the Administrator role in the default tenant. See Settings Overview.

All permissions

A check mark means the built-in role has the permission.

Permissions marked "instance operator only" work only for a user with the Administrator role in the default tenant, whatever roles they hold.

Create a custom role

1. 1

   Start a new role

   Go to Configure > Team, open Roles & permissions and click New role.

2. 2

   Name the role

   Field	What to enter
   Identifier	A unique name used in the API, 2 to 50 characters. It starts as ROLE_; complete it, for example ROLE_AUDITOR.
   Display name	The name people see, for example Auditor
   Description	What the role is for

3. 3

   Choose the permissions

   Under Permissions, tick the permissions the role needs. Use all to select every permission of a module.

4. 4

   Save

   Click Save role, then give the role to users on the Members tab.

To change a custom role, click Edit on it. To remove it, click Delete. Users who hold only that role are left without access to any module.

Custom roles belong to the tenant they were created in. You see "Role created", "Role updated" or "Role deleted"; "role name is already in use" means the identifier is taken, and "System roles cannot be modified" appears if you try to change a built-in role, and also when your own roles lack roles.write.

Which permissions each screen needs

Apart from a few places (the SOC-AI assistant, identity alias actions in the User Auditor and some integration controls), the interface does not hide buttons by permission. A user who lacks a write permission usually still sees the button, and gets "You do not have permission to do that" or a similar error when using it. Use this table to give each role what its screens need.

Pages a custom role reaches by address

Users without the Administrator role do not see the Configure menu, even when their role allows the pages in it. They can open those pages by typing the address, and the permissions in the table above still apply:

Replace siem.example.com with your UTMStack address. Bookmarks help these users.

Example custom roles

These examples show how to combine permissions for common jobs. Adjust them to your organization.

SOC tier 1 analyst

Triages alerts and works incidents, but cannot run commands on endpoints or change flows.

alerts.read, alerts.write, incidents.read, incidents.write, loganalyzer.read, loganalyzer.write, dashboards.read, notifications.read, notifications.write, soar.read, threatintel.read, adaudit.read, datasources.read

Compared with the built-in Analyst, this role cannot use the Interactive Console or edit dashboards.

Incident responder

Everything a tier 1 analyst can do, plus containment.

The tier 1 permissions, plus soar.write (create and change flows, run commands on agents through the Interactive Console) and soar.execute (run flows by hand).

The Interactive Console asks for the user's own UTMStack password before it runs commands. Users whose accounts were created by single sign-on have no UTMStack password, so give responders accounts with a local password if they need the console.

Detection engineer

Writes and tests correlation rules and parsing pipelines.

eventprocessing.read, eventprocessing.write, loganalyzer.read, loganalyzer.write, alerts.read, datasources.read, integrations.read, dashboards.read, dashboards.write

Users with this role open Alerting Rules and Pipelines by address (see above).

Compliance auditor

Reads compliance results and the audit trail, changes nothing.

compliance.read, audit.read, dashboards.read, loganalyzer.read, alerts.read, incidents.read

Users with this role open App Audit Logs by address.

Tips for designing roles

• Give people the smallest role that lets them do their work. Start from Viewer and add permissions as needed.

• Treat users.write and roles.write as administrator rights: anyone who can create roles and assign them can give themselves any permission.

• soar.write lets the holder run commands on agent hosts through the Interactive Console. Give it only to people you trust with that access.

• Changes to a user's roles reach their open sessions within one hour, when their sign-in renews.