Vulnerability assessment: come capire se i problemi critici del report sono veri

Cos'è un vulnerability assessment, e cosa vede quando è fatto da fuori

Un vulnerability assessment è una verifica che cerca le debolezze note di un sistema e le mette in fila per gravità. Quello che arriva più spesso sulla scrivania di un titolare è la versione esterna e automatica: uno scanner fa al sito le domande che potrebbe fare chiunque da internet (quali file risponde, che certificato usa, come è configurata la posta) e prova a interpretare le risposte. Quascan lavora così, senza entrare nei sistemi dell'azienda.

Il limite sta nell'interpretazione. Molti siti rispondono in modi che lo scanner non prevede: la pagina di cortesia dove ci si aspetta un errore, la schermata anti-bot di Cloudflare che copre il sito vero, la configurazione della posta scritta sul dominio senza il www mentre lo scanner la cerca su quello con il www. Davanti a una risposta così, uno scanner può dichiarare che il controllo non è concluso, oppure tirare a indovinare. Tirare a indovinare porta quasi sempre a un allarme, perché un report pieno di rosso sembra più utile di uno che ammette cosa non ha visto. E su un report pieno di rosso è più facile vendere l'intervento.

A noi è successo in più modi, tutti diversi:

• un'azienda con la posta protetta nel modo più rigoroso possibile si è sentita dire che quella protezione le mancava del tutto, perché lo scanner la cercava all'indirizzo sbagliato
• un server dei nomi lento a rispondere è diventato una protezione della posta dichiarata assente
• un certificato installato senza uno dei suoi pezzi intermedi è finito nel report come sito senza HTTPS, in rosso, mentre il lucchetto nel browser c'era
• un'applicazione che risponde con la sua pagina iniziale a qualunque indirizzo si è vista attribuire file di WordPress che non ha mai avuto

La prima correzione era sbagliata anche lei

Per riconoscere i server gentili abbiamo aggiunto un controllo semplice. Prima di cercare i file, lo scanner chiede un indirizzo inventato e mette da parte la risposta; se poi un file "trovato" ha più o meno la stessa lunghezza, lo scarta. Il sito dell'inizio è passato da 71 a 95, senza più critici. Abbiamo ricalcolato anche tutti i punteggi con cui confrontiamo i siti tra loro, perché erano costruiti sui numeri sporchi: è lo stesso principio del misurare sui dati veri prima di fidarsi di un confronto.

Un mese dopo, due report usciti verso i clienti erano di nuovo sbagliati. Uno diceva "copia del database esposta". Quel server inseriva in ogni pagina un codice casuale, diverso a ogni richiesta, e così due risposte identiche avevano sempre lunghezze diverse. Il controllo scritto per evitare i falsi allarmi non poteva accorgersene.

La regola: un problema critico si segnala solo con la prova

A settembre abbiamo rivisto tutti i controlli con una regola sola. Un problema entra nel report quando c'è la prova. Per un file esposto la prova è averne letto il contenuto e riconosciuto che è proprio quel file. Per un certificato che non passa la verifica, lo scanner deve dire cosa non va: scaduto, emesso per un altro nome, catena incompleta.

Quando un controllo non arriva a una conclusione, perché il server non risponde o mostra una schermata anti-bot, il risultato va in una sezione a parte del report, i controlli non conclusi. Lì resta, senza diventare un allarme. Il report adesso è più corto, e ogni riga che contiene il vostro tecnico la può verificare da solo.

Per un audit interno faremmo la scelta opposta. Con un team che controlla in cinque minuti, un falso allarme costa un ticket chiuso subito e un problema mancato costa molto di più, quindi conviene segnalare tutto. Un report che arriva alla direzione ha un altro lettore: chi lo riceve non può controllare un allarme da solo e lo gira al responsabile IT o al fornitore del sito. Se il primo critico che quella persona apre è falso, il documento perde credito tutto intero, comprese le cose vere scritte dentro. Per la stessa ragione preferiamo sistemi che dichiarano quando non sanno rispondere: ne parliamo nella nota su un interruttore per ogni integrazione fragile.

