Vulnerability management e assessment

Il ciclo di vulnerability management

Il vulnerability management non è un’attività una tantum ma un processo ciclico e continuo, perché nuove vulnerabilità (CVE) e nuovi asset compaiono di continuo. Le fasi fondamentali che devi saper distinguere sono:

1. Identificazione (discovery) — inventario degli asset e scoperta delle vulnerabilità presenti su host, servizi e applicazioni. Non puoi proteggere ciò che non sai di avere: l’asset discovery precede sempre lo scanning.
2. Valutazione (assessment/prioritizzazione) — classificare la gravità delle falle. Si usa lo standard CVSS (Common Vulnerability Scoring System, punteggio 0–10) affiancato al rischio reale = criticità dell’asset × esposizione × probabilità di sfruttamento. Una vulnerabilità CVSS 9.8 su un host isolato di test conta meno di una 7.5 su un server esposto in DMZ.
3. Mitigazione / remediation — applicare la contromisura: patch, hardening della configurazione, modifica di ACL, disabilitazione di un servizio. Quando la patch non è disponibile subito si applica un workaround o un controllo compensativo (mitigation), non una remediation definitiva.
4. Verifica e reporting — rescanning per confermare la chiusura della falla e documentazione per audit e compliance.

Questo ciclo si ripete e alimenta il processo di threat detection: i risultati orientano dove concentrare monitoraggio e detection.

Active vs passive reconnaissance

La distinzione è centrale nell’esame.

La passive recon raccoglie informazioni senza toccare il bersaglio, quindi è difficilmente rilevabile. La active recon invia traffico e ottiene dati più precisi (porte aperte, versioni), ma lascia tracce ed è intercettabile da IDS/IPS come Cisco Firepower o Secure IDS.

Port scanning e automazione degli scanner

Il port scanning (tipicamente con Nmap) mappa quali porte TCP/UDP sono aperte e quali servizi girano. Concetti chiave:

• TCP SYN scan (half-open): invia SYN e non completa il three-way handshake, più discreto.
• TCP connect scan: completa l’handshake, più rumoroso e loggato.
• Service/version detection: identifica versioni per correlare a CVE note.

I vulnerability scanner automatici (es. Nessus, OpenVAS, Qualys) vanno oltre: confrontano servizi e versioni rilevati con un database di firme/CVE e producono un report con severità. L’automazione consente scansioni schedulate ricorrenti su ampie reti — indispensabile per la scalabilità del processo — ma resta un’attività di rilevazione, non di sfruttamento.

Penetration testing e remediation

Il penetration test simula un attaccante reale: dopo aver identificato le falle, tenta di sfruttarle attivamente (exploitation) per dimostrarne l’impatto concreto — accesso non autorizzato, escalation di privilegi, movimento laterale. Fasi tipiche: recon → scanning → exploitation → post-exploitation → reporting con raccomandazioni di remediation.

Rispetto allo scan automatico, il pen test è manuale, guidato da competenza umana, conferma se una falla è realmente sfruttabile (eliminando i falsi positivi) e va condotto solo con autorizzazione scritta (rules of engagement / scope). L’output alimenta direttamente il piano di remediation prioritizzato.

Trappole tipiche d’esame

• Scenario: la domanda chiede quale attività “individua/elenca” le vulnerabilità senza sfruttarle. → Risposta: vulnerability scan (rileva e classifica). Se invece si chiede quale attività sfrutta attivamente le falle per dimostrarne l’impatto, la risposta è penetration test. Non confonderli: lo scan trova, il pen test buca.

• Scenario: uno scanner segnala una vulnerabilità critica ma la verifica manuale mostra che non è sfruttabile. → Risposta: è un falso positivo. Gli scanner automatici, basandosi su firme e versioni, generano falsi positivi (e falsi negativi); serve validazione umana, non applicare patch alla cieca su ogni alert.

• Scenario: raccolta informazioni tramite WHOIS, DNS pubblico o Shodan, senza toccare il target. → Risposta: passive reconnaissance. Un ping sweep o un port scan sono invece active reconnaissance (rilevabili nei log).

• Scenario: patch non ancora disponibile per una CVE nota su un server in produzione. → Risposta: applicare un controllo compensativo / mitigation (ACL restrittiva, IPS signature, disabilitazione del servizio), non attendere passivamente. La remediation definitiva è la patch, quando esce.

• Scenario: si chiede il primo passo del ciclo di vulnerability management. → Risposta: identificazione/inventario degli asset (discovery), non lo scanning: non puoi valutare ciò che non hai censito.