Recently, I noticed something interesting when it comes to tags applied via sites in Rapid7 InsightVM. As you may know, you can create tags in site configurations, and these tags will then be associated with any asset found within this site. This is really neat, and we use it at our org in order to create distinct groups of assets (as it’s more convenient to tag hundreds of servers of a particular group using this site tagging, rather than creating dynamic asset groups with complex filtering)
However, let’s say that you have a site with three assets (A, B & C), then after some time, C no longer should be a part of that group. So the site scope is changed to only include assets A & B - but the wierd thing is that asset C is still having the tag from the site applied to it - it’s even one of the “site assets”, but not one of the “included targets” as you would phrase it in the InsightVM API context.
The only way to clear the tag applied via the site to this “site asset” C is to manually go through the site in question, and for those assets which are not part of the scope (there’s no visual indiciation of this in the tool), just remove them from the site. You could of course do this via the API also.
I like InsightVM, I really do. But some of these gotchas are just wierd.
It sounds like, using your example, you don’t include asset C within the scope of the site’s scan, but asset C still ends up being a part of the site. This isn’t unexpected, assets can become part of sites even though they are not included in those sites’ scan scopes. For example, you could be scanning an IP address through a different site and that IP address could end up being correlated to an asset which belongs to the site in question. Those kinds of correlation issues can lead to all sorts of cross-talks between sites and usually, it’s caused by scanning without sufficient credentials. Unauthenticated scans will prevent you from collecting details such as UUID that would be used to accurately correlate discovered nodes to the assets in your database.
Create a site X and add 8 distinct assets to its scope (add tag to site configuration)
Run unauth. discovery scan after creating the site X
Modify the scope of site X to remove two assets (A & B) from the site X scope
Run another unauth. discovery scan after modifying the site X scope
At this point, the two assets (A & B) no longer part of the site scope are still part of the site assets, and will seemingly continue to be a part until removed via the UI.
I will test this with authenticated discovery scans and see what happends
In the 4-step workflow you outlined, it’s expected that the assets A & B will remain associated with the site X. Once associated with a site, assets will not lose that association until either removed from the site manually or historical scan data getting removed (e.g. through data retention policy).
