Vulnerability Assessment and Analysis

From Scanning to Assessment: A Critical Distinction

Vulnerability scanning and vulnerability assessment are not interchangeable terms. Scanning is the automated collection of data—banner grabbing, service detection, and signature matching against known vulnerabilities. Assessment demands human analysis: validating findings, contextualizing results against business impact, and determining whether a reported flaw is exploitable in your specific environment. The tools covered in this section generate raw material; your expertise transforms that data into actionable intelligence.

OpenVAS/GVM Architecture and Scan Calibration

The Greenbone Vulnerability Management (GVM) framework, formerly OpenVAS, operates through a modular architecture that directly impacts how you configure and tune scans. Understanding these components prevents the common failure mode of launching overwhelming scans that crash targets or return useless noise.

Core Components:

  • OpenVAS Scanner (openvas-scanner): The execution engine that runs Network Vulnerability Tests (NVTs) against targets
  • Greenbone Vulnerability Manager (gvmd): The central management daemon handling database operations, scheduling, and report generation
  • Greenbone Security Assistant (GSA)/GSM: Web interface and API layer
  • PostgreSQL database: Stores scan configurations, results, and asset data
  • Redis: Acts as the internal communication buffer between scanner and manager

The PostgreSQL backend stores not merely scan results but the entire vulnerability knowledge base. Feed updates—which you must treat as critical infrastructure—deliver new NVTs, CVE mappings, and product detection signatures. A stale feed means blind spots. Greenbone provides two feed channels: the Community Feed (delayed) and the Greenbone Enterprise Feed (real-time). For production environments, schedule daily feed updates via greenbone-feed-sync and verify completion in the GSA task logs.

Scan Calibration Techniques:

Performance tuning requires balancing completeness against target stability. The default "Full and Fast" scan config loads thousands of NVTs simultaneously—a recipe for overwhelming embedded systems or legacy network infrastructure.

Parameter Conservative Setting Aggressive Setting Use Case
Maximum concurrently executed NVTs per host 4 20 Embedded/SCADA
Maximum concurrently scanned hosts 5 30 Large subnets
NVT timeout 10 minutes 2 minutes Slow WAN links

For scan-sensitive legacy systems, create a dedicated scan configuration that excludes destructive NVTs (those tagged with destructive_test=true) and enables safe checks. The exclude_hosts directive in target definitions prevents accidental scanning of critical infrastructure during windowed maintenance periods.

# Example: Create a conservative scan config via gvm-cli
gvm-cli socket --xml "<create_config>
  <copy>698f691e-7489-11df-9d8c-002264764cea</copy>
  <name>Legacy-Safe-Conservative</name>
  <comment>Reduced parallelism for fragile infrastructure</comment>
</create_config>"

Nessus Professional vs. Tenable.io Integration

While GVM excels in open-source flexibility, Nessus dominates enterprise deployments through Tenable's commercial ecosystem. The architectural choice between Nessus Professional and Tenable.io extends beyond licensing to operational workflows.

Nessus Professional operates as standalone software installed locally. You manage scan policies, scheduling, and result storage directly. This suits isolated environments, air-gapped networks, or consultants requiring portable deployments. Limitations include no centralized dashboard, no multi-user role separation, and no native cloud asset correlation.

Tenable.io shifts to a SaaS delivery model with sensor-based architecture. Nessus scanners deployed in your environment communicate with Tenable's cloud platform, enabling centralized policy management, continuous monitoring, and integration with Tenable's Exposure Management (formerly Lumin) for risk-based prioritization. The critical advantage is passive asset discovery and agent-based scanning complementing traditional network scans—essential for cloud and remote work architectures.

For hybrid environments, deploy Nessus scanners as Tenable.io linked sensors while maintaining standalone Professional instances for sensitive enclaves. Export Tenable.io findings via API for correlation with GVM results in your vulnerability management platform.

Vulnerability Validation and False Positive Reduction

Automated scanners generate false positives through multiple mechanisms: version-based detection without patch verification, logical errors in NVTs, and environmental factors like load balancers masking true service versions. Systematic validation separates signal from noise.

Validation Hierarchy:

  1. Banner verification: Capture actual service responses, not inferred versions
  2. Changelog analysis: Confirm vendor backport practices
  3. Patch-level confirmation: Query package managers or registry entries
  4. Proof-of-concept testing: Controlled exploitation in non-production environments

Concrete Example: The Backported OpenSSH Patch

