Oggi affrontiamo il tema della corretta gestione delle vulnerabilità parlando di quanto sia importante l’attività di Vulnerability Management per mantenere “alta la guardia” dell’infrastruttura IT aziendale. Ne parlerà Andrea Veca, fondatore e Managing Director di Achab S.p.A., intervistato da Matteo Cecchini, Co-founder e CEO di T-Consulting Srl.
I nostri ospiti:
 |
| Matteo Cecchini |
| Imprenditore IT dal 2007, Matteo è prima di tutto un appassionato di tecnologia. Fin dall’adolescenza si dedica allo studio dei sistemi e del loro funzionamento, con un interesse spiccato per la Cybersecurity. Questa passione lo porta a poter contribuire - all’inizio della sua carriera - a prestigiosi progetti di digitalizzazione e di innovazione tecnologica. Nel 2007 fonda T-Consulting allo scopo di supportare con la giusta tecnologia le imprese del suo territorio, ad oggi è attivo su più fronti, come Presidente di CNA Forlì-Cesena e come membro del Consiglio Direttivo del Distretto dell'Informatica Romagnolo. |
 |
| Andrea Veca |
| Dopo aver conseguito la laurea in Ingegneria Elettronica e il master in Network Systems inizia la sua carriera come consulente e, successivamente, si occupa di sicurezza dell’informazione per lo Stato Maggiore Marina. Nel 1994 fonda Achab S.p.A., dove svolge all’inizio un ruolo tecnico per diventarne più tardi amministratore delegato fino al 2022. Oggi, nel ruolo di Managing Director, gestisce il team che seleziona le migliori tecnologie internazionali da portare sul mercato italiano. |
Il tema della videointervista di oggi: adottare una mentalità di Vulnerability Management
Il punto di partenza da tenere presente è che i software, in quanto tali, sviluppano per loro natura dei bug, delle vulnerabilità, che i criminali cercano e poi sfruttano, di conseguenza è consigliabile prevedere e programmare un Vulnerability Assessment con la giusta frequenza per non rischiare di lasciare aree scoperte per lungo tempo. Il consiglio è quello di fare Vulnerability Management per tendere sempre a una situazione in cui le vulnerabilità sono ridotte al minimo. In questo senso, le parole chiave da ricordare sono due: continuità (nel processo di ricerca delle vulnerabilità) e automazione.
Se sei interessato ad approfondire il tema del Vulnerability Management contattaci cliccando qui .
Transcript intervista:
MATTEO: Buon pomeriggio e ben ritrovati a tutti quanti! In questo nuovo appuntamento sono qui oggi con Andrea Veca, Managing Director di Achab. Ciao Andrea!
ANDREA: Ciao Matteo! Buongiorno a tutte le persone che ci ascoltano!
MATTEO: Eccoci qua. Allora, nuovo appuntamento, nuova chiacchierata. Oggi di che cosa parleremo? Parleremo dell’importanza di una corretta gestione delle vulnerabilità, più che altro da un punto di vista anche di approccio, non solo tecnico, delle vulnerabilità che inevitabilmente fioriscono come margherite all’interno delle infrastrutture IT aziendali. Il tema è un tema che è stato approfondito in modo egregio da Andrea durante il T-CON, oggi vogliamo riprendere un po’ alcuni concetti. Parto con una domanda: dal tuo punto di vista, Andrea, quando parliamo di Vulnerability Management, la prima cosa più importante che ti viene in mente parlando di questa tematica qui, qual è?
ANDREA: Farlo!
MATTEO: Farlo, perfetto!
ANDREA: Sembra una stupidaggine egregia, ma spesse volte manca questo aspetto che non è secondario.
MATTEO: Ottimo, e già con questa risposta in realtà potremmo chiudere la chiacchierata perché purtroppo molto spesso non si fa Vulnerability Management. In che senso? Nel senso che chiaramente quando l’azienda, e neanche tutte, fanno quello che vi sto per dire, si approccia alle tematiche di assessment, quindi viene fatto un Vulnerability Assessment, un Penetration Test o comunque un’attività che, però, per sua natura non è e non può essere un’attività continuativa (la faccio una volta all’anno, una volta ogni 6 mesi, o quello che è), il grande problema è: che cosa succede da quando faccio questa attività a quando questa attività viene reiterata 6/12 mesi dopo? Ecco, raccontaci un po’ il tuo punto di vista, Andrea.
ANDREA: Dunque, innanzitutto quando mi parli di 6 o 12 mesi a me tremano un pochino i polsi perché non sono in grado di indicare la frequenza ideale con cui fare un Vulnerability Assessment, ma mi sento di dire che va fatto molto più frequentemente di due volte all’anno. Una volta fatto questo, mi lancio in un’audace metafora: se io vado dal medico perché ho un problema, il medico mi prescrive delle medicine e io non prendo le medicine, è vero che Dio vede e provvede, mi guarisce, però a quel punto non si capisce perché io sia andato dal medico. L’obiettivo del Vulnerability Assessment è quello di assessare, voce del verbo “assessare”, cioè di individuare quali sono le vulnerabilità, poi non abbiamo molto tempo oggi, ma comunque tutto ciò che non è come dovrebbe essere.
MATTEO: Ok, chiaro!
ANDREA: Dovremmo parlare 4 ore di che cosa significa questo. Una volta che io ho verificato che ci sono delle cose che non sono come dovrebbero essere, devo intraprendere un piano per far sì che diventino come dovrebbero essere o, quantomeno, mitigare il fatto che non sono come dovrebbero essere. Finisco subito, Matteo, faccio questa petulante distensione perché prima ho detto come slogan “farlo”, talvolta dirlo è più facile che farlo. Ci sono delle circostanze che ostacolano questa attività che, sebbene non richieda fisici quantistici, comunque trova sul proprio cammino degli ostacoli operativi, per esempio server che non possono andare giù perché girano degli applicativi critici, o ancora, se parliamo di client, utenti riottosi non per cattiveria, ma per mancanza di sensibilità che non agevolano il compito di chi, invece, dovrebbe “managiare” le vulnerabilità.
MATTEO: Chiaro, chiaro. On top a questo scenario che comunque è uno scenario che già presenta diverse sfaccettature, quindi diverse criticità, non bisogna dimenticarsi anche una premessa importante, ovvero che tutti i software in quanto tali sviluppano per loro natura, più o meno frequentemente, dei bug, delle vulnerabilità, degli elementi che comunque espongono un po’ il fianco verso attaccanti o comunque minacce esterne.
ANDREA: Sì, assolutamente. Il software che io amo tanto non solo perché ci mangio, ma anche perché ci lavoro mi sembra dall’83.
MATTEO: Da qualche anno!
ANDREA: Nell’83 non ci lavoravo, ma ci giocavo, però insomma, a parte gli scherzi, il software ha dei problemi, ha degli errori, ha dei bachi. Come ben sappiamo, il problema nasce da criminali che fanno un sacco di soldi di solito con l’estorsione. Questi criminali hanno fior di team di Ricerca e Sviluppo che non fanno altro che cercare questi errori e poi sfruttarli.
MATTEO: Assolutamente, assolutamente. Abbiamo quindi questo scenario che, diciamo, è abbastanza plumbeo per sua natura. L’idea e il suggerimento fondamentalmente qual è? Quello di cercare di implementare un qualche cosa che aiuti l’IT aziendale, o chi per lui gestisce questo tipo di problematiche, a mantenere presidiato questo tema qui. Fermo restando che, molto probabilmente, io non raggiungerò mai una situazione di full patch all’interno dell’azienda perché, come giustamente dicevi tu prima, magari ho sistemi legacy che non hanno neanche più la possibilità di essere patchati, quindi li devo gestire in un modo diverso ma, volendo scomodare il sempreverde Pareto, dovrei andare a lavorare su quel 20% di vulnerabilità che per loro natura o criticità mi generano l’80% delle criticità di livello più alto. Cosa ne pensi di questo approccio?
ANDREA: Sì, assolutamente. Il fatto che non si riesca, o che magari non si possa, raggiungere la perfezione non è affatto una scusa per non raggiungere almeno un sub-ottimo (invece dell’ottimo). Poi che cosa voglia dire sub-ottimo non lo so, non mi interessa, però non è che non facciamo niente perché tanto non posso essere perfetto.
MATTEO: Corretto, corretto. “La perfezione è nemica del fare”, no?
ANDREA: Sì, esatto, in inglese viene meglio, ma il concetto è quello.
MATTEO: Ok, quindi diciamo che è veramente importante cercare di ridurre il più possibile il rischio che vulnerabilità conclamate o comunque facilmente utilizzabili vuoi perché sono già disponibili i relativi exploit, vuoi perché comunque sono particolarmente diffuse, vengano in qualche modo sfruttate. In tutto questo, va anche considerato un altro tema, che so essere particolarmente a te caro, che è il tema dell’automazione. Va bene cercare di risolvere tutte queste vulnerabilità, ma probabilmente fare tutto quanto a mano non è forse l’idea più furba, che dici?
ANDREA: No, è assolutamente impossibile. O forse sarebbe possibile, ma in uno scenario di paradosso, talmente estremo che sarebbe paradossale, per cui sicuramente bisogna, secondo me, automatizzare tutto ciò che può essere automatizzato e, se posso aggiungere, bisogna anche saper gestire l’automazione. In questo non voglio tirare acqua al tuo mulino, però...
MATTEO: Sentiti libero!
ANDREA: No, però voglio dire che un fornitore di servizi che gestisce una plator di clienti con esigenze diverse, ma le quali hanno comunque un nucleo comune, sviluppa una sensibilità, una competenza e ha la possibilità di spalmare il costo dello sviluppo di questa competenza su tante realtà che altrimenti non è possibile. È una questione proprio matematica, secondo principio della termodinamica. Fare patching costa, e non solo farlo nel senso di eseguirlo, ma progettarlo, capire come metterlo in opera, anche se automatico, perché l’automazione va gestita, se no succedono dei disastri; ebbene questa cosa costa, quindi chi meglio di chi può spalmare questo costo può portare un vantaggio all’azienda.
MATTEO: Assolutamente d’accordo. E non solo perché è un po’ il nostro modello operativo e/o cavallo di battaglia, che dir si voglia, cioè quello di cercare di ragionare in termini di economie di scala. Fare un certo tipo di attività, se lo devo fare solo per il mio orticello è un discorso, mentre farlo su migliaia di asset è un altro discorso, posso sicuramente lavorare e ingegnarmi su più fronti. L’idea, e qui anche per andare un pochettino in sintesi finale, se volessimo mettere in fila un po’ di punti è: fare Vulnerability Management, anche se non arriverò mai a una situazione di zero vulnerabilità, è sempre e comunque meglio e più importante che non farlo; dare probabilmente delle priorità in questo tipo di azione e operazione che viene svolta continuativamente (questa è l’altra parola chiave), quindi portare avanti questo tipo di attività in modo continuativo, e tenere sempre presente l’analisi costi-benefici. Noi fino ad adesso abbiamo parlato di “massimi sistemi”, ma va tenuto in considerazione anche questo. Quando tu giustamente dicevi che il non fare niente ha un non-costo, ma in realtà ha un costo molto alto perché se io non approccio questo tipo di esigenza nella giusta modalità, domani mi posso trovare con l’azienda ferma, la produzione ferma, la gente da mandare a casa e via dicendo. Questo è un altro elemento da tenere in considerazione, quindi il costo del non fare niente. Concordi?
ANDREA: Sì, totalmente. Volevo dire una cosa che mi hai fatto venire in mente: per chiudere il capitolo sull’automazione, ricordiamoci che i criminali automatizzano.
MATTEO: Giusto!
ANDREA: Loro lavorano in maniera più efficiente di noi se noi decidiamo di non automatizzare, quindi almeno cerchiamo di combattere ad armi pari. La seconda pillola di saggezza che volevo condividere in realtà è un numero, che non so se sia vero, ma suona molto bene: ogni giorno saltano fuori 50 vulnerabilità nuove. Ecco perché è un lavoro che va fatto con una certa frequenza. Non sto dicendo che ciascuna azienda in Italia abbiamo 50 buchi nuovi al giorno, ma sto dicendo che è uno scenario estremamente dinamico e aspettare 6 mesi potrebbe essere un po’ rischioso.
MATTEO: Rischioso, per usare un eufemismo. Io direi che di pillole di saggezza ce ne hai condivise diverse. Questo, ovviamente, voleva essere proprio un momento per una chiacchierata e per una condivisione di alcune riflessioni sul tema Vulnerability Management. A questo punto, come al solito, invito chi volesse approfondire la tematica e chi volesse vivere la propria esistenza all’interno dell’IT aziendale in modo un pochino più sereno a contattarci. Io ringrazio tantissimo Andrea per essere stato con noi in questa chiacchierata!
ANDREA: Grazie a te, Matteo, per l’invito!
MATTEO: Grazie a tutti, a presto e alla prossima!
ANDREA: Ciao, buon lavoro!
