Valutazione e Analisi delle Vulnerabilità

Dalla Scansione alla Valutazione: Una Distinzione Critica

La scansione delle vulnerabilità e la valutazione delle vulnerabilità non sono termini intercambiabili. La scansione è la raccolta automatizzata di dati—banner grabbing, rilevamento dei servizi e corrispondenza di firme con vulnerabilità note. La valutazione richiede analisi umana: convalida dei risultati, contestualizzazione degli esiti rispetto all'impatto aziendale e determinazione se una falla segnalata sia sfruttabile nel vostro ambiente specifico. Gli strumenti trattati in questa sezione generano materiale grezzo; la vostra competenza trasforma quei dati in intelligence actionable.

Architettura OpenVAS/GVM e Calibrazione delle Scansioni

Il framework Greenbone Vulnerability Management (GVM), precedentemente OpenVAS, opera attraverso un'architettura modulare che impatta direttamente come si configurano e si regolano le scansioni. Comprendere questi componenti previene la modalità di fallimento comune di lanciare scansioni travolgenti che mandano in crash i target o restituiscono rumore inutile.

Componenti Core:

  • OpenVAS Scanner (openvas-scanner): Il motore di esecuzione che esegue i Network Vulnerability Tests (NVT) sui target
  • Greenbone Vulnerability Manager (gvmd): Il demone di gestione centrale che gestisce le operazioni di database, la pianificazione e la generazione di report
  • Greenbone Security Assistant (GSA)/GSM: Interfaccia web e layer API
  • Database PostgreSQL: Memorizza configurazioni di scansione, risultati e dati degli asset
  • Redis: Agisce come buffer di comunicazione interna tra scanner e manager

Il backend PostgreSQL memorizza non solo i risultati delle scansioni ma l'intera knowledge base delle vulnerabilità. Gli aggiornamenti del feed—che dovete trattare come infrastruttura critica—forniscono nuovi NVT, mapping CVE e firme di rilevamento prodotto. Un feed obsoleto significa punti ciechi. Greenbone fornisce due canali di feed: il Community Feed (ritardato) e il Greenbone Enterprise Feed (in tempo reale). Per ambienti di produzione, pianificate aggiornamenti giornalieri del feed tramite greenbone-feed-sync e verificate il completamento nei log delle attività GSA.

Tecniche di Calibrazione delle Scansioni:

La messa a punto delle prestazioni richiede di bilanciare la completezza con la stabilità del target. La configurazione di scansione predefinita "Full and Fast" carica migliaia di NVT simultaneamente—una ricetta per travolgere sistemi embedded o infrastrutture di rete legacy.

Parametro Impostazione Conservativa Impostazione Aggressiva Caso d'Uso
NVT massimi eseguiti simultaneamente per host 4 20 Embedded/SCADA
Host massimi scansionati simultaneamente 5 30 Sottoreti estese
Timeout NVT 10 minuti 2 minuti Collegamenti WAN lenti

Per sistemi legacy sensibili alla scansione, create una configurazione di scansione dedicata che escluda NVT distruttivi (quelli taggati con destructive_test=true) e abiliti i controlli sicuri. La direttiva exclude_hosts nelle definizioni dei target previene la scansione accidentale di infrastrutture critiche durante periodi di manutenzione a finestre.

# Esempio: Creare una configurazione di scansione conservativa via gvm-cli
gvm-cli socket --xml "<create_config>
  <copy>698f691e-7489-11df-9d8c-002264764cea</copy>
  <name>Legacy-Safe-Conservative</name>
  <comment>Parallelismo ridotto per infrastrutture fragili</comment>
</create_config>"

Nessus Professional vs. Integrazione Tenable.io

Mentre GVM eccelle nella flessibilità open-source, Nessus domina i deployment enterprise attraverso l'ecosistema commerciale di Tenable. La scelta architetturale tra Nessus Professional e Tenable.io va oltre la licenza fino ai flussi di lavoro operativi.

