CySA+ Vulnerability Scanning Methods: Planning, Scan Types and Baselines

Vulnerability scanning starts with an asset inventory because the inventory defines what must be scanned, who owns each result and how much each system matters. A scanner can only assess targets it is told about or happens to discover; without a current list of assets, owners and business criticality, the program has no scope, no remediation routing and no basis for priority.

What the inventory supplies

• Scope: the systems, networks, cloud accounts and applications the program is responsible for. If the inventory cannot be trusted, scope is unknown, and every later decision (schedules, credentials, baselines) rests on it. Establishing scope is therefore the first step of a scanning program, not a refinement added later.
• Ownership: the team that remediates. A finding with no owner has nowhere to go.
• Criticality and data classification: what the system supports and what data it holds. These fields drive scan frequency, depth and, later, remediation priority.
• A stable identity: the key that ties every finding to the right asset over time.

Discovery keeps the inventory honest

The relationship runs both ways. Discovery scans regularly surface shadow or rogue assets: hosts that answer on the network but have no inventory record and no owner. The program's response is reconciliation, which means identifying each unknown asset and its owner and bringing it into scope. An unknown asset is a gap in visibility, not proof of compromise, so containment decisions belong to incident response once there is evidence.

Choose an asset key that does not move

In cloud and autoscaling environments, instances are replaced constantly and private IP addresses and generated hostnames are reused. Any identifier that is recycled will eventually attach old findings to new, unrelated workloads. A durable key is one the platform never reuses, such as the provider's resource or instance ID, enriched with owner and application tags from the inventory so findings route correctly however the workloads scale.

Scheduling, operations and performance decide when scans run and how hard they push, so that the required cadence is met without disrupting the business or the systems being scanned. Active scans add load to targets and to the network, and their traffic looks like an attack, so each of these planning considerations is about keeping coverage while controlling side effects.

Scheduling

The governing principle: coverage and cadence are fixed by policy and risk; timing and load are what you adjust.

• Maintenance windows. Each asset owner agrees a window when scan load is acceptable.
• Local time. A single central window can fall in another region's business hours. Distributed scan engines, managed from one console, can each run in their own site's off-hours.
• Availability. A scan only assesses hosts that are running. Systems with power or uptime schedules need windows that match when they are actually on; scanner timeouts and retries cannot assess a host that is powered off.
• Window length. When a full scan does not fit one window, the scope can be divided into groups scanned in rotation, so every host is still covered each cycle at the same depth.

Operations

Scans touch other teams. Scan traffic deliberately resembles port sweeps and exploit attempts, so intrusion detection systems raise alerts. The operational answer is coordination: the SOC knows the scanner addresses and scan windows, so matching alerts are recognised, while detection stays fully active. Scan-like traffic from a scanner outside its window, or from any other host, should still stand out, because a compromised scanner is a real attack path.

Some device types react badly to probes. Network printers are the classic case: raw printing services print whatever bytes arrive, so generic service-detection probes come out as pages of garbage. Scanners therefore offer device-specific handling, such as not sending service probes to raw print ports on printer targets, so the devices stay in scope without the side effect.

Performance

Two settings reduce the risk of crashing fragile or legacy hosts without removing them from scope:

• Safe checks, which skip tests that can disrupt a service (denial-of-service style or exploit-based checks).
• Throttling: lower concurrent checks per host, fewer hosts in parallel, or a lower packet rate.

Network capacity matters too. Scanning remote sites across congested WAN links slows users and can saturate branch links when concurrency is raised. Placing a scan engine at the site keeps the scan traffic local.

Sensitivity levels decide how intrusive and how frequent a scan should be for each group of assets, and segmentation decides where scanners must sit to see each zone. Both turn one company-wide scan into a set of scans tuned per target group.

Sensitivity levels

The term covers two related ideas:

• Template intrusiveness. Scanners ship templates ranging from discovery-only through moderate to thorough or full checks. Thorough templates can add intrusive tests such as password guessing and default-account logins, which can lock out real accounts. Production systems that cannot tolerate disruption get safe templates; lab and test systems can take the full set. Each risky check is applied only to the device types it is meant for, rather than to every target.
• Data sensitivity. Systems holding restricted data, such as cardholder or health records, get the most frequent and deepest (credentialed) scans; lower classifications are still scanned, on a longer cycle. When capacity is limited, effort follows risk rather than one flat rotation, and no class is excluded permanently.

