Sec/User Mgmt: How Role-Based Access Control Works

Document created by RSA Information Design and Development Employee on Oct 24, 2017Last modified by RSA Information Design and Development Employee on Apr 4, 2018
Version 5Show Document
  • View in full screen mode

This topic explains role-based access control (RBAC) when there is a trusted connection between Security Analytics Server and a core service.

In Security Analytics, roles determine what users can do. A role has permissions assigned to it and you must assign a role to each user. The user then has permission to do what the role allows.

Pre-Configured Roles

To simplify the process of creating roles and assigning permissions, there are pre-configured roles in Security Analytics. You can also add roles customized for your organization. 

The following table lists each pre-configured role and the permissions assigned to it. All permissions are assigned to the Administrators role. A subset of permissions is assigned to each of the other roles.

AdministratorsFull system access.The System Administrators persona is granted all permissions by default.
OperatorsAccess to configurations but not to meta and session content. The System Operators persona is focused on system configuration, but not Investigation, ESA, Alerting, Reporting, and Incident Management.
AnalystsAccess to meta and session content but not to configurations. The Security Operation Center (SOC) Analysts persona is centered around Investigation, ESA Alerting, Reporting, and Incident Management, but not system configuration.
SOC_ManagersSame access as Analysts plus additional permission to handle incidents. The SOC Managers persona is identical to Analysts, but with permissions necessary to configure Incident Management.
Malware_AnalystsAccess to investigations and malware events. The only access granted to the Malware Analysts persona is the  Malware Analysis module.
Data_Privacy_OfficersThe Data Privacy Officer (DPO) persona is similar to Administrators with additional focus on configuration options that manage obfuscation and viewing of sensitive data within the system (see Data Privacy Management). Users with the DPO role can see which meta keys are flagged for obfuscation, and they also see obfuscated meta keys and values created for the flagged meta keys.

Trusted Connections Between Server and Service

In a trusted connection, a service explicitly trusts Security Analytics Server to manage and authenticate users. This reduces administration on each service because authenticated users do not have to be defined locally in each Security Analytics Core service.

As the following table shows, you perform all user management tasks on the server:

Add a userServer
Maintain usernamesServer
Maintain passwordsServer
Authenticate internal Security Analytics usersServer
(Optional) Authenticate external users with:
- Active Directory
Install and configure PAMServer

The benefits of a trusted connection and centralized user management are that:

  • You perform all user administration tasks once, on Security Analytics Server only.
  • You control access to services but do not have to set up and authenticate users on the services.
  • Users enter passwords once at Security Analytics Log On and are authenticated by the server.
  • Users, already authenticated by the server, access every core service in Administration > Services without entering a password.

How Trusted Connections Are Established

When you install or upgrade to 10.6, trusted connections are established by default with two settings:

  1. SSL is enabled.
  2. The core service is connected to an encrypted SSL port.

To establish a trusted connection, each Security Analytics Core service must be upgraded to 10.4 or later. Trusted connections are not backwards compatible with Security Analytics Core 10.3.x or earlier.

Common Role Names on the Server and Services

Trusted connections rely on common role names on the server and service. On a fresh installation, Security Analytics installs the five pre-configured roles on the server and each core service. If you upgrade to 10.6 from 10.3x or earlier, Security Analytics does not install the new SOC_Managers and Malware_Anlaysts roles. You must add these roles to each core service.

If you add a custom role, such as JuniorAnalysts, you must add the role to each service, such as ArchiverA and BrokerB. Role names are case-senstive, cannot contain spaces and must be identical. For example, JuniorAnalyst (singular) and JuniorAnalysts (plural) do not meet the requirements for common role names.

End-to-End Workflow for User Setup and Service Access 

This workflow shows how role-based access control works when there is a trusted connection between Security Analytics Server and the service BrokerB.

  1. On Security Analytics Server, create an account for a new user:
    Name: Chris Jones
    Username: CAJ
    Password: practice123
  2. Determine if you want to assign a pre-configured or custom role to Chris Jones:
  • Pre-Configured role
  1. Keep or modify the default permissions assigned to the Analysts role, which include permissions such as access to the Alerting, Investigation and Malware modules,  
  2. Assign the Analysts role to Chris Jones.
  • Custom role
  1. Create the custom role, such as JuniorAnalysts.
  2. Assign permissions to the JuniorAnalysts role.
  3. Assign the JuniorAnalysts role to Chris Jones.
  4. Add the JuniorAnalysts role to the service, such as BrokerB.
  1. The user, Chris Jones, logs on to Security Analytics Server:
    Username: CAJ
    Password: practice123
  2. The server authenticates Chris. 
  3. The trusted connection allows the authenticated user, Chris, to access BrokerB without entering another password.

For more detailed descriptions and procedures, see Manage Users with Roles and Permissions.

Related Topic

Next Topic:Role Permissions
You are here
Table of Contents > How Role-Based Access Control Works