Identity and Access Management

Summary: High-level overview of the Identity & Access Management (IAM) feature in Ivanti Neurons RBVM/ASPM/VULN KB.

Overview

The new Identity & Access Management (IAM) feature redefines the Ivanti Neurons RBVM/ASPM/VULN KB platform IAM system to allow for more granular control of what users can do, including negating privileges. This update introduced a new Users page with new features and improved functionality and a new Roles page that helps users navigate the new Role-Based Access Control (RBAC) implementation.

IAM Feature Goals

  • Roll out a redesigned Users view with several updates and improvements and a new Roles view.

  • Enhance the access control system using customer-sourced use cases, pain points, and challenges.

  • Rollout a new IAM system that includes user and role management.

  • Adjust the menus to accommodate these new views.

  • Provide an easier-to-use and more functional feature.

Sample Customer Use Cases and Pain Points

  • I need the ability to restrict any user from uploading data regardless of their role.

  • Can I prevent users from modifying API integrations (connectors) if they are a manager?

  • How can I provide someone at the user level the ability to approve a workflow but not gain other privileges?

  • Is there a way to temporarily restrict the things users can do in the platform for our quarterly audit?

  • How can I give temporary access as manager and have the user revert to their original role after some amount of time?

  • Can I give my boss access to the platform and allow them to use dashboards and filters but prevent them from modifying data?

  • I need to provide some security analysts with the ability to approve false positives without giving them manager access to the platform.

  • I manage multiple clients within your platform, can you give me a single place to see the users across those clients that allows me to view and manage them without switching between clients?

  • Can I manage my own users’ access to the clients that I can access, e.g., my production and sandbox clients, without escalating to [email protected]?

  • Can I limit who can create networks, assessments, and groups within my platform regardless of their role?

What is Role-Based Access Control?

Role-based access control (RBAC) uses privileges (what a person can do) and associate one or more of these privileges to a role. You then assign users one or more roles based on their job and scope of work. This system allows you to define what users can and cannot do within the limitations of the system (in this case, RiskSense).

A role is a configuration of Allowed, Not Allowed, and Not Configured for each system privilege. Each privilege must be set to one of these three values for each role.

A privilege is an action or set of actions available in the platform, represented by the cards on the Roles page.

There are two types of RiskSense-provided roles: foundational and supplemental.

Foundational roles are a set of uneditable, predefined roles designed to provide a persona set that can use the platform in different ways. Use these foundational roles to give users the full RiskSense platform experience in their own intended ways.

Supplemental roles are a set of predefined roles designed to provide a specific job function to our customers that can be used in conjunction with other roles to bestow more user privileges without promoting the user to a higher foundational role and giving them additional privileges they should not have.

By default, RiskSense offers a mixture of 20+ foundational and supplemental roles. This feature also introduces the ability to create your own roles, allowing you to configure user permissions with more granularity than you could before.

Custom roles allow you to design a role specific to your needs. This could be like a foundational role or a very specific supplemental role. Use custom roles to give/take specific privileges to/from users, as well.

Feature Highlights

  • Select from two categories of RiskSense-provided roles, Foundational and Supplemental.

  • Previously used roles will no longer be available (though similar roles will be provided) as users are migrated to the new system.

  • Easily see the roles and groups that a user has access to from the new Users card view.

  • Easily see what the roles in the platform can do using the new Roles view found within the IAM module.

  • Create your own roles and allow/disallow those roles for each privilege the new system allows you to configure.

  • Manage multi-client users withoutescalating to the RiskSense Support team.

  • Manage all users for all clients you have permissions to access from a single redesigned user card view.

  • Negate a privilege in a role, providing the ability to take away things from users easily.

  • Expire roles individually to allow for things like giving limited time window additional access to a user for coverage of another team member.

  • Tailor the platform to fit user privileges needs by offering granular control over things you can allow or disallow users to do.

Legacy vs. Current System Comparison

Legacy System

Current System

4 built-in roles

 20+ built-in roles

No supplemental roles for giving small privilege sets exist

Supplemental roles allow giving of smaller privilege sets to users

Cannot create your own roles to ensure that you can meet your organization's needs

Can create your own roles that have the privileges that meet your needs

Cannot negate feature usage in the platform

Can negate (deny) privileges in roles you create

Has no granular control of platform actions

Has over 50+ privileges to allow/deny users

Has a technician role that only sees findings assigned to them

Does not have a role that is limited at the vulnerability level

Users can have only a single role that always determines user privileges

Users can have multiple roles that work together to determine a user’s overall privileges

Cannot see what a role can/cannot do within the platform

Can visually see and inspect what a role can/cannot do on the platform’s Roles page

Has no feedback on what you could do to gain access to some action/feature that you currently cannot access

Has feedback in the form of the Roles pages and new mouseovers that tell you what privilege and role you are missing or need to access something you cannot