The Authorization Policy

The authorization policy is the set of permissions to privileges granted to all profiles and roles (see figure below).

 

 

The following table represents a simplified version of the policy. Note that in the cross-tabulation between each profile and privilege there is a permission, which may be "allowed" (access granted explicitly) or "undefined” (access not granted, represented by a dash -). For the cross-tabulation between each role and privilege, there is a permission that may be "Allow with an associated context" (allow... if...) or "undefined."

 

Profiles and Roles

Privileges

Profile 1

Profile 2

Profile 3

Role 1

Role 2

Role 3

Privilege 1

Allowed

Allowed

-

-

-

Allow ... if ...

Privilege 2

Allowed

-

Allowed

Allow ... if ...

-

-

Privilege 3

Allowed

Allowed

Allowed

-

Allow ... if ...

-

Privilege 4

Allowed

Allowed

Allowed

-

-

-

 

Note that Profile 1 in this authorization policy has explicit permission to all privileges, and all the profiles shown have permission to Privilege 3. Also note that Role 1 has explicit permission to Privilege 2, but there is an associated context, a condition for granting the permission: Allow… if...

An authorization policy is provided with the installation of the system, which determines which permissions should be granted by default to each system privilege for each profile and role.

This authorization policy has many profiles, roles, and privileges, but in essence works the same as the example in the table above. Thus, after including people and groups of people in the appropriate profiles and assigning them to the appropriate roles, the system will be fully functional in terms of granting privileges.

Note: Regardless of how the permissions are configured, users automatically receive permission to view all the entities necessary to perform any activities they were authorized to carry out.

For example, when assigned to the Responsible for Knowledge Base role and receiving permission to edit this knowledge base, a user will be able to view details on the threats when editing the knowledge base, since the connection between the threats and the controls is part of the authorized operation of editing the knowledge base.

Similarly, upon being assigned leader of a risk management project and receiving permission to edit the scope of the project, a user will automatically receive permission to view asset components in order to be able to add them to the scope. However, the project leader will not be able to view this information outside of the context of editing the scope of the project by directly accessing the Organization module, for example.