Nessus Professional opera come software standalone installato localmente. Gestite direttamente policy di scansione, pianificazione e archiviazione dei risultati. Questo si adatta a ambienti isolati, reti air-gapped o consulenti che richiedono deployment portatili. Le limitazioni includono nessuna dashboard centralizzata, nessuna separazione multi-utente dei ruoli e nessuna correlazione nativa degli asset cloud.

Tenable.io si sposta verso un modello di distribuzione SaaS con architettura basata su sensori. Gli scanner Nessus deployati nel vostro ambiente comunicano con la piattaforma cloud di Tenable, abilitando la gestione centralizzata delle policy, il monitoraggio continuo e l'integrazione con Tenable's Exposure Management (precedentemente Lumin) per la prioritizzazione basata sul rischio. Il vantaggio critico è il passive asset discovery e l'agent-based scanning che complementano le scansioni di rete tradizionali—essenziali per architetture cloud e remote work.

Per ambienti ibridi, deployate gli scanner Nessus come sensori collegati a Tenable.io mantenendo istanze Professional standalone per enclaves sensibili. Esportate i risultati di Tenable.io via API per correlazione con i risultati GVM nella vostra piattaforma di vulnerability management.

Validazione delle Vulnerabilità e Riduzione dei Falsi Positivi

Gli scanner automatizzati generano falsi positivi attraverso molteplici meccanismi: rilevamento basato su versione senza verifica della patch, errori logici negli NVT e fattori ambientali come load balancer che mascherano le vere versioni dei servizi. La validazione sistematica separa il segnale dal rumore.

Gerarchia di Validazione:

  1. Verifica banner: Catturate le risposte effettive del servizio, non versioni inferite
  2. Analisi changelog: Confermate le pratiche di backport del vendor
  3. Conferma a livello di patch: Interrogate i package manager o le voci di registro
  4. Testing proof-of-concept: Sfruttamento controllato in ambienti non di produzione

Esempio Concreto: La Patch OpenSSH Backportata

Considerate uno scenario in cui OpenVAS segnala "Critico" per CVE-2020-15778 (esecuzione remota di comandi scp) su un server Ubuntu 20.04 LTS che esegue OpenSSH 8.2p1. Lo scanner segnala questo basandosi solo sulla stringa di versione: 8.2p1 appare vulnerabile secondo i dati NVD che mostrano fix nella 8.3p1.

Risultato iniziale dal report OpenVAS:

Vulnerability: CVE-2020-15778 (Critical, CVSS 9.8)
Detected: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
Evidence: Installed version: 8.2p1
Fixed version: 8.3p1

Il vostro processo di validazione:

# Passo 1: Verificare il pacchetto effettivamente installato, non il banner
ssh user@target "dpkg -l | grep openssh-server"
# Restituisce: ii  openssh-server  1:8.2p1-4ubuntu0.5  amd64

# Passo 2: Controllare il tracker di sicurezza Ubuntu per la versione specifica del pacchetto
# Visita: https://ubuntu.com/security/CVE-2020-15778
# Stato: "Released (1:8.2p1-4ubuntu0.2)"
# Il suffisso .5 nella versione installata è più recente della patch rilasciata

# Passo 3: Esaminare i changelog per conferma esplicita del backport
ssh user@target "zcat /usr/share/doc/openssh-server/changelog.Debian.gz | grep -A5 CVE-2020-15778"
# Restituisce: "* SECURITY UPDATE: scp command execution vulnerability
#   - debian/patches/CVE-2020-15778.patch: restrict scp -T handling
#   - CVE-2020-15778"

# Passo 4: Test PoC controllato in ambiente isolato
# Tentare lo sfruttamento di CVE-2020-15778 su build identica
# Risultato: Fallimento (patch efficace)

