ThreatTank – episodio 2 – andamento degli attacchi trimestrali

Un’introduzione a ThreatTank – episodio 2: Trend degli attacchi trimestrali

Tom Gorup: Benvenuto a ThreatTank, un podcast che copre le ultime informazioni sulle minacce. Risposta alle minacce e informazioni sul panorama della sicurezza in tutto il mondo. Sono il vostro host, Tom Gorup, Vice President of Security Services di Edgio, e oggi vi presento Richard Yew, Senior Director of Product Management di Edgio Security Solutions e Michael Grimshaw, Director of Platform Engineering di Edgio.

Tom Gorup: Benvenuto, Richard, Michael.

Richard Yew: Grazie per avermi invitato di nuovo qui.

Tom Gorup: Questo potrebbe diventare un tema ricorrente, Richard. Quindi, l’ultima volta che mi sono aperto con una domanda rompighiaccio e ho pensato che dovevamo continuare a farlo, ma trovarne una non e’ facile, giusto?

Perche’ credo che l’ultima volta abbiamo fissato una barra solida. Quindi, ecco la mia rompighiaccio. E per quel che vale, non ho neanche dato il tempo di pensarci. Quindi, mi unisco a questo. Ma ecco una domanda. Lo chiederò prima a te, Michael. Ti metterò sul posto. Se dovessi rimanere intrappolato in uno show televisivo per un mese, un mese intero, quale show sceglieresti e perché?

Michael Grimshaw: Devo ammettere che la prima cosa che mi viene in mente e che non ero nemmeno vivo nella prima corsa di questo sarebbe probabilmente l’Isola di Gilligan perché l’idea di passare un mese intero su un’isola tropicale, anche se devi usare il professore per capire come ottenere acqua corrente o qualsiasi altra cosa del genere. Una bella isola tropicale per un mese non sembra male.

Tom Gorup: Che risposta. Mi piace. No, non vedo Gilligan’s Island da molto tempo, e non lo dirò nemmeno ad alta voce è passato tanto tempo da quando ho guardato. E’ una buona risposta. E lei?

Richard Yew: Oh, wow, è difficile. Sai, ho pensato bene, voglio dire, ho detto un Peppa Pig come se ci fosse un altro show televisivo che ha maiali, sai che manterrò lo stesso tema maiale, ma credo che mi fermerò con questo.

Credo che per me, come Hands Down Game of Thrones, tipo, voglio dire, sarei intrappolato dentro Game of Thrones, ma forse avrò il primo o l’ultimo giorno, chi lo sa? Ma si’, voglio dire, andiamo avanti.

Tom Gorup: È questo. Si’. E’ coraggioso.

Richard Yew: Sì. E’ molto coraggioso. Si’. Sono piuttosto audace, amico.

Richard Yew: Probabilmente metterò il mio mantello nero e starò su un muro e vedrò cosa succede.

Michael Grimshaw: Bene, Tom, lascia che ti dia anche l’inverso. Qualsiasi Trono di Spade e qualsiasi serie di film a tema zombie sarebbe nella mia lista.

Tom Gorup: È una buona risposta. Volete sopravvivere, vero? E’ giusto.

Richard, amico, audace. Il Trono di Spade. Quindi, la settimana scorsa ero malato, sfortunatamente. Ho avuto il COVID, che è stato infelice. Ma ho recuperato alcune repliche della vecchia casa. Quindi credo di sì, sceglierei House. Voglio assolutamente fare qualche diagnosi e probabilmente dire che non e’ lupus. Devo solo dirlo almeno una volta.

Non è lupus. Non è mai lupus. Sarebbe il mio show per un mese. Penso che sarebbe un buon momento, almeno so che il mio tasso di sopravvivenza sarebbe piuttosto alto rispetto alla scelta di Richard.

Tom Gorup: Va bene. Quindi non siamo qui per parlare di programmi televisivi.

Siamo qui per parlare di un nuovo rapporto di tendenza con cui Edgio sta uscendo, di cui sono molto entusiasta. Sto scattando un’istantanea del quarto trimestre e osservo tutti i tipi di tendenze. E’ la prima volta dopo tanto tempo, dopo anni, direi che e’ una specie di rilancio di questo rapporto.

E stiamo coprendo tutti i tipi di punti dati dai metodi di richiesta, le tendenze nel tempo, uh, tipi MIME, ogni tipo di geolocalizzazione, uh, e questo va bene, vi ho portati qui oggi per parlare perché penso che ci siano molte informazioni interessanti dall’esaminare i dati in questo modo, penso che a volte si possano guardare i set di dati.

Tu sei tipo, beh, e allora? Che importa? Perché? Perché lo sto guardando? Come possiamo esaminare queste informazioni ed estrapolarne un certo valore? E poi sono cosi’ entusiasta di avere entrambi i vostri lavori. Approfondimenti. Quindi, a categorie di argomenti di alto livello che sono venuti in mente e che sarebbero di nuovo interessati alle vostre prospettive su uno era l’architettura delle applicazioni, giusto?

Architettura delle applicazioni: Ciò che osservi è importante

Tom Gorup: Se guardiamo questi, questo rapporto, pensando alla nostra, alla nostra architettura, alle nostre applicazioni, in che modo utilizziamo i nostri strumenti per essere configurati correttamente in base all’architettura della nostra app e magari anche in base alla conformità. Aspetti di, uh, come possiamo usare queste informazioni per ricominciare a pensare alle nostre app in un modo diverso.

Quindi, per cominciare, penso all’architettura delle applicazioni. E’ un po’ come ottenere un quadro di riferimento. Ci sono due punti dati in questo rapporto. Guarda i metodi di richiesta nei tipi di mente, e c’è di più. Possiamo sicuramente sentirci liberi di, sapete, avete visto i rapporti avere accesso. Potete tirare tutto quello che avete lì dentro.

