Users and roles

A role is a named set of permissions. Every user has one role. An admin decides what each role can do by ticking boxes on the Roles page. CICADA comes with three roles, and you can change them or add your own.

The Roles page

Open Settings > Roles. The page is a grid.

• The permissions run down the left side. They are in ten groups: Investigations, Evidence, Response actions, Playbooks, Sources, Reports, Assistant, Threat intel, API and Administration.
• Each role has one column of tick boxes. A tick means people in that role have that permission.
• Use the search box to find a permission by name or description. Click a group name to fold it away or open it again.
• A permission that your licence does not include is greyed out and marked Not in your licence. You can still tick it. It does nothing until the licence covers it.
• Anyone who has the Manage users permission can open the Roles page, but only to look. Only people with Edit roles can change it. Nobody has Edit roles except Admin.

Buttons that a person cannot use are hidden for them. Someone without Approve or deny actions does not see Approve or Deny. Someone without Execute actions on customer systems does not see Execute.

Built-in roles and their defaults

CICADA has three built-in roles.

• Analyst investigates. It can look at and work on investigations, upload and download evidence, recommend response actions, run playbooks, generate reports, use the assistant, look up indicators and create personal access tokens.
• IR lead has everything Analyst has. It can also approve, deny and execute response actions, manage sources and run collection, clear indicators, place a legal hold, export the evidence package, delete evidence files, edit the case narrative, and choose threat intel providers for an investigation.
• Admin has every permission, including all of the Administration group. Admin cannot be edited or deleted. You can rename it.

The table shows the starting ticks for all 41 permissions. An admin can change the Analyst and IR lead ticks at any time. When a later release adds a permission, Admin gets it automatically.

Four permissions can never be given to any role except Admin: Edit roles, Manage SSO, Back up and restore and Set the MFA policy. They cannot be ticked for any other role.

Creating and editing roles

You need the Edit roles permission, which only Admin has.

• Create a role. Press New role. The form has Name, Description and Start with the permissions of, which is set to No permissions until you pick a role to copy. Press Create role, then tick the permissions.
• Rename, reorder, duplicate and delete. Each column name has an Actions menu with Rename or describe, Move left, Move right, Duplicate (which makes a role called "<name> copy") and Delete. Any role can be renamed, including Analyst and IR lead. Admin's menu has only Rename, so you cannot move, duplicate or delete Admin. See role order. Admin always stays furthest right.
• Change permissions. Tick or untick boxes in the role's column. You cannot change Admin's.

A role that is still in use cannot be deleted. A role is in use when any of these is true: users have it, an SSO role mapping or an SSO default points at it, the MFA policy names it, or it is the default role for new users. Move those to another role first, then delete.

Saving

• When you tick boxes, a bar at the bottom lists the changes for each role. Press Save changes, then Save to confirm, or Discard.
• While you have unsaved ticks, New role, the Actions menus and the default-role list are greyed out until you save or discard.
• If you leave the page with unsaved ticks, CICADA or your browser asks you to confirm.
• If another admin changed one of the same roles after you opened the page, your save is refused and nothing is saved. Reload to see their changes.
• The server applies the change on the user's next action. Nobody is signed out. Buttons they newly have appear after they reload the page.

Default role for new users

Choose it on the Roles page. It cannot be Admin. CICADA gives it to a new local user unless you pick a different role when you create that user. It is also the role given to a person who arrives through Cloudflare Access for the first time.

Delegating user management

You can give Manage users to a role other than Admin. A help-desk role is a common example. Tick the permission in that role's column.

Someone who has Manage users but is not an admin is limited in five ways.

• They can only give out roles whose permissions they already have themselves.
• They can only act on users whose role they cover, which means a role whose permissions they all have.
• They can never change an admin account.
• They cannot link any account to SSO or unlink it.
• For an account that signs in with SSO, they cannot reset its password or turn off its MFA.

These limits stop a help-desk role from making itself, or anyone else, more powerful than it is.

SSO roles and sign-in

• Under Settings > Security > Single sign-on you map identity provider groups to roles. You can map a group to a role from the Roles page, including roles you created. Setting up SSO needs Manage SSO, which only Admin has. See single sign-on.
• When a person matches more than one mapped group, the role furthest right on the Roles page wins. See role order. A person who matches no group gets the provider's default role.
• An account linked to SSO signs in through the identity provider only. It cannot use a local password. The one exception is the appliance's emergency admin account, which exists for recovery from the console.
• CICADA refuses to link the last admin who can sign in with a password. That keeps one admin who can still get in if SSO stops working.

Role order

The order of the columns on the Roles page matters. Furthest right counts as the highest. Admin is always furthest right.

• For SSO, the highest of a person's matching roles is the one they get.
• The MFA policy under Settings > Security > MFA policy uses the same order. Its choices are Voluntary (no forced enrolment), Required for Admin only, and Required for [role] and every role above it. If you choose Required for IR lead and every role above it, IR lead and every role to the right of it, including Admin, must use MFA. To require MFA for everyone, choose the role furthest left. Changing the policy needs Set the MFA policy, which only Admin has.
• Moving a role changes who is covered by that MFA rule, so check the policy after you reorder.

What changed after the update

On an existing appliance, Analyst and IR lead start with the ticks shown in the table above. They match what each role could do before, with these differences.

• Analysts can no longer delete evidence files, including PCAPs. IR lead and Admin still can.
• Analysts and IR leads can no longer read the appliance configuration: LLM providers, security, TLS and backup settings. The application never showed these pages to Analysts or IR leads, so nothing a person used has gone.
• Users who are linked to SSO but used to sign in with a password must now use SSO. Tell them before you upgrade.

An admin can tick either permission back on for a role on the Roles page: Delete evidence files, including PCAPs and View appliance settings.

Next

• Multi-factor authentication
• Single sign-on
• Back to the onboarding overview