Consider a scenario where OpenVAS reports "Critical" for CVE-2020-15778 (scp remote command execution) on an Ubuntu 20.04 LTS server running OpenSSH 8.2p1. The scanner flags this based on version string alone: 8.2p1 appears vulnerable per NVD data showing fixes in 8.3p1.

Initial finding from OpenVAS report:

Vulnerability: CVE-2020-15778 (Critical, CVSS 9.8)
Detected: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
Evidence: Installed version: 8.2p1
Fixed version: 8.3p1

Your validation process:

# Step 1: Verify actual installed package, not banner
ssh user@target "dpkg -l | grep openssh-server"
# Returns: ii  openssh-server  1:8.2p1-4ubuntu0.5  amd64

# Step 2: Check Ubuntu security tracker for specific package version
# Visit: https://ubuntu.com/security/CVE-2020-15778
# Status: "Released (1:8.2p1-4ubuntu0.2)"
# The .5 suffix in installed version is newer than released patch

# Step 3: Examine changelogs for explicit backport confirmation
ssh user@target "zcat /usr/share/doc/openssh-server/changelog.Debian.gz | grep -A5 CVE-2020-15778"
# Returns: "* SECURITY UPDATE: scp command execution vulnerability
#   - debian/patches/CVE-2020-15778.patch: restrict scp -T handling
#   - CVE-2020-15778"

# Step 4: Controlled PoC testing in isolated environment
# Attempt CVE-2020-15778 exploitation against identical build
# Result: Failure (patch effective)

Conclusion: False positive. Ubuntu's security team backported the fix without changing the upstream version number. The scanner's signature-based detection lacked context for distribution-specific patching practices. Document this as "Risk Accepted with Verification" rather than dismissing entirely—future feeds or NVT updates may improve detection.

CVSS Interpretation and Business Risk Prioritization

CVSS Base Scores provide standardized severity measurement but dangerously oversimplify risk. A CVSS 9.8 vulnerability in an isolated lab network presents different organizational risk than a CVSS 7.5 flaw on your internet-facing VPN concentrator.

Supplemental Factors for Prioritization:

  • Threat Intelligence: Is active exploitation observed in the wild? CISA KEV catalog inclusion elevates priority regardless of CVSS
  • Exposure: Network segmentation, attack path accessibility, and compensating controls
  • Asset Criticality: Database servers housing PCI data versus internal wiki servers
  • Exploitability: Presence of public exploit code, weaponized malware, or Metasploit modules

Implement a risk scoring model combining CVSS with environmental metrics. Tenable.io's Vulnerability Priority Rating (VPR) and Greenbone's Severity Class (SC) offer starting frameworks, but customize weightings based on your threat model.

Custom Policy Creation for Compliance-Mapped Scanning

Compliance frameworks (PCI-DSS, CIS Benchmarks, DISA STIGs) require scanning policies aligned with specific control objectives rather than general vulnerability discovery.

Building Compliance-Mapped Policies:

For PCI-DSS Requirement 11.3.2 (internal vulnerability scans), create a GVM scan config that:

  • Targets only in-scope CDE (Cardholder Data Environment) systems
  • Excludes informational findings from report generation
  • Maps findings explicitly to PCI-DSS requirement numbers in notes
  • Runs quarterly with authenticated credentials for patch verification
<!-- GVM compliance policy snippet -->
<create_config>
  <name>PCI-DSS-11.3.2-Quarterly</name>
  <usage_type>scan</usage_type>
  <preferences>
    <preference>
      <scanner_name>scan_host_alive</scanner_name>
      <value>0</value>  <!-- Assume targets reachable; avoid ICMP flood -->
    </preference>
  </preferences>
  <nvt_selectors>
    <selector>
      <type>nvt</type>
      <family>General</family>
      <include>1</include>
    </selector>
    <!-- Explicitly exclude performance-heavy NVTs -->
    <selector>
      <type>nvt</type>
      <name>1.3.6.1.4.1.25623.1.0.10335</name>
      <include>0</include>  <!-- Disable aggressive DoS tests -->
    </selector>
  </nvt_selectors>
</create_config>

Authenticated scanning fundamentally changes accuracy. Unauthenticated scans miss patches not reflected in network-visible banners. Deploy scanning credentials via GVM "Credentials" objects—SSH keys for Linux, SMB for Windows—while isolating scan accounts with least-privilege access and monitoring their usage.

For firewall-traversed scanning, configure target definitions with alive tests using TCP SYN on known open ports rather than ICMP, and document expected latency increases in scan schedules. Legacy systems behind stateful firewalls may require dedicated, slower scan windows with explicit firewall rule logging to diagnose connection drops.