Ma prima cosa? Perché è importante considerare? Questi tipi di cose, come i metodi di richiesta, sono in mente. Voglio dire, quando guardo per la prima volta il rapporto, era come il 9 98 per cento delle richieste per ottenere post. Cosa? Benvenuto su Internet, giusto? Ad esempio, perché è importante guardare quei dati in questo modo? Che ne pensate?

Michael Grimshaw: No, vorrei richiamare, sai, alcune delle grandi cose che mi vengono in mente sono ciò che osservi conta, ciò che guardi conta. Quindi possiamo parlare di architettura e costruzione come nuove app greenfield e di tutta l’architettura su questo aspetto da un lato.

Ma la prima cosa che otterrei, ed e’ il potere di rapporti come questo e dati e informazioni come questo, ovviamente l’intelligence delle minacce. Sono un convinto sostenitore della vostra architettura per quanto riguarda la conformità, le vostre esigenze di sicurezza, e i requisiti non funzionali sono, sapete, la logica aziendale della vostra applicazione non è un piccolo pool, ma sono finiti i giorni in cui ci si può concentrare solo sulla logica aziendale e su una cosa, bisogna guardare a più dimensioni, come ad esempio come regolare la propria osservabilità, come adottare approcci più avanzati all’infrastruttura e alla piattaforma come il ripristino e la rotazione delle credenziali.

Posso parlare, possiamo parlarne per giorni, ma la cosa importante è avere un’intelligenza attuabile per sapere cosa stai cercando. Quindi da un’app, da strumenti che hai menzionato, questa è una delle prime cose che chiamerei, capire dove sei, sai, quali sono i vettori. Quali attori statali stanno sfruttando gli script e tutti coloro che si trovano in mezzo stanno sfruttando il che deve informare su ciò che state guardando ciò che sapete, che state facendo, trimestralmente, sapete scansioni, si spera che stiate eseguendo scansioni più che trimestrali ovviamente. A seconda del profilo di conformità, è necessario eseguirlo in un minimo di trimestre, ma si spera di passare a un modello DevSecOps più adatto, in cui si esegue una scansione continua o in cui si esegue un monitoraggio continuo della sicurezza di build e mobilità.

Quindi la prima cosa che vorrei richiamare sono questi dati. Queste informazioni sono importanti da conoscere. Su cosa dovete concentrarvi più da vicino, su cosa dovete modificare il vostro stack di osservabilità per cercare il vostro stack di osservabilità della sicurezza, e poi invertendo il turno, giusto? È prestare attenzione a più elementi e a più potenziali vulnerabilità che è possibile introdurre nel codice per essere sicuri di non farlo.

Devi avere un occhio sull’orizzonte. Ogni volta che avremo una di queste conversazioni, sentirete molte analogie, ma è come se tu stesse correndo in una maratona o se stai facendo una corsa di fondo o qualcosa del genere, tieni gli occhi all’orizzonte in modo che dopo aver dovuto cambiare tatticamente. In un modo o nell’altro, a causa di una buca, conosci un fiume o qualcosa del genere. Non stai perdendo di vista gli orizzonti verso cui stai correndo.

Richard Yew: Voglio dire, dall’altra parte, come lo guardi tu, giusto?

Lo è anche quando si tratta di architetture applicative, sai, quando guardo i dati, come ha detto Tom, la maggior parte delle richieste possono essere imposte, ma sai, è Internet, giusto? Ma credo che una delle cose che si scompongono, è anche quando si guardano i dati, come quante richieste, perché vi racconta storie come, quali sono le conversazioni dei contenuti che stiamo ricevendo, giusto?

Ovviamente. Se state gestendo molto spazio per le applicazioni, sapete, specialmente, diciamo che avete una spa, giusto? Come architetture primarie, giusto? Vedrete molti post. Vedrete molti metodi diversi, vero? Se prendete molti contenuti generati dagli utenti, potreste vedere molti post e metterli, giusto? Quindi e’ davvero un bel crollo da vedere. Inoltre, dato che si tratta di dati di sicurezza, significa che questi dati provengono da un Web Application Firewall, giusto? Vede davvero quanti carichi utili ispezioniamo che in realtà incidono molto.

Quindi, in questo caso, molte volte mi trovo bene. Ma si vede anche una quantità abbastanza significativa di queste cose che provengono dal post perché è lì che i payload, quindi è molto, e racconta davvero una storia sulla superficie. Le aree di superficie dell’attacco, e vi dice che se guardate le distribuzioni del metodo di richiesta, giusto, qualsiasi cosa che riceve un endpoint, giusto, avrete un’area di superficie molto più grande perché, sapete, il post è come, uso un’analogia e la gente mi dice che è stupido, è in casa, come la richiesta di posta, è come la spazzatura e i bagni e, sai, il tuo pubblico, qualcuno, come mandarti un carico, sai cosa sto dicendo?

Tipi MIME

Tom Gorup: Mi piace quello che stai dicendo, però, è che cose come il metodo Just Request iniziano a dipingere un quadro. Raccontate la vostra applicazione, come viene utilizzata, come viene attaccata, dove potrebbe essere vulnerabile. Ti dà una buona prospettiva. E porta anche al tipo MIME.

Una cosa che ho pensato fosse interessante, mi piacerebbe avere il pensiero dei vostri ragazzi su questo, è che quello che abbiamo visto questo giro è un, è una grande quantità, il 76% di quei blocchi. Anche in questo caso, questa attività WAF è di tipo MIME JSON applicazione. Quindi c’e’ molta prevenzione in giro. Tipo di richiesta JSON e cosa ci dice di Internet nel suo complesso, come vengono sviluppate e progettate le applicazioni?

Richard Yew: Voglio dire, inizierò con questo. Come se ti dicesse da dove provengono le tue giunche, giusto? In un certo senso, JSON ha senso perché, tipo, la maggior parte dell’endpoint API, uh. Tipo riposante, anche non riposante, come GraphQL, lo dici tu, giusto? Contiene payload come JSON. Um, giusto. Quindi questo è il punto di partenza del corso, secondo me, non dovrebbe essere qualcosa di sorprendente per molte organizzazioni, giusto?

