Tenable Interview Questions — Nessus, VPR, Lumin & OT Answers

① Nessus & the platform — portfolio, plugin families and scan policies

Q: Walk me through the Tenable platform portfolio. Where does each product fit?

Model answer: Tenable has four main tiers. Nessus Essentials is the free version for up to 16 IPs — great for learning or home labs. Nessus Professional is the commercial standalone scanner for compliance auditors, pen testers, and small security teams who want a direct UI with no cloud dependency. Tenable Vulnerability Management (TVM) — formerly Tenable.io — is the cloud-based SaaS platform that aggregates data from multiple Nessus scanners, Nessus Agents, and the Network Monitor into one tenant with asset-based dashboards, RBAC, and API integrations. Tenable Security Center (SC) — formerly Nessus.sc — is the on-premises manager for organisations that cannot send scan data to the cloud (regulated industries, air-gapped networks). And Tenable One is the exposure management platform that sits above all of these: it ingests VM, web app, cloud, identity, and OT data and presents a unified attack surface view with Lumin-powered Cyber Exposure Scores. The clean one-liner: Nessus is the scanner engine, TVM and SC are the management planes, Tenable One is the exposure umbrella.

Q: What are Nessus plugin families and why do they matter?

Model answer: Every Nessus check is a plugin — a small script that tests for a specific vulnerability, misconfiguration, or compliance condition. Plugins are grouped into families such as Windows, Debian Local Security Checks, Web Servers, Databases, CISCO, Firewalls, Policy Compliance, and many more. When you build a scan policy you choose which plugin families (or individual plugins) to enable: a basic network scan enables a broad default set; a credentialed patch audit adds the local security check families for the target OS; a compliance scan loads the relevant CIS or DISA STIG audit file. Interviewers often ask this to see whether you understand that what Nessus finds depends entirely on which plugins are active — a scan with only network families will never catch a missing Windows patch, even with credentials.

Q: What is the difference between Tenable Vulnerability Management and Tenable Security Center?

Model answer: Both are multi-scanner managers, but the architecture differs. TVM (cloud) hosts scan data in Tenable's cloud; organisations with internet-connected assets and no hard data-residency requirement benefit from its elastic capacity, instant updates, and integrations with tools like Jira and ServiceNow without standing up extra infrastructure. Tenable SC (on-prem) keeps all data inside your own network — mandatory for air-gapped environments, heavily regulated sectors, or any organisation with a policy against sending vulnerability data off-premises. Licensing also differs: TVM is asset-based subscription; SC is licensed by number of IP addresses. Feature parity is broadly similar, but Tenable One's Lumin CES features are primarily a TVM/cloud capability. The interview point: describe the cloud vs on-prem trade-off and name the air-gap use case for SC.

② Sensors & scanning — scanner, agent, passive and credentialed vs network

Q: Tenable uses multiple sensor types. What is the difference between a Nessus scanner, a Nessus Agent, and the Nessus Network Monitor?

Model answer: These are three complementary ways to collect vulnerability data. A Nessus Scanner runs on a dedicated host and actively reaches out over the network to probe target IPs — you point it at a subnet and it scans remotely. It needs network connectivity to targets and may need credentials for deep results. A Nessus Agent is a lightweight process installed directly on the endpoint (Windows, macOS, Linux). It runs the scan locally, eliminating the need for network credentials or scanner-to-endpoint connectivity, and is ideal for laptops, roaming users, and cloud instances that may be off-network when a traditional scan fires. A Nessus Network Monitor (NNM) is a passive sensor: it listens to network traffic (via a SPAN port or TAP) and infers vulnerabilities from observed protocol banners and traffic patterns without sending a single probe packet — essential for fragile OT/SCADA assets and environments where active scanning is disruptive.

Q: What does a credentialed scan add over a network-only scan, and when would you use each?

