Automated Scanning in a Formal Evaluation: Configuration, Triage & Verification

Prerequisites

• STE-K001: What STE Is
• PEN-K004: Vulnerability Assessment & CVE Research

Why This Lesson Matters

Automated scanners are fast and consistent — they will check every port and every URL without getting tired. But they also generate false positives at a rate that makes raw scanner output unusable in a formal evaluation. This lesson teaches you to configure scanners correctly, triage their output professionally, and verify every High/Critical finding manually before it goes in a report.

1. The Role of Scanners in STE

Scanners are evidence-gathering tools, not evaluation conclusions. Think of a scanner as a first-pass metal detector at an airport. It flags everything metallic. The security officer then examines each flagged item to determine what it actually is.

Scanner output → candidate findings
Manual verification → confirmed findings
Confirmed findings mapped to control requirements → STE findings

A finding that exists only in the scanner report without manual verification is not a STE finding.

2. Nessus Configuration for Formal Evaluation

2.1 Credentialed vs Uncredentialed Scans

For STE, always use credentialed scans where possible. A credentialed scan checks the actual installed version from inside the OS — eliminating the most common false positive (banner mismatch).

Nessus credential setup (Linux SSH):
  Credentials → SSH → username: nessus_scanner
                     → key or password
  Enable: "Enable SSH known_hosts file"
  Test connection before launching

Nessus credential setup (Windows WinRM):
  Credentials → Windows → username: svc_nessus (domain account)
                        → password
  Policies → Advanced → "Enable safe checks"   ← avoids service disruption

2.2 Policy Configuration for STE

Template: Advanced Scan
Settings → Assessment → Accuracy: "Perform thorough tests"
Settings → Assessment → Override normal scan speed: enabled
Plugins → Disable: DoS, destructive, or brute-force categories
  (These are excluded from STE — they can disrupt production services)

Discovery → Port scanning: "All ports" (0-65535)
Discovery → Service Discovery: "Probe all ports to find services"

3. Triaging Nessus Output

After a scan, the output requires systematic triage before any finding is confirmed.

3.1 Triage Categories

3.2 The Verification Workflow

Nessus flags: Apache Tomcat 9.0.65 — CVE-2022-29885 (Remote Code Execution)

Step 1: Read the CVE
  CVE-2022-29885 affects Apache Tomcat < 9.0.63

Step 2: Verify the actual version
  curl -s https://target:8080/ | grep -i "apache tomcat"
  OR: SSH to server → cat /opt/tomcat/RELEASE-NOTES | head

Step 3: Compare
  Actual version: 9.0.65 ≥ 9.0.63 (affected range) → NOT VULNERABLE
  Result: False Positive

Step 4: Document
  "Nessus flagged CVE-2022-29885 on Apache Tomcat. Manual verification confirmed
   the installed version is 9.0.65, which is outside the affected version range
   (< 9.0.63). Finding closed as false positive. Evidence: SSH version check
   output (EX-012)."

4. OWASP ZAP for Web Application STE

OWASP ZAP (Zed Attack Proxy) is the open-source standard for web application security scanning. In STE, it is used as part of a structured test suite, not as a standalone tool.

4.1 Authenticated Scan Configuration

# Start ZAP in daemon mode
zap.sh -daemon -port 8090

# Configure authentication via ZAP API
# Set session management: Cookie-based
# Set authentication: Form-based (username/password fields)
# Set logged-in indicator: text that appears only when authenticated

# Run authenticated spider then active scan
curl "http://localhost:8090/JSON/spider/action/scan/?url=https://app.corp.local&contextId=1"
curl "http://localhost:8090/JSON/ascan/action/scan/?url=https://app.corp.local&contextId=1"

4.2 ZAP Alert Triage

ZAP produces alerts at four risk levels (High, Medium, Low, Informational). For STE:

• High alerts: Manual verification required; map to relevant control
• Medium alerts: Manual verification recommended; may be informational
• Low/Info: Document in appendix; not formal STE findings unless control requires

# Export ZAP results as JSON for programmatic triage
curl "http://localhost:8090/JSON/alert/view/alerts/" > zap_alerts.json
python3 -c "
import json
alerts = json.load(open('zap_alerts.json'))['alerts']
highs = [a for a in alerts if a['risk'] == 'High']
for a in highs:
    print(a['name'], '|', a['url'], '|', a['solution'][:60])
"

5. Common Mistakes

Mistake 1: Including scanner output in the STE report without verification. Raw scanner output is an appendix item, not a finding. Every finding in the report body must be manually confirmed.

Mistake 2: Running an unauthenticated scan and treating it as a complete evaluation. An unauthenticated scan cannot check patch levels, configuration files, or any control that requires system access. It is always partial coverage.

Mistake 3: Disabling "safe checks" in Nessus. Without safe checks, some Nessus plugins actively exploit vulnerabilities to confirm them. In a STE on production or staging systems, this can cause crashes, data corruption, or service disruption. Always enable safe checks unless you have explicit authorisation for destructive testing.

6. Practice Exercises

1. Nessus reports: "OpenSSL 1.1.1k — Heartbleed (CVE-2014-0160)" on a server running OpenSSL 3.0.7. Describe your verification process and expected outcome.

2. A ZAP High alert says: "SQL Injection — URL parameter 'id' in /products". What three manual steps do you take to confirm or refute this before writing it up as a finding?

3. You are configuring Nessus for a formal STE of a production e-commerce platform. Which three configuration choices do you make to avoid service disruption, and why?

7. Lab

Assessment mode: quiz

You are given a Nessus scan report with 15 findings (3 Critical, 5 High, 7 Medium/Info). Triage each High/Critical: confirm or refute based on provided version information, and identify which require manual verification.

8. Framework Alignment

9. Further Reading

• Nessus User Guide — https://docs.tenable.com/nessus — Credential configuration chapter
• OWASP ZAP User Guide — https://www.zaproxy.org/docs/ — Authenticated scan setup
• NIST NVD API — https://nvd.nist.gov/developers — Automate version-to-CVE lookups

["Configure a Nessus credentialed scan with safe checks enabled and explain why credentialed scans produce fewer false positives than unauthenticated scans", "Apply the five-step triage workflow to a provided Nessus finding: read the CVE, verify the actual version, compare to the affected range, classify as TP or FP, and document the reasoning", "Triage a ZAP High alert by manually testing the flagged parameter and producing a confirmed or refuted finding with a request/response pair as evidence"]

Prerequisites → Why this matters (metal detector analogy) → Role of scanners in STE → Nessus configuration (credentialed vs uncredentialed, policy settings for STE) → Triage categories and verification workflow (CVE-2022-29885 worked example) → ZAP for web application STE (authenticated scan, alert triage) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading