Penetration test tools: come leggere l'output

Gli strumenti di penetration test in commercio sono, quasi sempre, scanner di vulnerabilità: restituiscono un elenco di debolezze note, ognuna con un identificativo CVE e un punteggio CVSS. Quell'elenco non è un piano. Diventa utile quando lo ripulisci dai falsi positivi, lo riordini sul tuo contesto e lo traduci in correzioni con un responsabile, una data e una verifica finale.

Qui non trovi una rassegna di prodotti: trovi come si legge il report di uno scanner, come si passa dalla lista al piano di remediation e con quali criteri si sceglie fra scanner interno e test gestito. Per le definizioni ci sono le schede su che cos'è un penetration test e sul vulnerability assessment.

Cosa produce davvero uno scanner

Uno scanner confronta quello che trova sugli asset con un catalogo di debolezze note e segnala le corrispondenze. Nel report escono tre oggetti diversi: l'identificativo CVE, cioè il nome pubblico della vulnerabilità; il punteggio CVSS, una misura di gravità calcolata sulle caratteristiche intrinseche del difetto; il livello di rischio assegnato dallo strumento, che è una scala proprietaria. Il NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (settembre 2008), osserva che gli scanner usano metodi propri per definire quei livelli, e che questo rende difficile confrontare i risultati di strumenti diversi.

Il punteggio dice la gravità, non il tuo rischio

Il CVSS, alla versione 4.0 mantenuta da FIRST, è composto da quattro gruppi di metriche: Base, Threat, Environmental e Supplemental. Il punteggio Base, quello che quasi tutti gli strumenti pubblicano, riflette la gravità secondo caratteristiche intrinseche costanti nel tempo e assume l'impatto ragionevolmente peggiore fra i diversi ambienti in cui il componente è installato. Il gruppo Environmental esiste proprio per rappresentare le caratteristiche specifiche dell'ambiente di un singolo utilizzatore, e la specifica distingue infatti la sigla CVSS-B dalle forme CVSS-BT, CVSS-BE e CVSS-BTE. Il numero nel report è la prima delle quattro parti, non il verdetto sul tuo caso: la specifica lo descrive come un ingresso di un processo di vulnerability management che considera anche fattori esterni al CVSS.

Il SP 800-115 usa un esempio: uno scanner può classificare a rischio moderato un server FTP perché trasmette le password in chiaro, ma se l'organizzazione lo usa solo come server pubblico anonimo il rischio reale è molto più basso. La raccomandazione è esplicita: determinare il livello di rischio appropriato per ogni vulnerabilità, non accettare quello assegnato dallo scanner.

Falsi positivi, falsi negativi, validazione

Sugli scanner applicativi lo stesso documento nota che, come tutti gli strumenti basati su corrispondenza di pattern e su firme, hanno tipicamente alti tassi di falsi positivi, e che soffrono anche degli alti tassi di falsi negativi propri degli strumenti a firma: vanno configurati e calibrati per ridurre entrambi, e i risultati vanno interpretati per isolare le vulnerabilità reali.

Nel capitolo sull'analisi lo stesso documento mette la validazione fra gli obiettivi primari e nota che l'esame manuale del sistema vulnerabile dà risultati tipicamente più accurati del confronto fra due strumenti, perché due strumenti diversi possono produrre gli stessi falsi positivi. Conseguenza operativa: un finding non validato non merita ancora un ticket.

Perché il CVSS più alto non è la prima cosa da correggere

L'ordine giusto per te si ottiene rispondendo a quattro domande su ciascuna voce.

• Da dove è raggiungibile? Lo stesso difetto su un servizio esposto a internet e su una macchina interna senza rotta verso l'esterno non pesa uguale.
• Cosa c'è dietro quell'asset? Il processo che si ferma, i dati che si perdono, il cliente che se ne accorge.
• C'è già qualcosa che limita lo sfruttamento? Segmentazione, autenticazione a più fattori, un account senza privilegi: i controlli compensativi non cancellano il difetto, cambiano l'urgenza.
• Qualcuno la sta sfruttando davvero? È la domanda che sposta di più l'ordine della lista.