Model answer: A network-only (uncredentialed) scan sees only what is visible from the outside: open ports, service banners, TLS certificate info, and network-level vulnerabilities. It is quick and requires no credentials, but it misses everything inside the OS: installed software versions, missing patches, local misconfigurations, and weak file permissions. A credentialed scan — providing an SSH key, Windows domain account, or database credential to Nessus — lets the scanner log in and run local checks. It can enumerate installed applications, service pack levels, registry settings, local firewall rules, and patch status far more accurately than a banner grab. In practice: use network-only for external attack-surface enumeration; use credentialed scans for internal asset audits, patch compliance, and CIS benchmark checks. A key interview detail: credentialed scans reduce false positives because Nessus can directly confirm whether a patch is installed rather than guessing from a version string.

Q: How do Nessus Agents help with transient or cloud-hosted assets?

Model answer: Traditional scanners struggle with laptops that are off the corporate network during a scan window, auto-scaling cloud instances that spin up and down, and remote workers on VPN where scan traffic is slow. Nessus Agents solve this by running the scan on the asset itself at a scheduled time regardless of network topology. Results are reported back to TVM or SC when the endpoint next phones home. Agents also eliminate the need to maintain a credential store for every host — a significant operational saving. The trade-off: agents must be deployed and kept up to date on every managed host, and they are not useful for discovering unknown assets (that still requires network scanning or passive monitoring).

③ VPR, Lumin & exposure — scoring, prioritisation and the Cyber Exposure Score

Q: Compare CVSS and VPR. Why does Tenable recommend prioritising by VPR?

Model answer: CVSS (Common Vulnerability Scoring System) is an industry-standard base severity score (0–10) that captures the inherent characteristics of a vulnerability: exploitability (attack vector, complexity, privileges required) and impact (confidentiality, integrity, availability). It is static — CVSS does not change unless the vulnerability is re-scored — and it is context-free: the same score applies to every organisation running the same software, regardless of whether an exploit is actively used in the wild or has never been seen in the field. VPR is Tenable's dynamic, threat-informed score. It layers in real-time threat intelligence (exploit kit presence, active exploitation campaigns, malware association) and updates automatically — a 7.0 CVSS vulnerability with active exploit code in the wild may jump to a VPR 9.5. In practice, most environments have thousands of CVSS Critical findings; VPR typically surfaces a much shorter list of findings that combine real exploitability with environmental context, letting teams fix the things that attackers are actually using first. The interview gold line: CVSS tells you what could be bad; VPR tells you what is likely to be exploited on your network today.

Q: What is Tenable Lumin, and what is a Cyber Exposure Score (CES)?

Model answer: Tenable Lumin is an add-on to Tenable VM that translates raw vulnerability and asset data into a business-level exposure picture. Its core output is the Cyber Exposure Score (CES) — a 0–1000 score (lower is better) that aggregates VPR scores, asset criticality, and remediation velocity across an asset group or the whole organisation. Lumin also provides benchmarking: it can compare your CES against industry peers (same sector, similar size) so you can answer the executive question 'Are we better or worse than our competitors?' with data. Additionally, Lumin surfaces Asset Exposure Score (AES) per host and identifies the assets that, if compromised, would have the highest business impact. The interview point: Lumin is the executive-facing layer — it answers 'How exposed are we?' and 'Where should we focus?', while raw CVSS/VPR data answers 'What is technically wrong?'

Q: How does a typical Tenable remediation workflow work end to end?

Model answer: A mature Tenable remediation workflow has five steps. First, discover and scan: scanners, agents, and passive sensors feed asset and vulnerability data into TVM or SC. Second, prioritise: filter the finding list by VPR (fix VPR 9–10 this sprint, triage VPR 7–8 next), further narrowing by asset criticality tags. Third, assign: TVM integrations push findings into a ticketing system (Jira, ServiceNow) with the VPR score, affected asset, and recommended fix. Fourth, remediate and re-scan: the ops or patching team applies the fix, and a verification scan (or agent check-in) confirms the vulnerability is gone. Fifth, track and report: dashboards in TVM or Lumin show fix rate, mean time to remediate (MTTR), and CES trend over time. Interviewers value candidates who can describe the re-scan confirmation step — many teams apply patches but never verify, leaving the vulnerability open in the system.