Ovviamente vedete anche payload provenienti dal tipo di contenuto HTML, uh, vedete un mucchio come da XML, giusto? Quindi, volete sicuramente una cosa quando si tratta di progettare e meccanismi di sicurezza, giusto? Non si vuole solo guardare JSON, ma si vuole solo, perché ho visto alcuni prodotti di sicurezza, possono solo analizzare XML.

Che non sono in grado di analizzare JSON. E’ come se non riesci a analizzare JSON, non puoi guardare i payload. Quindi vuoi essere sicuro di avere la capacità di JSON. Devi assicurarti che il parser sia aggiornato. Voglio dire, indovina un po’? Poiché la maggior parte di esso è stata ignorata a, a un WAV è come sfruttare il parser.

Quindi inviano payload tramite uno speciale formato di codifica o come se lo inviassero in un formato come. Anche solo a volte cambiare. Questo è un JSON, ma ha cambiato il formato in multi-part, qualunque cosa. E il web ha smesso di analizzarlo perché ha solo guardato le intestazioni. Oh, questo non e’ JSON. Quindi non lo sto analizzando.

Ecco come si fa scorrere il carico utile. Quindi è sicuramente qualcosa di cui si vuole essere in grado, prendere appunti come, wow, JSON, è il più popolare. Volete anche vedere quelli che sono alcuni dei più oscuri. Quelle e le cose che voglio sottolineare, ma le terrò per dopo.

Michael Grimshaw: Penso che Richard abbia fatto un’ottima osservazione: È solo una X e nessun parser la copre nell’era moderna dello sviluppo web. Non trovo sorprendente che i payload JSON e JSON delle applicazioni rappresentino una percentuale così elevata perché nello sviluppo web moderno, JSON è nel mondo, sapete, e non si tratta nemmeno solo di sviluppo web.

Guardate, per esempio, qualcuno dovrebbe nuocere. Che tu stia parlando di CloudFormation, AWS e altri, fammi usare perché AWS è grande là fuori. Non e’ stato molto tempo fa, quattro o cinque, forse un po’ piu’ di anni fa. Non ricordo la data esatta, ma CloudFormation era interamente XML e poi è stato trasferito su JSON e ha preso il sopravvento completamente.

Quindi è un’infrastruttura di sviluppo web, JSON. Si’, bisogna essere in grado di analizzare sia in JSON che in XML, ma anche il punto di Richard e’ ancora piu’ esoterico e il limite e’ che si deve essere in grado di analizzare tutti i dati.

Richard Yew: Sì. Parlando di valori anomali quando guardo i dati, bene, guardo sempre i punti dati più piccoli, come l’1% o il 0,5% o qualcosa che si è distinto dal rapporto è che ne abbiamo 0,14. Quindi il 0,14% di dati simili a tracce. Altre informazioni non caratterizzate, giusto? Ma potrebbe sembrare strano, ma quando si parla di miliardi di miliardi di punti dati al mese, voglio dire, il 0,14% del miliardo, è parecchio. E alcuni di questi tipi di contenuti si rivelano come immagini. JavaScript e altri, come si pensa storicamente che, oh, questi sono contenuti statici, come quelli sono altamente memorizzabili nella cache. Perché dovresti mettere il WAV davanti ai tuoi JPEG?

Sai, tipo perché hai molte immagini, giusto? Che cosa lo fa? Lascia che te lo dica, giusto? C’è questa cosa chiamata movimento laterale nella sicurezza, giusto? È come se quei JPEG. Ad esempio, a meno che non le inseriate nello storage, come ad esempio lo storage periferico, giusto, netto, e dove è solo il 100% di servizio, tutte queste richieste risalgono ai livelli Web, sapete, come nei vostri ambienti, se anche solo il 0,1% di queste richieste risale alle origini dell’utente, significa che l’utente malintenzionato può effettivamente inviare payload sotto forma di intestazioni, cookie, cookie, stringhe di query, argomenti, et cetera, dalla richiesta a un file JPEG e inviare questi elementi al backend. Quindi, se stai usando lo stesso backend per il tuo, ad esempio, il tuo, sai, il tuo HTML e il tuo JPEG, come JPEG, giusto?

Potresti essere sensibile ai movimenti laterali perché dicono: “Ehi, sai, questo è solo un dominio di immagini”. Forse non c’e’ bisogno che lo protegga. Molte persone sono come, perché dovrei mettere un WAF? Sprecare i miei soldi, sai, come mettere le protezioni su una cosa per lo più statica. E ancora una volta, questo è qualcosa da notare.

Vuoi sempre trovare difetti perché come difensore, come una squadra blu, giusto, devi avere sempre ragione. L’aggressore deve solo avere ragione una volta, giusto? Sapete, chissà, come i primi payload nella primissima richiesta JSON che viene inoltrata alle origini create dalla backdoor. Potrebbe succedere.

Tom Gorup: Sì. Il 100% e quello che mi piace di più di questo è che parlava prima di dipingere un’immagine o raccontare una storia sulla tua applicazione. Quindi, ottenere una buona comprensione dell’architettura della vostra app. E poi dove applicherete i vostri controlli?

Perché al punto in cui pensi che sia forse il meno vulnerabile potrebbe essere quella via di approccio quando guardiamo, ehm, e ancora, questo è anche all’interno del rapporto. Ma se guardiamo alle categorie di attacchi mitigati, il 45% era costituito da regole di controllo degli accessi, il che significa prevenzione delle richieste post.

Se la tua app non accetta post, come limita il tuo panorama di minacce, limita i punti in cui gli autori degli attacchi possono colpire la tua applicazione applicando regole di controllo degli accessi. Se non accetti la domanda, Jason, bloccalo. Giusto. Prevenirlo. Non c’e’ motivo di permettere che accada al primo posto.

