Implementation/Admin Learning Path
      Back to home
      1. Knowledge Base
      2. Implementation/Admin Learning Path

      User Management

      Create and manage users within NopSec's Unified VRM platform.

      Last Updated: 1/25/2024

       

      Roles

      In UVRM 5.0 we had two roles. Admin and User. 

      In UVRM 6.0 we have introduced 5 roles with each role being configured with a specific set of scopes or actions that give Administrators more control on how to manage user privileges. We will continue add more actions in the future allowing for finer grained control.

      The five roles are:

      • Admin: Administrators are given full privileges across all actions.
      • Manager: This is a new role to support large organization needs to have specific manager level actions such as approvals to be delegated down to specific people. The Manager role is similar to Administrators, however, they do not have any Edit privileges across several Admin focused actions such as; Integrations, Settings, and User Management. 
      • Analyst: This is the core role for any non-Admin or Manager user. This role is meant to support our Remediation Team users as well. They are not able to manage users, exceptions, settings, or integrations. In the future as more features are released we will introduce Remediation Team roles. 
      • Exception Manager: For users who need to be given a the specific privilege of Exception reviews. For instance, an Analyst within a team that isn't quite a Manager but needs to be able to help review Exception plans can be given this role. 
      • Default: Very limited read access and no edit access. Used as the default role for new users not assigned to a team.

      What are the Role's responsibilities?

      Typically we find the following structures depending on the size of the organization. Smaller orgs may only have admin users and only one team, however, as the organization grows the need to delegate these responsibilities to multiple users and teams. 

      The following is what we believe are the general responsibilities:

      • Leadership / Stakeholders : These users are looking to gain insights and overall status and health of the VM program. They will leverage the Insights and Dashboard pages the most.
      • Admin : These users can see all data and are typically responsible for bulk management of all integrations, settings, and data management. In large organizations these users may not actually be doing any vulnerability prioritization or analysis and will normally delegate those responsibilities down to other users.
      • VM Security Lead / Analyst: These users are typically responsible for reviewing vulnerabilities and conducting the prioritization effort and remediation plan creation. In this case, analysts need to learn how to query their data in order to create reports that are specific to their need. They then nominate specific vulnerability instances for remediation by creating a remediation plan and assigning those plans to the proper remediation teams.
      • Remediation Team member: These users are typically part of the patch / fix implementation team, potentially in an Infrastructure or Application team or other similar teams. These users want to be given prioritized lists of items to fix and are typically not interested in doing the analysis piece of the workflow. Their goal is to review the list and determine feasibility of the items and determine which if any cannot be done. If they cannot be done they are typically the users creating the Exception Plans describing why the items cannot be done. Some remediation team members only interact with the VM team through platforms like Jira or ServiceNow by receiving remediation plans in the form of tickets. NopSec allows both the analyst and remediation team member to work together within the platform within the Remediation Plans UI.

       

      Teams

      In UVRM6.0 we are introducing Teams as a way to manage users at scale. 

      Each Team can have a unique name set by Administrators, a Role, and a Data Access query that controls which Assets it's members have access to.

      Users can be added to a team, becoming members, and upon being added they inherit the Role and Data Access the Team provides. 

      Users can exist in multiple teams and the platform will leverage their highest privilege when taking actions and join the data access queries across both teams with an OR statement enabling them to view both team's data.

      The moment a user is removed from a Team they lose the Role and Data Access the Team provided. 

      For instance, a Team can be:

      • Team A
        • Role: Analyst
        • Data Access: asset.os = "Windows*"
      • Team B
        • Role: Analyst
        • Data Access: asset.os = "Linux*"
      • Team C
        • Role: Exception Manager
        • Data Access: asset.os = ["Windows*", "Linux*"]

      The use of Teams should greatly reduce the time and effort for Administrators performing User Management by having them do the work of Role and Data Access once per team rather than per user. 

      Note: We understand that in 6.0 the Administrator still needs to determine where a user must be placed. In 6.1 we will support Okta and Azure AD Auto Provisioning through SCIM to enable administrators to sync SSO Groups within UVRM. UVRM Admins will then be able to create a mapping between SSO Groups and Teams. As membership changes within a Group the Team membership changes as well. 

      What if a user is in two teams?

      This is a common use case as a user may need two or more roles to effectively support the VM program. For instance, being an Analyst and an Exception Manager. Or a user is part of two product teams with access to two different sets of assets.

      If a user is in two teams the following will happen:

      • The platform will leverage the highest role across all of their teams for their permissions.
        • If a user was a member of all three teams above the platform would choose Exception Manager when the user takes actions.
      • The platform will join all of the Teams specific data access queries leveraging an OR operator.
        • If a user was a member of all three teams above the platform would join the queries like so:
          • asset.os = "Windows*" OR asset.os = "Linux*" OR asset.os = ["Windows*", "Linux*"]
        • This means if you want to ensure a user does not have access to specific assets they must not be members of Teams with access to those assets.