Perché parlare direttamente con il pentester fa la differenza

Un penetration test produce un documento. Il documento arriva, viene letto, e nella maggior parte delle aziende comincia lì il vero lavoro: capire cosa farne.

È il momento in cui emerge una differenza che in fase di offerta nessuno considera, perché sembra un dettaglio organizzativo. Chi risponde quando avete una domanda su quel report? La persona che ha condotto il test, oppure qualcuno che lo ha letto come lo avete letto voi?

Non è una questione di cortesia commerciale. Buona parte di ciò che un test produce non sta nel report, e chi non ha eseguito la verifica non può restituirvelo in nessun modo.

1. Cosa resta fuori dal documento
2. Tre domande che arrivano sempre
3. Quando il vostro sistemista non è d’accordo
4. Le priorità dipendono dalla vostra azienda
5. Quando il report deve arrivare in consiglio
6. Sei mesi dopo, quando cambia qualcosa
7. Come si capisce prima di firmare

Cosa resta fuori dal documento

Un report di test contiene le vulnerabilità individuate, la classificazione di gravità, i sistemi coinvolti e le raccomandazioni. È un documento tecnico completo. E non basta, per una ragione strutturale.

Chi ha eseguito la verifica ha in testa molto più di quello che il documento riporta: quali strade ha provato senza successo, dove si è fermato per scelta e dove per limite di perimetro, cosa gli è sembrato fragile senza raggiungere la soglia di una segnalazione formale, quale vulnerabilità decade se ne correggete un’altra. Quel contesto non entra in un documento — non perché il report sia scritto male, ma perché è conoscenza tacita che si trasferisce solo parlando.

La struttura di un buon report è descritta nell’articolo sul report di vulnerability assessment. Qui parliamo del giorno dopo la consegna, che è il momento in cui la maggior parte del valore si crea o si perde.

Tre domande che arrivano sempre

In pratica, dopo la lettura di un report arrivano quasi sempre le stesse tre domande. Nessuna ha risposta nel documento.

La seconda è quella che si presenta più spesso nelle aziende con una produzione da mandare avanti. Una vulnerabilità su un sistema che non si può aggiornare non è un problema tecnico: è una decisione da prendere fra sostituzione, isolamento e accettazione documentata, e su quel bivio la conversazione con chi ha visto la rete vale più di qualunque raccomandazione scritta. È il tema dell’articolo sulle vulnerabilità che non si possono correggere.

Quando il vostro sistemista non è d’accordo

Un report che riceve obiezioni è un buon segno: significa che qualcuno in azienda lo ha letto davvero e conosce l’infrastruttura abbastanza per contestarlo.

Un esempio concreto, di quelli che capitano. Su una stampante di rete compare una vulnerabilità di gravità massima: credenziali predefinite rilevate, riferite a un sistema audio professionale. Il sistemista chiama e obietta, giustamente, che quella è una stampante e non un mixer.

Ha ragione: la firma deriva dal riconoscimento del servizio FTP e va riclassificata. Ma sullo stesso dispositivo c’è una seconda vulnerabilità che nessuno aveva guardato, perché era meno grave — l’accesso al server FTP è consentito senza autenticazione. Il problema esiste, non è quello segnalato, e la conclusione corretta non era né “ha ragione lui” né “ha ragione il report”.

Dall’altra parte c’è qualcuno che sa chi siete e si ricorda della vostra rete.

Senza quella telefonata sarebbe finita in uno dei due modi peggiori: la vulnerabilità archiviata come falso positivo, con la stampante lasciata aperta, oppure una settimana di discussione su una firma sbagliata.

Le categorie che generano più discussione sono quelle che dipendono dalla logica applicativa e dai controlli di accesso, cioè quelle che uno strumento automatico non decide da sé — le stesse su cui insiste la OWASP Top 10. Ed è anche la ragione per cui un report generato interamente da una scansione resta un elenco, tema dell’articolo sui vulnerability assessment automatici.

Le priorità dipendono dalla vostra azienda

Un punteggio di gravità è calcolato sulle caratteristiche tecniche della vulnerabilità, non sul vostro contesto. È il motivo per cui due aziende con la stessa vulnerabilità dovrebbero intervenire in ordine diverso, e il criterio per farlo non sta nel numero.

