Recently Viewed Topics
Reporting Tier (Tenable.sc)
The primary purpose of the reporting tier was to allow for centralized analytics and reporting of data collected from the Nessus Agent operational tier (Tenable.io). Dashboards, analytics, reports, and Assurance Report Cards are leveraged on this tier.
The following processes and uses take place in the Reporting Tier (Tenable.sc).
- Tenable.io was added to Tenable.sc as an “agent capable” scanner.
- Agent scans in Tenable.sc were configured to retrieve Nessus Agent scan results from Tenable.io.
- Analytics, dashboards, reports, and Assurance Report Cards in Tenable.sc were leveraged for all assessment types (Agent and Network Scanning).
- Tenable recommended that ACME configure Tenable.sc to retrieve Nessus Agent scan results from Tenable.io the same day Tenable.io collects assessment results from Nessus Agents. This configuration ensures that Tenable.sc captures proper detection dates.
- Tenable.sc required additional data repositories to support the Nessus Agent results. Tenable recommended that ACME establish two new repositories in Tenable.sc for Nessus Agent results, because repositories can only handle upwards of 50,000 assets each.
- Tenable.sc 5.7 introduced an agent-specific repository that leverages the Nessus Agent UUID to better track uniqueness when results are imported into Tenable.sc.
- ACME needed to perform a full analysis on their current Tenable.sc hardware configuration to determine if additional CPU/RAM/HDD was required for the additional data resulting from importing Nessus Agent scan results.
Design assumptions included:
- ACME will establish two (2) repositories to store Nessus Agent scan results.
- ACME will establish 50-70 agent scans to retrieve Nessus Agent scan results from Tenable.io.
- ACME will balance each agent scan retrieval evenly across the two (2) new repositories.
- ACME will evaluate current infrastructure to determine if additional CPU/RAM/HDD is required.