④ OT, WAS & scenarios — industrial control, web app scanning and troubleshooting

Q: What is Tenable OT Security, and why can't you just run a standard Nessus scan against OT assets?

Model answer: Tenable OT Security (formerly Tenable.ot, originally Indigo.io) is Tenable's purpose-built industrial cybersecurity solution for operational technology environments — PLCs, HMIs, RTUs, DCS, historians, and engineering workstations. Standard Nessus active scanning is dangerous in OT: the aggressive probing that works safely on IT equipment can crash or freeze PLCs and other real-time controllers, causing production outages or even safety incidents. Tenable OT Security addresses this with passive discovery (deep packet inspection of industrial protocols — Modbus, DNP3, EtherNet/IP, Profinet, IEC 60870-5-104 and others) to identify assets without sending a single probe, plus selective active querying (safe, protocol-native queries at a pace the devices can handle). It also provides ICS-specific vulnerability checks, firmware version tracking, configuration baselining, and Purdue model network mapping. The integration point: OT Security feeds asset and vulnerability data into Tenable One, giving a unified IT/OT exposure view — interviewers value candidates who name this convergence.

Q: What is Tenable WAS, and what does 'authenticated scanning' mean for web applications?

Model answer: Tenable WAS (Web Application Scanning) is Tenable's dynamic application security testing (DAST) module for finding vulnerabilities inside web apps and APIs. The critical distinction over a standard network scan is authenticated scanning: WAS can log into the application (form-based login, SSO, API key) and crawl behind the authentication wall, finding OWASP Top 10 classes like SQL injection, cross-site scripting, broken access control, and IDOR in the pages that only authenticated users can reach — vulnerabilities a network scanner simply cannot see. WAS integrates with TVM/Tenable One so web app findings appear alongside infrastructure findings in unified dashboards, with VPR scores applied. For APIs, WAS can ingest an OpenAPI/Swagger spec to drive coverage of REST endpoints. The interview point: name authenticated scanning as the key value, explain that unauthenticated DAST only sees the login page, and connect WAS results to the Tenable platform's unified risk view.

Q: A scan returns hundreds of CVSS Critical findings. How do you help a client prioritise without overwhelming the patching team?

Model answer: This is the VPR conversation in practice. First, switch from CVSS to VPR as the primary sort — the list of VPR 9.0–10 findings is almost always a fraction of the CVSS Critical list. Second, intersect with asset criticality: findings on production servers or assets tagged as business-critical are promoted above the same finding on a dev laptop. Third, check exploit context: within the VPR 9+ list, surface findings where Tenable's threat intelligence flags active exploitation in the wild. Fourth, set sprint-sized batches: give the team a realistic number of findings per sprint (e.g. VPR 9.5+ on Tier-1 assets this week) so they stay motivated and make visible progress. Fifth, track MTTR and CES trend in Lumin to show leadership that the programme is moving. The interview gold line: don't hand a team 400 Critical findings — filter to VPR 9+ on critical assets, confirm active exploitation, and timebox the work.

Q: A Nessus scan shows a finding as 'unverified plugin'. What does that mean and what should you do?

Model answer: An unverified (or confidence-limited) plugin result means Nessus could not conclusively prove the vulnerability because it lacked the access to run the definitive check — typically because the scan was network-only without credentials. Nessus inferred a likely vulnerability from a version string or banner but could not log in to confirm the patch level. The correct response is: (1) add credentials for the target and re-scan — a credentialed scan will either confirm or clear the finding definitively; (2) if credentials cannot be provided, treat it as valid for remediation purposes rather than dismissing it; (3) in some cases, deploy a Nessus Agent on the host to get a credentialed local check without needing network credentials. The interview point: understanding the confidence of a finding and knowing that credentials are the fix for unverified results is a mark of a Tenable practitioner rather than a tool user.