Segmentation

Firewalls between zones filter scan traffic, so a scanner in one zone scanning another largely measures the firewall rule set rather than the hosts: results look uniform across the zone and authentication-based checks tend to fail. Where the scanner sits is a design decision with trade-offs:

Distributed engines are the standard way to meet both coverage and segmentation goals, because each engine scans locally and only results cross zone boundaries.

Regulatory requirements set minimum scan frequency, scope, depth and, sometimes, who must perform the scan. The detailed example is PCI DSS v4.0.1, requirement 11.3, which treats internal and external vulnerability scans differently:

Principles to keep apart:

• Who scans is part of the requirement. Quarterly external scans count only when an ASV performs them; the quality or frequency of an organization's own external scanning does not change that. Internal scans have no such restriction.
• Authentication is mandatory internally. Requirement 11.3.1.2 (mandatory since 31 March 2025) requires authenticated internal scans. Operational problems with scan credentials are solved by managing the scan account, not by giving up authentication; accounts used for scanning that can log in interactively are managed under requirement 8.2.2.
• Each scan type has its own pass rule. The internal-scan risk-ranking allowance belongs to 11.3.1.1. External results are judged by the ASV Program Guide's criteria, and a failing component is remediated and rescanned by the ASV until it passes, unless the ASV accepts a dispute.
• Scanning and penetration testing are separate. Penetration testing is requirement 11.4, at least annually and after significant change. Neither substitutes for the other.

Other regimes, such as HIPAA, GLBA or sector rules, may require regular vulnerability assessment without stating PCI-style detail; the scan plan should record which requirement each scan satisfies.

An internal scan runs from inside the network and shows what an insider or an attacker who has a foothold could reach; an external scan runs from the internet and shows only what is exposed at the perimeter. The vantage point decides the results, so two scans of the same host can both be correct and still disagree.

• Match the vantage point to the threat being modelled. An internet attacker has no foothold, no agent and no credentials, so a faithful model of that attacker is an external, unauthenticated scan. Every other method adds access that attacker lacks.
• Filtering hides, it does not remove. A service the perimeter blocks disappears from external results but remains reachable inside, where it is a lateral-movement and malware risk. A difference between internal and external results is evidence of filtering, not of a false positive.
• Intermediaries change what is assessed. With a reverse proxy, load balancer or CDN in front, an external scan assesses the intermediary. Flaws on the origin server still matter whenever requests are forwarded to it, so origin findings from an internal scan stand on their own.

In short: external scans find the doors, and internal scans find the risks behind them. Mature programs run both.

Use agent-based scanning for hosts you can install software on, especially roaming ones, and agentless network scanning for devices that cannot run an agent or that you do not manage; most organizations need both. Each method has a coverage gap the other fills.

The blind spots are structural. An agent-only program can never discover what it does not know about, so it needs scheduled network discovery and scanning alongside it; fixing individual devices as they turn up treats the symptom, not the gap. A network-only program sees only what is connected when it runs, which leaves mobile workforces largely unassessed. Passive sensors add visibility to either approach but are a supplement rather than complete coverage.

A credentialed (authenticated) scan logs in to the target and reads its registry, file system, package database and local policy, so it finds missing patches and insecure local settings that a non-credentialed scan cannot see. A non-credentialed scan sees the host as an outsider does: open ports, banners, protocol versions, certificates and whatever a service reveals before login.

The dividing line is simple: if the evidence lives on the host, you need credentials; if a network service exposes it, you do not.

Credentialed scans therefore report more findings with fewer guesses, and they are what a security baseline (configuration) scan depends on.

Scan accounts

• Use a dedicated service account with least privilege: only the rights the scan policy needs (for example local administrator on scan targets granted through group policy, or scoped sudo on Linux), interactive and remote desktop logon denied, and the credential stored in the scanner's vault. Accounts with far broader rights than the scan needs, or accounts shared by people, fail least privilege or accountability.
• Lockouts and expired passwords are credential-management problems with credential-management fixes.

