Risk Identification, Monitoring, and Analysis →mediumMultiple Choice

SSCP Risk Identification, Monitoring, and Analysis Practice Question

A security operations center uses Nessus to scan its internal network nightly. A newly deployed web server is reporting a critical TLS vulnerability, but the vulnerability analyst confirms the server is configured to negotiate only TLS 1.3 with approved cipher suites. The scanner plugin was last updated eight weeks ago. Which action should the analyst take FIRST to resolve the discrepancy?

⚠ Common exam trap

The trap here is assuming a scanner finding is authoritative and jumping straight to remediation or risk acceptance instead of validating the scan data first.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Update the Nessus plugins and credentials, then rescan the host to validate the finding before acting.

Stale scanner content is a common source of false positives, especially for protocol and cipher detection where vendor logic evolves quickly. Before treating the TLS finding as real, the analyst should refresh plugins, confirm credentials work, and rescan so the scanner evaluates the actual negotiated protocol and cipher suites. Only validated findings should be escalated, suppressed, or formally accepted as risk.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Escalate the finding to the change advisory board as a confirmed critical risk requiring emergency patching.
Why it's wrong here
Escalating a finding the analyst has already determined to be contradicted by the actual server configuration would misdirect remediation resources and trigger unnecessary emergency change activity. A confirmed critical risk requires evidence that the vulnerability genuinely exists; here the evidence points the other way, so escalation should wait until the plugin and scan data are reconciled and the false positive is ruled out.
✗
Accept the risk for the web server and document the exception because TLS 1.3 is enabled.
Why it's wrong here
Accepting risk is a formal governance decision that requires the finding to be validated and the residual risk understood, not assumed from the question's premise. The analyst has not yet confirmed whether the scanner or the server configuration is authoritative. Documenting an exception prematurely could leave a real weakness unaddressed and bypasses the risk acceptance authority.
✗
Disable the TLS-related plugin family on the scanner so the server stops generating noisy findings.
Why it's wrong here
Suppressing an entire plugin family removes detection coverage for every other host and TLS weakness on the network. Disabling the plugin hides the symptom instead of determining whether the alert is a false positive or a genuine misconfiguration on this or another system. It is an inappropriate first step because it degrades the scanner's ability to identify real TLS flaws elsewhere.
✓
Update the Nessus plugins and credentials, then rescan the host to validate the finding before acting.
Why this is correct
An eight-week-old plugin set can produce false positives because detection logic for TLS versions and cipher negotiation changes frequently. Refreshing plugins and ensuring credentialed scanning lets the scanner inspect the true negotiated protocol and cipher list rather than inferring from a banner or stale signature. Validating before remediation prevents wasted patching effort and preserves trust in the vulnerability management process.

Visual reference

Go deeper

SSCP Risk Identification, Monitoring, and Analysis Practice Question

Why each option matters

Option-by-option breakdown

Related to this question