Conclusione: Falso positivo. Il team di sicurezza di Ubuntu ha eseguito il backport della fix senza cambiare il numero di versione upstream. Il rilevamento basato su firma dello scanner mancava di contesto per le pratiche di patching specifiche delle distribuzioni. Documentate questo come "Rischio Accettato con Verifica" piuttosto che scartandolo del tutto—feed futuri o aggiornamenti NVT possono migliorare il rilevamento.

Interpretazione CVSS e Prioritizzazione del Rischio Aziendale

I CVSS Base Scores forniscono una misurazione standardizzata della severità ma semplificano pericolosamente il rischio. Una vulnerabilità CVSS 9.8 in una rete lab isolata presenta un rischio organizzativo diverso da una falla CVSS 7.5 sul vostro VPN concentrator esposto a internet.

Fattori Supplementari per la Prioritizzazione:

  • Threat Intelligence: È stata osservata sfruttamento attivo in the wild? L'inclusione nel catalogo CISA KEV eleva la priorità indipendentemente dal CVSS
  • Esposizione: Segmentazione di rete, accessibilità del percorso di attacco e controlli compensativi
  • Criticità dell'Asset: Server database che ospitano dati PCI versus server wiki interni
  • Sfruttabilità: Presenza di codice exploit pubblico, malware weaponizzato o moduli Metasploit

Implementate un modello di scoring del rischio che combini CVSS con metriche ambientali. Il Vulnerability Priority Rating (VPR) di Tenable.io e la Severity Class (SC) di Greenbone offrono framework di partenza, ma personalizzate le ponderazioni basandovi sul vostro threat model.

Creazione di Policy Custom per Scansioni Mappate alla Compliance

I framework di compliance (PCI-DSS, CIS Benchmarks, DISA STIGs) richiedono policy di scansione allineate a obiettivi di controllo specifici piuttosto che alla scoperta generica di vulnerabilità.

Costruzione di Policy Mappate alla Compliance:

Per il Requisito PCI-DSS 11.3.2 (scansioni interne delle vulnerabilità), create una configurazione di scansione GVM che:

  • Targetizza solo i sistemi CDE (Cardholder Data Environment) in scope
  • Esclude i risultati informativi dalla generazione del report
  • Mappa esplicitamente i risultati ai numeri dei requisiti PCI-DSS nelle note
  • Esegue trimestralmente con credenziali autenticate per verifica delle patch
<!-- Frammento di policy di compliance GVM -->
<create_config>
  <name>PCI-DSS-11.3.2-Quarterly</name>
  <usage_type>scan</usage_type>
  <preferences>
    <preference>
      <scanner_name>scan_host_alive</scanner_name>
      <value>0</value>  <!-- Assume target raggiungibili; evita flood ICMP -->
    </preference>
  </preferences>
  <nvt_selectors>
    <selector>
      <type>nvt</type>
      <family>General</family>
      <include>1</include>
    </selector>
    <!-- Escludi esplicitamente NVT pesanti sulle prestazioni -->
    <selector>
      <type>nvt</type>
      <name>1.3.6.1.4.1.25623.1.0.10335</name>
      <include>0</include>  <!-- Disabilita test DoS aggressivi -->
    </selector>
  </nvt_selectors>
</create_config>

La scansione autenticata cambia fondamentalmente l'accuratezza. Le scansioni non autenticate mancano patch non riflesse nei banner visibili di rete. Deployate le credenziali di scansione tramite oggetti "Credentials" GVM—chiavi SSH per Linux, SMB per Windows—isolando gli account di scansione con accesso least-privilege e monitorandone l'utilizzo.

Per scansioni attraverso firewall, configurate le definizioni dei target con alive tests utilizzando TCP SYN su porte aperte note piuttosto che ICMP, e documentate gli aumenti di latenza attesi nelle pianificazioni delle scansioni. I sistemi legacy dietro firewall stateful possono richiedere finestre di scansione dedicate e più lente con logging esplicito delle regole firewall per diagnosticare cadute di connessione.