Chapter 10 — Vulnerability scanning
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Authorised scanning"]
N2["10.2 Reading results"]
N3["10.3 Fixing"]
N4["10.4 Verifying"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Authorised scanning"]
N2["10.2 Reading results"]
N3["10.3 Fixing"]
N4["10.4 Verifying"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Authorised scanning]
|
v
[10.2 Reading results]
|
v
[10.3 Fixing]
|
v
[10.4 Verifying]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) run authorised vulnerability scans; (2) interpret scan results; (3) verify fixes.
10.1 Authorised scanning
Vulnerability scanners check systems for known weaknesses. Jamal learns that scanning must be authorised in writing, scheduled to avoid busy times and limited to agreed systems. Riverbend's IT manager approves a monthly scan of the head office and one centre, outside opening hours. Ms. Grant reminds students that scanning someone else's system without permission is illegal in many countries. Jamal keeps a copy of the signed approval with the scan results. He runs the first scan with the IT manager watching, so any unexpected effect on the centre's systems can be handled immediately.
10.2 Reading results
The scan produces a long list of findings with severity ratings. Jamal learns that scanners produce false positives, reporting a weakness that is not present, and that severity ratings do not account for local context. A finding on an internal printer rated high may matter less than a medium finding on an internet-facing system. He sorts findings by severity and exposure and checks the top items manually. He confirms two false positives by checking the software versions directly and records them so they can be ignored in future scans.
10.3 Fixing
Jamal works with the IT manager to fix the top findings: an outdated remote access tool on the file server, a weak encryption setting on an internal website and the camera recorder's old firmware. Each fix is recorded with the date and the person responsible. He learns that clear records help when auditors or insurers ask whether known weaknesses were addressed. The IT manager updates the remote access tool and applies the new encryption setting, while Jamal downloads and installs the camera recorder firmware during a closed period. Each change is tested before the centre reopens.
10.4 Verifying
After fixing, Jamal reruns the scan on the affected systems to confirm the findings have gone. One remains, because the remote access tool had two installations. He removes the second and rescans successfully. Ms. Grant notes that verification is essential, because assuming a fix worked without checking is a common source of lingering weaknesses. Jamal adds a rescan step to the monthly checklist, so every fix is confirmed before the finding is closed. He also records the second installation in his notebook as a lesson: inventories of installed software should be checked before assuming a single fix is complete.
Worked example
Jamal runs authorised monthly scans, sorts findings by severity and exposure, fixes three top findings and verifies by rescanning, catching a second installation.
Synthetic case. Scans are synthetic.
Errors and limits
Assuming a fix worked without rescanning leaves weaknesses in place.
Exercises
- EX028 — Scan approval. Who approves the scan? Rubric: 3 = the IT manager, in writing;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX029 — False positive. What is a false positive? Rubric: 3 = a reported weakness that is not present;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX030 — Remaining finding. Why did one finding remain after fixing? Rubric: 3 = a second installation of the tool;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 10 (chapter 10 of 30)
← Chapter 09 · Course chapter index · Chapter 11 →
Continue to the next authored lesson.