E poi si porta un buon punto come, guardando il tipo di valori anomali, le porzioni più piccole dell’app. Mi piace quel processo di pensiero. Quindi lungo queste linee, continuiamo a tirare un po’ su quel filo. Quindi il 45% è costituito da regole di controllo degli accessi in cui abbiamo bloccato il 37%. Uh, siamo dei set di regole gestite.

Ecco tutta la vostra intelligence sulle minacce e il vostro cross-site scripting di questo tipo di tasse. E poi il 19% erano regole personalizzate che vedevano questo e pensavano come la difesa a livello. E’ un po’ quello che pensavo fosse che quando arrivano richieste, passano attraverso questi filtri che devi contemplare, giusto?

Un approccio di difesa a più livelli

Tom Gorup: Quando distribuite WAF o controlli di sicurezza all’interno dell’applicazione, è necessario conoscerne l’architettura e adattare gli strumenti di sicurezza in base a ciò. Per limitare ancora una volta il panorama delle minacce, ma poi servono anche livelli, giusto?

Michael Grimshaw: Hai bisogno di strati. E una delle cose che voglio fare, e voglio parlare con gli strati, ma credo che questo sia ciò di cui stiamo parlando, è che fa davvero luce sull’importanza del ciclo di feedback tra il vostro sviluppo, i vostri sviluppatori di funzionalità, il vostro SDLC, i vostri architetti, e la sua squadra di sicurezza, perche’ se la sua squadra di sicurezza o il suo WAF o il suo SOC o qualsiasi cosa stia volando cieca, non lo sanno, ok, dovremmo accettare i payload JSON qui?

Non pubblichiamo? Cosa facciamo? Quella comunicazione, quel circuito di feedback? È possibile risparmiare denaro fino allo spreco di tempo FTE, risparmiare sulle attrezzature, solo un ciclo di feedback stretto tra sviluppatori, architetti e team di sicurezza fa la differenza nel mondo.

Richard Yew: Quando si tratta di strati, dico sempre, no, ho intenzione di sollevare meta buzzword, sapete, come la difesa in profondità. Sai, penso davvero che abbiamo bisogno di una mentalità che abbia davvero ordine per le tue condizioni. Ma forse mi sbaglio.

Forse c’e’ un filtro dell’acqua a strato singolo, sapete, stanno usando dei cartoni di cocco, qualunque cosa, tipo, lo chiamiate. Giusto. Ma di solito in generale, quando guardiamo ai titoli, giusto? Nessun singolo strato può essere considerato un proiettile magico. Ad esempio, il fatto che si disponga di una gestione dei bot non significa che ci si aspetti che la gestione dei bot raccolga tutto, dalle applicazioni, come gli attacchi DDoS alle acquisizioni degli account.

Ogni meccanismo funziona insieme. E il modo in cui stai cercando di metterla, tipo, come sai. OK. Il più efficiente possibile. Tipo, quindi stiamo prendendo come regole di eccesso del 45%. Mi piace chiamarla ACL. Voglio dire, questo e’ solo, e’ ACL, giusto? È che l’ACL di solito viene eseguito sul nostro primo livello. E c’e’ un motivo dietro questo perche’ e’ economico da correre.

E’ solo un mucchio di IP, paese, qualsiasi cosa. ASN, firme JA3, giusto? Li hai messi dietro perché è una firma statica che qualsiasi cosa li violi. Immediatamente allontana il futuro in un secondo millisecondi, sai, giusto? Sono tutti i nostri strati, al plurale in meno di millisecondi.

Ma sai, come vuoi essere in grado di liberarti di tutta la sua spazzatura, giusto? E una volta avevo un amico che lavorava nel settore e’ come mi diceva lui, giusto, questo e’ un po’ quello che chiamiamo “riduzione del pagliaio”. Vuoi accettare un sacco di richieste simili in arrivo, vero? E cerca di trovare l’attacco.

E’ come se, beh, si stesse cercando di trovare quella singola richiesta HTTP che trasporta quel payload negativo e che si traduce in una violazione. Quindi stai cercando il bisogno di un pagliaio. In questo modo, puoi agganciare rapidamente il pagliaio e rimuovere la maggior parte della spazzatura possibile dagli strati anteriori in modo che possano essere elaborati i livelli più sofisticati.

Con ulteriori dati, cosa sarebbe di grande aiuto, si torna al fatto che non stiamo solo eseguendo la difesa perimetrale, giusto? E’ solo perché attraversi il muro. Non significa che ci siano, dovresti avere torri di guardia, giusto? Infatti, l’intero concetto di difesa in profondità è una strategia militare che è venuta dai Romani quando hanno ampliato i loro territori fino a diventare un impero.

Non e’ possibile essere dei muri intorno e assicurarsi di fare affidamento solo sugli altri perimetri per sconfiggere l’attacco. Ecco perché. Abbiamo stratificato la difesa.

Michael Grimshaw: Assolutamente. E penso che potremmo averne parlato, ne abbiamo parlato in una precedente discussione, Richard. Mi piace l’esempio di immunologia qui è che se la tua salute dipende da un ambiente sterile, sei un uomo morto.

Sai, non si tratta di evitare, non di avere un ambiente isolato e tutto ciò che è sterile. Si tratta di costruire l’immunità. E l’unico modo per ottenere che è così che si è liberi da agenti patogeni è sviluppare l’immunità a loro e un approccio difensivo stratificato è necessario per questo.

E’ come te. Sì, sono necessari i migliori firewall di rete. Sai, hai bisogno di un perimetro forte. Ma indovina un po’? Questo sarà violato. Voglio dire, nel mondo degli attori statali e dove si trova il mondo intero, è potenzialmente una minaccia. In effetti, è sufficiente pianificare che il perimetro venga violato.

