2. What's New?

This is a major release with many new features and improvements based on user feature requests. Let's deep dive into what's new.

Overview

We've introduced new concepts like Roles, Teams, Targets, Remediation Plans, and Exception Plans. Fundamentally this is the same product but... better, and these new concepts are a result of listening to what our users wanted.

Roles

Previously we supported two Roles; Admin and User. Users may be given Edit privileges or left as View Only, so in theory you had three options:

• • Admin
  • User with Edit
  • User

In our new release we have expanded our default set of Roles to 5 roles

• Default 
• Analyst
• Manager
• Admin
• Exception Manager
  
  

Roles now have more fine grained privileges in the form of “scopes” or “actions” supported. 

The main differences between the roles are:

• If you want certain users to be delegated tasks such as Exception Approvals, Team / User management, but don’t want to have them manage or interact with Integrations, or other platform settings, then the Manager is the role you can use.
• If you want a subset of Analysts to be able to be delegated the ability to Review Exceptions and approve them but don’t want them to be able to manage users you can give them Exception Manager.
• Default has the most limited set of scopes and by default will have no data access. This is where new SSO users will be added to. Admins will have to move them to teams manually.
• Admins see and can do everything
• Analysts are the base user class.

Teams

A new feature we are introducing is Teams.

Teams allow Admins to manage Data Access and Roles in one place, then all they have to focus on is moving users in and out of teams. 

• Users who are added to a Team inherit the Role and Data Access of the Team
• Users may live in one or more teams at once.
  • The platform will leverage the privileges from the highest access team; e.x. if a user is in the Admins team and the Default team, the platform chooses the Admins team data access and role.
  • In another example, let's say a user is a member of two teams with different data access queries, then the platform joins the two queries with an OR, effectively allowing the user to see both sets of assets. If you would like to explicitly deny a user access to certain targets they must not be in a team that allows access to those targets. 

If you would like to explicitly deny a user access to certain targets they must not be in a team that allows access to those targets.

NopSec creates the first two teams, which can’t be deleted:

• • Default
    • Role: Default
    • Data Access: No Access
    • All new users created via Basic SSO are placed in the Default Team automatically.
  • Admins
    • Role: Admin
    • Data Access: All Access

Previously Admins had to manage users individually, giving each user a Role AND Data Access via tag assignment. This becomes time intensive when managing hundreds of users. Now Admins configure a Team once and be confident that when he adds or removes a user from that team the user automatically is assigned or removed their Role and Data Access.

In future releases we plan on releasing our support for SSO Auto Provisioning with Azure AD and Okta. Admins will be able to map an SSO Group to a Team within UVRM further automating the user management process.

Targets

We are temporarily removing the terminology of Asset and replacing it with Target. Think of Targets as Scanner Results/Findings, for clients with only one integration nothing really changes a Target and an Asset are synonymous. However, if you have multiple scanners scanning the same location then Targets starts making sense.

• Say you have two scanners scanning the same location, to you that's one asset, but we've ingested two targets. At first, these may be duplicate Assets but by themselves they serve a purpose. Say one scanner provided better enrichment than the other, you may prefer to use the metadata or results from one scanner over the other. In the past this logic was hidden from you and the platform may have chosen the wrong one. 
• So Targets will enable us to provide self-service tools to Admins to configure how the platform should do asset association. By starting with Targets we now have the foundation to allow you the control to choose what data to use for your derived NopSec Asset.
• Targets are also meant to be scanner agnostic across the full tech stack of tools covering infrastructure, source code, web apps, cloud artifacts (functions, images, containers, cloud services, etc.), and other future locations.
• You will also see the use of Normalized fields such as Target Name and Target Location as a way to enable users to search across targets easier without having to filter out different types first.

So for now you will use Targets in your reports as we start releasing the tools for you to create and manage Assets, our goal for these features are end of Q42023 and early Q12024.

Data Access

Previously Admins were able to give users access to data by assigning specific Asset Tags to the user. 

• Tags came in from your scanners as part of an Assets metadata.
• By using Tags Admins were able to ensure all assets tagged with the same value could be assigned to a user.
• For example an Asset Tag may be tagged on 10 assets/targets. By assigning the Asset Tag to a user, that user is now able to only view the 10 assets/targets and nothing else. 

