A comprehensive study guide covering vulnerability assessments, the 7-step scanning workflow, scope considerations, scanner types (passive/active, credentialed/non-credentialed, server-based/agent-based), scanning parameters, scheduling constraints, vulnerability feeds (SCAP/OVAL/XCCDF), scan sensitivity and templates (discovery/basic/full/compliance), privileged access management, and scanning risks.
Objective 2.1 — Implement vulnerability scanning methods and conceptsObjective 2.2 — Analyze output from vulnerability assessment tools
1
Vulnerability Assessments — Three-Step Process
A vulnerability assessment is an evaluation of a system's security and compliance posture based on the configuration state of the system. The goal is to identify every known weakness so it can be accepted, mitigated, transferred, or avoided. Every vulnerability represents a risk — and you can't manage what you don't know about.
Step 1
Collect target attributes
Gather a predetermined set of attributes — firewall rules, Windows security policies, open ports, installed software versions. These are the specific things you want to check against a known standard or baseline.
Step 2
Analyse current vs. baseline
Compare what you found to what was expected. If a firewall had 2 open ports at baseline and now has 20 — that's 18 unexplained changes requiring investigation. Deviation from baseline = potential vulnerability.
Step 3
Report the results
Document and communicate findings. Automated tools do the scanning, but a human analyst must prioritise findings by asset criticality and threat level. The report drives remediation and stakeholder decisions.
Why automation is essential: A network with 1 million endpoints cannot be manually assessed. Automated vulnerability scanners perform the collection and comparison — but a human analyst must prioritise findings. A compromised CEO workstation is more important than an assistant's, even if the vulnerability is identical. Asset criticality drives priority, not just the vulnerability severity score.
2
Scanning Workflow — Seven Steps & Scan→Patch→Scan
The IT Vulnerability Management Mantra
SCAN → PATCH → SCAN
Find vulnerabilities, fix them, then verify the fixes worked. Repeat on your chosen schedule.
1
Install software and patches — establish baseline. New system, fully patched, properly configured. This is your gold standard for what the system should look like.
2
Perform an initial scan of the target system. Scan the newly configured system. This creates your baseline — everything future scans are measured against.
3
Analyse the assessment reports against the baseline. What did the scan find? Were things installed correctly? Are there unexpected vulnerabilities even on the fresh build?
4
Perform corrective actions based on findings. Patch the vulnerable IIS version. Update missing Windows security updates. Close unnecessary open ports. Fix what was found.
5
Scan again to verify the fixes worked. Don't assume the patch installed correctly. Scan again to confirm vulnerabilities are resolved — patches fail silently in large environments more often than you'd expect.
6
Document findings and report to stakeholders. "Here is the remaining risk. These are the five vulnerabilities we couldn't fix yet. Here are the compensating controls in place. Do you accept this risk?" Stakeholders get the data to make an informed decision.
7
Conduct ongoing scanning — continual remediation. Vulnerability scanning is a point-in-time assessment, not a one-time event. A zero-day released the day after your scan bypasses it entirely. Ongoing scanning at your defined frequency is mandatory.
Align scan and patch cycles: If you scan weekly but patch monthly, you'll report the same vulnerabilities four times before they get fixed. Synchronise scan frequency with patch cycle. Scan → find issues → patch issues → scan to verify → repeat. If you're on Patch Tuesday (weekly Microsoft updates), weekly scanning makes sense.
3
Scope Considerations — Internal vs. External
The scope of a vulnerability scan defines the range of hosts and subnets included in a single job. Proper scoping prevents network overload, focuses resources on the right assets, and allows compliance-specific scanning subsets.
Internal scan
From inside the network
Conducted from within the LAN — no firewall to cross. Sees everything the internal network sees. Used with credentialed scans to find the most vulnerabilities. Result: a comprehensive vulnerability list but includes issues an external attacker couldn't reach. Use this for baseline and compliance work.
External scan
From outside the network
Scans from the internet — through the firewall. Shows exactly what an attacker sees from outside. Finds fewer vulnerabilities (firewall blocks most), but the ones found are the highest-priority exposure. Use this for attacker's perspective and PCI DSS required quarterly scans.
Scope configuration strategies
Time-based scoping
Schedule accounting department scans overnight (nobody working). Defer e-commerce server scans away from peak shopping periods. Spread scans across segments so they don't all run simultaneously and overload the network.
Compliance-based scoping
PCI DSS scope = only systems that touch credit card data. No need to scan the video editor's computer for PCI compliance. Create separate scan jobs for each compliance requirement with only the relevant hosts.
Criticality-based frequency
DMZ web servers (higher attack exposure) → scan weekly. Internal office workstations → scan monthly. High-value or high-exposure assets deserve more frequent scanning than low-risk internal systems.
Internal vs. external — when to use each: Internal = maximum findings, attacker's internal view, use for baseline. External = attacker's external view, fewer but most critical findings, required for PCI DSS. Both perspectives are needed — use both in your programme.
Analyses intercepted network traffic only — no probes sent. Minimum network impact. Least likely to find vulnerabilities (only sees what passes the tap). Used when active scanning would disrupt the network, or during threat hunting when you don't want to tip off attackers that you're monitoring.
Active Scanner
Sends probes to targets and analyses responses. Most common type used by analysts. Consumes network bandwidth and CPU/memory on target systems. Risk of overloading the network if improperly scoped. Never scan eight scanner engines simultaneously across your entire network — this is a lesson learned the hard way.
Credentialed Scan
Scanner is given a user account (admin credentials) to log into target systems. Finds significantly more vulnerabilities than non-credentialed. Shows misconfigurations inside the OS. Best for compliance and deep internal assessment. Risk: scanner admin holds admin credentials for all systems — insider threat concern. Mitigate with PAM solution or service account with restricted logon hours.
Non-Credentialed Scan
Sends test packets without logging into the target. Finds fewer vulnerabilities — simulates an external attacker's view. Can still probe with default passwords and test application vulnerabilities. Best for: external scans, attacker perspective, situations where giving out credentials is too risky.
Server-Based Scan
Centralised scanning server (e.g. Nessus) launches scans against target systems over the network. Simple architecture. Requires firewall exemptions for scanner-to-target traffic. If the scanner server goes down, all scanning capability is lost. Static IP needed so firewall rules can identify trusted source.
Agent-Based Scan
Software agents installed on each target perform local scanning and report back to a management server. Advantages: lower network impact, resilient to server outage, works on offline/mobile devices (laptops on travel). Disadvantages: OS-specific agents needed (Windows/Linux/Mac/iOS/Android = multiple codebases), agent can be bypassed by rootkit malware. Hybrid approach (agent for laptops/mobile, server-based for desktops/servers) is common.
A vulnerability scanner must be configured to work with — not against — your network's security controls. If you don't configure exemptions correctly, the scanner is either blocked from reaching targets, or the IDS/IPS blocks the scanning traffic as suspicious.
Segmented networks
When VLANs and subnets are in use, a single scanner in one segment may not reach other segments. Options: open firewall rules to allow scanner traffic across segments (minimum ports); or install separate scanners in each enclave and report to a centralised server. Never disable the firewall entirely during scanning — this is a terrible practice despite being mentioned in textbooks.
Firewall exemptions
Firewalls will block scanning traffic unless exceptions are added. Configure firewall rules to allow scanner (or agent) traffic from a specific trusted static IP. Use static IPs for all scanning servers — this allows precise ACL rules. Don't open ports to all sources, only to your scanner IPs.
IDS/IPS exceptions
Your IDS/IPS will flag vulnerability scanning activity as an attack — because it looks like one. Add exceptions for your scanner's IP addresses so they're treated as trusted traffic. Without this, your IPS will block your own scans. Same applies for agent-based scanning — agent activity must be whitelisted.
Feed access rules
Scanners must reach the internet to download vulnerability feed updates. Configure firewall rules to allow the scanner to reach only the specific update URLs — not general internet access. Lock down scanner internet access to update sites only.
Never disable your firewall for scanning: Some organisations open a "scanning window" where the firewall is disabled to allow scans. This is a significant security risk and bad practice. Instead: install scanners in each network segment, or configure specific firewall rule exceptions for your scanner IPs. The extra configuration cost is worth it.
6
Scheduling & Constraints — When, How Often, and Why
Scan frequency is a risk management decision — not a technical one. More frequent scanning = less risk exposure but more resource cost. The right answer depends on your organisation's risk appetite, data sensitivity, and operational constraints.
When should you scan?
New system
When deploying any new or updated system. Know the vulnerability posture before it joins production.
New CVE
When new vulnerabilities are publicly disclosed. Example: WannaCry 2017 — immediately scan your network for the SMBv1 vulnerability.
After breach
Following any security breach. Attackers come back — plug all holes, not just the one they used to get in.
Regulatory
PCI DSS requires a quarterly external scan. Sarbanes-Oxley, HIPAA, and other regulations may specify their own frequencies.
Scheduled
On your defined recurring schedule — ideally weekly. Microsoft Patch Tuesday fires weekly; weekly scanning aligns with the patch cycle.
Technical constraints on scan frequency
CPU / memory spikes
Scanning causes the target system's CPU to spike to near 100% during the scan. Real users notice this. Schedule scans outside business hours for critical production systems. Agent-based scans are slightly less disruptive than server-based.
Feed update frequency
Vulnerability feeds only update so often — daily at most, sometimes weekly. Running the scanner 10 times per day won't find new vulnerabilities between feed updates. Scan after each feed update is the natural rhythm.
Network bandwidth
Active scanning generates significant network traffic. Scanning the same segment simultaneously from multiple scanners can cause a self-inflicted DoS. Scope and schedule carefully.
Cost
Each scan consumes analyst time to review results, infrastructure resources, and (for agent-based tools) licensing costs per agent. Scan as frequently as risk warrants — not as frequently as technically possible.
Professional recommendation: Weekly scanning is a good baseline for most environments. Monthly is acceptable for lower-risk internal systems. Quarterly is the minimum for PCI DSS external scans. Systems handling sensitive/classified data should be scanned more frequently and with credentialed scans.
7
Vulnerability Feeds — SCAP, OVAL, XCCDF
Vulnerability feeds are the regularly updated databases of known vulnerabilities that a scanner uses to test your systems. Like antivirus signature updates, if you don't update the feed, you're scanning with stale information. Commercial tools (Nessus = "plugins", OpenVAS = "NVTs") require ongoing subscriptions. All feeds use the SCAP standard for cross-tool compatibility.
The overarching NIST framework that standardises how vulnerability scanning is performed, how results are reported, and how vulnerabilities are scored and prioritised. Because all tools speak SCAP, vulnerability data can flow between different tools and databases. Upholds internal and external compliance requirements.
OVAL
Open Vulnerability and Assessment Language
An XML schema for describing system security states and querying vulnerability reports. Defines what a vulnerability looks like on a system in machine-readable format. Allows different tools to describe and query the same vulnerability data using the same language.
XCCDF
Extensible Configuration Checklist Description Format
An XML schema for developing and auditing best practice configuration checklists. Replaces the old 30–50 page written hardening guides. Those same steps are now in machine-readable format — compatible software runs the 30 configuration checks automatically, without the admin doing each one manually.
The actual scripts that check for specific vulnerabilities. Unlike antivirus signatures (pattern match only), these are active test scripts that attempt to exploit the vulnerability on the target and report whether it succeeded. Commercial scanners require paid subscriptions for current feeds.
How feeds actually work: When a scanner finds a vulnerability, it's running an actual exploit script against your system to check if it's vulnerable. If the exploit succeeds, it reports the finding. This is why safe-scan mode exists — some exploits could crash the system, so safe mode skips those unless you explicitly enable unsafe scanning.
8
Scan Sensitivity & Templates — Four Types
Scan sensitivity determines how aggressively the scanner tests a target. A scan template pre-configures which plugins to use, which targets to scan, and whether to use safe mode. Most tools (like Nessus and OpenVAS) provide pre-built templates for common use cases.
🔍
Discovery Scan
Creates and updates an asset inventory. Performs network enumeration (ping sweep + port check). Does NOT scan for vulnerabilities — just finds what's there. Fast. The first step before a deeper scan. Essentially the same as running Nmap across the network.
Scans for unpatched software and basic configuration issues. Selects plugins appropriate for the identified OS (no Windows plugins on Linux targets). Uses previous scan results to skip already-verified-clean checks. Faster than a full scan. Good for routine weekly vulnerability checks.
Comprehensive — forces all plugin types. Safe mode may be disabled (tests exploits that could crash the target). Ignores all previous scan results and rescans everything from scratch. Takes much longer and carries higher risk of service disruption. Use only during maintenance windows on non-critical production systems.
Use: periodic deep assessment, post-incident, high-sensitivity systems
📋
Compliance Scan
Scans against a specific compliance framework checklist (e.g. PCI DSS, HIPAA, CIS Benchmarks). Pre-built templates — just specify targets. Automatically selects the right plugins and configuration checks for that framework. PCI DSS quarterly external scans use this type. Required outputs align with audit evidence requirements.
Exam: PCI DSS = quarterly external scan. This is specifically tested on the CySA+ exam. If you see "which regulatory standard requires a quarterly scan?" — the answer is PCI DSS. No other regulatory requirement frequency is required to memorise for this exam. PCI DSS applies to any organisation that processes, stores, or transmits payment card data.
9
Scanning Risks — Protecting Results & PAM
Risks scanning can cause
Crashing target systems
Printers, VoIP phones, and embedded systems react unpredictably to scanning. Even desktop OS scanning can trigger reboots if exploits succeed. Use safe-scan mode and create dedicated scopes for sensitive device types.
Network overload
Scanning too many systems simultaneously generates massive traffic. Can self-inflict a DoS. Scope carefully, stagger scan timing, and never run multiple scanner engines against the same segment simultaneously.
Exposing the scan results
Scan results are a blueprint for attacking your network. If an attacker obtains your vulnerability report, they know every weakness. Encrypt scan results at rest and apply restrictive ACLs — only authorised personnel should access results.
Credential exposure
Credentialed scans require admin credentials. Scan administrators effectively have admin access to all scanned systems. This creates insider threat risk. Mitigate with PAM or service accounts with restricted logon hours.
Privileged Access Management (PAM) for credentialed scanning
A PAM solution is the best way to mitigate the insider threat risk of credentialed scanning. Instead of giving scan admins a permanent admin password, PAM automates credential management:
How PAM works
1. Scanner requests credentials from the PAM server. 2. PAM server logs into the target and changes its password to a random one-time value. 3. PAM provides that credential to the scanner. 4. Scanner completes its scan. 5. PAM server changes the password again immediately. The scan admin never sees the credential — it exists only during the scan.
If PAM is not available
Use a dedicated service account with restricted logon hours (midnight–2 AM only). If someone uses that account at 3 PM, it's an insider threat indicator — escalate immediately. The service account limits both the access window and the scope of potential misuse.
Static IPs for scanners
Give all scanning servers static IP addresses. This lets you write precise firewall ACL rules allowing only those IPs to perform scanning traffic — not the entire network. Reduces attack surface while keeping scanning functional.
Additional best practices: Use a dedicated service account (not personal admin accounts) for credentialed scans — one password change updates all scans across the domain. Minimise open ports to only what scanning requires. Encrypt and ACL-protect all scan result files. Don't over-prioritise open ports for scanning at the expense of increased attack surface.
Exam
Quick Reference Cheat Sheet
Vulnerability assessment
3 steps: (1) Collect target attributes (baseline). (2) Analyse current vs. baseline (what changed?). (3) Report results. Automated tools do the scanning — human analyst prioritises findings by asset criticality. Every vulnerability = a risk to accept/mitigate/transfer/avoid.
7-step scanning workflow
1 Establish baseline (install + patch). 2 Initial scan. 3 Analyse vs. baseline. 4 Corrective actions. 5 Re-scan to verify. 6 Document + report to stakeholders. 7 Ongoing scanning. Mantra: SCAN → PATCH → SCAN. Align scan frequency with patch cycle.
Internal vs. external scan
Internal = from inside LAN, no firewall, most findings, use for baseline + compliance. External = from internet, through firewall, fewest findings but highest priority (attacker's view), required for PCI DSS. Use both in your programme. PCI DSS = quarterly external scan (memorise this).
Scanner types
Passive = traffic only, no probes, fewest findings. Active = sends probes, most findings. Credentialed = logs in as admin, most findings, insider threat risk. Non-credentialed = no login, external attacker view. Server-based = one central scanner (Nessus). Agent-based = software on each host — better for offline/mobile, but OS-specific agents needed.
Scanning parameters
Segmented networks → scanner per enclave OR firewall rules. Never disable firewall for scanning. IDS/IPS must whitelist scanner IPs. Agent traffic must be exempted from IDS rules. Feed update sites need outbound firewall rules (nothing else). Static IPs for scanning servers enable precise ACL rules.
Scheduling
When to scan: new system, new CVE, post-breach, regulatory requirement, scheduled. Weekly = recommended minimum. Monthly = acceptable for low-risk. Quarterly = PCI DSS minimum. Constraints: CPU spikes, feed update timing, bandwidth, cost. Don't scan continuously — diminishing returns + resource cost.
SCAP / feeds
SCAP = NIST standard framework for vulnerability scanning automation. OVAL = XML schema for describing vulnerabilities (what it looks like). XCCDF = XML schema for configuration checklists (machine-readable hardening guides). Plugins (Nessus) / NVTs (OpenVAS) = actual test scripts that run exploits. Paid subscription required for current feeds.
Crash risk: printers/VoIP/embedded — use safe mode, dedicated scope. Network overload: stagger, scope carefully, never multi-engine same segment. Results: encrypt + ACL-protect (blueprint for attackers). Credential risk: use PAM (one-time use credentials) or service account with restricted logon hours. Static IPs for scanner ACLs.