Quindi, una volta fatto questo, qual è il livello successivo? E il livello successivo dopo quello, e il livello successivo dopo quello. E poi come monitorate e rilevate questi tipi di violazioni in modo da sapere cosa stanno cercando. Si’, e’ imperativo

Architettura distribuita

Tom Gorup: Questo è interessante, e per qualche motivo, ci sta pensando a come gioca un’architettura distribuita in questo? Perché qui vedo due estremità dello spettro. Potreste guardarla e considerare il rischio, aggiungete una proliferazione incontrollata, ma poi potreste anche farlo. Guardatelo e, uh, apportando più valore. Distribuzione dei carichi di lavoro in varie regioni o ubicazioni, per una maggiore disponibilità.

Allora, dove lo vedete giocare?

Michael Grimshaw: Assolutamente. Viviamo nel mondo dell’architettura distribuita. Quando hai un’impronta globale, bene. Sapete, più di 300 POP punti di presenza in tutto il mondo. Siamo in un’era di elaborazione parallela ampiamente distribuita, e non siamo solo noi. Voglio dire, questo risale a oltre 20 anni fa, ma questa è l’essenza dello sviluppo web. Infrastruttura Web. Dovete presumere di essere distribuiti. Che state correndo massicciamente in parallelo e dove, la cosa che sposta l’ago qui da una sicurezza, da un supporto e da un costo è la prima cosa che vorrei richiamare è evitare di evitare i fiocchi di neve, e questo riguarda anche la conformità, in breve, arriveremo a questo punto: se si esegue un’architettura massiccia parallela, distribuita in modo massiccio, è necessario che l’infrastruttura sia il più simile possibile con il maggior numero di varianze in quella architettura distribuita e distribuita. Um, um, uno, perché quando parli con i tuoi auditor, puoi affermare che puoi attestare.

Michael Grimshaw: Sì, dobbiamo solo esaminare uno di questi perché questo è un forziere in ogni, sai, dobbiamo guardare, sai, e i tuoi auditor lo assaggeranno. Non prenderanno solo un esempio e correranno con quello. Potete dare un’occhiata a uno qualsiasi dei nostri punti di presenza globali e sono fondamentalmente esattamente lo stesso tagliabasette uno dopo l’altro che aiuta a garantire la sicurezza.

Quindi, avete praticamente lo stesso modello a cui state lavorando sui vostri livelli e distribuendo i vostri livelli uno, ma anche mentre state monitorando, scansionando e osservando. Questa è una delle grandi cose di cui parlerei per quanto riguarda l’architettura distribuita e il motivo per cui ho detto che, in conformità, è perché se ci si trova in un sistema ampiamente distribuito, i vostri revisori non vorranno sottoporli a test e verifiche se possono convalidare e verificare e si può affermare che sono corretti. Esattamente la stessa architettura, sono concorrenti l’uno dell’altro.

Tom Gorup: Deve essere più facile a dirsi che a farsi, giusto? Specialmente quando si parla di un’architettura distribuita nel nostro scenario, giusto? Non stiamo parlando di distribuire un intero gruppo di istanze EC2 provenienti da un’immagine dorata in qualche luogo.

Stiamo parlando di hardware. Giusto. In un certo senso. E come si fa a rendere operativa una cosa del genere?

Michael Grimshaw: Questo è un punto eccellente. E in questo caso, si tratta di un approccio multilivello anche a questo. Non solo la sicurezza in questo aspetto viene da voi, dal vostro team di approvvigionamento e dal vostro team di gestione del ciclo di vita, dovete essere allineati su questo perché un buon esempio, il motivo per cui lasciate che ottenga Kubernetes è un ottimo esempio.

È distribuito in parallelo, non globalmente, ma non è possibile eseguire un cluster Kubernetes in tutto il mondo. Ma Kubernetes ottiene un grande esempio di questo è che si incontrano problemi in Kubernetes. Se avete un sacco di server che hanno driver diversi o diversi, sapete, nick card o hardware diverso, non è praticamente possibile eseguire Kubernetes.

Ecco perché, come ho detto, lavorare con la vostra gestione del ciclo di vita e il vostro team di approvvigionamento per rendere la vostra infrastruttura più conveniente. Questa è la punta della lancia sulla punta della lancia. Si desidera che l’hardware sia il più simile possibile all’altro. Ora, permettetemi di sottolineare un grande rischio che abbiamo recentemente sperimentato durante il COVID è il problema che abbiamo trovato con la logistica e il massiccio shock per lo spazio di distribuzione globale è arrivato dove voi, anche se si utilizzava hardware per tagliare i biscotti prima del COVID con i ritardi nella spedizione e gli shock per le spedizioni, il trasporto e la logistica.

Michael Grimshaw: Di essere in grado di ottenere lo stesso tipo di chipset o qualsiasi altra cosa del genere e non sei solo tu, ma le persone che acquisti hardware dai loro fornitori, ecc. È una sorta di grande sfida in questo modo che solleva il secondo livello in cui devi adattarti e che è attivo quando si passa all’imaging e al software effettivo che stai utilizzando, prima di tutto, come l’hypervisor o il sistema operativo o l’hypervisor?

Questo è il livello successivo a dove, anche se non è completamente uniforme sotto, si vuole arrivare il più vicino possibile. Il livello successivo è quello di renderlo uniforme e tagliatore di biscotti nell’imaging e nel livello hypervisor del sistema operativo. E poi, da lì, un approccio simile con le applicazioni.

Per una serie di motivi, è necessario ottenere la massima standardizzazione possibile per garantire la sicurezza dei costi.

Richard Yew: Sai, ti dirò come quando si tratta di applicazioni. Bene, sapete, contestata, so che probabilmente è contrario alla credenza popolare, e questo potrebbe essere un po’ controintuitivo perché stiamo pensando a un’architettura ben distribuita.

