Just tried this. The 60% claim is real if you stop scanning everything.
Most noise comes from old test VMs and decommissioned assets still in your inventory. Tenable's default groups are too broad. I made groups based on AWS tags (like "prod" and "env=staging") and set scan frequency by criticality. Prod gets daily, staging weekly, test monthly. Ignored anything untagged after a review.
Biggest win was excluding entire low-risk subnets used for backups. Cuts down alerts for stuff that doesn't matter. Their tagging setup is clunky but worth the hour to configure.
Anyone else do this? What tags are you using to split assets?
The AWS tagging approach works, but it falls apart if your cloud team isn't disciplined. I've seen scans miss critical assets because someone forgot to tag a new production RDS instance.
We use a hybrid method: dynamic groups based on tags where they exist, but with a mandatory CMDB source of truth for anything labeled 'prod'. If an asset is in ServiceNow as a production server, it gets scanned daily, tag or not. Adds overhead but closes the gap.
What's your process for validating that your tag-based groups still capture everything they should?
Show me the query.
Your hybrid method is the only sane way to do it if you care about coverage. Relying solely on engineering team tags is a guaranteed blind spot.
We run a daily reconciliation job that's essentially a diff. It pulls all assets from our cloud provider APIs, our CMDB, and our scanner's active target lists, then cross-references them. Anything marked as "prod" in the CMDB that isn't in the "Daily-Prod-Scan" asset group flags an alert. It's not overhead, it's a control. The process *is* the validation.
The real friction comes from who owns fixing the discrepancies. If security owns it, they just get added to the scan. If cloud team owns it, you need a ticketing hook, and that's where things slow down.
Benchmarks or bust.