Mappa globale - Vulnerability Assessment#
Che cos'e' un Vulnerability Assessment#
Un vulnerability assessment e' il processo sistematico per identificare, analizzare e documentare le debolezze di sicurezza in sistemi, reti e applicazioni. L'obiettivo e' valutare la security posture dell'organizzazione e produrre un report con le vulnerabilita' trovate e le raccomandazioni per risolverle.
A differenza del penetration test, il vulnerability assessment si ferma all'identificazione: non sfrutta attivamente le falle trovate.
Il processo tipico:
- Definire lo scope (quali sistemi, quali reti)
- Raccogliere informazioni (asset inventory, versioni software)
- Eseguire la scansione automatica
- Analizzare i risultati ed eliminare i falsi positivi
- Produrre il report con CVE e CVSS score
- Raccomandare remediation prioritizzate
Credentialed vs Non-Credentialed#
La distinzione fondamentale tra i due tipi di scan e' il livello di accesso al sistema target. Questa differenza impatta direttamente la qualita' dei risultati e il numero di falsi positivi.
| Aspetto | Credentialed | Non-Credentialed |
|---|---|---|
| Accesso | Account admin (SSH, WMI) | Nessuna credenziale |
| Visibilita' | Versioni esatte, config interne | Porte aperte, banner, comportamento esterno |
| Accuratezza | Alta | Media-bassa |
| Falsi positivi | Pochi | Molti |
| Prospettiva | Difensore dall'interno | Attaccante esterno |
| Usa per | Audit interno, compliance | Vedere cosa vede l'attaccante |
Gli attaccanti tipicamente iniziano non-credentialed. Dopo privilege escalation, possono eseguire scan credentialed anche loro. Per questo molti team security eseguono entrambi i tipi: il credentialed per l'audit interno, il non-credentialed per vedere la superficie esposta.
Dev parallel: e' la differenza tra
npm audit/composer auditeseguito localmente con accesso apackage-lock.jsonocomposer.lock(credentialed: vede esattamente le versioni installate, zero ambiguita') e uno scanner black-box che colpisce il tuo endpoint pubblico cercando di indovinare framework e versioni dai response header (non-credentialed, lo stesso banner grabbing). Un Nessus puntato sul tuo IP pubblico senza login e' non-credentialed; uno scan nella pipeline CI con accesso al codice e' credentialed.
Active vs Passive Scanning#
Oltre alla distinzione credentialed/non-credentialed, gli scan si differenziano anche per il metodo di raccolta dati.
| Tipo | Come funziona | Pro | Contro |
|---|---|---|---|
| Active | Invia probe attivi, interroga i target direttamente | Risultati completi e aggiornati | Puo' impattare i sistemi, genera traffico visibile |
| Passive | Osserva il traffico esistente, nessuna interazione | Zero impatto, invisibile | Meno completo, dipende dal traffico presente |
Agent-Based vs Agentless#
La terza dimensione degli scan riguarda il deployment: il software di scanning gira localmente sull'endpoint (agent-based) o si connette da remoto (agentless).
Dev parallel: e' la distinzione tra un sidecar container (agent-based: gira sempre accanto all'applicazione, raccoglie metriche in tempo reale, va aggiornato) e un init container o script di avvio (agentless: gira al bootstrap, fa quello che deve, si ferma). In cloud, CrowdStrike Falcon e' tipicamente agent-based (daemon permanente sul host); un controllo di compliance che interroga l'API di AWS Config al momento del check e' agentless. Per il Wazuh agent nel lab vedi wazuh-architecture.
Tool principali#
I vulnerability scanner principali che compaiono all'esame Security+:
| Tool | Vendor | Note |
|---|---|---|
| Nessus | Tenable | Il piu' diffuso, basato su plugin, supporta credentialed e agentless. AutoNessus automatizza gli scan |
| OpenVAS | Greenbone | Open source, fork di Nessus originale |
| Qualys | Qualys | Cloud-based, spesso usato in ambienti enterprise |
| Rapid7 InsightVM | Rapid7 | Integra remediation workflow, agent-based disponibile |
Keyword esame per Nessus: "nessun software da mantenere" indica tipicamente la modalita' agentless.
Output e Prioritizzazione#
L'output di una vulnerability scan include CVE identificate, CVSS score, versioni vulnerabili e raccomandazioni di remediation. Il CVSS score e' il punto di partenza per la prioritizzazione, ma non basta da solo: va combinato con il contesto (vedi cvss).
Un risultato va sempre verificato prima di agire: eliminare i falsi positivi e' parte essenziale del processo. Solo dopo la verifica la remediation entra nel change control process aziendale.
| Tipo di risultato | Significato | Azione |
|---|---|---|
| True Positive | Vulnerabilita' reale trovata | Remediation |
| False Positive | Alert su qualcosa che non e' una vuln | Eliminare dal report |
| True Negative | Nessuna vuln, correttamente non segnalato | - |
| False Negative | Vuln reale non trovata | Il caso peggiore: falsa sensazione di sicurezza |
Dev parallel: un false positive in uno scanner e' uguale a un flaky test che fallisce su codice corretto. Un false negative e' il test che resta verde su codice rotto in produzione - il caso peggiore perche' da' falsa sicurezza. Stesso discorso per SonarQube/PHPStan: una regola troppo aggressiva genera false positive (rumore), una troppo permissiva genera false negative.