Quindi, stiamo prendendo da soft server centralizzati, ambienti cloud e siamo distribuiti in tutto il mondo. E se vi dicessi che avere un’architettura distribuita rende la superficie di attacco più piccola? Sembra un po’ strano. Sembra un po’, ma pensa in questo modo, giusto?

Avendo distribuito, ed è per questo che penso che sia molto importante quando si progettano applicazioni, specialmente stiamo parlando di siti web, giusto? No, design e quello che trovo un errore comune, e questa e’ la sicurezza al limite. Quindi, se escludo un po’ l’argomento, trovo che ci sia un errore in cui ho visto persone, clienti, organizzazioni, progettano le applicazioni in base a un’architettura centralizzata e poi cercano di eseguirle nella piattaforma distribuita come a, CDN, poi bisogna creare molta ottimizzazione, ma come, Oh, cosa deve essere spedito, sai, dopo il fatto della logica, ma sai, il moderno, si chiama design moderno, giusto?

Si tratta di progettare effettivamente applicazioni tenendo conto delle architetture distribuite. Sarebbe come, ad esempio, essere abituati a elaborare molte logiche in una posizione centralizzata. È sufficiente utilizzare CDN per memorizzare nella cache i file JPEG e statici, ecc. Ma che ne dici di spedire alcune logiche?

Diciamo che prendiamo solo un esempio molto semplice, come i vostri reindirizzamenti, giusto? Proprio come la vostra infrastruttura centralizzata originale sta per fare dei reindirizzamenti per un cliente. E se ci fossero decine di migliaia di reindirizzamenti collegati? Giusto. Che ne dici di spostare quelle logiche al limite?

Che ne dici di cambiare quelle cose? E facendo questo, giusto, quando dico superficie di attacco, giusto, lo siete, spostando quella logica verso il limite, giusto, riducete i carichi, riducete la probabilità di fallimento in un centralizzato, come, ad esempio, architetture, avendo scaricato parte di questo, sapete, la sicurezza esterna e’ la CIA, giusto?

Richard Yew: Stiamo parlando della disponibilità di questo. E’ molto importante. Quindi direi spostando molti di questi, compresi i meccanismi di sicurezza. Quindi, se siete in grado di filtrare di nuovo, restringere lo stack di fieno dell’attacco al bordo esterno dei perimetri, giusto, siete suscettibili, meno vulnerabilità nel vostro centralizzato, sapete, un cloud o un hardware simile, speriamo che non più.

Richard Yew: Voi ragazzi 2024, sapete, ma hardware, ma fondamentalmente chiamiamo le origini infrastruttura ed è molto importante. Posso solo dire che ci sono così tante altre cose che puoi fare perché siamo ovviamente al limite di quello che stiamo implementando molte tecnologie e ti dirò, amico, come fare il conteggio distribuito.

In circa 1 millisecondo e avere tutti i server, come, come le cose, giusto, che i dati, è un problema, sai, quando cerchi di sincronizzare il numero di richieste conteggiate al secondo in tutte le tue infrastrutture, uh, in un pop, giusto? Ma io… penso che sia qualcosa di cui vuoi fare uso.

Richard Yew: Quindi, quindi, invece di avere solo un cervello centrale, come, uh, logiche nella tua, nella tua architettura centralizzata. Iniziato forse a dividerlo proprio come gli umani, sapete, i cervelli umani sono architetture tecnicamente distribuite. Hai il cervello e il cervello della lucertola. E indovina un po’? Perché, perché quando tocchi qualcosa di caldo, non avrai tempo di reagire.

Richard Yew: Se quelle cose devono passare attraverso un cervello centrale. Devi bruciarti prima di tirarti indietro, vero? Ecco perché iniziare a pensare a ciò che è un nuovo progetto di architettura. Forse invece di fare apprendimento automatico e formazione e tutto ciò che avviene in un ambiente centralizzato, si fa deduzione all’edge della rete e poi si fa un training in sedi centralizzate.

Di nuovo, torna a piacermi. In un certo senso, si sta effettivamente riducendo un po’ la vulnerabilità e si rende l’intero sistema più robusto dal punto di vista della sicurezza.

Michael Grimshaw: Sì. Si’, e questa roba dice perfettamente quello che stavamo parlando di stratificazione e’ perche’ allontanarsi da un centralizzato, um, um, o anche quello di cui stavamo parlando con l’immunologia, allontanandosi da un approccio centralizzato, um, um, um,

Tu, se, quando vieni attaccato e ti pedinano, la quantità di dati o, o, o, o l’esposizione che hai è tremendamente limitata, quindi non è un booleano pieno, pieno, sono protetto o no? Quando tutto è centralizzato. Va bene. Se sono dentro e hanno accesso ai dati, avranno accesso ai dati, li renderanno distribuiti.

OK. Forse una regione o un sottoinsieme o un sottosistema. Um, um, un aggressore può sfruttare un giorno zero o qualsiasi cosa sia ed entrare, ma non hanno l’intero sistema. Ed è anche una cosa di resilienza perché non si perde tutta la corteccia cerebrale tutto in un colpo solo.

Richard Yew: A proposito, tipo, Lindsay bot mi ha appena controllato e, uh, credo di aver usato una cattiva analogia. L’essere umano e’, credo che noi, non abbiamo cervelli e altrove, ma avrei dovuto, avrei dovuto dire che e’ un polpo. Un polpo ha il cervello e tutte le braccia. Si’. Questa è una vera architettura distribuita.

Geolocalizzazione – dove stiamo bloccando la maggior parte degli attacchi?

Tom Gorup: Si’, e’ giusto. Bene. Quindi, rimanendo sulla linea dell’architettura distribuita, magari tirando un po’ la conformità qui. Una delle statistiche che pensavo fosse. Era piuttosto interessante per me, almeno per vedere sulla carta, stavo guardando la geolocalizzazione. Allora, dove stiamo bloccando gli attacchi dai primi cinque paesi?

