This chapter covers vulnerability scanning and assessment, a critical process for identifying security weaknesses before attackers can exploit them. For the SY0-701 exam, this maps to Objective 2.1: Explain the importance of vulnerability scanning and assessment. You will learn the types of scanners, how they work, what they detect, and how to interpret results. Understanding scanning is essential for proactive defense and compliance with standards like PCI DSS.
Jump to a section
Imagine a building security inspector who walks through a large office complex with a detailed checklist. The inspector does not break down doors or disable locks; instead, they check every door, window, and security camera to see if it is properly secured or has any weaknesses—like a faulty lock or a window left open. They record every issue in a report, noting the severity (e.g., a broken lock on a main entrance is critical, a loose hinge is low). The inspector does not fix anything; they only identify potential problems. Similarly, a vulnerability scanner is like that inspector: it probes systems and services (like checking doors and windows) against a database of known vulnerabilities (the checklist). It sends packets, analyzes responses, and compares them to signatures of known flaws. The output is a list of vulnerabilities with severity scores, but it does not exploit or fix them. Just as the inspector might miss a hidden weak point (false negative) or flag a harmless feature as a problem (false positive), scanners have limitations. The key is that scanning is a non-intrusive check—unlike penetration testing, which is like a security tester actually trying to pick the lock to prove it can be opened.
What is Vulnerability Scanning and Assessment?
Vulnerability scanning is the automated process of identifying security vulnerabilities in systems, networks, and applications. It is a key component of a vulnerability management program. The goal is to discover weaknesses—such as missing patches, misconfigurations, default credentials, or known CVEs—before attackers do. Scanners compare the state of target systems against a database of known vulnerabilities, often using signatures, behavior analysis, or both.
How Vulnerability Scanners Work Mechanically
A scanner operates in several phases: 1. Discovery: The scanner identifies live hosts, open ports, and running services. This is often done via ICMP ping sweeps, TCP SYN scans (port scans), or SNMP queries. 2. Service Enumeration: For each open port, the scanner determines the service and version (e.g., Apache HTTP Server 2.4.49) by banner grabbing or analyzing responses to crafted probes. 3. Vulnerability Detection: The scanner sends specific payloads or requests to test for known vulnerabilities. For example, it might attempt to trigger a buffer overflow or check for default credentials. It compares responses to signatures of known flaws. 4. Reporting: The scanner generates a report listing vulnerabilities with severity scores (e.g., CVSS), affected hosts, and remediation recommendations.
Key Components and Standards
CVE (Common Vulnerabilities and Exposures): A dictionary of publicly known vulnerabilities, each with a unique identifier (e.g., CVE-2021-44228 for Log4j).
CVSS (Common Vulnerability Scoring System): A framework for rating vulnerability severity from 0.0 to 10.0, with metrics like attack vector, complexity, and impact.
NVD (National Vulnerability Database): The U.S. government repository of standards-based vulnerability management data.
CWE (Common Weakness Enumeration): A list of software weakness types (e.g., CWE-79 for XSS).
Types of Scanners
Network-based scanners: Scan IP addresses and ports over the network (e.g., Nessus, OpenVAS).
Host-based scanners: Scan a single host's OS, installed software, and configuration (e.g., Qualys, Microsoft Baseline Security Analyzer).
Application scanners: Test web applications for vulnerabilities like SQL injection, XSS (e.g., Burp Suite, Acunetix).
Database scanners: Check database configurations for weaknesses (e.g., default passwords, missing patches).
Cloud scanners: Assess cloud infrastructure (e.g., AWS Inspector, Azure Security Center).
How Attackers Exploit and Defenders Deploy
Attackers often use the same tools to identify vulnerabilities in target systems. However, defenders use scanning as part of a proactive security posture. Scans should be scheduled regularly (e.g., weekly or monthly) and after significant changes. Scans can be authenticated (with credentials for deeper checks) or unauthenticated (external view). Authenticated scans provide more accurate results but require credentials and can be more intrusive.
Real Command/Tool Examples
Nmap is a popular open-source scanner. Example command to scan a host for open ports and service versions:
nmap -sV -p 1-1000 192.168.1.1Output might show:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4
80/tcp open http Apache httpd 2.4.6Nessus (commercial) provides a GUI and can be automated. OpenVAS is an open-source alternative. For web apps, OWASP ZAP can be used:
zap-cli quick-scan -t http://example.comInterpreting Scan Results
Scans produce many findings. Critical vulnerabilities (CVSS 9.0-10.0) require immediate action. High (7.0-8.9) and Medium (4.0-6.9) should be prioritized. Low (0.1-3.9) may be informational. False positives are common; analysts must verify findings. For example, a scanner might report a missing patch that is actually installed. Conversely, false negatives occur when a vulnerability exists but the scanner misses it.
Integration with Remediation
Scanning alone is not enough. Results must be tracked in a ticketing system, assigned to owners, and remediated within SLAs. Re-scans confirm fixes. Compliance frameworks like PCI DSS require quarterly external scans and internal scans after changes.
Limitations
Scanners cannot find zero-day vulnerabilities (not in signature database).
They may cause disruption if overly aggressive (e.g., crashing services).
They provide a point-in-time snapshot; continuous monitoring is better.
They do not verify exploitability; a penetration test is needed for that.
1. Define Scope and Rules
Before scanning, define the scope: which IP ranges, systems, or applications will be scanned. Obtain written authorization from system owners. Set rules of engagement, including acceptable scan times (e.g., outside business hours) and exclusion lists (e.g., critical production servers). For example, a SOC might receive a ticket to scan a new subnet 10.10.20.0/24. The analyst documents the scope in the scanning tool and schedules the scan for 2 AM to minimize impact.
2. Run Discovery Scan
The scanner performs host discovery to identify live systems. It sends ICMP echo requests, TCP SYN to common ports (e.g., 80, 443), or uses ARP for local networks. In a tool like Nmap, `nmap -sn 10.10.20.0/24` lists responsive hosts. The analyst reviews the list to confirm it matches expected assets. Any unknown host may indicate a rogue device. Logs from the scanner show each IP and its response type.
3. Run Port and Service Scan
For each live host, the scanner probes ports to identify open ports and running services. A full TCP connect scan (`nmap -sT`) or SYN scan (`nmap -sS`) is used. Service version detection (`-sV`) grabs banners. For example, port 3389 might reveal 'Microsoft Terminal Services'. The scanner records each service and its version. Analysts look for unexpected services like Telnet (port 23) or outdated versions like IIS 6.0.
4. Run Vulnerability Scan
The scanner now performs vulnerability checks. It sends payloads tailored to each service. For example, if it found Apache 2.4.49, it might test for CVE-2021-41773 (path traversal). It sends a crafted GET request like `GET /cgi-bin/.%2e/%2e%2e/...` and checks if the response contains a directory listing. If yes, it flags the vulnerability. The scanner also checks for weak passwords by attempting common credentials (e.g., admin/admin).
5. Analyze and Prioritize Results
After the scan, the analyst reviews the report. Each finding includes the CVE ID, CVSS score, description, and affected host. The analyst filters out false positives by verifying manually. For example, if a scanner reports 'SMB Signing Disabled' on a Windows server, the analyst checks the local policy. True positives are prioritized: critical vulnerabilities (CVSS >= 9) are remediated within 24 hours, high within 72 hours. The analyst may use a SIEM to correlate findings with other logs.
6. Remediate and Re-scan
Findings are assigned to system owners for remediation. For a missing patch, the owner applies the update. For a misconfiguration, they change settings. After remediation, a re-scan is performed to confirm the vulnerability is gone. The analyst runs the same scan profile and checks that the finding no longer appears. If it persists, the issue may not have been fully fixed. All actions are documented for audit and compliance.
Scenario 1: PCI DSS Quarterly Scan A SOC analyst at a payment processing company runs a quarterly external vulnerability scan required by PCI DSS. They use a PCI-approved scanner (e.g., Qualys) targeting the public IP range of the cardholder data environment. The scan reveals a critical vulnerability: CVE-2019-0215 (Apache mod_jk buffer overflow) on a web server. The analyst verifies the server is indeed running Apache 2.4.6 with mod_jk enabled. They create a ticket for the web team to patch or mitigate (e.g., disable mod_jk). After remediation, a re-scan confirms the vulnerability is resolved. A common mistake is ignoring false positives—for example, the scanner might flag a vulnerability that is actually mitigated by a WAF. The analyst must check if the WAF rule blocks the exploit.
Scenario 2: Internal Scan for Ransomware Prevention A company recently suffered a ransomware attack via EternalBlue (MS17-010). The SOC now runs weekly internal scans using OpenVAS. During a scan, they find SMBv1 enabled on several legacy servers. The scanner reports it as high severity. The analyst prioritizes these servers and works with IT to disable SMBv1 or apply the patch. One server cannot be patched due to legacy app support; the analyst implements a firewall rule to block SMB ports (139, 445) from all but necessary IPs. A common mistake is scanning only during business hours, causing network congestion; the analyst schedules scans for off-peak hours.
Scenario 3: Cloud Environment Scan A cloud security engineer uses AWS Inspector to scan EC2 instances. The scan identifies an instance with a public-facing SSH port (22) open to 0.0.0.0/0. The engineer reviews the security group and sees it was misconfigured. They change the inbound rule to allow only specific IPs. The scanner also finds a missing patch on an Amazon Linux AMI. The engineer applies the patch via AWS Systems Manager. A common mistake is relying solely on cloud-native scanners without validating findings; for example, AWS Inspector might miss vulnerabilities in custom applications, so a third-party scanner should also be used.
What SY0-701 Tests on This Objective - The difference between vulnerability scanning and penetration testing. - Types of scanners: network, host, application, database, cloud. - The role of CVE, CVSS, and CWE in vulnerability management. - Authenticated vs. unauthenticated scans. - False positives and false negatives. - The importance of scheduling scans and remediation. - Compliance requirements (e.g., PCI DSS quarterly scans).
Common Wrong Answers and Why Candidates Choose Them 1. 'Vulnerability scanning exploits vulnerabilities to prove they are real.' This is wrong because exploitation is penetration testing, not scanning. Candidates confuse scanning with pentesting. 2. 'Unauthenticated scans provide the most accurate results.' Wrong because authenticated scans have deeper access and are more accurate. Candidates think 'no credentials' means less intrusive, but accuracy is lower. 3. 'A false positive means a vulnerability exists but the scanner missed it.' That's a false negative. False positive means the scanner reported a vulnerability that doesn't exist. Candidates mix up the terms. 4. 'CVSS score is the only factor for prioritization.' While important, other factors like asset value, exploitability, and business impact also matter. Candidates overlook the context.
Key Terms and Acronyms - CVE: Common Vulnerabilities and Exposures (e.g., CVE-2021-44228) - CVSS: Common Vulnerability Scoring System (0-10) - CWE: Common Weakness Enumeration - NVD: National Vulnerability Database - PCI DSS: Payment Card Industry Data Security Standard (requires quarterly scans) - Authenticated scan: uses credentials for deeper checks - Unauthenticated scan: external view without credentials
Trick Questions - A question might ask: 'Which scan type would best identify missing patches on a Linux server?' The answer is authenticated scan, because it can check installed packages. Unauthenticated scans rely on version guessing and are less reliable. - Another trick: 'What is the primary purpose of vulnerability scanning?' The correct answer is to identify potential weaknesses, not to exploit them.
Decision Rule for Eliminating Wrong Answers If a question involves 'exploiting' or 'proving' a vulnerability, it's likely about penetration testing. If it involves 'identifying' or 'listing' vulnerabilities, it's scanning. Also, if the question mentions compliance (e.g., PCI DSS), scanning is the answer. For prioritization, look for CVSS score combined with asset criticality.
Vulnerability scanning is an automated process to identify known vulnerabilities using signature databases like CVE.
CVSS scores range from 0.0 to 10.0, with 10.0 being most severe; used for prioritization.
Authenticated scans provide more accurate results than unauthenticated scans.
False positives are incorrect findings; false negatives are missed vulnerabilities.
PCI DSS requires quarterly external vulnerability scans and scans after significant changes.
Scanners do not exploit vulnerabilities; penetration testing does.
Common scanner tools: Nessus, OpenVAS, Qualys, Nmap, Burp Suite, OWASP ZAP.
These come up on the exam all the time. Here's how to tell them apart.
Vulnerability Scanning
Automated process using scanners
Identifies potential vulnerabilities
Does not exploit vulnerabilities
Generates a list of findings with severity scores
Less intrusive, can be run frequently
Penetration Testing
Manual or semi-automated by human testers
Verifies exploitability of vulnerabilities
Exploits vulnerabilities to demonstrate impact
Produces a report with proof of exploitation
More intrusive, typically performed less often (e.g., annually)
Authenticated Scan
Uses credentials (e.g., SSH keys, Windows domain account)
Can check local configuration, registry, installed patches
More accurate, fewer false negatives
Requires credential management and may impact system performance
Provides deeper visibility into OS and application settings
Unauthenticated Scan
No credentials provided; external view only
Relies on service banners and network responses
May miss vulnerabilities that require authentication to detect
Less intrusive, no credential management needed
Useful for external attacker perspective
Mistake
Vulnerability scanning is the same as penetration testing.
Correct
Scanning is automated and identifies potential vulnerabilities; penetration testing involves manual exploitation to verify and demonstrate impact. Scanning is a subset of a pen test but not equivalent.
Mistake
An unauthenticated scan gives a complete picture of vulnerabilities.
Correct
Unauthenticated scans only see what is visible externally; they miss vulnerabilities that require authentication to detect, such as missing patches on installed software. Authenticated scans are more thorough.
Mistake
All vulnerabilities found by a scanner are real and must be fixed immediately.
Correct
Scanners produce false positives. Each finding should be verified manually before remediation. Also, not all vulnerabilities are exploitable in the environment; risk assessment is needed.
Mistake
A vulnerability scanner can detect zero-day vulnerabilities.
Correct
Scanners rely on signature databases of known vulnerabilities. Zero-day vulnerabilities are unknown to the vendor and have no signature, so scanners cannot detect them. Behavioral analysis may help but is limited.
Mistake
Running a vulnerability scan once a year is sufficient.
Correct
New vulnerabilities emerge daily. Scans should be run regularly (e.g., weekly or monthly) and after any significant network change. Compliance often requires quarterly scans.
Vulnerability scanning is an automated process that identifies potential vulnerabilities without exploiting them, producing a list of findings. Penetration testing is a manual or semi-automated process where testers attempt to exploit vulnerabilities to prove they are real and assess impact. For the exam, remember that scanning identifies, pen testing validates.
CVSS stands for Common Vulnerability Scoring System. It provides a numerical score (0.0 to 10.0) to rate the severity of a vulnerability based on metrics like attack vector, complexity, privileges required, user interaction, and impact. Higher scores indicate more critical vulnerabilities. It helps prioritize remediation efforts.
A false positive occurs when a scanner reports a vulnerability that does not actually exist. For example, a scanner might flag a missing patch that is actually installed, or misidentify a service version. Analysts must manually verify findings to avoid wasting resources on non-issues. False positives are common in unauthenticated scans.
Authenticated scans use credentials (e.g., SSH keys, Windows domain account) to log into the target system. This allows the scanner to check local configurations, installed patches, registry settings, and other details that are not visible from the network. Unauthenticated scans rely on banner grabbing and may guess versions, leading to false positives and negatives.
Best practice is to run scans regularly, such as weekly or monthly, and after any significant network or system change. Compliance standards like PCI DSS require quarterly external scans and scans after major changes. The frequency should be based on risk tolerance and organizational policy.
Generally, no. Vulnerability scanners rely on signatures of known vulnerabilities (e.g., CVE entries). Zero-day vulnerabilities are unknown to the vendor and have no signature. Some advanced scanners use behavior analysis or anomaly detection to identify potential zero-days, but this is limited and not reliable. Regular patching and defense-in-depth are needed.
CVE (Common Vulnerabilities and Exposures) is a dictionary of publicly known vulnerabilities. Each vulnerability has a unique identifier (e.g., CVE-2021-44228). Scanners use CVE IDs to reference specific vulnerabilities in their reports, making it easy to look up details and remediation steps. The CVE database is maintained by MITRE.
You've just covered Vulnerability Scanning and Assessment — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?