00:02 Introduzione
02:12 Cybercrime in aumento
05:59 Scenario competitivo
10:41 La storia finora
13:00 9 cerchi dell’inferno
14:50 Modello di minaccia (concetti 1/3)
20:54 Superficie d’attacco (concetti 2/3)
25:14 Raggio nero (concetti 3/3)
30:48 Hardware non sicuro (peccati 1/3)
38:05 Software non sicuro (peccati 2/3)
43:42 Attacchi alla supply chain (peccati 3/3)
49:22 Saggezza comune (virtù 1/3)
57:23 Inversione della sicurezza (virtù 2/3)
01:03:28 (In)Sicuro per design (virtù 3/3)
01:09:56 Conclusione
01:12:10 Prossima lezione e domande del pubblico
Descrizione
Il crimine informatico è in aumento. Il ransomware è un business in forte crescita. A causa della loro natura fisicamente distribuita, le supply chain sono particolarmente esposte. Inoltre, la complessità ambientale è terreno fertile per i problemi di sicurezza informatica. La sicurezza informatica è controintuitiva per sua natura, perché è proprio l’approccio adottato dagli aggressori per individuare e sfruttare le vulnerabilità. A seconda delle varianti di ricette numeriche coinvolte nell’ottimizzazione della supply chain, il rischio può aumentare o diminuire.
Trascrizione completa
Benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel, e oggi presenterò “Cybersecurity for Supply Chain.” Le modern supply chains sono ampiamente guidate dal software e lo sono sempre di più ogni giorno. Se da un lato il software offre grandi vantaggi, come una maggiore produttività o reattività, dall’altro comporta gravi svantaggi. Tra questi, c’è la sicurezza informatica, che rappresenta una categoria di problemi a sé stante e può risultare estremamente costosa. Tuttavia, per la supply chain non si può tornare a un’era pre-software; non è più possibile gestire in modo profittevole una supply chain su larga scala senza software. Pertanto, la sicurezza informatica deve essere affrontata in maniera diretta.
Il primo obiettivo di questa lezione sarà comprendere l’entità e la portata della sfida della sicurezza informatica, in particolare da una prospettiva della supply chain, per capire cosa è necessario per mettere in sicurezza una supply chain moderna. Il secondo obiettivo di questa lezione sarà comprendere cosa rende la sicurezza informatica così unica e impegnativa, poiché è profondamente controintuitiva. In particolare, da una prospettiva della supply chain, vogliamo capire cosa rende le intuizioni applicabili alla sicurezza informatica così in contrasto con il senso comune che prevale nella maggior parte dei circoli della supply chain.
Il crimine informatico è in aumento da oltre un decennio. L’FBI fornisce statistiche molto interessanti sul crimine informatico. L’anno scorso, le perdite riportate negli USA per crimine informatico hanno superato i 4 miliardi di dollari. Questi numeri probabilmente sottostimano l’entità del problema, poiché le aziende, per vari motivi, tendono a segnalare meno problemi di quanti realmente accadano. In primo luogo, ci sono gli incidenti su piccola scala, che sono particolarmente difficili da valutare e quantificare. Ad esempio, se perdi mezza giornata di operatività in un magazzino a causa di una lieve violazione della sicurezza informatica, questo difficilmente costituirà il tipo di incidente che giustifichi un vero rapporto e una richiesta di risarcimento, nonostante si siano verificati danni concreti.
D’altro canto, gli incidenti su larga scala tendono a essere sottosegnalati dalle grandi aziende, anche solo per evitare di causare un panico sul mercato qualora l’azienda fosse quotata. Quindi, gli incidenti di grande entità tendono a essere minimizzati. Tuttavia, le cifre più importanti e interessanti di questi rapporti sono la crescita annua delle perdite segnalate, che si attesta intorno al 30 percento. L’FBI mostra che questi numeri sono stati molto stabili negli ultimi cinque anni. La mia opinione personale è che questa crescita continuerà molto probabilmente a mantenersi nella tendenza positiva per il decennio a venire. Infatti, l’importanza del software continua a crescere in modo costante, e la nostra economia moderna diventa sempre più dipendente dal software. Pertanto, sospetto che questa tendenza continuerà a crescere per circa un decennio prima di stabilizzarsi.
Ora, il crimine informatico è un problema grande e in crescita; tuttavia, non è la fine del mondo, specialmente se paragonato alla portata di altri problemi. Ad esempio, se ipotizziamo un decennio di crescita annua costante del 30 percento, il crimine informatico, in termini di perdite segnalate, raggiungerebbe qualcosa come 50 miliardi di dollari all’anno negli USA. Questo farebbe sì che la scala del problema rappresenti circa un terzo del mercato degli stupefacenti illegali. Quindi, sebbene il crimine informatico sia un problema rilevante, non è esattamente un problema da livello apocalittico, specialmente se paragoniamo questa cifra al PIL degli USA. Tuttavia, è un problema che sta diventando abbastanza serio da richiedere attenzione dedicata, soprattutto poiché la maggior parte dei costi è sostenuta dagli attori che prestano meno attenzione. Questo costo non è distribuito in modo uniforme, e secondo me le supply chain, essendo particolarmente esposte, stanno sopportando una quota maggiore di tale costo rispetto al resto dell’economia. In questa parte, le aziende che prestano meno attenzione stanno in realtà sostenendo la maggior parte dei costi.
Per creare un problema di sicurezza informatica, è possibile compromettere macchine, persone, o una combinazione di entrambe. Le tecniche che sfruttano le persone sono tecnicamente note come tecniche di social engineering, che possono essere incredibilmente efficienti nell’approfittare dei problemi di sicurezza informatica. Tuttavia, il social engineering meriterebbe una lezione a sé, e oggi l’obiettivo di questa lezione è concentrarsi sulla parte informatica del problema. Le supply chain sono particolarmente esposte, per design. Innanzitutto, le supply chain coinvolgono molte macchine. In secondo luogo, le supply chain consistono in operazioni distribuite geograficamente. In terzo luogo, per design, le macchine nelle supply chain sono incredibilmente interconnesse e interdipendenti. Infine, molte persone sono coinvolte nelle supply chain, il che significa che il panorama applicativo è molto complesso. Dove c’è complessità, c’è anche fragilità in termini di sicurezza informatica. In totale, le supply chain hanno tutti gli ingredienti per essere bersagli privilegiati dei problemi di sicurezza informatica.
Se non bastasse la complessità, vorrei sottolineare immediatamente che la sicurezza informatica solitamente entra in conflitto con altri tipi di sicurezza, e quindi migliorare la situazione dal punto di vista della sicurezza informatica potrebbe effettivamente creare altri tipi di problemi di sicurezza. Per illustrare questo aspetto, che potrebbe essere piuttosto controintuitivo, diamo un’occhiata al caso di un data lake. Se introduci un data lake in cui raccogli tutti i dati della tua supply chain, crei un punto unico di fallimento. Se in questo data lake si verifica una violazione e un intruso riesce a comprometterlo, quell’unico attaccante sarà in grado di esfiltrare tutti i dati in una volta sola. Questo è qualcosa che deriva per definizione dal concetto stesso di data lake, e non esiste una soluzione alternativa.
Tuttavia, un data lake ha anche i suoi vantaggi. Se non si dispone di un data lake, l’azienda è esposta a un’altra categoria di problemi. La maggior parte delle frodi aziendali si basa sul fatto che, tipicamente in una grande organizzazione, la mano destra non sa cosa faccia la mano sinistra, e questa mancanza di comunicazione e sincronizzazione all’interno dell’azienda può essere sfruttata per commettere vari tipi di frode. Un modo per mitigare questi problemi consiste nel mettere insieme tutti i dati in modo che tali frodi risultino molto più evidenti, semplicemente perché tutti i pezzi sono stati riuniti. In tal senso, avere un data lake può essere un ottimo modo per mitigare ogni sorta di frode che altrimenti passerebbe inosservata solo perché i dati non possono essere conciliate. Quindi, possiamo vedere che avere un data lake crea un problema di sicurezza informatica, ma fa anche parte della soluzione per evitare vari tipi di frodi che possono essere molto costose per l’azienda.
Vediamo qui che la sicurezza informatica riguarda tutti i compromessi, non solo tra i costi legati ai meccanismi di sicurezza, ma anche compromessi con altri tipi di sicurezza che vanno oltre l’ambito specifico della sicurezza informatica.
Questa lezione è la settima lezione di questo quarto capitolo sulla supply chain, e questo quarto capitolo è dedicato alle scienze ausiliarie della supply chain. Le scienze ausiliarie rappresentano argomenti che non riguardano esattamente la supply chain, ma sono fondamentali per una pratica moderna della supply chain.
Da quando abbiamo iniziato questo quarto capitolo, siamo saliti nella scala dell’astrazione. Abbiamo cominciato con la fisica del calcolo per poi passare al software con l’elemento più basilare, cioè gli algoritmi. Successivamente, ci siamo addentrati in due tipi specifici di algoritmi piuttosto elaborati, l’ottimizzazione matematica e il machine learning, che sono di fondamentale interesse per la supply chain. In particolare, abbiamo visto che sia l’ottimizzazione matematica che il machine learning sono guidati dai paradigmi di programmazione. Così, abbiamo fatto una deviazione attraverso la lezione su linguaggi e compilatori, che è probabilmente uno degli argomenti maggiormente sottovalutati nei circoli della supply chain per quanto riguarda la conoscenza informatica.
Nell’ultima lezione, abbiamo approfondito l’ingegneria del software, concentrandoci per un po’ su lasciare da parte le macchine e focalizzandoci sulle persone che creano il software necessario per gestire una supply chain. Oggi, dopo aver esaminato cosa serve per creare il software di cui la tua supply chain ha bisogno per operare, ci concentreremo su cosa serve per distruggere e disabilitare proprio questo software che dovrebbe far funzionare la tua supply chain.
Il resto di questa lezione sarà suddiviso in tre blocchi. In primo luogo, esamineremo tre concetti chiave che sono necessari per comprendere la sicurezza informatica. Sebbene la sicurezza informatica sia profondamente controintuitiva, ciò non significa che sia immune alla razionalità e all’analisi logica. In secondo luogo, analizzeremo e elencheremo una serie di cause radice molto comuni alla base di molti, se non la maggior parte, dei problemi di sicurezza informatica di oggi. In particolare, vedremo che è difficile non sentirsi sopraffatti considerando l’immensità delle cause radice dei problemi di sicurezza informatica. Infine, esamineremo cosa si può fare per, almeno, mitigare i rischi di sicurezza informatica. Vedremo che la maggior parte delle conoscenze riscontrabili sul lato positivo, o su ciò che si può fare, è di tipo “conoscenza negativa”, enfatizzando ciò che va evitato piuttosto che ciò che dovrebbe essere fatto. Cercherò di coprire tutti questi argomenti da una prospettiva della supply chain; tuttavia, ci sono molti aspetti che non sono strettamente specifici della supply chain per quanto riguarda la sicurezza informatica.
Per poter pensare a una soluzione, dobbiamo prima chiarire il problema che stiamo cercando di risolvere. Questo è esattamente il ragionamento che ho avuto per il terzo capitolo di questa serie, che è dedicato al personale della supply chain. Infatti, il personale della supply chain cerca di cristallizzare i problemi stessi che stiamo cercando di risolvere, e nella sicurezza informatica esiste un equivalente approssimativo sotto forma di modello di minaccia. Il modello di minaccia è letteralmente uno strumento per cristallizzare il tipo di problema che stiamo cercando di risolvere in termini di sicurezza. La sicurezza informatica è alquanto sfuggente, vaga e diversificata; è molto difficile ragionare sulla sicurezza informatica. Durante una discussione sulla sicurezza, è molto difficile non incorrere nel problema di spostare gli obiettivi durante la conversazione, anche se le persone che partecipano alla discussione lo fanno in buona fede.
Ad esempio, se stiamo discutendo della minaccia rappresentata dal fatto che una password venga resa pubblica da un dipendente, il quale può sembrare più semplice di quanto non appaia, anche se il dipendente non ha torto, la discussione non dovrebbe deviare verso altri tipi di minacce, come quelle relative a password deboli o comuni. Pensare in modo chiaro a una minaccia è essenziale nella sicurezza informatica perché una soluzione mal concepita a un determinato problema tende a essere peggiore del problema originale. Se un’azienda decidesse che, per limitare il problema delle password esposte, avrebbe intrapreso azioni disciplinari contro i dipendenti ritenuti colpevoli di aver divulgato le proprie password, questo approccio probabilmente avrebbe conseguenze disastrose. Invece di cercare supporto, i dipendenti comincerebbero a nascondere i problemi che incontrano con le loro password, peggiorando la situazione nel lungo termine.
La cosa interessante dei modelli di minaccia è che ti costringono a scegliere le tue battaglie, a selezionare le minacce che affronterai e quelle che, pur essendo reali, non affronterai. Ad esempio, considera la seguente minaccia: che dire di un dipendente malintenzionato con accesso ad alto livello al data lake? Cosa succederebbe se questa persona esfiltrasse dati, sfruttando i suoi privilegi elevati? Questa è una minaccia, ma decidi di combattere questa minaccia specifica o no? Hai risorse e tempo limitati. Affrontare questa minaccia specifica può rivelarsi incredibilmente costoso, e quindi il threat modeling ti aiuta anche a decidere che, a un certo punto, ci sono alcune minacce semplicemente troppo costose da affrontare. Le tue risorse e il tuo tempo sarebbero meglio spesi ad affrontare altri tipi di minacce, che possono essere altrettanto pericolose ma molto più economiche e facili da gestire.
In questo senso, fate attenzione alle analogie. Il tipo di minacce che affronti nella sicurezza informatica è completamente diverso da quello che affronti in termini di rischio industriale o rischio fisico. La sicurezza informatica coinvolge avversari – persone che sanno pensare e adattare le loro azioni alle tue pratiche e politiche. Ad esempio, se hai processi di sicurezza ben documentati, un attaccante potrebbe sfruttare questa documentazione esistente per identificare le tue aree cieche. Il mio punto non è che non dovresti avere alcuna documentazione sulla sicurezza; il mio punto è che, quando si tratta di sicurezza informatica, gli avversari sono intelligenti e possono sfruttare qualunque cosa tu fornisca loro, anche se si tratta dei tuoi stessi processi di sicurezza. Pertanto, il threat modeling aiuta davvero a iniziare a pensare a questo tipo di problemi.
Nel mondo fisico, la superficie di attacco è qualcosa di relativamente ovvio. Se pensassimo a un castello medievale, la superficie di attacco sarebbe rappresentata dai muri e dal ponte levatoio. Tuttavia, nel mondo informatico la situazione è molto più complessa. In termini di sicurezza informatica, elementi apparentemente insignificanti possono essere potenzialmente attaccati. Un’intuizione chiave sulle superfici di attacco è che sono sempre più ampie di quanto si pensi.
Un esempio reale di questo è il cavo OMG, che sembra un normale cavo USB ma contiene al suo interno un microcomputer in grado di compromettere qualsiasi computer semplicemente collegando il cavo. Questo economico dispositivo hardware può essere acquistato per soli $139, dimostrando quanto possano essere accessibili queste superfici di attacco.
In termini di superfici di attacco, ogni singolo pezzo di hardware e software ha la propria superficie di attacco, per quanto possa sembrare insignificante. Inoltre, nel caso specifico di supply chain, è molto difficile identificare tutte le superfici di attacco. Il Shadow IT, che è diffuso nel mondo della supply chain, e i dispositivi di proprietà dei dipendenti (pattern bring your own device) rappresentano ulteriori punti di ingresso per un attaccante nella tua supply chain. Non si tratta solo di ciò che è gestito dal team IT, ma anche di tutte quelle cose che non sono gestite dal tuo team IT ma che in qualche modo contribuiscono alle operazioni della tua supply chain.
L’idea alla base della superficie di attacco è chiarire cosa possa essere attaccato, senza concentrarsi su come l’attacco venga eseguito. Concettualmente, l’aspetto interessante dell’idea di superficie di attacco è che ti costringe a creare una sorta di mappatura di tutti gli elementi che possono essere compromessi in un modo o nell’altro. Da una specifica prospettiva di supply chain, qualsiasi tipo di software con capacità programmabili, come Excel spreadsheets o script Python, presenta una superficie di attacco assolutamente enorme se la programmabilità o l’estesa compatibilità è realizzata con un linguaggio di programmazione generico. Pertanto, per quanto riguarda la supply chain, e considerando la quantità di configurazioni in corso, la superficie di attacco è tipicamente piuttosto massiccia.
Ora, come terzo concetto, abbiamo il blast radius, che è un modo per misurare l’impatto potenziale totale di un evento di sicurezza. Quando inizi a pensare in termini di blast radius, non ti chiedi se questo evento accadrà; inizi semplicemente a pensare: “Quando accadrà, quale sarà il vero blast radius del problema?” L’idea è cercare di pensare alle conseguenze, indipendentemente dalle misure di rimedio adottate. Se e quando questo evento si verifica, quale sarà l’impatto?
Se torniamo all’analogia del castello, il blast radius nel mondo dei computer può essere incredibilmente grande. Ad esempio, nel caso dell’attacco al Colonial Pipeline, il sistema compromesso era solo una piccola parte dell’intero sistema, meramente il sistema di fatturazione. Il vero blast radius derivante dalla compromissione del sistema di fatturazione di una singola azienda ha colpito l’intero stato del Texas. Questo ti dà un’idea del reale blast radius dei problemi di sicurezza informatica quando inizi a pensare alle supply chain.
Con l’avvento del cloud computing, i blast radius si sono espansi enormemente. Sebbene il cloud computing sia estremamente competitivo come modello di business e come modello operativo IT, esso comporta blast radius massicci. Se un attaccante ottiene il controllo amministrativo delle tue risorse di cloud computing, può annullare l’intero panorama applicativo in un colpo solo, creando un unico punto di fallimento con conseguenze di vasta portata. Il fatto che tu stia spostando le app nel cloud tende a esacerbare il problema dell’interconnessione, che porta a blast radius maggiori.
Quando sposti le app nel cloud, ottieni la facilità di interconnetterle con altre app nel cloud, il che comporta vantaggi concreti per il business. Tuttavia, in termini di blast radius, stai creando interdipendenze massicce che un attaccante può sfruttare per generare un blast radius di dimensioni impressionanti.
In termini di supply chain, pensare al blast radius è un buon modo per riflettere su come mitigare tali blast radius. Se torniamo ad un altro esempio di supply chain, consideriamo che, come ho descritto nella lezione precedente, abbiamo due tipi di elementi software nella gestione della supply chain. Abbiamo gli elementi transazionali, che costituiscono essenzialmente la gestione della supply chain stessa, come il monitoraggio dei livelli di stock. Poi, abbiamo gli elementi analitici, che riguardano l’ottimizzazione della supply chain, includendo previsioni, pianificazione e varie analisi statistiche dei dati.
Se decidiamo di mantenere tutti gli elementi software di natura analitica strettamente isolati dalla produzione, in modo che la parte analitica del tuo panorama applicativo possa leggere i dati dai sistemi transazionali ma non scrivere mai nulla in quei sistemi, ciò significa che, qualora i sistemi analitici vengano compromessi, il blast radius rimarrà contenuto alla parte analitica del tuo panorama applicativo. In altre parole, se il tuo software di previsione viene compromesso, non mette a rischio il componente software che tiene traccia dei tuoi livelli di stock.
Adesso, esaminiamo le cause principali e le fonti dei problemi di sicurezza informatica. Per quanto riguarda l’hardware, la situazione è assolutamente terribile. In breve, la botte perde ovunque, e l’intera comunità continua ad applicare del nastro adesivo per riparare in fretta i problemi che emergono costantemente. Oggigiorno quasi tutto, hardware incluso, è rotto.
Ad esempio, tutte le CPU moderne sono praticamente difettose. Nel 2018, un gruppo di ricercatori sulla sicurezza ha svelato due nuove classi di vulnerabilità nelle CPU moderne, chiamate Spectre e Meltdown. Queste vulnerabilità sfruttano le capacità di branch prediction presenti nelle CPU moderne. Come forse ricorderai dalla lezione sul calcolo moderno per la supply chain, abbiamo visto che le CPU moderne hanno pipeline di esecuzione molto profonde, e uno dei modi per ottenere prestazioni elevate è proprio tramite la branch prediction. Si scopre che questo meccanismo di branch prediction, presente in ogni CPU moderna sul mercato, può essere sfruttato per violare i confini della sicurezza. Questa situazione è difficile da risolvere perché rappresenta un difetto di progettazione intrinseco all’uso della branch prediction nelle CPU fin dall’inizio.
Le CPU hanno un’infinità di problemi, e non sto nemmeno parlando di quelle con backdoor accidentali dovute al supporto legacy. Ma risulta che anche le memorie sono difettose. Esiste una classe di attacchi, detti attacchi Rowhammer, che sfruttano il layout fisico delle celle di memoria moderne presenti nelle DRAM ad alta densità. È possibile innescare errori di memoria e sfruttarli per esfiltrare dati dalle macchine. Non esiste una vera soluzione alternativa, anche se si dispone di DRAM ECC (Error Correction Code), che è il tipo di memoria tipicamente presente nelle macchine dei data center di livello produttivo. L’ECC rallenta solo gli attacchi Rowhammer; non può prevenirli. Tutto ciò che serve per eseguire un attacco Rowhammer è far eseguire alla macchina una pagina web con JavaScript abilitato, e poi si possono esfiltrare direttamente dati dalla memoria della macchina. Non solo CPU e memoria sono difettose, ma anche l’USB lo è. Per quanto riguarda l’USB, è sicuro presumere che qualsiasi dispositivo USB che colleghi al tuo dispositivo possa compromettere il dispositivo connesso. Abbiamo visto un esempio con il cavo “Oh My God” in una diapositiva precedente, ma fondamentalmente il problema è molto profondo. La causa principale risiede essenzialmente in decisioni molto sbagliate prese decenni fa riguardo all’USB, specialmente per quanto concerne il plug-and-play.
Da una prospettiva di user experience, è fantastico che, quando colleghi un dispositivo al tuo computer, questo funzioni immediatamente out-of-the-box. Tuttavia, ciò che avviene dietro le quinte è che all’interno del controller USB c’è un’enorme quantità di intelligenza per importare automaticamente i driver e abilitare automaticamente ogni sorta di funzionalità che può essere sfruttata come punto di ingresso da un attaccante per prendere il controllo della tua macchina. Pertanto, tutte queste funzionalità plug-and-play sono molto apprezzabili dal punto di vista dell’esperienza utente, ma rappresentano un vero incubo dal punto di vista della cybersecurity.
A proposito, molti, se non la maggior parte, dei chipset Wi-Fi presentano anche gravi falle di sicurezza. Ricercatori nel 2017 hanno dimostrato che i chipset prodotti da Broadcom, ampiamente utilizzati sia negli iPhone sia nei telefoni Samsung, erano difettosi. Tutto ciò di cui aveva bisogno un attaccante per compromettere il dispositivo era trovarsi nel raggio del Wi-Fi e avere il Wi-Fi attivo per prendere il controllo del dispositivo da remoto.
Da una prospettiva di supply chain, vediamo che non solo l’hardware convenzionale è ampiamente difettoso, ma anche la distribuzione geografica, che può essere ulteriormente amplificata se hai a che fare con qualsiasi tipo di IoT nella tua supply chain, è soggetta a tutti i problemi appena descritti e anche a molto altro. Un attaccante può spesso ottenere accesso fisico al tuo hardware, o quantomeno diventa molto più difficile impedire l’accesso fisico a qualsiasi dispositivo che potrebbe essere collegato alla tua supply chain. Pertanto, le supply chain sono estremamente esposte per design in termini di hardware.
Dato che abbiamo visto come la situazione in termini di sicurezza hardware sia terribile, non sorprende affatto che anche la sicurezza software sia altrettanto pessima. Non intendo enumerare tutte le vulnerabilità che si possono trovare nel software; l’idea chiave è che ogni singolo strato presenta le proprie problematiche di sicurezza informatica. Potremmo parlare del sistema operativo, delle macchine virtuali, degli hypervisor, dei framework applicativi, dei server web e così via. Tutti questi livelli hanno incontrato una serie di gravi problemi di sicurezza informatica.
Tuttavia, la cosa che vorrei sottolineare è che, dal punto di vista software, anche i programmi che dovrebbero proteggerti possono ritorcersi contro in modo grave. Ad esempio, gli antivirus rappresentano un’intera classe di problemi di sicurezza. Un antivirus è un software che opera con privilegi enormi sulla macchina, proprio perché dovrebbe essere in grado di monitorare ciò che fanno tutti gli altri processi. Per necessità, l’antivirus opera con privilegi elevati, il che lo rende un bersaglio primario per un attaccante. Inoltre, l’antivirus, se presente, sarà installato su molte macchine in azienda, quindi si tratta dello stesso software con privilegi molto alti che, per caso, è presente su numerose macchine. Questo lo rende davvero un obiettivo primario per un attaccante, e indovina un po’? Molti attaccanti al giorno d’oggi prendono di mira direttamente gli antivirus. Questo è, a proposito, ciò che puoi vedere sullo schermo: ricercatori di sicurezza che mostrano come compromettere un antivirus esistente sul mercato per utilizzarlo nell’estrazione di dati dal bersaglio.
Tuttavia, i problemi con gli antivirus sono molto profondi. Un antivirus è fondamentalmente un’elaborazione che richiede molte risorse. Di conseguenza, ciò significa che gli antivirus comportano inesorabilmente numerosi trucchi di programmazione a basso livello per raggiungere il livello di prestazioni desiderato. Sfortunatamente, più operazioni a basso livello implementi nel tuo software per ottenere elevate prestazioni di calcolo, maggiore sarà la superficie d’attacco, semplicemente perché ti espone a problematiche di basso livello. Inoltre, gli antivirus sono, per design, pezzi di software che devono interagire costantemente con l’esterno. Tipicamente, un antivirus perde di valore se non si aggiorna costantemente con l’ultimo set di firme e logiche su come rilevare il malware più recente. Di conseguenza, finisci con un software che aumenta la tua superficie d’attacco semplicemente perché deve connettersi alla rete e fare molte altre cose.
La mia opinione personale è che la maggior parte delle soluzioni antivirus faccia più male che bene nell’attuale mercato dell’enterprise software. Ma la realtà è che praticamente lo stesso si può dire della maggior parte delle soluzioni di sicurezza. Negli ultimi anni, ci sono stati problemi mondiali molto gravi in cui gli attaccanti hanno preso di mira specifiche soluzioni di sicurezza, proprio perché queste soluzioni condividono le stesse caratteristiche chiave degli antivirus: privilegi elevati, ampia portata e alta connettività, che le rendono obiettivi primari per gli attaccanti.
Per concludere, da una prospettiva di supply chain, vorrei sottolineare che il tipo di enterprise software prevalente nei circuiti della supply chain tende ad avere una sicurezza pessima a causa della sua pura complessità interna. È già difficile mettere in sicurezza un software che è molto snello; quando si ha a che fare con un prodotto molto gonfio che è cresciuto costantemente per decenni, diventa un compito quasi impossibilmente arduo.
Infine, gli attacchi supply chain sono di interesse per almeno due motivi molto distinti. Prima, gli attacchi supply chain sono interessanti perché sono cresciuti enormemente negli ultimi anni. La mia previsione personale è che questi attacchi supply chain probabilmente diventeranno una delle forme dominanti di attacchi di sicurezza informatica nel prossimo decennio. Secondo, la presenza della parola chiave “supply chain” nel nome degli attacchi può generare molta confusione, specialmente quando si discute con un pubblico supply chain. Un attacco supply chain è semplicemente un attacco che prende di mira una delle tue dipendenze software. Ad esempio, attaccare direttamente Amazon, ovvero il software prodotto direttamente da Amazon, potrebbe rivelarsi molto difficile. Possibilmente, i team di Amazon sono molto sicuri di sé e competenti, e il loro software è molto ben progettato, con poche falle di sicurezza da sfruttare. Tuttavia, che dire di tutte le dipendenze o pezzi di software che Amazon utilizza ma che non sono stati creati o progettati originariamente da Amazon? Tutti quegli elementi rappresentano, ad esempio, il caso del software open-source. Attualmente, ogni fornitore utilizza in modo massiccio il software open-source. Oggigiorno puoi nominare qualsiasi grande azienda; è probabile che sfrutti ampiamente parti di software open-source.
Se torniamo al caso di Amazon, che dire di compromettere uno dei componenti open-source utilizzati da Amazon, se non riesco a compromettere direttamente Amazon? Questa è esattamente l’essenza di un attacco supply chain. Si scopre che venerdì scorso c’è stato probabilmente uno dei più grandi furti di sicurezza informatica del decennio, con la scoperta della vulnerabilità “catastrophic” in Log4j. In breve, Log4j è un componente open-source usato per registrare gli errori. In sostanza, quando il software incontra un errore, vuoi essere in grado di rintracciare gli errori in seguito e, quando un errore si verifica, solitamente vuoi registrarlo. Questa è la funzione primaria di un logger, come Log4j. La “j” in Log4j sta per Java, che, nel mondo del software aziendale, è uno degli stack software dominanti. Per tutto il software implementato in Java, la maggior parte dei prodotti necessita di un logger, e la maggior parte probabilmente utilizza Log4j a questo punto.
Si è scoperto che venerdì scorso è stata trovata in Log4j una vulnerabilità catastrofica, classificata 10 su 10 su una scala di criticità della sicurezza. Poiché questo specifico pezzo di software è stato sottoposto a un grande scrutinio, a causa del caos su larga scala a livello mondiale generato da questa singola vulnerabilità, oggi ne è stata scoperta un’altra critica. Questa è davvero l’essenza di un attacco supply chain: un piccolo componente, apparentemente innocuo, qualcosa di cui probabilmente non hai mai sentito parlare o nemmeno capito di essere una dipendenza, si trova al centro del tuo sistema e può creare un’enorme quantità di caos poiché genera vulnerabilità.
Da una prospettiva supply chain, risulta che le supply chain sono particolarmente vulnerabili agli attacchi supply chain. Questo perché le supply chain moderne sono fortemente interconnesse. Molto probabilmente, la tua azienda, se gestisci una supply chain moderna, è fortemente collegata in termini di software sia ai tuoi fornitori che ai tuoi clienti. Ciò può assumere la forma dell’EDI, ma può anche presentarsi in molte altre forme con l’integrazione informatica tra aziende. In termini di attacchi supply chain, significa che non sono solo le dipendenze software a poterti attaccare; è probabile che basti compromettere una delle dipendenze di uno dei tuoi fornitori o una delle dipendenze di uno dei tuoi clienti. In termini di superficie d’attacco, le supply chain sono per definizione molto vulnerabili ed esposte.
Finora, ciò che abbiamo visto è un quadro piuttosto cupo della situazione, e credo che questa sia una rappresentazione accurata della sicurezza informatica odierna. Abbiamo un sacco di problemi, e temo che in questa ultima sezione discuterò cosa si possa fare a riguardo. Tuttavia, lasciatemi essere chiaro; in questo momento si tratta di una battaglia in salita ed estremamente difficile, e bisogna essere preparati a subire delle sconfitte di tanto in tanto. Solo perché è molto difficile, non significa che non dovremmo cercare di migliorare la sicurezza.
Iniziamo con la saggezza comune in termini di sicurezza informatica. L’FBI ha una raccomandazione tra le prime cinque in ambito di sicurezza informatica. Esaminiamo queste raccomandazioni. La prima raccomandazione è fare backup, testare i propri backup e mantenere i backup offline. In generale, è una buona raccomandazione. Tuttavia, l’idea di mantenere i backup offline è alquanto irrealistica. È molto costoso e difficile. Perché un backup sia utile, deve essere eseguito frequentemente. Un backup vecchio di un mese è generalmente inutile. Se fai backup molto frequentemente, ogni giorno, ora o addirittura ogni minuto, diventa difficile avere un vero backup offline. Il mio suggerimento sarebbe di tenere i backup strettamente isolati. Quando si tratta di backup, concentrati su un rapido ripristino. Ciò che conta non è avere un piano di backup, ma un piano di recupero nel caso in cui il tuo ambiente applicativo venisse compromesso.
La seconda raccomandazione è utilizzare l’autenticazione a più fattori. Anche in questo caso, si tratta di un buon consiglio, poiché le password non sono sicure. Tuttavia, il problema dell’autenticazione a più fattori è che molto spesso hai solo l’illusione di averla. Ad esempio, se hai una password e una conferma via telefono, si potrebbe dire che si tratta di un’autenticazione a due fattori. Ma se posso resettare la password con il telefono in mano, si tratta solo di un’autenticazione a un fattore. Con l’autenticazione a più fattori, assicurati che quei fattori siano veramente isolati e non si riducano a un’autenticazione a un solo fattore perché un fattore prevalga sugli altri.
La terza raccomandazione è aggiornare e patchare i tuoi sistemi. Questa è una buona pratica; tuttavia, troppo di una cosa buona può trasformarsi in una cattiva cosa. Uno dei problemi più gravi che abbiamo oggi sono gli attacchi supply chain, in cui dipendiamo dagli aggiornamenti software automatici. Se un attaccante riesce a condurre un attacco supply chain compromettendo un pezzo di software open-source, e ce ne sono migliaia, vuol dire che lasciando fare gli aggiornamenti automatici, quel malware riesce ad infiltrarsi nei tuoi sistemi. Questo sta diventando sempre più pericoloso. La maggior parte dei problemi legati all’hardware USB deriva dalle capacità di aggiornamento automatico del firmware. Quindi, pur essendo importante aggiornare e patchare i sistemi, valuta sempre se stai creando un problema di sicurezza ancora maggiore.
La quarta raccomandazione è assicurarsi che le soluzioni di sicurezza siano aggiornate. Su questa raccomandazione, non sono molto sicuro di cosa costituisca una soluzione di sicurezza. Questa raccomandazione sembra essere il prodotto diretto di qualche sforzo di lobbying da parte di un’azienda di sicurezza. La maggior parte di ciò che oggi viene pubblicizzato come soluzione di sicurezza potrebbe non rendere la tua supply chain o azienda più sicura. Tuttavia, se hai un pezzo di software, è in genere meglio tenerlo aggiornato, sia che si tratti di una soluzione di sicurezza o di qualcos’altro.
L’ultima raccomandazione è di rivedere ed esercitare il tuo piano di risposta agli incidenti. Questa raccomandazione non è male, ma a mio parere non arriverebbe tra le prime cinque. Questo tipo di approccio è più appropriato per gestire incidenti industriali, come il rischio di incendio, piuttosto che problemi di sicurezza informatica. La mia raccomandazione personale numero quattro, in termini di sicurezza, sarebbe di conoscere i tuoi modelli di minaccia, di conoscere la tua superficie d’attacco e di conoscere il tuo raggio d’esplosione. Il semplice fatto di sapere come sei esposto e quali tipi di problemi possono verificarsi fa molta strada nel prevenire i problemi. La conoscenza in termini di sicurezza informatica è fondamentale.
La mia raccomandazione personale numero cinque sarebbe che la sicurezza informatica è una cultura, non un processo, e non una soluzione. Questo è solo un promemoria che nessuna checklist, di qualsiasi tipo, farà alcun bene alla tua azienda nel lungo termine. È una cultura.
Per quanto riguarda l’inversione della sicurezza, sembra che le nostre aspettative intuitive riguardo ai modelli di riferimento o a chi dovremmo fidarci per la sicurezza informatica siano invariabilmente errate. Le organizzazioni che appaiono più sicure all’esterno o per aspetto sono tipicamente le peggiori, mentre quelle che appaiono molto grigie o losche sono spesso le migliori. Questa è l’essenza del paradosso dell’inversione della sicurezza.
A titolo esemplificativo, vorrei citare un intervento del 2014 sulla sicurezza aeroportuale, in cui due ricercatori di sicurezza hanno dimostrato che, in termini di sicurezza informatica, gli aeroporti sono davvero pessimi. La sicurezza è così scarsa che sarebbe quasi comica se non fosse così grave. Ci si aspetterebbe che gli aeroporti internazionali beneficino di una sicurezza informatica incredibilmente rigida, ma la realtà è esattamente l’opposto. La sicurezza informatica è letteralmente una completa barzelletta, con un’enciclopedia di vulnerabilità che dimostra completa incompetenza, mancanza di cura e apatia verso il problema.
Questo intervento rispecchia la mia esperienza professionale. Come hobby professionale, ho condotto audit tecnologici per conto di società di investimento per più di un decennio. Ho avuto l’opportunità di auditare dozzine di aziende tecnologiche, e la mia osservazione è che più sicuro appare l’aspetto o il contesto di un’azienda, peggiore sembra essere la sua sicurezza informatica effettiva. Le aziende che operano nei settori della difesa e della sicurezza tendono ad avere una sicurezza incredibilmente scarsa, mentre quelle che operano in aree grigie, come i siti di scommesse e i siti per adulti, tendono ad avere un’ottima sicurezza informatica.
Gli stessi problemi si riscontrano anche all’interno di uno specifico settore. Ad esempio, in sanità, ho constatato che la sicurezza dei dispositivi usati dai chirurghi durante gli interventi è completamente pessima, mentre la sicurezza informatica dei distributori automatici presenti in ospedale è piuttosto buona. Intuitivamente, penseresti che i dispositivi usati in sala operatoria debbano essere incredibilmente sicuri, ma il contrario è vero. Il distributore automatico è più sicuro dei dispositivi usati dal chirurgo.
Questa inversione controintuitiva, credo, deriva da una semplice questione di darwinismo. Nessun aeroporto internazionale è mai fallito a causa di massicci problemi di sicurezza informatica. Questi aeroporti non sono nemmeno autorizzati a fallire e possono cavarsela con problemi di sicurezza informatica per anni, mantenendo un notevole grado di apatia. Al contrario, se gestisci un’azienda che opera un’app di scommesse online e lasci che gli hacker esfiltrino denaro, non durerai a lungo e nessuno verrà in tuo soccorso.
A titolo esemplificativo, vorrei citare un intervento del 2014 sulla sicurezza aeroportuale. In questo intervento, due ricercatori di sicurezza hanno dimostrato che, in termini di sicurezza informatica, gli aeroporti sono davvero pessimi. La sicurezza è così scarsa che sarebbe quasi comica se non fosse così grave. Questo è l’esatto opposto di ciò che ci si aspetterebbe; ci si aspetterebbe che gli aeroporti internazionali avessero una sicurezza informatica incredibilmente rigida. Tuttavia, la sicurezza informatica negli aeroporti è letteralmente una completa barzelletta. Questi ricercatori di sicurezza hanno dimostrato che non si tratta di una sola vulnerabilità, ma di un’enciclopedia di vulnerabilità, molti dei problemi i quali dimostrano completa incompetenza, mancanza di cura e apatia.
Questo intervento corrispondeva alla mia esperienza professionale. Come hobby professionale, ho condotto audit tecnologici per conto di società di investimento per più di un decennio. Ho avuto l’opportunità di auditare dozzine di aziende tecnologiche, e la mia osservazione è che più sicuro appare l’aspetto o il contesto di un’azienda, peggiore sembra essere la sua sicurezza informatica effettiva. Ad esempio, le aziende che operano nei settori della difesa e della sicurezza tendono ad avere una sicurezza incredibilmente scarsa, mentre le aziende che operano in aree grigie, come i siti di scommesse o i siti per adulti, tendono ad avere un’eccellente sicurezza informatica.
È interessante notare che gli stessi problemi si verificano anche in un settore specifico. Ad esempio, in sanità, la sicurezza dei dispositivi utilizzati da un chirurgo durante un’operazione è pessima, mentre la sicurezza informatica dei distributori automatici nel corridoio dell’ospedale è piuttosto buona. Intuitivamente, penseresti che qualunque cosa entri in sala operatoria debba essere incredibilmente sicura perché in gioco c’è la vita del paziente, ma il contrario è vero. Il distributore automatico è più sicuro dei dispositivi usati dal chirurgo.
Questa inversione controintuitiva, credo, è una semplice questione di darwinismo. Nessun aeroporto internazionale è mai fallito a causa di massicci problemi di sicurezza informatica, e non sono nemmeno autorizzati a fallire. Di conseguenza, possono cavarsela con problemi di sicurezza informatica per anni, mostrando un notevole grado di apatia. Al contrario, se gestisci un’azienda che opera un’app di scommesse online e lasci che gli hacker esfiltrino denaro perché possono cambiare l’esito delle scommesse, non durerai a lungo e nessuno verrà in tuo soccorso.
Di conseguenza, quelle persone sono essenzialmente sopravvissute. Sono quelli che hanno fatto tutto il necessario per mettere in sicurezza i loro sistemi. Per quanto riguarda la supply chain, il punto chiave qui è che se cerchi un aiuto autentico per la sicurezza informatica per mettere in sicurezza la tua supply chain, non cercare ex ufficiali militari con credenziali impeccabili. Invece, cerca un amministratore di sistema o qualcuno che sia stato coinvolto con un sito per adulti o con scommesse online — quelle aree marginali in cui le persone avevano davvero bisogno di abilità, talento e dedizione per sopravvivere. Altrimenti, l’azienda avrebbe smesso di esistere sotto la loro sorveglianza.
Come ultima parte su ciò che si può fare in termini di sicurezza informatica, vorrei delineare il ruolo del design. Per quanto riguarda la sicurezza informatica, molti cosiddetti esperti ti direbbero che è necessario formare i tuoi team. Personalmente, non ne sono così convinto, nel senso che non puoi addestrare le persone a non commettere errori. Anche le persone più intelligenti si stancheranno, si ammaleranno e commetteranno errori estremamente stupidi di tanto in tanto. Non puoi affidarti esclusivamente alla formazione. La sicurezza informatica non è come la sicurezza militare; non puoi semplicemente sottoporre le persone a un addestramento intenso affinché possano agire d’istinto. Nella maggior parte dei casi, la situazione richiede davvero di mantenere la calma e riflettere attentamente su ciò che sta accadendo. Altrimenti, la soluzione adottata rischia di essere peggiore del problema originale.
La mia opinione è che se nella tua organizzazione esiste un problema di design in ambito sicurezza informatica, nessuna quantità di formazione o nastro adesivo riuscirà a risolvere il problema. Sarà una battaglia che non potrai vincere. Quando consideri le cose da una prospettiva progettuale, cerchi decisioni o aspetti che possano avere un impatto massiccio sui modelli di minaccia, sulle superfici di attacco e sul raggio d’esplosione. Vuoi prendere decisioni di design che eliminino il maggior numero possibile di classi di modelli di minaccia, elimini intere superfici di attacco e limiti il potenziale raggio d’esplosione.
Ad esempio, quando si parla di superfici di attacco, considera le decisioni di design coinvolte. Se la tua organizzazione seleziona fornitori di software tramite Requests for Proposals (RFPs) o Requests for Quotes (RFQs), puoi essere certo che avrai massicci problemi di sicurezza informatica per design a causa degli RFP e RFQ. Perché? Beh, se selezioni fornitori di software enterprise basandoti su RFP o RFQ, stai scegliendo fornitori che possono spuntare tutte le caselle, dato che ce ne saranno molte da spuntare. Un tipico supply chain RFP avrà centinaia di caselle da spuntare, e queste caselle riguardano le capacità e le funzionalità del software. Quando conduci la selezione dei fornitori di software enterprise tramite un RFP, in realtà stai scegliendo fornitori che possiedono prodotti massicciamente gonfiati con tonnellate di funzionalità e capacità, il che a sua volta si traduce in una superficie di attacco massiccia. Più capacità e funzionalità, maggiore sarà la superficie di attacco. Se ogni singolo fornitore di software che scegli viene selezionato tramite questo processo, ti ritrovi con un panorama applicativo che ha una superficie di attacco incredibilmente grande alla fine della giornata, o meglio, alla fine del decennio, perché questi sono problemi a lento movimento per quanto riguarda le supply chain.
Lo stesso tipo di decisioni di design può avere un impatto massiccio anche sul raggio d’esplosione. Ad esempio, il modo in cui gestisci i dati ha conseguenze piuttosto drammatiche da una prospettiva di supply chain. La maggior parte dei dati personali è semplicemente completamente inutile per qualsiasi tipo di ottimizzazione della supply chain. Se vuoi avere previsioni migliori e una migliore pianificazione, non hai bisogno di conoscere il nome e il cognome dei tuoi clienti. L’idea, e questa è una pratica che Lokad ha adottato più di un decennio fa, è di considerare i dati personali come una passività, non come un attivo. In termini di raggio d’esplosione, ciò significa che se i sistemi vengono violati, il danno sarà molto minore se i dati personali non vengono trapelati. Sì, è negativo se tutti i livelli di stock vengono esposti pubblicamente, ma questo non avrà un impatto negativo molto grande sulla tua azienda, a differenza dei dati personali trapelati. Questo è un aspetto progettuale dell’organizzazione della tua supply chain che può avere conseguenze massicce in termini di raggio d’esplosione.
Le decisioni di design migliori sono quelle che eliminano intere categorie di problemi. Il ruolo di una cultura della sicurezza informatica all’interno di un’azienda è quello di permettere all’organizzazione di sviluppare le giuste intuizioni su quali decisioni di design dovrebbero essere adottate per proteggere l’azienda. Le giuste intuizioni progettuali sono il prodotto di una cultura adeguata intorno alla sicurezza informatica.
Questo mi porta alla conclusione che la sicurezza informatica è troppo importante per essere lasciata esclusivamente nelle mani degli specialisti IT. La sicurezza informatica va affrontata come una cultura all’interno dell’azienda ed è una responsabilità condivisa, non solo quella delle persone che hanno la parola “sicurezza” nel loro titolo professionale. Come abbiamo discusso in precedenza in questa lezione, la sicurezza informatica spesso compete con altri tipi di sicurezza all’interno di un’azienda, quindi è un’illusione pensare che uno specialista di sicurezza informatica possa salvarti. Potrebbero risolvere solo una delle sfaccettature del problema, ed è per questo che la cultura è essenziale per favorire l’emergere di decisioni di design che apportano grandi benefici in termini di sicurezza alla tua azienda.
La cultura giusta è anche essenziale per rifiutare istintivamente cattive decisioni di design che creerebbero problemi continui che non possono essere risolti in seguito. Avere una grande cultura della sicurezza non riguarda solo ciò che dovresti fare, ma anche ciò che non dovresti fare. Uno degli aspetti più difficili di una cultura della sicurezza informatica sana è fare in modo che i dipendenti si preoccupino sufficientemente del problema da non accontentarsi dell’apparenza della sicurezza. In una cultura della sicurezza informatica sana, le persone cercano una sicurezza genuina, non solo l’apparenza di sicurezza. L’illusione della sicurezza è spesso molto peggiore di una reale mancanza di sicurezza.
Questa è stata l’ultima lezione del 2021, e la prossima lezione si terrà nel 2022, lo stesso giorno della settimana. Nella prossima lezione inizierò il quinto capitolo, che riguarda le previsioni. In particolare, credo che sarà una presentazione piuttosto interessante perché Lokad è riuscita a ottenere un risultato molto spettacolare nella competizione M5 di forecasting. Presenterò questo risultato, ma discuterò anche delle lezioni che sono legate a questo modello per quanto riguarda la supply chain.
Ora, lasciate che affronti le domande.
Domanda: In generale, i leader della supply chain considerano la sicurezza informatica irrilevante per loro oppure no?
Il mio sentimento è che sì, in larga misura, lo fanno, ma la situazione può essere ancora peggiore. L’indifferenza è un grosso problema, ma anche quando i leader della supply chain si preoccupano, tendono ad affrontare la sicurezza informatica da una prospettiva di analisi del rischio, quella che sarebbe applicabile per rischi industriali. Questo non è l’approccio più efficiente in ambito cybersecurity. Quindi il mio punto è che i leader della supply chain non si preoccupano assolutamente abbastanza di ciò che può distruggere le loro supply chain al giorno d’oggi, e devono veramente familiarizzare con il giusto tipo di rimedio.
Domanda: Poiché la cybersecurity è in aumento, gli investimenti delle aziende in questo settore crescono più velocemente del loro budget per altri software. C’è la possibilità che in futuro i benefici di avere un sistema software siano compensati da costi elevati per la cybersecurity, e che la gente ritorni alla penna e carta?
Non ho detto che la cybersecurity sia in aumento; ho detto che il cybercrime è in aumento. Spero che a un certo punto la cybersecurity possa crescere. È vero che gli investimenti delle aziende in questo settore stanno crescendo più velocemente dei loro budget per altri software. La domanda è se, in futuro, i benefici di avere un sistema software possano essere compensati da costi elevati per la cybersecurity, e se la gente potrebbe tornare a usare penna e carta.
Come dicevo, poiché il cybercrime è in aumento, le persone sentono la pressione e quindi spendono soldi per soluzioni di cybersecurity. Infatti, anche l’FBI raccomanda di investire in qualche tipo di soluzione di sicurezza. Il mio problema con queste soluzioni di sicurezza è che la sicurezza non può essere un ripensamento; la maggior parte di essa deve essere progettata fin dall’inizio. Se la tua azienda seleziona software basandosi su RFP, hai un problema nel nucleo stesso della tua azienda, in quanto stai selezionando fornitori di software enterprise che saranno estremamente deboli dal punto di vista della sicurezza. Quindi, non importa se decidi di investire in qualche soluzione di sicurezza sofisticata in seguito—è troppo tardi. Per design, sei compromesso.
Se torniamo all’analogia del castello medievale, non puoi progettare un fossato più grande sopra un ponte levatoio debole né rendere le mura del castello più alte se non lo sono già abbastanza. Nell’era medievale, la maggior parte dei castelli crescevano nel tempo e non erano costruiti in un’unica soluzione. L’idea di avere strati additivi di sicurezza funziona se si ha a che fare con rischi fisici, ma nel software non funziona. Più linee di codice aggiungi, più il tuo problema di sicurezza diventa grande.
Concordo sul fatto che il cybercrime sia in aumento e che la spesa per la cybersecurity stia crescendo. Tuttavia, se dovessimo misurare la cybersecurity come un rapporto tra le perdite segnalate nel cybercrime e il PIL, questo rapporto sta peggiorando. Abbiamo meno sicurezza informatica mentre spendiamo di più per combatterla.
Per quanto riguarda la possibilità di tornare a penna e carta, non credo che il mondo tornerà all’era pre-digitale. Il costo per farlo è semplicemente troppo alto. I benefici offerti dal software sono assolutamente enormi, e anche se consideriamo il cybercrime un problema significativo, alla fine resta comunque un problema che, in termini di portata, è solo un terzo della dimensione del problema delle droghe illegali. Le droghe illegali rappresentano un problema significativo, ma non preannunciano la fine della nostra civiltà industriale. Non credo che le persone torneranno a penna e carta. Tuttavia, sospetto che molti fornitori di software inizieranno ad adottare soluzioni tecnologiche più semplici.
Per illustrare questo punto, consideriamo la vulnerabilità di Log4j, che ha colpito il mondo causando scompiglio tra le grandi aziende. Questa vulnerabilità, legata ad un attacco alla supply chain, è stata causata dalla complessità e dalle capacità del componente Log4j. Normalmente, dovrebbe essere un piccolo pezzo di software che registra errori, ma si è rivelato essere una bestia in termini di capacità del software. Le persone hanno scoperto un modo per sfruttare questa bestia per conseguire effetti indesiderati.
In Lokad non usiamo Log4j; il nostro stack è in .NET, e utilizziamo NLog, il componente equivalente nello stack .NET. Tuttavia, alla luce dei problemi nella comunità Java, il mio CTO ed io abbiamo deciso di eliminare progressivamente NLog e optare per qualcosa di molto più semplice. Non sarà un NLog migliore, ma qualcosa che abbia solo l’uno per cento della complessità. Questi logger sono incredibilmente capaci, ma le loro capacità diventano una grande passività.
L’equivalente di tornare a penna e carta sarebbe iniziare a sostituire pezzi di software molto potenti e complessi con pezzi di software molto più piccoli e meno capaci. Questo può aiutare ad alleviare il peso dei costi della sicurezza. A un certo punto, diventa chiaro che è più economico reimplementare un piccolo pezzo di software che faccia esattamente ciò di cui hai bisogno, anche se devi reinventare la ruota, invece di usare un componente open-source gratuito che comporta una massiccia superficie di attacco extra a causa delle sue dimensioni.
Per quanto riguarda i grandi attacchi noti che impattano le supply chain, potrebbero esserci dei bias negli attacchi che vengono notiziati. Log4j è stato un problema mondiale immenso perché ha colpito molte industrie, inclusi il settore bancario, la supply chain, i fornitori di cloud computing e le aziende di gaming. Tuttavia, se guardiamo all’attacco al Colonial Pipeline, si trattava di un attacco ransomware che ha preso di mira un singolo componente di fatturazione software. Quello che vedo è che il tipo di attacchi che fanno notizia sono quelli che ricevono molta copertura mediatica, ma ciò non significa che gli attacchi specifici contro la supply chain non stiano accadendo. Anche se non posso divulgare dettagli sulla base clienti di Lokad, ho assistito ad attacchi ransomware tra i nostri oltre 100 clienti. Ci è evidente quando non riceviamo dati per una o due settimane mentre le aziende faticano a rimediare alla situazione, solitamente ripristinando i loro sistemi da zero con i backup. A volte, Lokad finisce per essere l’unico backup che avevano. Attacchi gravi mirati ai sistemi della supply chain stanno accadendo abbastanza frequentemente.
Con un campione piuttosto piccolo, Lokad ha più di 100 aziende come clienti, ma non è che ne abbiamo un milione. Anche con ciò, attualmente stiamo vedendo circa mezza dozzina di incidenti maggiori all’anno, il che equivale a un rischio annualizzato del 5% per un incidente di cybersecurity significativo. Questo, a mio avviso, è un rischio piuttosto elevato.
Domanda: Sembra che la cybersecurity stia diventando l’analogo digitale dell’igiene personale. Pensi che le scuole dovrebbero iniziare a insegnare ai bambini queste competenze?
Sì, capisco il tuo punto sull’igiene. Tuttavia, nella cybersecurity, gli attaccanti sono intelligenti. I virus della vita reale mutano, ed è difficile contenere i patogeni. Ma c’è una differenza significativa tra affrontare un attacco senza senso e dover fare i conti con persone che sono in grado di pensare in maniera approfondita su come infliggerti il maggior danno possibile a te e alla tua azienda.
Concordo sul fatto che ci sia una sfida nell’insegnare e formare le persone, anche i bambini, riguardo alla cybersecurity. La mia convinzione personale è che un bambino di 12 anni sia fondamentalmente intelligente quanto un adulto, mancando solo dell’esperienza che un adulto possiede. Quindi sì, questo è qualcosa che dovrebbe essere affrontato, inclusi frodi e schemi di social engineering. Molte persone cadono ancora vittima di truffe ovvie, come le famose email del principe nigeriano.
Le scuole dovrebbero preparare le giovani menti e le nuove generazioni ad affrontare un mondo che può essere ostile. Anche in tempi relativamente pacifici, ci sono persone che desiderano il tuo male. L’aspetto chiave della cybersecurity è che una persona che ti vuole male può trovarsi a migliaia di chilometri di distanza e riuscire comunque a causare danni a te, alla tua organizzazione e ai tuoi cari.
A un certo punto, le scuole dovrebbero affrontare questa questione. Tuttavia, almeno in Francia, è ancora una sfida trovare insegnanti che possano insegnare le competenze di programmazione di base. Questa lotta costante rende difficile trovare insegnanti che possano insegnare la cybersecurity e la sicurezza digitale ai bambini. Tuttavia, probabilmente dovrebbe essere fatto, anche se non ho molta speranza in questo ambito nel prossimo decennio.
Poiché non ci sono altre domande, vorrei augurare a tutti voi un Buon Natale e arrivederci al prossimo anno.
