Vulnerability Assessment (VA)

1.1. Define Objectives

• Clearly state the primary driver for the assessment (e.g., routine security hygiene, compliance audit (PCI, HIPAA), post-incident review, assessing a new network segment).

1.2. Define Scope

• In-Scope Assets: Explicitly define the target network segments. This must be documented and approved.
• Examples: Specific IP ranges (10.1.0.0/16), VLANs (VLAN-10_Servers), physical locations (Data-Center-A), or asset groups (All production web servers, Workstation networks).
• Out-of-Scope Assets: Explicitly list what must not be scanned.
• Examples: Highly sensitive systems (Industrial Control Systems/ICS), third-party vendor equipment, or systems where a scan could cause operational failure. These require special handling.

1.3. Define Scan Type

• Uncredentialed (Black-Box) Scan:
• Credentialed (White/Grey-Box) Scan:

1.4. Establish Rules of Engagement (ROE)

• Testing Window: Define precise dates and times when scanning is permitted.
• Scanner IP Whitelisting: Provide the source IP addresses of the vulnerability scanners to the client, so they can be whitelisted in Intrusion Prevention Systems (IPS) or firewalls. This prevents the scan from being blocked and ensures a complete assessment.
• Communication Channels: Establish a clear point of contact (e.g., IT manager, security lead) and a communication channel (e.g., email, phone) for progress updates or in case of any issues.

2.1. Host Discovery

• Use network scanning techniques (e.g., nmap ping sweeps, ARP scans, or the scanner's built-in discovery module) to identify all live hosts (servers, workstations, printers, routers, etc.) within the scoped IP ranges.

2.2. Service Enumeration

• For each live host, perform a comprehensive port scan to identify all open TCP and UDP ports.
• The goal is to map every running service (e.g., HTTP on port 80, SSH on port 22, SMB on port 445).

2.3. Version Detection

• Actively and passively fingerprint each service to determine its precise version (e.g., "Microsoft-IIS/10.0," "OpenSSH 8.2p1").
• Identify the underlying operating system of the host (e.g., "Windows Server 2019," "Ubuntu 20.04"). This information is critical for matching against vulnerability databases.

3.1. Scan Execution

• Configure and launch a commercial or open-source vulnerability scanner (e.g., Nessus, Qualys, OpenVAS, Nexpose) against the discovered assets.
• Execute both uncredentialed and credentialed scans as defined in the scope.
• Ensure scan policies are set appropriately (e.g., using "safe" non-intrusive checks for sensitive environments).

3.2. Data Collection

• The scanner will test each host and service against a large database of known vulnerabilities (CVEs), common misconfigurations, and default credentials.
• All findings are collected into a raw data report, often containing thousands of potential issues.

4.1. Data Aggregation

• Consolidate results from all scans (credentialed, uncredentialed, different network segments) into a single dataset.

4.2. False Positive Reduction

• Manually review and validate high-impact findings. Scanners can make mistakes (e.g., flagging a vulnerability based on a service banner when a backported patch has already been applied).
• Attempt to confirm the vulnerability's presence through non-intrusive manual checks (e.g., verifying a file version, checking a registry key).

4.3. Vulnerability Correlation

• Identify patterns and root causes. For example, 100 servers may share a "Critical" vulnerability due to a single-service misconfiguration or a single missing patch in a master VM image.
• Analyze how vulnerabilities might be chained, even if exploitation is not performed.

4.4. Risk Assessment

• A vulnerability's risk is more than its technical severity (e.g., a CVSS score). Each finding must be contextualized:
• Asset Criticality: Is the asset a non-production test web server or a domain controller? A "Medium" vulnerability on a critical asset is often a higher priority than a "Critical" one on an isolated, low-value system.
• Data Sensitivity: Does the system store or process PII, financial data, or intellectual property?
• Exploitability: Is a simple, public exploit available?
• Impact: What is the business impact if the vulnerability is exploited (e.g., data breach, service disruption, reputational damage)?
• Based on the contextualized risk, assign a final priority rating (e.g., Critical, High, Medium, Low) to each validated vulnerability.

4.5. Reporting

• Executive Summary:
• Technical Report:

• Present the findings in a debrief meeting.
• Support the technical teams as they apply the recommended fixes.
• Verification (Re-test): After the remediation window, perform a targeted re-scan on the patched systems to validate that the vulnerabilities have been successfully resolved.