13.3 External vs Internal, Web vs Network Scanning
Key Takeaways
- Vulnerability scanning regularly inventories weaknesses from new assets, configuration drift, and newly published CVE records — it is a finding program, not an exploit tutorial.
- External scans see internet-facing surface; internal scans see patch and service gaps that outsiders cannot reach. A complete strategy uses both.
- Network scans inventory hosts, ports, services, and missing patches; web scans crawl application paths and check application-layer weaknesses such as injection classes and missing security headers.
- Vulnerability management owns cadence, credentials, exception tickets, and patch SLAs. The SOC owns the live alert queue and exploitation-in-the-wild incidents.
- Authorized scanner traffic that matches an IDS signature is a benign true positive: the probe really happened, and it was allowed. Do not page it as a breach, and do not call it a false positive because packets were sent.
13.3 External vs Internal, Web vs Network Scanning
Vulnerability scanning is a scheduled, authorised attempt to find security weaknesses: missing patches, exposed services, default credentials, outdated libraries, and misconfigured applications. This independent OpenExamPrep section covers SAL1 Vulnerability Scanning topics: why scans must be regular, how external differs from internal, how web differs from network, and how those activities sit in a security strategy. It does not teach you to exploit findings. SAL1 L1 analysts need to read scan-related alerts and tickets, not to run exploit modules.
A scan is a snapshot. New virtual machines appear, developers open ports, and Common Vulnerabilities and Exposures (CVE) records are published continuously in sources such as the National Vulnerability Database (NVD). A scan from last quarter does not describe this week's attack surface. Regular scanning is how the organisation notices drift. Recurrence also closes the loop: after a patch window, you scan again to see whether the finding actually disappeared.
Purpose and place in strategy
Vulnerability scanning feeds the Identify and Protect work of a security program even though SOC shifts live in Detect and Respond. Scans produce a backlog for system owners. Patching, configuration hardening, and risk acceptance reduce the chance that the SOC later sees a true-positive exploit against that hole. If scanning never happens, the SOC inherits preventable incidents. If scanning happens but nobody patches, the SOC still inherits the incidents — plus a report that predicted them.
Strategy uses exposure and exploitability, not raw finding counts. An internet-facing remote-desktop service with a known remote bug outranks a missing workstation font patch behind three firewalls. Common Vulnerability Scoring System (CVSS) numbers appear on tickets as a starting rank; they are not automatic isolation orders for L1. Business context (medical device, payroll file server, unused lab PC) still belongs to vulnerability management and the asset owner.
| Scan question | Why it matters |
|---|---|
| What assets exist? | You cannot patch a server the inventory missed |
| What is reachable from where? | External findings are attacker-visible; internal findings enable lateral movement |
| What is actually vulnerable? | Banners lie; credentialed scans see missing patches |
| Did we fix it? | Rescan after change control |
| What do we accept? | Documented exceptions stop the same CVE from being a weekly page-out |
External versus internal scanning
External scanning runs from the internet (or from a vendor's cloud probes) toward addresses and names you publish: web sites, mail gateways, VPN portals, partner APIs. It answers: what could a stranger with no VPN account see and fingerprint? Typical findings are open ports that should not be public, expired or weak TLS, exposed administration interfaces, and internet-facing software with known CVEs.
Internal scanning runs from inside the organisation — a scanner appliance on a datacenter VLAN, an agent, or a jump host. It answers: what would an attacker or a worm see after a foothold? Typical findings are missing operating-system patches, SMBv1 left on, database ports on user VLANs, default community strings, and unauthenticated service banners. Internal unauthenticated scans see less than credentialed (authenticated) scans, which log in with a locked-down service account and read patch level the way an administrator would.
Both vantages belong in a comprehensive program. External-only programs miss the workstation that will become ransomware staging. Internal-only programs miss the forgotten test site still mapped on a public IP. L1 does not choose the calendar, but L1 must recognise which vantage produced a ticket: "external: RDP on a public IP" is a different urgency story than "internal: missing patch on an isolated printer VLAN."
Fragile environments (some operational-technology controllers, old medical devices) can fault during aggressive scans. That is why scan windows, exclusions, and throttling exist. Those exclusions are vulnerability-management decisions. If a device is never scanned, say that coverage gap in incident notes when the SOC is asked whether the host was "known vulnerable."
Web versus network scanning
Network vulnerability scanning inventories hosts and services: live IPs, open ports, service versions, missing OS and application patches, default credentials on network services, SNMP and file-share misconfiguration. It is wide. It is relatively shallow on any one web form.
Web application scanning crawls a site or API the way a user (or a scripted user) would: paths, parameters, cookies, authentication to a test account if provided. It looks for application-layer weakness classes such as injection flaws, cross-site scripting conditions, insecure session handling, and missing security headers. For SAL1 you must know that those classes are what the scanner is aimed at. You must not use this study guide as a cookbook to exploit them. Verification of a web finding belongs to application security or a controlled test environment, not to an L1 "proof" on production data.
| Dimension | Network scan | Web application scan |
|---|---|---|
| Primary objects | Hosts, ports, services, OS patches | URLs, parameters, sessions, app libraries |
| Typical engine | Service fingerprint and CVE correlation | Crawler plus app-layer checks |
| Blind spot | Business logic in a form the crawler never reached | A host with no HTTP service |
| L1 SOC overlap | IDS sees port sweeps and exploit-kit signatures | WAF and IDS see injection-like probes |
| Owner of closure | OS and server teams via patch SLAs | App owners via fix-and-rescan |
Neither scan replaces the other. A network scan can report "Apache outdated" while the web scan reports "parameter reflects unsanitised input." Different teams close those tickets. L1 should not merge them into one "the website is hacked" incident without evidence of active exploitation.
SOC versus vulnerability-management ownership
Vulnerability management owns scanner configuration, credentials, cadence, scope, exception tickets, risk acceptance, and patch service level agreements (SLAs). They live in finding trackers. Their success metric is time-to-remediate and coverage, not mean time to acknowledge a SIEM alert.
The SOC owns the live detection queue and incident process. SOC analysts are consumers of scan context ("this host has been unpatched for 40 days") and handlers of exploitation ("someone is firing this CVE against the VPN tonight"). L1 does not become the patch owner because a CVE appeared in a report.
Hand-offs that work:
- Vuln-mgmt publishes scanner IP ranges and windows to the SOC so detections can be tagged.
- SOC escalates suspected in-the-wild exploitation to incident response, copying the open finding if one exists.
- Recurring scanner noise is fixed by allow-listing or detection tuning, not by L1 closing every ticket as false without a lookup.
Hand-offs that fail: L1 trying to "validate" a web finding by submitting attack strings on the live customer site; vuln-mgmt ignoring SOC evidence that a finding is already being exploited; either team treating the other as optional.
False positives, true positives, and scanner traffic in the queue
Two different "false" ideas get mixed in exams and on night shift.
Vulnerability-scanner false positive. The report says CVE-XXXX exists because a banner matched, but the service is a honeypot string, a different product, or already mitigated. That dispute belongs to vulnerability management and the asset owner. L1 should not spend the queue rewriting CVSS.
SOC alert on authorised scanning. The intrusion detection system (IDS), WAF, or SIEM correlation fires because the scanner really sent traffic that looks like an attack: SQL-injection-shaped requests, directory probes, credential guesses against a test page. The packets were real. The activity was approved. Classification is a benign true positive (sometimes called a true positive, benign): the detection logic worked, and the intent was authorised operations, not an adversary. It is not a false positive. A false positive would mean the signature fired with no matching traffic or a hopeless mismatch.
Worked example: Thursday web-scan window
Queue. Twenty High IDS notables: "SQL injection attempt" against www.internal-app.example (fictional) from 10.50.9.12, between 02:00 and 03:00.
Lookup. 10.50.9.12 is in the vulnerability-management web-scanner range. The change calendar lists an authenticated web scan for that application in this window. WAF logs show the same User-Agent as the scanner documentation.
L1 action. Classify as benign true positive, attach the scan-window evidence, do not page the application owner as if customers were being attacked, do not disable the IDS signature globally. Note any extra source IPs in the same rule that are not on the scanner list — those remain separate investigations.
Contrast. The same signature from a random cloud IP at noon, no change ticket, no scanner User-Agent: treat as a suspected attack. Open the incident path. Mention any open web-scan finding as context, not as proof the stranger already succeeded.
Do not "verify" by exploiting. If a ticket asks whether the injection finding is real, the answer for L1 is: point to the scanner report, the owner, and the SLA, or escalate to application security. Do not dump the database to prove a point.
Traps
Treating every CVE in a weekly report as a SOC incident. Treating every IDS hit during a known scan as a breach. Calling authorised scanner traffic a false positive. Assuming internal scans make external scans unnecessary. Assuming a web crawler tested every business workflow. Assuming L1 must run exploits to be useful. Coverage gaps (unscanned OT, forgotten public IPs) are findings about the program, and they belong in notes when leadership asks why Detect never saw the box.
What is the main difference between external and internal vulnerability scanning?
Who typically owns scan cadence, scanner credentials, exception tickets, and patch SLAs, versus who handles scanner-shaped alerts in the SIEM?
IDS fires SQL-injection signatures from 10.50.9.12 during the published web-scan window, and that IP is the documented scanner. How should L1 classify the notables?
How do web application scans differ from network vulnerability scans in this SAL1 topic?