Vulnerability assessment o penetration test: quale serve

Sono due lavori diversi e rispondono a due domande diverse. Il vulnerability assessment chiede quali debolezze note ci sono, e restituisce un elenco ordinato per gravità. Si fa in buona parte con strumenti automatici, costa meno e si può ripetere spesso, per esempio dopo ogni rilascio importante. Il penetration test chiede fin dove arriverebbe qualcuno che attacca davvero: una persona prova a sfruttare le debolezze, una dopo l'altra, e documenta i percorsi che funzionano. Richiede più tempo e più competenza, e si fa più di rado.

Per un'azienda che parte da zero, l'ordine sensato è quasi sempre lo stesso: prima un assessment, poi la verifica dei critici che ne escono, poi il penetration test sulle parti che contano di più, come il gestionale esposto online o l'area clienti. Un critico uscito da un assessment automatico è un'ipotesi. Il penetration test, o una verifica fatta a mano, dice se è raggiungibile.

NIS2 per le PMI: il vulnerability assessment basta?

Da solo no. La NIS2, recepita in Italia con il D.Lgs. 138/2024, chiede misure di sicurezza che per buona parte non si vedono da internet: chi ha accesso a cosa, come si fanno e si provano i backup, cosa succede quando c'è un incidente, chi ne risponde in azienda. Uno scan esterno del sito copre una fetta piccola di questo elenco. È utile per trovare le porte lasciate aperte e per avere evidenze ripetute nel tempo, e da solo non dimostra la conformità.

Chi è stato inserito nell'elenco dei soggetti NIS nel 2025 ha 18 mesi dalla comunicazione dell'ACN per adottare le misure di base: per la maggior parte delle aziende la scadenza cade a ottobre 2026. La data esatta è scritta sulla comunicazione ricevuta. C'è poi un effetto che tocca anche chi nell'elenco non c'è: le aziende e gli enti soggetti alla NIS2 devono tenere sotto controllo la sicurezza dei propri fornitori, e i questionari arrivano a cascata. Per molte PMI la prima richiesta di un vulnerability assessment arriva da un cliente, o da una gara nella pubblica amministrazione.

In quel caso conviene consegnare un report che regge a una seconda lettura. Un documento con critici falsi, girato al cliente, apre domande che poi toccherà chiudere una per una.

Cosa chiedere a chi vi manda il report

Sono domande che stanno in una mail, e le risposte si capiscono anche senza essere tecnici.

• Per ogni problema critico, qual è la prova? Se la risposta è che il server ha risposto in un certo modo, la prova manca.
• Il report separa i problemi trovati dai controlli che non sono riusciti? Se è tutto verde o tutto rosso, senza niente in mezzo, qualcosa è stato indovinato.
• Il report dice cosa non può vedere? Da fuori restano invisibili i backup, gli accessi del personale, le procedure. Per la NIS2 è la parte che pesa di più.
• Chi ha scritto il report è anche chi vi vende la correzione? Se sì, fate controllare i critici a qualcun altro prima di approvare la spesa.
• Lo stesso controllo, rifatto oggi, dà lo stesso risultato? Un allarme che compare e sparisce a ogni scansione dipende da come risponde il server.

Se avete un report in mano e non sapete quanto fidarvi, lo leggiamo con voi e vi diciamo quali critici hanno una prova dietro. Fa parte del lavoro che facciamo in cybersecurity, per le aziende e per chi lavora nel settore sicurezza. Quando la sicurezza va costruita dentro un gestionale o un'applicazione nuova, entra nel progetto di software su misura dal primo giorno. Come è fatto lo scanner lo raccontiamo nel caso, e Quascan si trova anche tra i nostri prodotti.