Quello che sposta l’ordine sono cose che solo voi sapete e che chi ha testato può interpretare: quale sistema ferma la produzione se cade, quale contiene dati che attivano obblighi di segnalazione, quale può essere aggiornato solo durante la chiusura estiva, quale è già in sostituzione fra tre mesi e quindi non vale la spesa. La logica di come si combinano gravità, probabilità di sfruttamento e contesto è quella descritta in CVSS, EPSS e CISA KEV.

Quando il report deve arrivare in consiglio

C’è un secondo momento in cui la disponibilità di chi ha testato diventa decisiva, e non è tecnico.

Chi in azienda deve portare il risultato di un test a un consiglio di amministrazione, a una proprietà o a un cliente enterprise ha bisogno di una cosa che il report contiene solo in parte: la capacità di rispondere in diretta a domande non previste. Quanto realisticamente rischiamo un fermo? Se investiamo su questi tre punti e non sugli altri sette, cosa resta scoperto? Il nostro concorrente ha avuto un problema simile — noi siamo esposti allo stesso modo?

Sono domande a cui si risponde bene solo avendo visto quella rete. E sono anche il punto in cui una persona tecnica preparata vale più di una presentazione curata: in consiglio la credibilità si costruisce sulle risposte alle domande, non sulle slide.

Vale anche per gli obblighi documentali. Le valutazioni tracciabili richieste dalla direttiva NIS2 non si esauriscono nella consegna di un PDF: richiedono che dentro l’azienda qualcuno sia in grado di spiegare perché sono state prese certe decisioni, e quel qualcuno deve poterlo chiedere a chi ha fatto la verifica.

Sei mesi dopo, quando cambia qualcosa

L’ultimo caso è il meno considerato in fase di offerta e il più frequente nella vita reale.

Passano mesi. Cambiate un firewall, migrate un servizio, aprite un accesso a un nuovo fornitore, mettete in produzione un’applicazione. La domanda che nasce è sempre la stessa: questo riapre un problema che avevamo chiuso?

Non è una richiesta di un nuovo test. È una domanda di dieci minuti a cui chi conosce la vostra infrastruttura risponde subito, e che senza quell’interlocutore diventa una di due cose: un’incognita che vi portate dietro, o un progetto da riaprire con relativo preventivo. Nessuna delle due è la risposta proporzionata alla domanda.

È anche la ragione per cui una verifica una volta l’anno lascia scoperto tutto quello che succede in mezzo, tema dell’articolo sul monitoraggio continuo delle vulnerabilità.

Da noi il numero di chi ha eseguito il test resta quello, e chi chiama trova una persona del team tecnico. Capita di rispondere fuori orario, nei fine settimana e durante le feste: non lo vendiamo come servizio di reperibilità e non lo scriviamo in un contratto, è come lavoriamo. Se quello che ci raccontate richiede una struttura organizzata per la gestione degli incidenti ve lo diciamo subito e vi indirizziamo — ma la telefonata in cui capite se quello che state osservando è un problema serio, quella la fate con noi.

Come si capisce prima di firmare

Vale per noi come per chiunque altro stiate valutando. Quattro domande, si fanno in cinque minuti, e raramente vengono poste.

Chi eseguirà materialmente l’attività, e fa parte dell’azienda con cui firmo o è subappaltata? Chi presenta i risultati è la stessa persona che li ha prodotti? A chi si rivolge il mio tecnico quando ha una domanda dopo la consegna, e in quanto tempo ottiene risposta? Per quanto tempo dopo la chiusura del progetto posso chiedere chiarimenti?

La quarta è quella che distingue di più le offerte, perché quasi nessuna la mette per iscritto. E se un fornitore fatica a rispondere alla prima, l’informazione che avete ottenuto è già rilevante. Sono domande che vale la pena aggiungere al questionario con cui valutate i fornitori, dove di solito si chiede tutto tranne chi farà il lavoro. Per il quadro completo dei criteri di selezione, il riferimento è l’articolo su come scegliere un’azienda di cybersecurity.

Una precisazione per onestà: le strutture grandi hanno vantaggi reali — capacità di assorbire progetti multipli, continuità garantita, presidio internazionale — e in alcuni contesti sono decisivi. Il rapporto diretto con chi esegue il lavoro non è uno di quelli. È un vantaggio delle strutture piccole, e per un’azienda di medie dimensioni in Italia conta più di quanto sembri quando si confrontano due preventivi.