Sull'ultimo punto ci sono due riferimenti pubblici e gratuiti. Il Known Exploited Vulnerabilities Catalog di CISA raccoglie le vulnerabilità di cui è documentato lo sfruttamento reale, e CISA indica di usarlo come ingresso del processo di prioritizzazione: se una voce della tua lista è lì dentro, il punteggio conta poco. L'EPSS di FIRST stima invece la probabilità che una CVE venga sfruttata nei trenta giorni successivi, con un valore fra 0 e 1 aggiornato ogni giorno.

Per non ridiscutere i criteri a ogni finding conviene scriverli una volta sola. CISA ne pubblica una versione, SSVC (Stakeholder-Specific Vulnerability Categorization), che tiene insieme stato di sfruttamento, impatti sulla sicurezza fisica e diffusione del prodotto interessato. Valuta cinque elementi e arriva a quattro esiti: Track, che rientra nei normali cicli di aggiornamento, Track*, da tenere sotto osservazione, Attend, da correggere prima dei cicli ordinari, e Act, da correggere il prima possibile coinvolgendo il vertice. Non serve adottarlo alla lettera, serve un criterio equivalente scritto.

Anche la norma ragiona così: il D.Lgs. 138/2024, che recepisce la NIS2, all'articolo 24 comma 1 lettera b) chiede misure proporzionate al grado di esposizione a rischi del soggetto, alle sue dimensioni e alla probabilità che si verifichino incidenti, oltre che alla loro gravità.

Dalla lista al piano di remediation

È il passaggio che separa una scansione utile da un file in un cassetto.

1. Valida. Elimina i falsi positivi prima di distribuire lavoro, con verifica manuale sui casi che contano.
2. Contestualizza. Assegna un tuo livello di rischio con le quattro domande qui sopra, e scrivi perché.
3. Decidi la risposta. Le opzioni sono tre, e le misure di base pubblicate da ACN usano esattamente questi termini: le vulnerabilità sono prontamente risolte attraverso aggiornamenti di sicurezza o misure di mitigazione, ove disponibili, ovvero accettando e documentando il rischio in accordo al piano di trattamento dei rischi.
4. Assegna responsabile e data. Il SP 800-115 chiede che il piano di azione affronti le singole vulnerabilità con azioni specifiche, misurabili, raggiungibili, realistiche e tangibili.
5. Prova la correzione prima della produzione. Il primo passo del processo di remediation descritto nello stesso documento è testarla su sistemi che replicano l'ambiente di destinazione.
6. Verifica e registra. Nuova scansione o retest sul punto corretto, con l'esito scritto: è la parte che un auditor guarda per prima.

Resta fuori una cosa: la causa. Il SP 800-115 chiede raccomandazioni di mitigazione che includano l'esito dell'analisi della causa, distinguendo fra raccomandazioni tecniche e raccomandazioni sui processi. Se la stessa classe di vulnerabilità ricompare a ogni scansione, il problema non è la patch mancante.

Quando lo scanner interno basta

Per una parte consistente del lavoro lo strumento interno è la scelta corretta.

• Igiene periodica su infrastruttura standard e software di mercato: sistemi operativi, ipervisori, apparati di rete, componenti di un fornitore che rilascia aggiornamenti.
• Verifica dopo gli aggiornamenti, per confermare che le correzioni siano applicate ovunque e non solo sulle macchine che qualcuno ricorda.
• Copertura ampia e frequente: nessun test manuale passa ogni mese su tutti gli asset.
• Superficie che cambia spesso: ambienti di staging, macchine che nascono e muoiono, nuove esposizioni da vedere in fretta.

Due condizioni reggono tutto: l'inventario, perché la macchina fuori elenco resta fuori dal report, e il tempo di una persona competente. Il SP 800-115 definisce la scansione un'attività che richiede un alto grado di coinvolgimento umano per interpretare i risultati.

