This topic explains that role-based access control (RBAC) is a trusted connection among core services and Security Analytics Servers.
In Security Analytics, roles can be determined by what the customers are doing. A role has certain various permissions assigned to it and everyone should be assigned a role in that. The user has the permission to do what the roles of the customer allows or follows.
Pre-Configured Roles:
To simplify the creating roles process and assigning permissions, there might be many Security Analytics pre-configured roles. One can also add and increase the customized roles for the organization.
The list shown below are the permissions assigned and pre-configured role to each and everyone. All the permissions can be assigned to the role of Administrators. The permissions are subjected and assigned to each of their roles.
Operators – The configurations actions are meant to meta content and session content. The Operators personal systems are focused on the configuration of the system, but not on the Alerting, ESA, Investigation, Reporting, and Incident Management.
Administrators – It is also known as the Full system access.The System Administrators can have the grant to all the permissions assigned by default.
SOC_Managers – Same access as Analysts plus additional permission to handle incidents. The SOC Managers persona is identical to Analysts, but with permissions are very much required in order to configure Incident Management.
Analysts – Access to the session and meta content but not to all configurations. The Security Operation Center (SOC) Analysts of the persona are centered around the whole ESA Alerting, Reporting, Investigation, and Incident Management, but not on the system configuration.
Malware_Analysts – Access to malware and investigations events. The only access granted to the Malware Analysts persona is the module Malware Analysis.
Trusted Connections Between Service and Servers :
In the trusted connection, a service can be used to explicitly trust Security Analytics Server in order to authenticate and manage the users. This can be used to reduce the administration on each and every service because authenticated users do not have to be defined locally in each Security Analytics Core service.
As the list shows, the user in performing all the user management tasks on the customer server:
| Task | Location |
| Maintain usernames | Server |
| Add a user | Server |
| Internal Security Analytics users | Server |
| Maintain Passwords | Server |
| Configure and Install PAm | Server |
| Authenticate External usage | Server |
The advantages of the trusted centralized connection user’s management are as follows:
One must have the control access to the services but do not have to authenticate and set up the users on the services.
One must have to perform all tasks of user administration at least once only on the Security Analytics Server.
Users must have to enter passwords at Security Analytics Log On and can be authenticated by each server.
Users who were already authenticated by the access server, the core service in Administration > Services have to enter the password.
How to establish the trusted connections?
While installing or upgrading to the level 10.6, the connections connection are established by default having the powerful two settings:
The core service can be connected to the encrypted port of SSL.
SSL can be enabled.
In order to establish the trusted connection, each and every Security Analytics Core service has to upgrade to 10.4 or later.
Trusted connections cannot be backwards incompatible with the Core Security Analytics 10.3.x or earlier.
Workflow for Service Access and User Setup:
This workflow shows how role-based access control works when there is a trusted connection between Security Analytics Server and the service BrokerB.
- On Security Analytics Server, create an account for a new user:
- Name: John
- Username: SA
- Password: practice 2704
- Ensure if you want to assign the customer or the pre-configured role to John :
Pre-Configured role
Modify or keep or the permissions (default) that are assigned to the role of Analysts, which include other permissions like access to the Investigation, Alerting,and modules of Malware
Assigned the role of Analyst to the Jhon.
Custom role
Create the role of custom, like Junior Analysts.
Assign certain permissions to the role of Junior Analysts.
Assign the role of Junior Analyst to John.
Add and create the role of Junior Analysts to the services like Broker B.
- The user i.e., John, logs on to the server of the Security Analytics:
Username: SA
Password: practice 2704
- The server often authenticates John.
- The trusted connection can allow the authenticated user John in order to access BrokerB (without the password).
The model of role-based access control permission:
Information or data in the GRC solutions can be integral to a company’s Risk Intelligence strategy and can be well-protected. The Role-based access control is considered as the best approach that can be often used in restricting the overall system access in order to some of the authorized users, and it is adopted globally by most enterprises which can be implemented for business systems and IT.
If the customer uses the internal database as the source of identity, the customer can use the console of Security in order to manage all user information / data. Access to the session and meta content but not to all configurations. The Security Operation Center (SOC) Analysts of the persona are centered around the whole ESA Alerting, Reporting, Investigation, and Incident Management, but not on the system configuration.
If the customer uses a directory of LDAP, the identity source must be used read-only. One can also add users to a directory of LDAP while using a tool appropriate. After the customers are added, one can use the console of security in order to perform certain functions of the administration like enabling the user for RBA.
The customer can also have to manage certain user activities from the account on the Dashboard page in the console of security. In Security Analytics, roles can be determined by what the customers are doing. A role has certain various permissions assigned to it and everyone should be assigned a role in that.
Conclusion:
Hope you have the complete details on how to manage the user access in the archer of RSA. Any queries? Comment below.
