Targets are the locations your Scanners are scanning and providing results for.
Overview
Some Scanners scan IPs, others scan Repositories, and other scan Cloud Resources like IAM policies. All of these are Targets with different sources and types but ultimately are considered scanner specific data coming into the NopSec platform.
In order to become Scanner agnostic we have adopted the terminology of Targets. This will also enable us to better support multi-scanner clients where you may have two or more Scanners scanning the same location. In this scenario there would be two Targets.
Our goal is to reintroduce the concept of a NopSec Asset as the parent of one or more Targets. This will give our clients the ability to manage duplication and Target association logic. This is currently a Q1 2024 goal.
Targets
Think of Targets as the specific locations each Scanner is scanning. If you're only using one Scanner to scan a given location then you have one Target. However, if you're using two Scanners to scan the same location, you will have two Targets.
Each Target sharing some information but potentially formatted differently or potentially with more or less enrichment based on the specific Scanner reporting that information.
NopSec will attempt to normalize a few fields for each Target. These include:
- Target Name
- NopSec will follow a set of rules to determine the best normalized name from among a list of metadata available per Target type. For example, if the type is Infrastructure a Scanner may provide a Hostname, an FQDN, a Netbios Name, and potentially other fields depending if it was a Cloud Infrastructure asset or not.
- The goal is to identify a name for a Target to allow for easy reporting and querying. For example, using the above we may prioritize using FQDN first then Hostname, then Netbios Name if the other two were Null. Today these rules are not configurable but we aim to allow Admins the ability to set and configure these rules.
- Target Location
- Similar to Target Name each Scanner may provide a list of fields that point to a specific location and the platform follows a set of rules per Target Type to determine the best location value to use.
- We will also aim to allow Admins to set and configure these rules in the future.
- Similar to Target Name each Scanner may provide a list of fields that point to a specific location and the platform follows a set of rules per Target Type to determine the best location value to use.
- There may be other Normalized fields introduced in the near future such as Owner and Uniqueness.
By using normalized fields users are able to focus on finding their targets without having to worry about which specific metadata field to use in their queries as it would mean having to know the intricacies of each Scanner.
Pricing
NopSec has traditionally priced its platform based on the number of Assets, however, we found that we were measuring the wrong thing. As described above, there may be situations where a specific Asset may be scanned by multiple products and each require NopSec to ingest, process, associate, store, and manage information. This work was not being accounted for in our pricing.
Targets allow for us to enable clients to bring in all of their data and for pricing to be transparent on both ends. If two scanners scan that same Asset it will count as two Targets. All NopSec plans have been updated to reflect higher number of Targets allowed per plan because of this reason.
Assets
We are not completely done with Assets. For now, we have started with Targets but we will be building more tools to better manage the relationships between targets. We also know that clients think in terms of Assets and not Scanner results. Because of this we will be introducing NopSec Assets as the object that combines one or more Targets together.
NopSec Assets in this way will be able to show the relationships it is comprised of better than our old version of Assets (which was really De-Duplicated Targets).
Assets will be associated with CMDB, one or more Targets, and potentially with other Assets (think Clusters). This will enable us to improve our contextual risk use cases planned for 2024.