Troubleshooting a drop in findings

A sudden fall in findings after a credentialed scan is a warning sign, not good news. Authentication has two stages, and the scan log shows which one failed: the login itself, or the privilege elevation the checks need afterwards (for example sudo on Linux). When elevation fails, the scanner silently falls back to remote checks only. The fix addresses the stage that failed, and findings that disappeared because the scanner could not look are not remediated findings.

Active scanning sends probes to targets and analyses the responses; passive scanning sends nothing and instead identifies hosts, services and software versions from network traffic it observes through a SPAN (mirror) port or a network tap. Passive is the right choice when sending traffic to the devices is unsafe or forbidden, as with PLCs and HMIs on an OT network.

Passive blind spots

• Silent devices: a device that rarely or never talks is never learned. Absence from a passive inventory is not proof of absence from the network, however long the sensor listens.
• Sensor placement: traffic switched locally between neighbouring devices never reaches a sensor on an uplink, so whole cells of an OT network can be invisible.
• Encryption: TLS hides the banners and protocol fields used to identify software versions.

Because passive monitoring cannot prove completeness, the usual approach in a fragile environment is to compare the passive inventory with a lightweight active discovery scan: host discovery only, at a low rate, in an approved maintenance window. The principle is to use the least intrusive active method that answers the question being asked.

Discovery scans find what is on the network before vulnerability checks run: a mapping scan (host discovery) identifies which addresses are live and how the network is laid out, and device fingerprinting identifies what each live host is, such as its operating system, device type and services.

Mapping scans and host discovery

• Probe variety. Discovery that uses only ICMP echo (ping) misses hosts whose firewalls drop ping, which is common on hardened servers. TCP SYN and ACK probes (and UDP probes) to common ports find hosts whose services still answer. Discovery is the stage that decides which hosts exist for the rest of the scan; every later stage (service detection, fingerprinting, credentialed checks) only works on hosts discovery has already found.
• ARP discovery. On a local segment ARP is very reliable, because a host must answer ARP to communicate on its LAN even when its firewall drops unsolicited IP packets. ARP is a layer 2 protocol and is not routed, so it only works from a scanner or scan engine attached to the same subnet.
• Topology mapping. Traceroute-style techniques reveal network paths, hops and layout; identifying what a host is belongs to fingerprinting.

Device fingerprinting

Active OS fingerprinting sends crafted probes and compares responses (TTL values, TCP window sizes, TCP options and similar behaviours) against a signature database, then reports a best match with a confidence level, for example Nmap's "Aggressive OS guesses" line with a percentage. Service fingerprinting does the same for applications on open ports. Passive fingerprinting infers the same from observed traffic without sending probes. A fingerprint is a guess; a credentialed check reads the exact build. Fingerprints are valuable for spotting inventory errors: when what a host is on the wire disagrees with what the inventory says it is, the record needs investigating.

Reading the full output of specific tools such as Nmap, Nessus or OpenVAS belongs to objective 2.2; this objective is about choosing the right method.

Security baseline scanning (also called configuration or compliance scanning) checks each system's settings against a defined secure configuration and reports deviations; it finds weak configuration that a CVE-focused vulnerability scan does not report. A system can be fully patched, with no CVE findings, and still run insecure legacy protocols, weak account policies or permissive access settings. Baseline scans are usually credentialed, because they read local settings.

The three named sources play different roles:

Because PCI DSS and ISO 27001 say "harden and manage configuration" but not which values to set, an organization subject to both commonly adopts the CIS Benchmark for each platform as its baseline and uses a compliance scanner to check it. One baseline then provides evidence for both programs.

CIS profile levels

• Level 1: practical, prudent settings with a clear security benefit and minimal impact on how the system works. The usual baseline for general-purpose systems.
• Level 2: defense-in-depth settings for high-security environments; they may reduce functionality or break applications.

Choosing a profile is a risk decision, and no benchmark is applied blindly: the organization picks the level that fits each system's role and documents a justification for every setting it deviates from. What it cannot do is stop measuring configuration, because vulnerability (CVE) scans do not check settings at all.