Va bene. Ho capito che i primi cinque paesi erano noi, Francia, Germania, Russia e Cecenia. Quello che ho pensato fosse super interessante qui è per quello che vale la pena sapere che ci sono molti Apts che scappano dalla Cina. Non sono sulla lista. Non sulla lista, cosa che ho pensato fosse interessante quando pensiamo alla geolocalizzazione.

Penso che molte persone si rivolgano al geofencing. Ehi, fammi chiudere in paesi da cui so che potrebbero essere attaccati, ma al 26%. L’odiatore numero uno era dagli Stati Uniti. Tipo, cosa vi dice questo? Penso anche di pensare a questo aspetto dal punto di vista della conformità. Come fa quello che e’ il geofencing in, sai, 2023, 2024, e’ a questo punto che ci troviamo ora.

Richard Yew: Voglio dire, la mia opinione, giusto, so che abbiamo, tipo, ogni cliente, sai, quando saliamo a bordo, parliamo di controllo delle esportazioni, e dobbiamo, tipo, fare, tipo, quel controllo con, tipo, geofencing, mi sento come se alcune di queste cose, alcuni di quei requisiti da rivisitare, visto che so che potrebbe non essere qualcosa che tutti vogliono sentire, specialmente se gestisci GRC, mi scuso in anticipo se ti sto dando il mal di testa, ma credo che siamo in un giorno in cui e’ come se tutti avessero messo le mani su VPN e tutto il resto, giusto? E così facile far girare le macchine virtuali ovunque. Come, ricordo quando guardavamo Black Hat l’anno scorso, stavamo guardando distribuzioni come l’ISP per un attacco DDoS anonimo del Sudan, giusto?

Richard Yew: C’è tipo, stanno usando un provider di hosting. Ovunque. Sappiamo da dove vengono, come se provenissero da questo specifico paese, l’Europa dell’Est, come se fosse lì che si trova l’organizzazione, giusto? Ma poi l’attacco viene da qualsiasi luogo, come al giorno d’oggi. Quindi e’ come se poi bloccaste un hacker cinese da Joe che scherma la Cina? Funziona al giorno d’oggi? Giusto?

Michael Grimshaw: No, ma hai assolutamente ragione. E, la Cina è nota storicamente per aver utilizzato questo approccio molto, molto VPN e, e offuscando davvero l’origine di dove l’attacco è, um, ovviamente con la Russia, usano così tanto di un locale, sapete, quasi lo stato, quasi incoraggiando i singoli attori in Russia a prenderne parte.

La struttura di comando e controllo della Cina è un po’ meno di quanto diciamo mob o, um, orientata che vedete in Russia o, o, o Cheshire e cose del genere erano decentralizzate. Esattamente. Um, bella scelta. Um, ma si’, e, e Richard, penso assolutamente che tu abbia ragione. Dobbiamo riesaminare questo aspetto, ma ci saranno clienti e ci saranno segmenti di mercato.

E i mercati verticali che hanno requisiti normativi. Quindi, e uno dei più grandi con cui non si scherza è l’Office of Foreign Asset Control, OFAT. Ed è qui che il geofencing e con, come in particolare uno qualsiasi dei servizi finanziari, del settore bancario, assicurandosi che, sai, assicuratevi che le vostre banche o i vostri servizi finanziari non siano disponibili per la Corea del Nord, ad esempio, o per l’Iran e altri posti nelle liste dell’elenco.

Il geofencing è ancora importante, soprattutto per quanto riguarda i requisiti normativi. Dobbiamo rivisitarli. E, e abbiamo bisogno, um, in effetti, questo, questo è appena venuto fuori in Ucraina dove, um, um, uh, si è detto che, che il forte russo, mentre [00:39:00] Starlink usa la geolocalizzazione. Per evitare che venga usato in Russia, la Russia opera soldati russi e operatori lo stanno usando, uh, provenienti da altri paesi nel, uh, territorio ucraino occupato.

L’elenco è lungo sul duplice uso. Materiali a duplice uso, cose del genere che potrebbero essere utilizzate sia per scopi civili che militari e come spesso provengono da paesi terzi, e questo è vero anche in questo caso, ma ci sono ancora linee normative assolutamente rigide. Alcuni clienti hanno a che fare con o con il geofencing.

Richard Yew: Hai ragione. E’ solo una corsa agli armamenti. Penso che il punto sia che, mentre parliamo di architettura distribuita, abbiamo parlato di quanto sia importante per i nostri clienti usarla per proteggerci. Ma come Mike e io abbiamo detto, entrambi gli autori degli attacchi utilizzano architetture distribuite.

Richard Yew: Voglio dire, sono, beh, voglio dire, è un po’ divertente, era questo il punto dell’attacco DDoS. Giusto? Voglio dire, è da lì che viene la D.

Tom Gorup: Sì, questo è buono. Sai, sono delusa dal fatto che stiamo finendo il tempo, perché penso che possiamo passare almeno altri 20 minuti solo su questo argomento.

Considerazioni e raccomandazioni finali

Tom Gorup: Ma visto che abbiamo un periodo di tempo, mi piacerebbe sentire un po’, sai, pensare a questo rapporto, pensare ad alcuni dei punti dati di cui abbiamo parlato qui. Dall’architettura delle applicazioni, alla conformità, al geofencing, a tutto il gioco d’azzardo. Mi piace sentire i tuoi pensieri e consigli al pubblico.

Cosa dovremmo guardare? Come possono proteggersi meglio?

