An Introduction to Edgio’s Beyond the Edge Podcast Episode 5: Identifying and mitigating Zero-Day Threats condotto da Andrew Johnson, Sr. Product Marketing Manager – Security presso Edgio.
Andrew Johnson: Benvenuti in Beyond the Edge, dove approfondiamo le tendenze che influenzano le moderne aziende digitali. Sono Andrew Johnson, il tuo co-pilota per questo episodio. E oggi stiamo esplorando il tema delle minacce zero-day, in particolare come le identifichiamo e le mitighiamo. Oggi ci si uniscono Dave Andrews Edgio, VP of Engineering, e Marcel Flores, ricercatore capo presso Edgio.
Benvenuto, Dave. E Marcel, è bello avere entrambi qui. Può dirci qualcosa di voi e dei vostri ruoli qui a Edgio?
Dave Andrews: Certo. Grazie per averci invitato Andrew. E’ un piacere essere su. Quindi sono VP di Engineering. Sono stato a Edgio per penso solo un’ombra in 11 anni. E sono responsabile delle piattaforme edge e di molte delle infrastrutture centrali da una prospettiva ingegneristica.
Andrew Johnson: Fantastico. Grazie.
Marcel Flores: Sì. Grazie mille per averci ricevuti. Come hai detto, sono Marcel Flores. Sono il ricercatore capo presso Edgio Labs, il gruppo di ricerca qui a Edgio. Il mio team lavora per migliorare le prestazioni, l’affidabilità e le operazioni della rete eseguendo rigorose attività di ricerca e sviluppo, oltre a interagire con i sistemi più ampi e la comunità di ricerca di rete.
Cos’è un Zero-Day?
Andrew Johnson: Fantastico. Grazie ancora per essere venuti a trovarci oggi, ragazzi. Quindi, il tema delle minacce zero-day, penso che sia importante dare rapidamente al nostro pubblico un background su quali sono le vulnerabilità e gli attacchi zero-day. Cercherò brevemente di coprire questo prima di entrare in alcune delle vostre esperienze di protezione di Edgio e dei nostri clienti. Quindi che giorno zero è in termini di ciò di cui stiamo parlando qui? Beh, fondamentalmente le applicazioni moderne, le aziende moderne, i servizi moderni sono costituiti da software, software da codice open source, basi di codice commercializzato protocolli diversi, ecc. Sappiamo che nessun software è perfetto e di tanto in tanto verranno rilevate delle vulnerabilità in quel codice. “In sostanza, “giorno zero” si riferisce al periodo di tempo entro il quale viene rilevata una vulnerabilità e al tempo necessario per trovare una patch o una soluzione alternativa, giusto?”
Quindi, gli sviluppatori, una volta che sanno di una vulnerabilità, cercheranno di patch il più rapidamente possibile o dare ai clienti e agli utenti di quel software passi che possono fare per prevenire l’exploit. Ma fondamentalmente, come ho detto, è un problema che non sta andando via. Il numero di CVE o vulnerabilità ed esposizioni comuni aumenta ogni anno di circa il 25% nel 2022 rispetto al 2021. Non è super sorprendente che altre vulnerabilità verranno individuate. Esistono strumenti di intelligenza artificiale in grado di eseguire rapidamente la scansione delle basi di codice. Ci sono certamente incentivi finanziari sia per gli attori buoni che per quelli cattivi per trovare queste vulnerabilità sul lato positivo, sul lato positivo. Ci sono programmi di bug Bounty.
Hai familiarità con quando Apple spinge fuori le correzioni di codice per il tuo iPhone tutto il tempo. I bravi ricercatori stanno inviando exploit a questi sviluppatori, e poi ci sono dei malintenzionati che sfruttano anche le vulnerabilità. Quindi, solo un po’ di background su questo. Forse alcuni comuni di cui hai sentito parlare di recente. HTTP2/Rapid Reset è stato di recente un elemento molto importante nel mondo della sicurezza delle applicazioni. Forse avete sentito parlare di Log4j, Spring4Shell, o qualche anno fa, della vulnerabilità Apache Struts 2 che ha causato enormi violazioni dei dati qui negli Stati Uniti, in realtà in tutto il mondo. Quindi questo è solo un po’ di background sulle minacce zero-day, ma sì, forse andrò avanti e inizierò chiedendo a Dave solo un po’ cosa fate voi per proteggere Edgio e i nostri clienti dalle minacce zero-day.
In che modo Edgio protegge se stessa e i suoi clienti dalle minacce Zero-Day?
Dave Andrews: Si’, assolutamente. Quindi credo che la sicurezza sia tutta una questione di difesa in profondità, giusto? Come, non c’è mai una cosa particolare che fai. Si tratta di fare in modo di avere un certo numero di strati tutti Uniti. L’idea è se uno o due strati sono imperfetti, come tutti lo sono perché abbiamo umani molto intelligenti che cercano attivamente di romperli, il numero assoluto di strati e con protezioni e mitigazioni sovrapposte è progettato, sai, il, il punto qui è quello di, non importa se una cosa fallisce perché ci sono altre cinque cose sedute lì che ti proteggeranno. Quindi, fare un passo indietro, come il primo, e credo che probabilmente una delle cose più importanti sia che generalmente cade nel secchio della preparazione.
Vi sono almeno tre aspetti distinti. Il primo che mi viene in mente è l’igiene. Avere una buona igiene della sicurezza è assolutamente fondamentale. E aiuta in gran parte riducendo la vostra area di preoccupazione. Cosa intendo per igiene? Ci sono due cose principali. Uno è mantenere il software aggiornato o applicare regolarmente patch. Questa è la cosa più noiosa del mondo. È anche probabilmente una delle migliori e più critiche linee di difesa. Ciò significa che potete trarre vantaggio da tutte le divulgazioni responsabili di cui stavate parlando, Andrew, i bravi ricercatori, trovare vulnerabilità, divulgarle ai fornitori, correggerle e implementare le correzioni.
Puoi sfruttare tutti i vettori di attacco fondamentalmente noti nel software che stai usando. Solo perché è noioso non significa necessariamente che è facile soprattutto quando si lavora alla scala che siamo in Edgio, così come in un certo numero di altri luoghi, è molto, molto difficile gestire il rischio che deriva dall’aggiornamento di tutto il software su base regolare. Quindi, come vedremo più avanti, ci sono molte cose che facciamo operativamente per renderlo più sicuro e più facile da fare. Ma cade comunque abbastanza bene nel secchio igienico, se volete. Il prossimo pezzo che atterra nell’igiene è la scansione. Che l’intero punto qui è attivamente alla ricerca di cose che sono indicazioni che hai un problema prima che un cattivo attore lo trovi.
Questo assume diverse forme. Può trattarsi di team di sicurezza interni o di team di sicurezza delle informazioni. È possibile assumere parti esterne per eseguire scansioni. Può essere entrambe. Spesso le organizzazioni sfruttano la taglia dei bug per incoraggiare le persone a seguire la strada del cappello bianco, trovare vulnerabilità rivelarle a noi o alla parte in questione in modo che possano essere riparate prima di essere attivamente sfruttate. Quindi quelle cose cadono in questo secchio di qualsiasi cosa tu possa aggiustare, sistemare prima, giusto? Ad esempio, approfitta del buon lavoro che l’intera comunità sta facendo per rendere Internet e il software in generale più sicuri. E poi guarda attivamente le tue applicazioni, cercando di trovare vulnerabilità e risolverle in modo proattivo come meglio sei in grado. La prossima sezione che direi in merito alla preparazione, sto per passare a Marcel, è l’osservabilità.
Marcel Flores: Sì, grazie Dave. Quindi penso che un’altra cosa importante da fare in molti di questi casi sia essere in grado di vedere cosa sta succedendo sulla tua rete o con la tua infrastruttura. Penso quindi che questo tipo di approccio rientri in due categorie che sono fondamentalmente affrontate allo stesso modo, ma ritengo sia importante richiamare l’attenzione. Il primo è pensare ai comportamenti a livello di applicazione, giusto? Assicurandoti di capire quali richieste vengono inviate alla tua rete e in che modo sono le funzionalità di tali richieste, come sono modellate e come sono normalmente e come potrebbero apparire durante determinati eventi. Penso che sia anche importante, tenere a mente che ogni volta che stai comunicando su Internet, giusto, è una sorta di operazione full stack, giusto?
In cui ogni richiesta passerà attraverso il livello dell’applicazione, ma anche i protocolli di livello inferiore. E quindi è importante tenere d’occhio ciò che sta succedendo più in basso nello stack, giusto? E capire che ci possono essere comportamenti e risposte complessi da sistemi di livello inferiore che non sono ben catturati in quei comportamenti a livello di applicazione. Quindi è importante tenere traccia di una sorta di entrambi i componenti di questo e di avere osservabilità in ciò che sta succedendo in entrambi i casi. E credo che un elemento chiave sia essere in grado di capire quando quel traffico cambia, giusto? Quando il traffico sfida le aspettative, giusto? Potresti iniziare a vedere le funzionalità delle richieste delle applicazioni che non sono quello che vedi normalmente, giusto? Ad esempio, un improvviso aumento dei post HTTP anziché GET, pensando al livello dell’applicazione, pensando al livello del protocollo, giusto?
Questo può essere qualcosa di molto complicato nel protocollo come HTTP2 o qualcosa di ancora più basso. E pensare a cosa sta succedendo ai socket TCP e a cosa sta succedendo con le interazioni del protocollo a quel livello, specialmente quando stai pensando a cose come gli attacchi DDoS che potrebbero provare a sfruttare particolari vulnerabilità. Penso che la chiave per avere queste vulnerabilità, per questa osservabilità non sia solo avere metriche che ti permettono di vedere cosa sta succedendo, ma anche avere la capacità di scavare in una sorta di questi comportamenti, giusto? E di segmentarli di conseguenza, giusto? Per capire se c’è una particolare popolazione di utenti che sta generando un certo set di traffico. Ci sono reti specifiche, sono clienti specifici, proprietà specifica di un determinato cliente, giusto? In questo modo è possibile capire e restringere i limiti in cui le cose stanno effettivamente accadendo e in che modo potrebbero accadere.
Andrew Johnson: È interessante. Questo è interessante. Quindi, dopo aver osservato questi diversi tipi di comportamento o qualcosa che pensi possa essere un giorno zero, quali sono alcuni dei passaggi operativi che puoi fare?
Quali misure è possibile adottare per mitigare le minacce Zero-Day?
Dave Andrews: Si’, posso prenderlo, Andrew. Si’. I due tipi di elementi di cui parlava Marcel sono davvero le fondamenta, giusto? Come il primo sta guardando le cose, guardando la tendenza, che si riduce a da un’unica prospettiva, guardando le cose in aggregato, giusto? Come, nel complesso, cosa sembra? E il punto è che si ottiene una visione di alto livello di quello che sta succedendo, e permette di identificare i cambiamenti molto, molto rapidamente, come hai detto. La seconda parte in termini di immersioni profonde è essere in grado di stuzzicare e sviluppare la vostra comprensione su quale cambiamento, a che livello opera, ed è un rischio, giusto? Tipo, sai, Internet è il selvaggio, selvaggio West, giusto? Le cose cambiano continuamente.
Nuovi comportamenti si verificano continuamente. Non tutte queste cose sono un problema di sicurezza, giusto? Ad esempio, la possibilità di disporre di un insieme aggregato di informazioni molto più ampio, ma consente di scavare, fare e osservare o piuttosto rispondere a domande molto più sfumate, consente di arrivare al cuore di ciò che è cambiato e perché e consente di prendere questa decisione. Tipo, oh mio Dio, questo va bene. È un nuovo cliente che fa qualcosa. O sai che in realtà è un problema, o dobbiamo andare a vedere. Quindi allontanarsi da, sai, vedere cosa è successo, e sviluppare una certa comprensione su di esso è un problema. Entri nel regno di tipo, grande, e poi?
Come, cosa fate a riguardo? E questo insieme di ciò che chiamiamo agilità operativa e agilità. Ci sono alcuni temi di alto livello che pensiamo a quando consideriamo l’agilità operativa. Anche in questo caso, tre sono reattività, sicurezza e ridondanza. Quindi, passare un po’ di tempo per ognuno di questi tempi di risposta è esattamente quello che sembra, giusto? Quando qualcosa va storto dal punto di vista della sicurezza, il tempo è essenziale, giusto? Come sapete, volete essere in grado di risolvere i problemi di sicurezza molto, molto rapidamente, per dare agli autori degli attacchi un tempo minimo per creare il caos e darvi la massima quantità di tempo per ripulire. Ciò che ci prefiggiamo da un punto di vista molto ampio, non solo per quanto riguarda i problemi di sicurezza, ma anche per tutti i tipi di cambiamenti operativi che apportiamo, l’obiettivo è di circa cinque secondi per raggiungere il 99,99% dell’infrastruttura.
Questo è l’obiettivo. Non sempre arriviamo lì perché alcune cose richiedono necessariamente più tempo, ma questo è l’obiettivo. E molti dei nostri sottosistemi raggiungono quell’obiettivo. La sicurezza è un tema strano a cui pensare con l’agilità operativa. Quindi lasciate che la prenda un po’ a parte. Uno dei rischi che hai quando stai cercando di fare qualcosa con un alto livello di reattività, cioè molto, molto rapidamente, è che potresti risolvere il problema molto, molto rapidamente, supponendo di avere una perfetta osservabilità e una perfetta comprensione di ciò che sta accadendo, e puoi perfettamente prevedere la risposta al cambiamento che stai per fare. Questo è grande, e molte volte è il caso. Tuttavia, c’è anche la possibilità che la tua comprensione di una qualsiasi di queste cose sia imperfetta, e potresti anche peggiorare molto, molto rapidamente.
Nessuno lo vuole. Quindi il punto della sicurezza è che si mettono in atto sistemi, processi e automazione, e molte altre cose vanno in essa per assicurarsi di non peggiorare le cose. Questo si riduce a un paio di cose molto, molto di alto livello. All’inizio. È come una modellazione proattiva. Questo vale molto per la pianificazione di base della capacità, giusto? Ad esempio, se per qualche motivo è necessario mettere fuori produzione i computer per applicarli perché per qualsiasi motivo è necessario riavviare i servizi. Uno dei rischi lì se si tenta di farlo molto, molto rapidamente è prendere troppe macchine fuori produzione per il carico che stanno attualmente vivendo. Lo potete sapere in anticipo, vero?
Abbiamo quindi molti sistemi di modellazione che si integrano con i sistemi di workflow, in modo che quando una richiesta di applicare patch a tutto quanto più velocemente possibile, non elimini immediatamente tutti i server dalla produzione. Quindi, esistono sistemi di sicurezza di base che è possibile costruire e integrare per evitare di sparare al piede. Quindi, supponendo che, che non peggioreremo le cose da quella prospettiva, solo in una prospettiva di infrastruttura di pianificazione della capacità pura, vogliamo anche sapere che il cambiamento che stiamo facendo ha l’effetto previsto a livello di applicazione o a qualsiasi livello, applicazione osservabilità, protocollo, qualsiasi cosa sia che stiamo cercando di mitigare. Quindi, quello che facciamo, per sfruttare un sistema che chiamiamo miniera di carbone. Ne abbiamo parlato e parlato pubblicamente prima, ma l’idea che ci sia fondamentalmente tutto esce come quello che chiamiamo canarino – canarini nella miniera di carbone.
Il punto è che non succede nulla in tutto il mondo in una volta sola, non importa quanto sia terribile. Almeno due fasi per far uscire qualcosa. Quindi lo mettiamo su un sottoinsieme di infrastrutture. In genere, l’infrastruttura che sta vivendo l’evento più egregiamente o è più visibile, convalidamo che fa quello che ci aspettiamo e poi lo distribuiamo rapidamente in un secondo momento. Siamo spiacenti, distribuitelo in modo più ampio e verificate che il problema globale si risolva a livello globale. Quindi, miniera di carbone e canarie strettamente integrate con i loro sistemi di misurazione e osservabilità in modo da poter correlare a colpo d’occhio, come, cos’è questo? Cosa sta facendo questo canarino alle metriche aggregate che sto guardando? Quindi otteniamo feedback in tempo reale che, ehi, il cambiamento che stiamo facendo sta effettivamente affrontando il problema.
Quindi è molto, molto utile. Ciò su cui stiamo effettivamente lavorando al momento e che ci stiamo preparando per il lancio interno e in seguito, produrremo questo per i clienti e le loro modifiche alla configurazione, è fondamentalmente un’analisi metrica completamente automatizzata. Quindi attualmente, quando facciamo un cambiamento come questo, richiede che un umano si sieda lì e lo guardi, assicurandosi che stia accadendo la cosa giusta e assicurandosi che le metriche di cui sono preoccupati si muovano nella giusta direzione. E poi fondamentalmente far avanzare il canarino, dire al sistema come, grande, hai superato la prima fase. Sembra tutto a posto. Andate avanti e andate alla fase globale di quel canarino. Facciamo questo, sfruttiamo il sistema per tutte le modifiche, non solo, conoscete le modifiche operative della sicurezza, ma tutte le modifiche che fluiscono in tutto il sistema.
E quello che stiamo entrando in gioco è che costruiamo sempre più visibilità sul nostro punto vendita, sempre più visibilità, sempre più metriche, sempre più informazioni su ciò che sta accadendo, c’è sempre più da guardare per gli esseri umani, giusto? E quel carico sta raggiungendo il punto in cui è troppo alto. E così gli umani cominciano a fare errori, giusto? Perché ci sono semplicemente troppi grafici da guardare, troppi grafici da guardare e le persone si stancano e le persone sono comunque imperfette. Quindi stiamo lanciando un sistema chiamato Birdwatcher, la cosa che osserva i canari fondamentalmente che fa alcune sofisticate analisi statistiche sulle metriche, come quando le modifiche stanno arrivando e gli dà un pollice in su o un pollice in giù. E questo è integrato con la miniera di carbone in modo che possiamo dire, Hey, in modo automatizzato, otteniamo qualche indicazione che canary è buono, sta facendo quello che ci aspettiamo.
E anche separatamente non sta facendo nulla di male che non ci aspettiamo, e che, quel lancio procederà senza alcun intervento umano. Così super eccitato. Questo renderà la nostra reattività ancora più veloce e ancora più sicura. Quindi queste sono le cose principali che consideriamo quando parliamo di sicurezza, essere in grado di far sparire il problema in modo rapido e sicuro. L’ultimo punto che ho menzionato è la ridondanza, che è relativamente chiara. C’è un punto o una filosofia chiave che utilizziamo e implementiamo, che è fondamentalmente un doppio percorso per molti di questi cambiamenti, quanti più possiamo raccogliere. Quindi, cosa significa “doppio percorso”, i due percorsi che pensiamo sono fondamentalmente veloci, con il massimo sforzo e lenti, affidabili. L’idea è che gestiamo una grande quantità di infrastrutture in luoghi molto, molto, disparati in tutto il mondo.
La capacità di colpire tutto con un’affidabilità al cento per cento in pochi secondi è una favola. Come, questo non è qualcosa che è fattibile. Qualcosa da qualche parte ha sempre un problema. E non c’è davvero niente che tu possa fare al riguardo. Quindi quello che facciamo è fondamentalmente unire queste cose in modo simile alla sicurezza, alla difesa in profondità, giusto? Ad esempio, avete messo insieme queste due cose e, in realtà, questo è sfruttare il percorso veloce. Andate a colpire il più possibile. E poi qualsiasi cosa ti manchi, ci assicuriamo di avere un percorso ridondante e affidabile che continueremo a provare fino a quando non funzionerà, che è un po’ più lento. Quindi per mettere alcuni numeri a questo, il percorso veloce toccherà faremo un cambiamento su circa il 99,9% della nostra infrastruttura in meno di cinque secondi, giusto?
E quel 99,9% è ripetibile e affidabile. E poi il percorso lento e affidabile corre nell’ordine di 60 secondi. E quel sistema continuerà a provare finché non avrà successo. Quindi, facendo leva su questi due insieme, otteniamo il meglio di entrambi i mondi. E se uno di questi sottosistemi va completamente giù, non significa che tutto è giù, saremo ancora dove abbiamo bisogno di essere al massimo cinque minuti dopo. Quindi queste due cose insieme ci danno questa reattività e agilità con l’affidabilità che stiamo cercando. Ci sono altre piccole cose divertenti per assicurarci che ci siano dei licenziamenti. Come si fa a mettere in moto questi sistemi? Come molti sistemi hanno lo sai, chatbot integrati, quindi è molto, molto facile.
Chiunque può farlo da qualsiasi parte del mondo al telefono. Molte altre cose hanno API. C’è una CLI per molti sottosistemi. Quindi assicurarci che non ci sia solo un modo per dare inizio a questi compiti è un altro esempio di come cerchiamo di costruire la ridondanza in modo da poter sempre avere quella agilità operativa a nostra disposizione indipendentemente da ciò che sta accadendo o da quale particolare sistema potrebbe essere in difficoltà. Ci assicuriamo di avere il controllo e le capacità operative di cui abbiamo bisogno. Molte di queste cose, sai, sono tutte di uso generale, ma come ho detto, le facciamo leva per il più possibile. Tutto, dai flussi di lavoro della nostra infrastruttura, come la messa fuori produzione di una macchina e l’applicazione di patch fino alle modifiche alla configurazione del cliente. Tutto sfrutta lo stesso sistema centrale in cui il cibo per cani e ci avvantaggiiamo in modo aggressivo. Quindi il prodotto che esponiamo ai nostri clienti è affidabile e molto, molto solido.
Andrew Johnson: Fantastico. Fantastico. Grazie, Dave. E Marcel, penso che tu abbia parlato di BEST practice o considerazioni che i team di sicurezza possono applicare alla loro pratica. Apprezzo quelle mance. So che avete sicuramente affrontato alcuni esempi zero-day davvero interessanti per proteggere Edgio e i nostri clienti. Sono sicuro che hai alcune buone storie e applicazioni di queste migliori pratiche. Potrebbe parlarne un po’?
Esempi zero-day: HTTP2/Ripristino rapido
Dave Andrews: Si’, assolutamente. Penso che quello che è più pertinente o più recente, credo, ed è stato un po ‘interessante è, l’hai detto prima, è l’attacco HTTP2/Rapid Reset. E’ stata un’esperienza molto interessante. Quindi solo per riferirlo dal punto di vista di Edgio, c’è un piccolo blog che abbiamo scritto su questo ragazzo come è successo. HTTP2/Rapid Reset è stato un attacco zero-day in cui le persone si sono rese conto che l’implementazione delle librerie server HTTP2 non solo aveva preso qualcosa nel RFC HTTP2, la specifica, la specifica del protocollo come raccomandazione generale e fondamentalmente lo ha codificato nelle librerie stesse. E questo era il numero di richieste simultanee che potevano essere, mi dispiace, i flussi simultanei che potevano essere in volo su una particolare connessione, che era nelle specifiche, scritto come cento.
Questo insieme a un aspetto interessante dell’H2, che è, sapete, l’idea di essere il multiplex, un sacco di richieste su un singolo socket TCP, e la possibilità di annullare le richieste ha portato a questa vulnerabilità molto, molto interessante o vulnerabilità DDoS. Il punto è che quello che gli aggressori cercano è qualcosa che costa una piccola somma per l’aggressore e costa di più per l’aggressore, per la persona dall’altra parte E l’hanno trovato nel ripristino rapido dell’HTTP2. Ciò significava che l’utente malintenzionato era in grado, molto, molto rapidamente, di infilarsi come un singolo pacchetto che iniziava una richiesta e poi la annullava più e più volte, come centinaia di quelli su un singolo socket spiacenti, su un singolo pacchetto e inviarlo al server.
Il server deve quindi svolgere molto più lavoro che inviare un singolo pacchetto. Dobbiamo creare una richiesta, spesso dobbiamo avviare una connessione proxy. Questo è ciò che i CDN fanno per andare a prendere qualsiasi risorsa che l’attaccante stava richiedendo. E alla fine dobbiamo registrare che la richiesta è avvenuta. Quindi, il fatto che gli autori degli attacchi siano stati in grado di generare tali iniziazioni e annullare le richieste è molto, molto rapido. Fondamentalmente la maggior parte, come chiunque sia stato sotto quell’attacco, è più costoso. Era più costoso elaborarli che generarli. E questo diventa una vulnerabilità DDoS. Quindi ci piace che molte altre persone del settore siano state attaccate da questo.
E tutti sono stati attaccati nello stesso momento, il che lo ha reso particolarmente interessante. E’ stato un attacco molto ampio. E mi piacerebbe capire cosa pensavano gli aggressori quando hanno iniziato. Perché stavano attaccando molti, molti, molti fornitori tutti allo stesso tempo. Che abbiamo scoperto quando abbiamo iniziato a parlare con gli altri fornitori e siamo tipo, oh, quando l’hai visto? Oh, è esattamente lo stesso momento in cui l’abbiamo visto, in cui ci siamo imbattuti perché abbiamo trovato l’attacco. Abbiamo identificato ciò che stava accadendo a causa dell’osservabilità di cui parlava Marcel. E abbiamo iniziato a costruire mitigazioni, giusto? Quindi, questa mitigazione sembra aggiungere ancora più osservabilità per arrivare esattamente al centro di ciò che stava accadendo e quindi costruire controlli operativi che ci permettano di modificare una risposta.
Quindi, come si presentava in realtà, tenere traccia di quante volte un client sta reimpostando le richieste su un particolare socket, e se la percentuale supera una soglia predefinita, terminare la connessione. Pertanto, l’idea è fondamentalmente di non consentire all’utente malintenzionato di inviare continuamente queste richieste per apporvi un limite e quindi di essere in grado di mitigare l’attacco. Così abbiamo pubblicato quel blog dopo aver costruito quella mitigazione, implementata, implementata e convalidata che in realtà impediva a quegli attacchi di ripetersi. Poi c’erano persone del settore che si avvicinavano e tipo, oh, abbiamo visto il blog. In realtà siamo stati colpiti anche da questo e stiamo lavorando sulla divulgazione responsabile. Così ci siamo Uniti a un gruppo del settore con cui ha lavorato come Vince, che fa parte del certificato per passare attraverso il flusso di divulgazione responsabile, assicurandoci che in questo caso le persone che stavano implementando librerie HTTP2 o server HPD abbiano avuto il tempo di generare patch, distribuire quelle patch prima del, la vulnerabilità è stata più ampiamente pubblicizzata.
Quindi era un flusso molto, molto interessante, interessante. Siamo stati in grado di farlo, di ribaltare molto velocemente, giusto? Come in parte per il lavoro che facciamo in materia di igiene e funzionamento, visibilità e agilità operativa, siamo stati in grado di avere un piccolo cambiamento da fare, giusto? Come, non era, sai, oh mio Dio, dobbiamo aggiornare questa libreria e siamo come 10 versioni indietro perché non la aggiorniamo regolarmente. Non era che fosse come, in realtà siamo, siamo una versione dietro, giusto? Ad esempio, perché aggiorniamo regolarmente le patch che il rischio è ridotto perché si tratta di un piccolo hop, il che significa che puoi farlo molto rapidamente pur mantenendo quella soglia a basso rischio che abbiamo. Quindi l’abbiamo fatto molto, molto rapidamente e siamo in grado di implementarlo e mitigare l’attacco. E poi abbiamo messo su il blog senza sapere che l’attacco aveva colpito più persone in parte per cercare di socializzare non solo con i nostri clienti, ma con il settore. Come, Hey, questo è qualcosa di strano che abbiamo visto che sembra che non sia nulla di specifico per Edgio e in realtà potenzialmente più applicabile. E si è scoperto che lo era.
Andrew Johnson: Questo è, è davvero interessante. È fantastico vedere una visione interna di voi, la comunità della sicurezza di tutto il mondo che collabora per migliorare i risultati per tutti. Marcel, vuoi aggiungere qualcosa?
Marcel Flores: Sì, volevo solo aggiungere una nota che io, penso che questo, questo esempio sia stato interessante in cui l’osservabilità iniziale che avevamo sicuramente mostrato comportamenti strani come Dave stava descrivendo, giusto? Questa interazione di una sorta di funzione di protocollo di livello inferiore con i comportamenti di livello superiore della CDN ha creato alcuni comportamenti davvero imprevisti. E parte di questo, parte del capire cosa stava succedendo qui era capire che c’era questo grave squilibrio, giusto? Che il numero di richieste che vedevamo rispetto al numero di richieste che stavamo effettivamente restituendo ai clienti era inclinato, giusto? E questo è risalto. E anche se quelle erano entrambe le metriche che avevamo raccolto, non le avevamo confrontate esattamente in questo modo. Quindi, parte del risultato era sedersi e guardarlo e dire: “Ehi, cosa, come possiamo combinare la visibilità che già abbiamo in qualcosa che è fatto su misura per rilevare questo problema?” E siamo stati in grado di fare esattamente questo e di migliorare l’ambito della nostra visibilità osservando i dati che avevamo già attraverso una lente leggermente diversa.
Andrew Johnson: Fantastico. Fantastico. È un bene da tenere a mente. E grazie per questo, Marcel. Si’, ragazzi, quindi penso che siamo, stiamo finendo. Se, se ci sono altre raccomandazioni che vuoi condividere? Penso che abbiamo coperto un alto livello, alcuni molto buoni.
Raccomandazioni per rafforzare il vostro approccio alla sicurezza
Dave Andrews: Bella domanda. Credo che una raccomandazione generale sia di fondamentale importanza per l’igiene. Concentrandomi sulla sua osservabilità, penso che la cosa che chiamerei sia trovare persone che possano aiutare, giusto? Come parte del valore di una proposta di valore critico che un’azienda come Edgio fornisce è che possiamo sicuramente aiutare, giusto? Hai un intero team di persone come me e Marcel che stanno lavorando su questo e stanno lavorando per prevenire in modo proattivo intere classi di attacchi dall’impatto delle persone. Quindi trova persone che possano aiutare, giusto? Come se ci fosse un mucchio di strumenti e tecnologie che costruiamo, che la comunità ha a disposizione che può rendere il tuo lavoro più facile. Quando stiamo parlando, sai, generalmente le cose su Internet, un WAF è come, è il più critico, come il più basilare anche, direi l’esempio più critico di qualcosa del genere.
Ti dà la possibilità se è implementato in modo appropriato, ti dà la possibilità di combinare insieme l’agilità e gli elementi di sicurezza. Il WAF Edgio viene eseguito in modalità duale, il che significa che è possibile distribuire nuove regole in produzione, alle macchine che lo ricevono, che stanno osservando il traffico. E potete vedere cosa sta succedendo. Un buon esempio è stato con Log4j, che era, sai, un po’ indietro nel tempo. Quando sviluppiamo la risposta a questo, siamo in grado di sviluppare la regola molto, molto rapidamente e convalidarla molto, molto rapidamente. Dato che stavamo spingendo gli aggiornamenti delle regole e siamo in grado di implementarli in modalità di avviso sui computer effettivi e di vedere che hanno risposto agli attacchi, mostrare ai nostri clienti che non erano stati attaccati o che erano stati attaccati. E poi prendere una decisione molto basata sui dati per abilitare la regola in modalità di blocco e impedire che questi attacchi arrivino ai nostri clienti. Quindi combina tutte queste cose insieme, giusto? Come velocità di risposta, sicurezza, ridondanza e affidabilità. Trova persone che possono aiutare. Credo che sarebbe la mia raccomandazione principale.
Andrew Johnson: Ha molto senso. Lo apprezzo, Dave. Si’, voglio dire, quando si risponde a zero giorni, il tempo e’ critico. Quindi, avere queste soluzioni specializzate, ma anche, cosa ancora più importante, le persone che possono aiutarti a superare questo problema è fondamentale per chiudere la porta agli autori degli attacchi. Quindi grazie mille per essere qui con noi. Vorrei ringraziare anche il pubblico, e ci vediamo nel prossimo episodio. Grazie.