Quando serve un test gestito

Cinque situazioni in cui lo scanner non risponde alla domanda che ti stai facendo.

• Devi sapere se una catena di debolezze porta da qualche parte. Il SP 800-115 avverte che gli scanner non rilevano le vulnerabilità che emergono solo dalla combinazione di molti pattern di attacco, e che uno strumento che assegna un rischio basso a ciascuna voce può lasciare chi valuta falsamente tranquillo: il modo più affidabile per stimare il rischio nel suo insieme è il penetration test.
• Il bersaglio è software scritto su misura. Gli scanner conoscono i difetti pubblicati, non la logica della tua applicazione: è il tema del penetration test sul software e del web application penetration test.
• Un obbligo o un contratto chiedono il test, non la scansione. Capita sempre più spesso nei capitolati e nelle richieste dei clienti enterprise.
• Serve un'evidenza opponibile a un auditor. Un export dello scanner non racconta metodo, perimetro e regole d'ingaggio, una relazione di test sì.
• Hai cambiato architettura. Nuova esposizione, nuovo provider di identità, rete riorganizzata: il rischio si sposta senza che una singola CVE lo segnali.

Il confronto punto per punto fra le due attività sta nella scheda su penetration test e vulnerability assessment. Se un test annuale invecchia in poche settimane, il modello continuativo è il penetration test as a service.

Cosa chiedono le norme

Per chi rientra nel perimetro NIS2 il riferimento italiano è puntuale: le misure di sicurezza di base stabilite dalla determinazione ACN 379907/2025 vanno adottate entro diciotto mesi (ottobre 2026) dalla ricezione della comunicazione di inserimento nell'elenco nazionale NIS, con l'allegato 1 per i soggetti importanti e l'allegato 2 per i soggetti essenziali.

La differenza fra i due allegati, sul nostro tema, è sostanziale. Nell'allegato 2 la misura ID.RA-01 chiede che, per almeno i sistemi informativi e di rete rilevanti, siano eseguite periodicamente e comunque prima della messa in esercizio attività di identificazione delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test, documentate con relazioni che riportino attività svolte, esiti, vulnerabilità rilevate e livello di impatto. Nell'allegato 1 la stessa misura non contiene quel requisito. Entrambi chiedono invece, alla misura ID.RA-08, un piano di gestione delle vulnerabilità documentato e approvato dagli organi di amministrazione e direttivi.

Il resto del quadro:

• Il D.Lgs. 138/2024, articolo 24 comma 2, elenca fra le misure minime la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, comprese la gestione e la divulgazione delle vulnerabilità (lettera e), e le politiche per valutare l'efficacia delle misure di gestione dei rischi (lettera f); il comma 4 aggiunge che chi rileva di non essere conforme adotta senza indebito ritardo le misure correttive. Il quadro completo è nella guida alla NIS2.
• L'Allegato A della ISO/IEC 27001:2022 prevede la gestione delle vulnerabilità tecniche (controllo 8.8) e i test di sicurezza in sviluppo e accettazione (controllo 8.29): dettaglio nella scheda sull'Allegato A.
• Per il comparto finanziario, DORA colloca queste attività nel programma di test di base, mentre il test guidato dalla minaccia (TLPT) resta riservato ai soggetti individuati dalle autorità competenti: vedi i test di resilienza operativa.

Come si mettono insieme le due cose

La scelta non è fra strumento e servizio, è una questione di ritmo: lo scanner dà ampiezza e frequenza, il test gestito dà profondità nei momenti che la giustificano, e il valore di entrambi dipende dal ciclo di remediation che li segue. Resta una terza domanda a cui nessuno dei due risponde: se qualcuno stia provando a sfruttare quelle vulnerabilità adesso. Quella risposta sta nei log, raccolti e correlati in continuo.

AmagisTech lavora con le aziende mid-market italiane su tutte e tre le parti. Se hai una lista di vulnerabilità ferma da mesi e non sai da dove cominciare, parliamone in una call.