Michael Grimshaw: Sì, amo questo rapporto. Voglio riportarlo indietro e parlare del rapporto. Abbiamo parlato di molte cose, ma una delle cose che, e forse questo e’ perche’ sto passando. Una delle cose che apprezzo di questo rapporto è l’audit PCI in due aspetti che vengono in mente, um, in cui questo rapporto e questi approcci aiutano a migliorare la sicurezza e, soprattutto, il livello di conformità è in PCI. Uno dei requisiti PCI è stabilire un processo per identificare le vulnerabilità della sicurezza delle vulnerabilità utilizzando fonti esterne affidabili per ottenere informazioni e assegnare una classificazione dei rischi. Ora, questo rapporto non fornisce esattamente un CVE, ma questo fa parte del layering del vostro approccio di controllo è che mi piacerebbe, sapete, prendere un rapporto come questo con specifiche di vulnerabilità del sistema operativo o spostare a sinistra come database delle vulnerabilità in quel background.

Michael Grimshaw: Da un lato, la possibilità di mettere insieme un quadro completo per i nostri revisori e, dall’altro, il PCI è assicurarsi che tu sia e io mi concentri solo sul PCI. Calza ISO a un intero gruppo di altri regimi. Ma l’altra cosa è che è importante che i dipendenti siano formati e aggiornati sul panorama della sicurezza e su come evitarlo.

E sì, si fa formazione su base annuale. Sai, devi allenarti quando qualcuno viene assunto. OK. Ogni anno dopo, ma rapporti come questo, questo è assolutamente qualcosa che vorrei fare attraverso tutti i miei dipendenti e in tutta l’azienda solo per aumentare la consapevolezza della sicurezza, contribuire alla loro conformità e contribuire alla vostra sicurezza. Sono un grande fan.

Tom Gorup: È un ottimo Consiglio. Mi piace. Che ne dici di te, Richard?

Richard Yew: Dirò sicuramente tipo, sai, a volte avere la visibilità è molto importante. E io direi di rendere le cose più facili, giusto? Sarebbe bello avere questo tipo di visibilità in tutte le applicazioni, almeno quello che stiamo parlando di applicazioni rivolte al pubblico, perché non esamineremo tutti gli endpoint della gestione, come i computer portatili e i Mac, ma almeno possiamo vedere come va avanti e indietro perché sono fermamente convinto che sia necessario avere un unico pannello di vista per tutto ciò che, come Internet, sta entrando e uscendo da qui.

Come nel caso di ogni richiesta HTTP, ogni richiesta esterna, dentro e fuori dalla rete deve essere catalogata ed essere eccellente. Ad esempio, se sono tutti raccolti e sono in grado di segnalarli con una visione consolidata come quella di cui abbiamo parlato qui, penso che contribuirà anche a facilitare la vostra conformità, specialmente quando si tratta di fornire prove, eccetera

Quindi. OK. Di nuovo, la visibilità è importante, giusto? Sai, se guardi le tre, beh, in realtà le cinque fasi di un framework di sicurezza NIST, giusto? Voglio dire, che c’e’ che, all’estrema sinistra, c’e’ solo un messaggio come le prevenzione e poi devi rispondere, giusto? Ma, sai, avere la capacità di avere visibilità, il rilevamento è molto importante.

Non potete mitigare ciò che potete vedere.

Tom Gorup: Si’, si’. Equiparo sempre il comportamento di sicurezza, la visibilità, le esposizioni e le minacce. Non posso proteggere quello che non vedo. Devo capire dove sono le mie debolezze, e devo capire come mi stanno attaccando. Sono i tre che si uniscono per definire il vostro approccio alla sicurezza.

E mi è sembrato un po’ interessante condividere questa cosa con altre persone del settore. Una delle immersioni più profonde che facciamo nella relazione, oltre a scavare nell’attraversamento delle directory, è stata in realtà il tipo di attacco numero uno che vediamo ancora oggi molto prominente su Internet.

Ora ci stiamo proteggendo da questo problema, ma ciò non significa che le applicazioni non siano vulnerabili ad esso. E assicurarsi che i vostri ingegneri o sviluppatori comprendano come questo attacco può essere utilizzato contro di voi è un ottimo modo per assicurarsi di creare codice sicuro da zero. E quello di cui ho parlato oggi è pensare all’architettura delle applicazioni, non solo all’architettura delle applicazioni, ma anche all’azienda e al suo funzionamento.

Quindi usandolo per informare i vostri strumenti di sicurezza, giusto? Quindi, disponete dell’architettura dell’applicazione per quali tipi di richieste mi aspetto di vedere? Quali tipi di MIME, ma anche dove è in grado la mia azienda di operare, applicarli e inserirli tutti come parte dei controlli nei vostri strumenti di sicurezza?

Quindi penso che questo sia ciò che mi entusiasma del rapporto non sia solo guardare i dati, ma prendermi anche il tempo di pensare, tipo, a come posso usare queste informazioni per pensare al mondo solo in modo un po’ diverso e magari usarle per informare i miei strumenti di sicurezza per mettere più controlli, vincoli, impedire che la mia attività venga spaccata. In fin dei conti, questo è ciò che siamo qui per fare è proteggere l’azienda, permettergli di dargli la libertà di manovra per fare soldi per gli elettori e portare valore ai nostri clienti. Così bella roba. E’ tutto quello che abbiamo per oggi. Grazie a tutti per aver partecipato a ThreatTank.

Se vuoi rimanere aggiornato con le ultime informazioni sulle minacce di Edgio, passa a edg.io. Questo è edg dot io e iscriviti, sai, otterrai più informazioni non appena uscirà. Michael, Richard ha amato la conversazione. Mi sembra di nuovo che avremmo potuto passare almeno altri 45 minuti. E’ stato fantastico.

Tom Gorup: Apprezzo davvero entrambi i vostri tempi.

Richard Yew: Sì. Si’. Grazie per averci invitati qui. Grazie per il grande impegno e le discussioni.

Michael Grimshaw: Grazie per la grande informazione, Tom. Si’. Lo apprezzo. E sempre divertente a chiacchierare con te, Richard. Eccezionale.

Richard Yew: Allo stesso modo, amico. Ci vediamo, ragazzi.

Tom Gorup: Fino alla prossima volta.