Now we are broadening this capability and providing our users with more flexibility. 

• Users will now be able to create data access queries that can be used to find assets/targets using metadata other than tags (although Tags can still be added within a query to continue the same use case as before).
• This helps clients with assets/targets that can’t be tagged easily by a scanner. 
• Examples include creating data access for assets/targets with no tags by using their asset metadata instead (OS, FQDN, IP, etc.)

It is important to note that Data Access will continue to be managed at the Target (Asset) level.

• You may use vulnerability based filters in your query to find assets/targets with specific vulnerabilities but you may not subdivide an asset for data access needs.
• In other words, you either allow access to view all vulnerabilities on the asset or not.

Settings

A new product goal going forward is to enable our users to have more control within the platform. In order to support the first phase of this we are introducing a Settings page that will continue to expand as time goes on. We are going to display settings that we typically had to manage in the backend but now users will be able to self-service.

The first set of pages will be to see are:

• Users - Manage Users and Teams
• SLA Configuration - Set your SLA by Asset Criticality x Vuln Severity
• Exceptions - Enable Exception Approvals and Manage Exception Reason list

Going forward we'll add:

• Self Service SSO
• Advanced SSO management - map SSO Group to Team
• Asset Criticality Rules - ability to map asset criticality from CMDB or Scanner data, and manage NopSec recommendation rules
• Vuln Instance Configuration - Ability to set modifiers, severity ranges, and more
• And many other settings.

Integrations

Previously our Integrations were relatively simple. We displayed them under some organization of categories. We would display their logo and allow you to enter the credentials to configure the integration, that's it, nothing else was available.

Now we have changed the overall design and organization of the integrations page and released some new functionality.

• Users can now search for an integration quickly
• Users can see which integrations they have configured quickly under their “My Integrations” tab
• Users will be shown the number of integrations available from their Subscription Plan
• Users will only be shown integrations which are GA
• Users will be shown a button to email CS/Sales based on their intent to upgrade their plan
• Users will be able to view Task Sync histories to see the status of each sync, which was not available before.
• Users will be able to self-service configure advanced settings for specific integrations not available before.

Reports

Getting to a Report Table

Previously the navigation structure of the product meant that you had to click on something called Infrastructure Vulns Reports to get to a Report Table, however, you had to first decide whether to load a report or create a new one. We've changed this so you load directly into a Report Table within our new page named Prioritize.

Querying

We will continue leveraging the new query builder recently released and continue to expand on it's functionality and usability. We understand it may be a bit daunting to some users so we're working hard on an easier way to create queries that we're excited about called Quick Filters.

Report Table

Previously our report table was pretty minimalistic. It dictated what data you could see and how you could see it. We've switched our strategy here and opted for giving users more control. You will now have more columns to view and soon the ability to save your column preferences as Column Presets. Other improvements include Pagination and improved CSV Downloads.

Remediation Plans

Previously we supported a feature we called ITSM Ticketing or Ticketing for short. This enabled clients to integrate with Jira or ServiceNow or Email to Ticketing use cases like Trello or Asana. Users selected the vuln instances they believed needed to be worked on by a remediation team and created tickets within the remote system. The platform would handle the creation of the remote ticket and it would track its state both internally and externally.

However, visibility and management of that work was kept to those external systems and users requested ways to better manage those items internally.

We are releasing the concept of Remediation Plans. Users select the vuln instances and determine how to group them, we create internal records for those vuln instances as a Remediation Plan. Users can then elect to send that plan as a remote ticket if needed or choose to keep everything within the platform. In both scenarios users can oversee and manage the work. being conducted within the new Remediate page.

Exception Plans

Similarly, users were able to mark items with a compensating control such as Risk Accept or False Positive but there was no way for internal review and approval of those records or for better management of those records. Today Admins may elect to turn on a feature to enable Admins or Managers to review and approve exception requests internally within the platform. Or they may choose to continue an external process but gain the benefit of easier management within the platform alongside Remediation Plans in the Remediate page.

 

Conclusion

Overall, we believe the improvements made in this latest release are impressive and should allow our users more control, flexibility, and support their workflows. We are super excited to have users start using these features. We have a great roadmap planned for the next 6-12 months focused on making the user experience top notch and providing users more actionable insights.