Introduzione al podcast Beyond the Edge di Edgio episodio 5: Identificazione e mitigazione delle minacce Zero-Day condotto da Andrew Johnson, Sr. Product Marketing Manager – sicurezza presso Edgio.
Andrew Johnson: Benvenuti in Beyond the Edge, dove analizziamo i dettagli delle tendenze che interessano 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 mitighiamo. Oggi si uniscono a noi Dave Andrews Edgio, VP of Engineering, e Marcel Flores, ricercatore capo presso Edgio.
Benvenuto, Dave. E Marcel, è bello avervi entrambi qui. Può dirci un po’ di se stesso e dei suoi ruoli qui alla Edgio?
Dave Andrews: Certo. Grazie per averci invitato Andrew. E’ un piacere essere su di noi. Quindi sono VP della divisione Engineering. Sono stato a Edgio per penso solo un’ombra oltre 11 anni. E sono responsabile delle piattaforme edge e di un sacco del tipo di infrastruttura centrale da un punto di vista ingegneristico.
Andrew Johnson: Fantastico. Grazie.
Marcel Flores: Sì. Grazie mille per averci invitato. Come hai detto, sono Marcel Flores. Sono il capo ricercatore 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, nonché impegnandosi con la comunità di ricerca più ampia di sistemi e reti.
Cos’è uno Zero-Day?
Andrew Johnson: Fantastico. Grazie ancora per essere venuti oggi, ragazzi. Quindi, l’argomento delle minacce zero-day, penso sia importante dare rapidamente al nostro pubblico uno sfondo 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 Edgio e i nostri clienti. Quindi cos’è uno zero-day 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 commercializzate protocolli diversi, ecc. Sappiamo che nessun software è perfetto e di tanto in tanto vengono rilevate vulnerabilità in quel codice. “Fondamentalmente, “zero day” si riferisce al periodo di tempo entro il quale viene scoperta una vulnerabilità e al tempo necessario per trovare una patch o una soluzione alternativa, giusto?”
Quindi, gli sviluppatori, una volta a conoscenza di una vulnerabilità, cercheranno di patch il più rapidamente possibile o di fornire ai clienti e agli utenti di quel software i passaggi che possono fare per prevenire lo sfruttamento. Ma fondamentalmente, come ho detto, è un problema che non sta scomparendo. Il numero di CVE o di vulnerabilità ed esposizioni comuni aumenta ogni anno di circa il 25% nel 2022 rispetto al 2021. Non è super sorprendente che più 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, quello buono. Ci sono programmi bug Bounty.
Hai familiarità con quando Apple distribuisce continuamente correzioni di codice per il tuo iPhone. I ricercatori di un buon cappello bianco stanno inviando exploit a questi sviluppatori, e poi ci sono anche attori cattivi che sfruttano anche le vulnerabilità. Quindi, solo un po’ di informazioni. Forse alcuni comuni di cui hai sentito parlare di recente. HTTP2/Ripristino rapido è stato di recente un aspetto 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 di dati qui negli Stati Uniti, in realtà in tutto il mondo. Questo è solo un po’ di background sulle minacce zero-day, ma sì, forse andrò avanti e inizierò chiedendo a Dave solo un po’ di cosa fate voi per proteggere Edgio e i nostri clienti dalle minacce zero-day.
In che modo Edgio protegge se stesso e i suoi clienti dalle minacce Zero-Day?
Dave Andrews: Si’, assolutamente. Quindi la sicurezza, credo, sia tutta una questione di difesa in profondità, giusto? Tipo, non c’è mai una cosa particolare che fai. Si tratta più di assicurarsi di avere un certo numero di strati tutti legati insieme. L’idea è se uno o due strati sono imperfetti, come tutti perché abbiamo esseri umani molto intelligenti che cercano attivamente di spezzarli, l’enorme numero di strati e con protezioni e mitigazioni sovrapposte è progettato, sai, il punto è: 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 una delle cose più importanti sia che di solito 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 aggiornato il software o applicare regolarmente le patch. Questa è la cosa più noiosa del mondo. È anche probabilmente una delle migliori e più critiche linee di difesa. Significa che si approfittano di tutte le informazioni responsabili di cui si parlava, Andrew, i buoni ricercatori del cappello bianco, trovando delle vulnerabilità, divulgarli ai fornitori, correggerli 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 sia facile soprattutto quando si sta lavorando sulla scala che siamo in Edgio, così come in molti altri posti, è molto, è molto difficile gestire il rischio che comporta l’aggiornamento regolare di tutto il software. Quindi, come vedremo più avanti, ci sono molte cose che facciamo operativamente per renderlo più sicuro e più facile da fare. Ma cade ancora abbastanza perpendicolarmente nel secchio dell’igiene, se volete. Il prossimo pezzo che atterra all’interno dell’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.
Quindi questo assume una serie di forme. Può trattarsi di team di sicurezza interni o di team di sicurezza delle informazioni. È possibile assumere parti esterne per eseguire le scansioni. Possono essere entrambe le cose. Spesso le organizzazioni sfruttano la taglia dei bug per incoraggiare le persone a prendere la strada del cappello bianco, trovare le 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 tutto quello che puoi aggiustare, prima sistemare, giusto? Ad esempio, approfittate del buon lavoro che l’intera comunità sta facendo per rendere Internet e il software in generale più sicuri. E poi guardare attivamente le proprie applicazioni, cercando di trovare le vulnerabilità e correggerle in modo proattivo come meglio si è in grado. La prossima sezione che direi circa la preparazione, mi rivolgerò a Marcel, è osservabilità.
Marcel Flores: Si’, 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 vostra rete o con la vostra infrastruttura. Credo quindi che questo tipo di cose ricada in due categorie che sono fondamentalmente affrontate allo stesso modo, ma credo che sia importante fare chiarezza. Il primo è pensare ai comportamenti a livello di applicazione, giusto? Assicurarsi di comprendere quali richieste vengono inviate alla rete e quali sono le funzioni di tali richieste, come sono strutturate e come appaiono normalmente e come potrebbero apparire durante determinati eventi. Penso che sia anche importante, tenere presente che ogni volta che stai comunicando su Internet, giusto, è una sorta di operazione full stack, giusto?
Dove ogni richiesta passerà attraverso sia il livello dell’applicazione, sia i protocolli di livello inferiore. E quindi è importante tenere d’occhio ciò che sta succedendo più in basso nello stack, giusto? E capire che potrebbero esserci 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 avere osservabilità in ciò che sta succedendo in entrambi i casi. E penso che un elemento chiave sia riuscire a capire quando cambia il traffico, giusto? Quando il vostro traffico supera le aspettative, giusto? Potresti iniziare a vedere caratteristiche delle richieste di applicazioni che non sono ciò che vedi normalmente, giusto? Ad esempio, un improvviso aumento dei post HTTP rispetto ai GET, pensando al livello dell’applicazione, pensando al livello del protocollo, giusto?
Questo può essere qualcosa di molto intricato nel protocollo come HTTP2 o qualcosa di ancora più basso. E pensando a cosa sta succedendo ai socket TCP e a cosa sta succedendo con le interazioni del protocollo a quel livello, soprattutto quando si pensa a cose come gli attacchi DDoS che potrebbero tentare di sfruttare particolari vulnerabilità. Penso che la chiave per avere queste vulnerabilità, per questa osservabilità non è 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 il punto in cui le cose stanno effettivamente accadendo e come potrebbero accadere.
Andrew Johnson: Questo è interessante. Questo è interessante. Quindi, dopo aver osservato questi diversi tipi di comportamento o qualcosa che pensi possa essere uno zero-day, quali sono alcuni dei passi operativamente che puoi fare?
Quali misure potete adottare per mitigare le minacce Zero-Day?
Dave Andrews: Sì, posso prendere quello, Andrew. Si’. I due tipi di elementi di cui parlava Marcel sono davvero le fondamenta, giusto? Come il primo è guardare le cose, guardare le tendenze, che si riduce a una prospettiva, guardare le cose in aggregato, giusto? Come, cosa sembra tutto questo? E il punto è che hai una visione di alto livello di ciò che sta succedendo, e ti consente di identificare i cambiamenti molto, molto rapidamente, come hai detto. La seconda parte, in termini di immersioni profonde, è in realtà riuscire a prendere in giro e sviluppare la propria comprensione su quale cambiamento, a quale livello sta operando, ed è un rischio, giusto? Come, sai, Internet è il selvaggio West selvaggio, giusto? Le cose cambiano di continuo.
Ci sono sempre nuovi comportamenti. Non tutte queste cose sono un problema di sicurezza, giusto? Ad esempio, la capacità di avere un insieme aggregato di informazioni molto più ampio, ma consente di scavare, porre e osservare o meglio rispondere a domande molto più sfumate, consente di arrivare al cuore di ciò che è cambiato e perché e di prendere quella decisione. Tipo, oh mio Dio, come, questo va bene. È un nuovo cliente che fa qualcosa. O sai che questo è davvero un problema, o dobbiamo andare a controllare. Quindi allontanarsi da, sai, vedere ciò che è successo, e sviluppare una certa comprensione su di esso è un problema. Entri nel regno di tipo, grande, e poi?
Che cosa fate? E questo secchio di ciò che chiamiamo agilità e agilità operativa. Ci sono alcuni temi di alto livello che riflettiamo quando consideriamo l’agilità operativa. Anche in questo caso, tre sono reattività, sicurezza e ridondanza. Quindi passare un po’ di tempo su ognuna di queste reattività è 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 rapidamente, in modo da dare agli autori degli attacchi il tempo minimo necessario per seminare il caos e dare il massimo tempo per ripulire. Quindi, ciò che ci prefiggiamo da un senso molto ampio, non solo per quanto riguarda i problemi di sicurezza, ma anche per tutti i tipi di cambiamenti operativi che apportiamo, miriamo a circa cinque secondi per raggiungere il 99,99% dell’infrastruttura.
Questo è l’obiettivo. Non ci arriviamo sempre perché alcune cose richiedono necessariamente più tempo, ma questo è il bersaglio. E molti dei nostri sottosistemi soddisfano quell’obiettivo. La sicurezza è un tema strano a cui pensare con agilità operativa. Quindi lasciate che lo prenda in giro un po’. Uno dei rischi che si ha quando si sta cercando di fare qualcosa con un alto livello di reattività, cioè molto, molto rapidamente, è che si potrebbe risolvere il problema molto, molto rapidamente, supponendo di avere una perfetta osservabilità e una perfetta comprensione di esattamente ciò che sta accadendo, e puoi prevedere perfettamente la risposta al cambiamento che stai per fare. Questo è grande, e molte volte è così. Tuttavia, c’è anche la possibilità che la tua comprensione di una di queste cose sia imperfetta, e potresti anche peggiorare molto, molto rapidamente.
Nessuno lo vuole. Quindi il punto fondamentale della sicurezza è che si mettono in atto sistemi, processi e automazione, e molte altre cose entrano in esso per assicurarsi che non peggiori, in realtà, le cose. Si riduce a un paio di cose di altissimo livello. All’inizio. È come la modellazione proattiva. Questo vale molto per la pianificazione delle capacità di base, giusto? Ad esempio, se per qualche motivo è necessario interrompere la produzione dei computer per applicarne le patch, perché è necessario riavviare i servizi per qualsiasi motivo. Uno dei rischi lì se si tenta di farlo molto, molto rapidamente è prendere troppe macchine fuori produzione per il carico che stanno attualmente sperimentando. Lo sa in anticipo, vero?
Abbiamo molti sistemi di modellazione che si integrano con i sistemi di flusso di lavoro in modo che quando una richiesta di patch di tutto il più velocemente possibile non estragga immediatamente tutti i server dalla produzione. Esistono quindi sistemi di sicurezza di base che è possibile costruire e integrare per evitare di sparare ai piedi. E quindi, supponendo 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, qualunque cosa sia che stiamo cercando di mitigare. Quindi quello che facciamo per sfruttare un sistema che chiamiamo miniera di carbone. Ne abbiamo parlato pubblicamente prima, ma l’idea che ci sia praticamente tutto va fuori come quello che chiamiamo canarino – canarini nella miniera di carbone.
Il punto è che non succede nulla a livello globale in una volta, non importa quanto sia terribile. Un minimo di due fasi per uscire qualcosa. Quindi l’abbiamo messo su un sottoinsieme di infrastrutture. In genere, l’infrastruttura che sta vivendo l’evento più egregiamente o più visibile, verifichiamo che faccia quello che ci aspettiamo e poi lo distribuiamo molto rapidamente in seguito. Spiacenti, implementarlo in modo più ampio e verificare che il problema generale venga risolto a livello globale. Quindi, miniere 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 di fatto affrontando il problema.
Quindi è molto, molto utile. Ciò su cui stiamo effettivamente lavorando al momento e ci stiamo preparando per il lancio interno e in seguito, produrremo questo per i clienti e le loro modifiche di configurazione, è fondamentalmente un’analisi metrica completamente automatizzata. Quindi, attualmente, quando facciamo un cambiamento come questo, richiede che un essere umano si sieda lì a guardarlo, assicurandosi che stia accadendo la cosa giusta, e assicurarsi che le metriche di cui sono preoccupati si muovano nella giusta direzione. E poi sostanzialmente 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. In questo modo, utilizziamo il sistema per tutte le modifiche, non solo per le modifiche operative di sicurezza, ma anche per tutte le modifiche che avvengono all’interno del sistema.
E quello che stiamo cercando è 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 quindi gli umani cominciano a commettere 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 guarda i canarini fondamentalmente che fa alcune analisi statistiche sofisticate sulle metriche, come quando i cambiamenti si stanno diffondendo e gli dà un pollice su o un pollice giù. E questo è integrato con la miniera di carbone in modo da poter dire, ehi, in modo automatizzato, otteniamo qualche indicazione che il canarino è 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 emozionata. 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 scomparire rapidamente e in sicurezza il problema. L’ultimo punto che ho menzionato è stato il licenziamento, che è relativamente autoesplicativo. C’è un punto chiave o una filosofia che utilizziamo e distribuiamo che è fondamentalmente un percorso duale per molti di questi cambiamenti, quanti più possiamo raccogliere. Quindi, cosa significa doppio percorso, i due percorsi che pensiamo sono sostanzialmente veloci, migliori sforzi e lenti, affidabili. L’idea è che gestiamo una grande quantità di infrastrutture in luoghi molto, molto diversi 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 è fattibilmente possibile. Qualcosa da qualche parte e’ sempre un problema. E non c’è davvero niente che tu possa fare al riguardo. Quindi quello che facciamo e’ che in pratica mettiamo insieme queste cose in modo simile alla sicurezza, alla difesa in profondità, giusto? Ad esempio, avete messo insieme queste due cose e, e ciò che sembra, è sfruttare il percorso veloce. Andate a colpire il più possibile. E poi qualsiasi cosa ti perdi, ci assicuriamo di avere un percorso ridondante e affidabile che continueremo a riprovare fino a quando non funziona, questo è 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 che il 99,9% è ripetibile e affidabile. E poi il percorso lento e affidabile corre nell’ordine di 60 secondi. E quel sistema continuerà a provare fino a quando non avrà successo. Quindi, sfruttando questi due elementi 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 cose tipo, piccole cose divertenti per assicurarci che ci siano dei licenziamenti. Come si fa a dare il via a questi sistemi? Come molti sistemi hanno lo sai, i chatbot integrati, quindi è molto, molto facile.
Chiunque può farlo da qualsiasi parte del mondo sul proprio telefono. Molte altre cose hanno API. C’è una CLI per molti sottosistemi. Quindi assicurarci che non ci sia un solo modo per dare il via a questi compiti è un altro esempio di come cerchiamo di costruire in ridondanza in modo da poter sempre avere quell’agilità operativa a portata di mano, indipendentemente da ciò che sta accadendo o da quale particolare sistema potrebbe avere un problema. Ci assicuriamo di avere il controllo e la capacità operativa di cui abbiamo bisogno. Molte di queste cose, sai, sono tutte di uso generale, ma come ho detto, le utilizziamo per il più possibile. Tutto, dai flussi di lavoro dell’infrastruttura, come l’interruzione della produzione di una macchina e l’applicazione di patch, fino alle modifiche di configurazione dei clienti. Tutto sfrutta lo stesso sistema di base che utilizziamo per il cibo per cani e ci sfruttiamo in modo aggressivo. Quindi il prodotto che esponiamo ai nostri clienti è affidabile e molto, molto solido.
Andrew Johnson: Fantastico. Fantastico. Apprezzo quel Dave. E Marcel, credo che tu abbia parlato di BEST practice o considerazioni che i team di sicurezza possono applicare alla loro pratica. Apprezzo quei consigli. So che avete sicuramente avuto a che fare con alcuni interessanti esempi zero-day in natura per proteggere Edgio e i nostri clienti. Sono sicuro che hai alcune buone storie e applicazioni di queste BEST practice. Potrebbe parlarne un po’?
Esempi zero-day: HTTP2/Ripristino rapido
Dave Andrews: Si’, assolutamente. Penso che quello che è più pertinente o più recente, immagino, ed è stato un po ‘interessante è, l’hai menzionato 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 tizio mentre è successo. HTTP2/Rapid Reset è stato un attacco zero-day in cui le persone si sono rese conto che non solo l’implementazione delle librerie server HTTP2 in modalità aveva preso qualcosa nel RFC HTTP2, la specifica, la specifica del protocollo come raccomandazione generale e sostanzialmente 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 nella specifica, scritto come un centinaio.
Questo insieme a un piccolo aspetto interessante dell’H2, che è, come sapete, l’idea di essere il multiplex (molte e molte richieste su un singolo socket TCP) e la possibilità di annullare le richieste ha portato a questa vulnerabilità molto interessante o vulnerabilità DDoS. Il punto è che quello che gli attaccanti cercano è qualcosa che costa una piccola somma per l’attaccante e costa di più per l’attaccante, per la persona dall’altra parte E l’hanno trovato nel ripristino rapido HTTP2. Ciò significava che l’utente malintenzionato poteva, molto, molto rapidamente, entrare come un singolo pacchetto avviando una richiesta e poi annullandola continuamente, come centinaia di quelli su un singolo socket spiacenti, su un singolo pacchetto e inviarla 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 poi, alla fine, dobbiamo registrare che la richiesta e’ avvenuta. Pertanto, il fatto che gli autori degli attacchi siano stati in grado di generare tali iniziazioni e annullare le richieste è molto, molto rapidamente. 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 piacciono molte altre persone del settore, sono state attaccate da questo.
E tutti sono stati attaccati nello stesso periodo, il che lo ha reso particolarmente interessante. E’ stato un attacco molto ampio. E mi piacerebbe capire cosa pensavano gli aggressori quando l’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 quando l’hai visto? Oh, è esattamente la stessa ora 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 parla Marcel. E abbiamo iniziato a costruire mitigazioni, giusto? In questo modo la mitigazione sembra aggiungere ancora più osservabilità per arrivare al cuore di ciò che stava accadendo e quindi costruire controlli operativi che ci permettono di modificare una risposta.
In realtà, tenete traccia di quante volte un client ripristina le richieste su un particolare socket e, se la percentuale supera una soglia predefinita, interrompete la connessione. Pertanto, l’idea è fondamentalmente di non consentire all’utente malintenzionato di inviare continuamente queste richieste per porre un limite e quindi essere in grado di mitigare l’attacco. Così abbiamo pubblicato quel blog dopo aver creato quella mitigazione, implementato, implementato e convalidato che in realtà stava impedendo che quegli attacchi si ripetessero. Poi abbiamo avuto persone del settore che si avvicinavano e come, oh, abbiamo visto il blog. In realtà siamo stati influenzati anche da questo e stiamo lavorando sulla divulgazione responsabile. Quindi ci siamo Uniti ad un gruppo dell’industria con cui lavorava come Vince, che fa parte del cert per passare attraverso il flusso di divulgazione responsabile, assicurarsi che in questo caso le persone che stavano implementando librerie HTTP2 o server HPD abbiano avuto il tempo di generare patch, distribuire tali patch prima di, la vulnerabilità fosse più ampiamente pubblicizzata.
Quindi è stato un flusso molto, molto interessante e interessante. Siamo stati in grado di cambiare le cose molto rapidamente, giusto? Come in parte a causa del lavoro che facciamo sull’igiene e sul funzionamento, sulla visibilità operativa e sull’agilità, 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 lo aggiorniamo regolarmente. Non era che fosse come, in realtà siamo, siamo una versione dietro, giusto? Ad esempio, perché aggiorniamo regolarmente le patch, il rischio è ridotto perché è un piccolo salto, il che significa che puoi farlo molto rapidamente mantenendo la soglia di basso rischio che abbiamo. Quindi l’abbiamo fatto molto, molto rapidamente e siamo in grado di implementarlo e mitigare l’attacco. E poi abbiamo pubblicato il blog senza sapere che l’attacco aveva colpito più persone in parte per cercare di socializzare non solo con i nostri clienti, ma anche con il settore. Come, Hey, questo è qualcosa di strano che abbiamo visto che sembra non sia nulla di specifico per Edgio e in effetti potenzialmente più applicabile. Ed è venuto fuori che lo era.
Andrew Johnson: Questo è, è davvero interessante. È interessante vedere una visione interna di voi conoscete, la comunità di sicurezza di tutto il mondo che lavora insieme per migliorare i risultati per tutti. Marcel, voleva aggiungere qualcosa?
Marcel Flores: Sì, volevo solo aggiungere una nota che io, credo questo, questo esempio era interessante in cui l’osservabilità iniziale che avevamo mostrato chiaramente strani comportamenti come Dave stava descrivendo, giusto? Questa interazione di una sorta di caratteristica di protocollo di livello inferiore con i comportamenti di livello superiore della CDN ha creato alcuni comportamenti davvero inaspettati. 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 consegnando ai clienti era distorto, giusto? E questo si è distinto. E anche se quelle erano entrambe metriche che avevamo raccolto, non le avevamo confrontate esattamente in quel modo. Quindi parte del risultato è stato sedersi a guardarlo e dire, Ehi, cosa, come possiamo combinare la visibilità che abbiamo già in qualcosa che è fatto su misura per rilevare questo problema? E siamo stati in grado di fare esattamente questo e migliorare la nostra visibilità osservando i dati che avevamo già attraverso una lente leggermente diversa.
Andrew Johnson: Fantastico. Fantastico. E’ un bene da tenere a mente. E grazie per questo, Marcel. Si’, ragazzi, quindi penso che siamo, stiamo concludendo. Se, se ci sono raccomandazioni aggiuntive che vuoi condividere? Penso che ne abbiamo coperti di alto livello, alcuni molto buoni.
Consigli per rafforzare il vostro approccio alla sicurezza
Dave Andrews: Bella domanda. Ritengo che una raccomandazione generale sia fondamentale per l’igiene. Concentrandomi sulla sua osservabilità, penso che la cosa che vorrei chiamare e’ trovare persone che possano aiutare, giusto? Come parte del valore di una proposta di valore critica che un’azienda come Edgio fornisce è che possiamo sicuramente aiutare, giusto? C’è 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 che potrebbero avere un impatto sulla gente. Quindi trova persone che possano aiutare, giusto? Come se ci fosse un sacco di strumenti e tecnologie che costruiamo, che la comunità ha a disposizione che possono rendere il vostro lavoro più facile. Quando stiamo parlando di, sai, generalmente cose su Internet, un WAF è come, è il più critico, come il più elementare inoltre, direi l’esempio più critico di qualcosa di simile.
Ti dà la possibilità se è implementato in modo appropriato, ti dà la possibilità di combinare l’agilità e gli elementi di sicurezza insieme. Quindi l’Edgio WAF viene eseguito in modalità doppia, il che significa che è possibile distribuire nuove regole alla produzione, sulle macchine che lo ricevono, che osservano il traffico. E potete vedere cosa sta succedendo. Un buon esempio è stato con Log4j, che è stato, sai, tornare indietro nel tempo un po’. Quando sviluppiamo la risposta a questo, siamo in grado di sviluppare la regola molto, molto rapidamente e convalidarla molto, molto rapidamente. Poiché stavamo inviando gli aggiornamenti delle regole e potevamo distribuirli in modalità di avviso sui computer effettivi e vedere che corrispondevano agli attacchi, dimostrate ai nostri clienti che non venivano attaccati o che venivano attaccati. E poi prendere una decisione basata sui dati per attivare la modalità di blocco di quella regola 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 possano aiutare. Credo che sarebbe la mia raccomandazione chiave.
Andrew Johnson: Ha molto senso. Lo apprezzo, Dave. Si’, cioe’, quando si risponde a zero giorni, il tempo e’ fondamentale. Quindi avere queste soluzioni specializzate, ma anche, cosa più importante, le persone che possono aiutarvi in questo modo è la chiave per chiudere la porta agli autori degli attacchi. Quindi, con questi ragazzi, grazie mille per essere qui con noi. Vorrei ringraziare anche il pubblico, e ci vediamo nel prossimo episodio. Grazie.
