User permissions

Permissions on the Intelligence Center are granular controls on user access
to features and data. They're predefined,
and assigned to users through roles.

Permissions are usually named with the convention <verb> <object>, where:

• <verb> describes the action allowed, and
• <object> describes the object being acted on.

To see a full list of permissions:

• make a GET /permissions request,
• or sign in on the Intelligence Center and
  go to Settings > User management > Permissions

The table of permissions below
covers permissions as they are applied in the Intelligence Center.

Control access through groups, roles, and permissions

What a user is allowed to access is determined by a combination of:

• Groups

  Groups are used to organize users and
  defines the resources that its members are allowed to access.

• Roles

  Roles are sets of permissions that determine the tasks a user assigned that role can perform.

The following flow chart is an example of
how to decide what to assign to your user
to give a certain level of access:

Groups

Groups allow you to name the resources
it's members are allowed to access.

You can set for a group:

• Allowed sources
• Allowed roles

Allowed sources

Allowed sources are sources that
members of the group can access data from.

An allowed source has two properties:

• the source
• a TLP color

Sources can be:

• Groups. By default, a group has itself as an allowed source. You can add other groups as allowed sources to give group members access to intelligence created by members of that group.
• Incoming feeds. Entities and observables that are ingested through an incoming feed have their source automatically set to the name of the incoming feed.
• Enrichers. When an observable or entity is enriched, the resulting entities and observables have their source set to the name of the enricher used.

TLP colors set for a source determines the most restrictive TLP (inclusive) that that members of this group can access. By default, this is set to RED for a source. This means that group members can access objects with TLP colors WHITE, GREEN, AMBER, and RED.

✅

Setting an allowed source's to a less restrictive TLP color would prevent group members from accessinng objects with more restrictive TLP colors. For example, setting the TLP color for an allowed source to GREEN would mean that objects with TLP colors AMBER and RED cannot be accessed by group members.

Allowed roles

Groups must specify a set of roles that group members can be assigned to.

Setting allowed roles for a group does not actually assign the role to group members. You must first add roles to the allowed roles of a group, then explicitly assign those roles to the user.

Roles

Roles are sets of permissions that grant read
or modify access to a given resource.

✅

modify permissions grant both read and modify permissions
for a resource.

A role can contain any number of permissions. Users inherit their permissions from the roles that they are assigned.

Table of permissions

The following table describes permissions as
they are applied in the Intelligence Center.

Permissions required for each endpoint is documented in the API reference.

✅

All -modify permissions already
include -read level permissions.

For example, modify users permissions
include read users permissions,
so you can assign a user modify users
without read users.

📔

Permission dependencies

Some permissions depend on other permissions.

For example, a user must first have read-tickets permissions in order to be able to read task comments with read ticket-comments permisisons.