Un’introduzione al podcast Beyond the Edge di Edgio episodio 4: DevSecOps: Shift Left per evitare di spostare la tua roadmap dei prodotti a destra ospitato da Lauren Bradley, Global Campaign Manager di Edgio.
Lauren Bradley: Ehi, e benvenuti a Beyond the Edge, dove approfondiamo i dettagli delle moderne aziende digitali. Sono Lauren Bradley, la tua co-pilota per questo episodio, e oggi esploreremo l’argomento del cambiamento di sinistra, in particolare come la cultura e la tecnologia cambiano man mano che la protezione delle applicazioni web e delle API diventa una parte nativa e intrinseca del tuo ciclo di vita DevOps.
Iniziamo con una statistica scioccante del Ponemon Institute. Oggi, la maggior parte delle aziende impiega più di 200 giorni per rilevare una violazione. Se non stai rilevando una violazione abbastanza velocemente, ti costerà molto. IBM ha rilevato che il costo dei bug corretti rilevati durante la fase di test può essere 15 volte superiore a quello riscontrato durante la progettazione.
Quindi, per dirla semplicemente, più a lungo aspetti di trovare un problema, più ti costerà. E, non stiamo parlando solo di soldi, la rilavorazione, il tempo, e l’energia in definitiva possono spostare indietro le roadmap dei prodotti. Quindi, in che modo è possibile spostarsi a sinistra in modo efficace ed evitare di sprecare risorse preziose e di bloccare i propri progressi?
Oggi ci uniamo a noi, Michael Grimshaw, Director of Platform Engineering di Edgio, e Richard Yew, Senior Director of Product Management per Edgio Security Platform. Benvenuto, Michael e Richard. E’ bello averti.
Michael Grimshaw: Grazie, Lauren. E’ bello essere qui. Grazie.
Lauren Bradley: Potete dirmi un po’ di voi stessi e dei vostri pensieri iniziali su questo argomento? Mike, inizieremo con te.
Michael Grimshaw: Assolutamente. Prima di tutto, permettetemi di iniziare ringraziando, ringraziandovi, Lauren, per aver avuto un tale interesse. In questo argomento molto importante e, e stai scavando e aumentando e le conversazioni che abbiamo avuto e stiamo avendo intorno a questo, compreso questo un anno qui è, è solo un inestimabile e imperativo per il lavoro che stiamo facendo nel settore.
Michael Grimshaw: Questa comprensione deve essere condivisa in lungo e in largo e, e apprezzare davvero l’interesse. Mi chiamo Michael Grimshaw. Sono il Direttore di Platform Engineering qui a Edgio. Per quelli di voi che non hanno familiarità con, o, super familiarità con la piattaforma in termini di industria, sta davvero pensando in termini di unificazione delle vostre applicazioni e infrastrutture in unità coerenti.
E vengo alla piattaforma con un background di sicurezza pesante, e questa è un’area di cui sono abbastanza appassionato perché sposta l’ago in un modo così grande, per quanto riguarda la sicurezza, la redditività, e così tante delle aree che sono così importanti per il nostro settore.
E posso andare in giro per DevSecOps, ma lascia che lo dia a Richard per la sua introduzione.
Richard Yew: Grazie mille, Michael. Sì. Sì. Si tratta di un argomento molto importante. È molto vicino e caro nel mio cuore perché personalmente ho vissuto l’intero processo del ciclo di vita dello sviluppo del software, oltre a tradurli nel business.
Ora, parlando di quello che faccio… ovviamente, come ha detto Lauren, gestisco le nostre organizzazioni di gestione dei prodotti di sicurezza presso Edgio. Quindi, la mia vita quotidiana prevede di lavorare con il team R&D, il team di progettazione per garantire che stiamo effettivamente offrendo valore ai nostri clienti. E, sapete, tutto ciò che ovviamente includerebbe come ottimizzare la nostra pratica di sviluppo, la nostra sicurezza, la pratica dei CD ci. per essere certi di poter fornire prodotti sicuri.
Giusto. In questo modo, i nostri clienti sono in grado di offrire loro valore, rispettando i tempi e i budget previsti e garantendo loro un’esperienza eccellente. Quindi, il mio obiettivo in questo è quello di guardare davvero l’intero DevSecOps, sapete, dal punto di vista delle persone – il processo anziché la tecnologia e come possiamo effettivamente implementare le BEST practice, per il settore.
Cos’è DevSecOps?
Michael Grimshaw: Fino al tuo punto, Richard, lascia che ti ruoti la palla se non ti dispiace.
E penso solo che standardizziamoci su cosa intendiamo con DevSecOps e spostiamo a sinistra, giusto? C’era Gartner, ecco le cose per alcune persone che ascoltano su questo DevSecOps, e i termini cambiano a sinistra, spostano a destra, ecc. potrebbero sembrare relativamente nuovi. Questo non è nuovo, sai, non è come, oh, la cosa più calda che ha appena colpito un anno fa.
No, è da un bel po’ che si cuoce nel settore. Gartner ha inoltre pubblicato un rapporto del 2017 sul ciclo di vita di DevSecOps. Era solo un’estensione del DevOps, la tendenza DevOps del settore, che si estendeva per includere la sicurezza nell’infosec nel ciclo di feedback e nel ciclo di vita dello sviluppo del software.
E così, come ho detto, Gartner stava scrivendo in giro, scrivendo di questo, nel 2017, ed era già stato, un processo e un movimento nel settore. Per un bel po’ prima. Quindi, questi non sono concetti nuovi di zecca. E’ solo un’estensione di quello su cui abbiamo lavorato per anni. In effetti, DevSecOps è basato sul modello simile di DevOps, in quanto si ha un lato dello sviluppo e un lato operativo.
E al punto cruciale, si sta sviluppando in tutte le vostre esigenze di sicurezza il prima possibile, voglio dire, dall’inizio del progetto, costruire l’intero processo fino a dove i vostri sviluppatori sulla sinistra della nave si trovano sul lato dello sviluppo, mi scusi, spostare a destra è più sul lato dell’osservabilità delle operazioni. Ci concentreremo sul lato sinistro del turno oggi, ma fondamentalmente sta cuocendo nelle vostre analisi le vostre scansioni, e la vostra convalida, fin dall’estrema sinistra. E il più presto possibile nel ciclo di vita dello sviluppo nell’SDLC. Ad esempio, una delle cose di cui parla, e ancora una volta, risale a più di sette anni fa, è la sicurezza, la scansione e la scansione di librerie open source di terze parti, archivi, base di codice, così come il codice che scrivete, il design, l’architettura, tutti i nove metri, e la cottura fin dall’inizio. E uno degli esempi che ho dato è costruire e la scansione della sicurezza negli stessi IDE che i vostri sviluppatori utilizzano. È solo un esempio, e CE ne sono molti.
In modo che mentre scrivono il loro codice, ottengano un feedback immediato. Oh, ho appena lasciato la porta aperta per, sai, il credential stuffing o l’iniezione sequel, e diventano proprio come un errore di sintassi, ottengono un errore di sicurezza proprio lì c’è la scrittura del codice. Quindi, possono risolvere immediatamente questo problema, in modo da non avere un cliente che si lamenta del cliente o dell’utente finale che viene messo in pegno, sai, un mese dopo, no, è gestito proprio lì.
Il più economico, veloce, facile all’inizio. Richard, stava per dire qualcosa.
Perché cambiare a sinistra è così importante quando si tratta di costi?
Richard Yew: Oh, sì. Si’. Come penso che il costo sia davvero molto importante di cui parlare, sapete, beh, tutti conoscono molti costi operativi, sapete, qualsiasi organizzazione, è come lo sviluppo, giusto? Il processo di ricerca e sviluppo.
Quindi, quando si tratta di costi, è per questo che spostare a sinistra è più importante, giusto? Perché stiamo facendo un sacco di sforzi e parlando del perché, sai, sono sicuro che andremo nel “come” più tardi, ma vogliamo tornare a casa sul motivo per cui questo è così importante perché, sai, abbiamo dei dati.
Si’. Questo, secondo la nostra ricerca, mostra che sai, se stai correggendo una vulnerabilità di sicurezza che è stata trovata dopo aver rilasciato il tuo codice e le produzioni costano 15 volte di più di quanto tu sappia quando viene trovata in una fase di progettazione quando stai facendo il montaggio delle minacce. Ovviamente, non stiamo dicendo che sai, la fase iniziale dello sforzo di sviluppo catturerebbe completamente tutte le vulnerabilità di sicurezza.
Per questo motivo dobbiamo attuare la difesa in profondità. Ma è molto importante che tu sappia, guardando le otto fasi, sai, in generale, dei cicli di debito, dei cicli di vita da, sai, pianificare, codificare, costruire, testare, fino ad apprezzare monitorare e operare. Giusto. Li guardi più a destra vai, sai, come quando trovi una vulnerabilità della sicurezza, più costosa ci vorrà, sai.
Che le organizzazioni possano effettivamente risolvere il problema. Quindi, stiamo parlando della differenza tra, sai, trovare una vulnerabilità su una scansione che si verifica dopo che hai già rilasciato un mucchio di codici alle produzioni, invece di dire, sai, come fare un’attività di sicurezza dinamica delle applicazioni nell’ambiente di staging per rilevarlo prima di spedire quel codice alle produzioni, giusto?
Richard Yew: Potreste essere in grado di risolvere questi problemi o implementare una sorta di patch virtuali in anticipo prima di rilasciare una riduzione del codice per mitigarlo. Ma, ancora una volta, è molto importante capire che la sicurezza deve essere messa a punto fin dalla prima fase del processo, anche prima di iniziare a scrivere il codice prima di inserire qualsiasi cosa nel vostro IDE e iniziare a pensare di fare modellazione delle minacce. Ehi, quale parte del progetto potrebbe essere potenzialmente suscettibile allo sfruttamento?
Implicazioni quotidiane per i team DevOps e Security
Lauren Bradley: Sì, e questi sono davvero buoni punti, ragazzi. Voglio dire, dal punto di vista degli utenti, cosa può significare, al di fuori dei costi, dal punto di vista monetario, che cosa può significare per un DevOps o un team di sicurezza da sperimentare quotidianamente, se non lo implementano subito?
Inoltre, vorrei parlare di come implementarlo efficacemente nel ciclo di vita DevOps.
Michael Grimshaw: Ottima domanda. Ottima domanda. E voglio essere molto schietto nella mia risposta iniziale. Sono tutti nel settore, CEO, CTO, CFO – tutti, ingegneri, utenti – ciò che tutti vogliamo è solo un proiettile magico che possiamo fare, quello che facciamo quotidianamente.
E poi abbiamo un proiettile magico di sicurezza che ti basta premere l’interruttore e tutto il tuo lavoro viene reso improvvisamente sicuro. Questo è ciò che tutti vogliono, ma non è la realtà. Cioè, la gente CE lo chiede. Voglio chiedere loro, come va il tempo nella terra fantasy? Ho sentito dire che è bello. Questo tipo di anno è, e se vi avvicinate alla vostra sicurezza, alla vostra infosec, così come al vostro sviluppo, perché questo è solo un problema. Sai, “oh, comprerò alcuni strumenti che sto per imbattermi dopo che avremo tutto sviluppato, costruito e distribuito, e andrà avanti e renderà tutto sicuro”, stai comprando un peso cartaceo molto costoso, ad essere onesti con te.
Ed è per questo che, sapete, è stato menzionato, riguarda le persone, i processi e gli strumenti. Per questo motivo la coerenza totale di questo approccio è così importante. Sei tu, siamo lontani anni, decenni, se mai fosse possibile. Ad essere onesti con voi, abbiamo imparato molte lezioni dall’idea di voi solo progettare qualcosa e mettere un utensile di sicurezza e voi siete, siete pronti ad andare.
Influisce su tutto, dai costi alla velocità degli sviluppatori e sui costi per i clienti. E, un grande esempio di questo è il mio sospetto è che quasi tutti coloro che stanno ascoltando questo podcast ad un certo punto della loro carriera si sono trovati in una situazione in cui è stata distribuita una nuova funzionalità o un nuovo servizio o qualcosa del genere, o anche solo una patch e un aggiornamento. Sembra tutto a posto. Va tutto bene. E all’improvviso ricevi una chiamata da uno dei tuoi clienti o le infosecs ricevono una chiamata da uno dei clienti. “Siamo appena stati messi in pegno”, o “abbiamo appena avuto un incidente di sicurezza”, o qualcosa del genere. E il motivo è perché, okay, l’hai implementato, ma forse le scansioni non avevano finito di funzionare, o non hai fatto scansioni, o non le hai messe a punto correttamente, e hai appena introdotto una vulnerabilità di sicurezza enorme.
Forse vi riguarda, ma soprattutto riguarda i vostri clienti. DevSecOps consiste nel cuocere tutto questo insieme in un processo coerente ed evitarlo. Si tratta di tagliare i costi. Assolutamente. Si tratta di migliorare i margini? Oh, in gran senso. Ma si tratta anche di rimuovere la responsabilità per la tua azienda e quella dei tuoi clienti.
Incorporare la sicurezza in DevOps – è come cuocere una torta!
Richard Yew: Assolutamente. Sai, parlando di, sai, parlando di cuocere, sai, come Mike ha usato un termine così coerente totalità. Come se fosse così vero. Questo è molto potente, questa è una parola molto potente per mostrare perché è così importante avere quel cotto al posto, sai, come sono noto all’interno di Edgio per essere il ragazzo dell’analogia.
Mi piace lanciare un sacco di analogie e ho sentito questo grande. Credo che le analogie servirebbero da solida base per spingere per le giuste culture all’interno di qualsiasi organizzazione, come tutti sappiamo, in quanto persone della sicurezza, gran parte del nostro lavoro è l’evangelismo. Non si tratta solo di implementare le giuste tecnologie e creare un processo, ma anche di fare davvero un sacco di marketing interno.
Dire alle persone che sono importanti per la sicurezza dell’azienda, giusto? Perché, sapete, come leader della sicurezza, non è solo come, è come se le persone spesso pensassero alla sicurezza, come aggiungere ulteriori livelli di processo nel vostro flusso di lavoro, ma sapete, il modo giusto di pensare a questo è che la sicurezza può accelerare il business?
In che modo la sicurezza può effettivamente generare maggiori profitti, perché questo è un buon modo per giustificare molte delle implementazioni di sicurezza aggiuntive che è necessario fare per garantire la sicurezza dell’organizzazione. Quindi, una delle analogie che ho sentito era grande è che sai, la sicurezza non dovrebbe essere trattata come una ciliegina sulla torta, sai, come si cuoci la torta e si mette tutte le ciliegine come un ultimo passo, sai, di solito è quello che fanno le persone quando non hanno una sicurezza, flusso di lavoro ICD, e implementano firewall e, sai, protezione API, qualunque sia l’ultima fase della fase della fase di produzione. Quello che dovrebbe essere, la sicurezza, è come la farina, sai, dovrebbe essere stato qualcosa fin dall’inizio.
La sicurezza è come farina per preparare la torta. E poi quando la sicurezza è fatta bene, non si può vedere. E l’intero punto della sicurezza è quando è fatto bene, avrebbe dovuto essere cotto e non è visibile. Non dovrebbe essere qualcosa che crea sfide. Non dovrebbe essere qualcosa che rallenta l’organizzazione.
Come analogie che, sapete, ho usato per aiutare a mostrare al business perché questo è importante è che avere un processo di sicurezza forte, culture tecnologiche di sicurezza, è un po’ come avere freni forti. In una macchina da corsa, sapete perché ogni supercar là fuori ha grandi, sapete, davvero grandi, freni di lusso perché permette loro di affrontare più velocemente le curve.
Consente loro di frenare bruscamente. Permette loro di andare più veloce e di diventare più duro, giusto? Permette loro di vincere la gara. Quindi, avere freni forti è importante quanto avere un motore forte, giusto? E’ così che dovremmo considerare la sicurezza su un piano filosofico. Sai, ovviamente, parliamo molto di alti livelli, giusto? Quindi, ovviamente vogliamo, sai, un po’ più a fondo in questo. Il senso di tutto questo va bene, ma come lo implementeremo esattamente?
Michael Grimshaw: Sì. Penso che questa sia una grande chiamata è frenare. Una frenata potente garantisce il massimo controllo. C’è la corrente o la strada che abbiamo davanti è piena di curve, tornanti, e tutto questo, e c’è, certo, ci sono strade dritte in cui la pianeggiate e non toccate i freni, ma per navigare tutto, che, quel freno, penso, amore, amo entrambe queste analogie, Richard, perché quell’analogia di frenata, ti dà il controllo, ti dà un controllo più fine del grano quando ti trovi di fronte a marciapiedi, sfide e cose inaspettate.
Richard Yew: Ottima scelta. A proposito voglio chiarire, non mi è venuta in mente quell’analogia è di questo ragazzo chiamato Dr. Eric Koh. L’ha fatto, e gestisce un ottimo podcast. Quindi, Consiglio a tutti di andare a guardare. Ma sì, lo trovo così appropriato quando spiego il concetto al business, specialmente con coloro che sono nuovi a questo tipo di concetto.
Team problematici e isolati e roadmap dei cambiamenti
Lauren Bradley: Richard, parli di come, hai detto, sai, se, se la DevSecOps fosse finita, giusto? Non lo vedi. E ovviamente, una di quelle visibilita’ lampanti e’ il costo. Sono anche squadre isolate. Sembra anche che ci sia una disconnessione tra le squadre quando ci sono questi problemi che sorgono e perché non sono stati scoperti prima?
Quali processi, quale comunicazione non stava avvenendo per risolvere questi in modo rapido o efficace? Quindi, la mia domanda per voi è, sapete, nella vostra esperienza, quale di… sapete, c’è, probabilmente c’è una mancanza di trasparenza. C’è un processo decisionale lento, c’è potenziale per sprecare risorse.
Quando avete dei team isolati, quali sono i problemi più problematici quando, secondo voi, i team operano in silos?
Richard Yew: Sì, prenderò questo. Penso che una cosa che, sai, ho vissuto personalmente nella mia vita passata, giusto, è che sai, e questo è quando, sai, quando parliamo di prodotti simili, sai, come una sorta di pianificazione, è importante che a volte hai un team di sicurezza che non è un po’ incorporato nella R&S, come all’interno dell’organizzazione CTO.
A volte in molte organizzazioni, osserviamo silos tra i team di sicurezza e l’organizzazione CTO, e scoprirai che molti processi sono stati fatti dopo il fatto. Quindi, ad esempio, ci imbattiamo in una situazione in cui rilasciamo molti prodotti, rilasciamo molti codici perché non c’è un tipo forte di collaborazione di comunicazione tra i team di sicurezza e i team di ingegneria.
Quello che avete scoperto è che, sapete, un’organizzazione deve essere conforme. A volte, gli esempi specifici sono i team che vengono a fare le scansioni una o due volte l’anno. Qual è il risultato di quelle scansioni? Beh, mi verrà detto: “Ehi Richard, dobbiamo rallentare il prossimo trimestre perché abbiamo appena trovato un centinaio di bug di sicurezza grandi e piccoli diversi, sai, forse, tipo 20, come tra i primi 20 sono la gravità uno e due e più, mentre il resto, sai, si tratta, devi concentrarti sulla correzione di quelle cose.”
E c’è uno SLA all’interno dell’organizzazione per risolvere, sapete, quello che è successo è che facendo questo, in sostanza hai semplicemente seguito la mia roadmap e li hai buttati giù al trimestre successivo. Quindi, non spostandoci a sinistra, non mettendo in pratica questo processo, semplicemente facendo queste cose solo sul lato destro, stiamo essenzialmente spingendo la nostra roadmap, che è, sapete, la produzione di ricavi, potenzialmente che potrebbe aiutare a espandere la nostra attività. Avremo potenzialmente spostarlo bene in modo da poter effettivamente, sapete, spendere un quarto sta cercando, dopo il fatto, di mitigare questi problemi.
Questo è il motivo per cui dico, beh, è tremendamente costoso per l’organizzazione e per l’azienda immaginare di avere, dovendo spostare gli elementi della roadmap di un trimestre. Quindi, tutte le pianificazioni di rilascio dei nuovi prodotti, funzioni e funzionalità devono essere spostate, giusto? Perché non ti sei spostato a sinistra nella tua pratica.
Alcuni di questi aspetti avrebbero potuto essere migliorati grazie a collaborazioni migliori, in particolare tra i team di sicurezza delle applicazioni all’interno di un’organizzazione e il team di sviluppo. Ecco perché vediamo che molte organizzazioni stanno iniziando ad avere questo nuovo concetto. Sapete, avete sentito parlare di HR BP, sapete, HR business partner integrati in diverse business unit.
C’è ora un concetto di Application Security BP. Quindi, inizierai ad ascoltare questi termini come APP SEC BP che, potrebbe diventare pratica in cui hai persone che lavorano. Quasi come un manager semi-integrato del team di progettazione per garantire che forniscano la guida, gli strumenti e i processi giusti in ogni fase del flusso di lavoro di sviluppo, ad esempio, implementando l’analisi della composizione del software, implementando l’ID sicuro, implementando tutte le attività in scatola nera e bianca, durante il processo per garantire che, sai, siamo in grado di acquisire alcuni di questi problemi prima, sai, subito prima del ciclo di vita dello sviluppo.
Michael Grimshaw: E amo tutto. Ottima domanda, Lauren. E amo tutto quello che hai appena detto, Richard. Perché c’è un costo associato a questo. Sai, se le persone, se qualcuno è in un prodotto in cui sentono, aspetta, sai, se mi sposto a sinistra, non devo spostare la mia roadmap a destra.
Questa è musica per le loro orecchie. Ma forse per i CFO, o anche le operazioni, o altre aree del business, potresti dire, ok, beh, qual è l’impatto di questo? L’impatto è enorme. Hai appena inginocchiato il tuo reparto vendite. Hai influenzato i tuoi clienti perché hai, soprattutto quando si tratta di sicurezza, molti clienti. Dal punto di vista della piattaforma, quando parlo con i miei fornitori, voglio sapere qual è la roadmap perché, ok, forse devo andare dai miei revisori e devo ottenere un controllo compensativo finché non rilasciate qualcosa sulla vostra roadmap. Beh, se me l’hai detto, quello che mi aspettavo di essere consegnato in un quarto sarebbe stato di tre quarti. Inizierò a guardare altri fornitori. Perché? Perché ho degli obblighi con i miei revisori che devo incontrare.
E mi piace anche, Richard, che tu abbia parlato di revisori e del processo di conformità. Questo è un altro esempio qui al tuo punto, Lauren, su dove la siloizzazione può far saltare radicalmente le cose.
Se sei nel mezzo di un PCI, SOC, ISO, FedRAMP, uno qualsiasi di questi vari framework di conformità, e non hai davvero integrato, stai ancora gestendo una mentalità di asilo, probabilmente avrai qualcuno che è in conformità o INFO sec che parla con i tuoi revisori, dovranno tradurlo attraverso uno o due livelli al lato ingegneristico che si spera implementerà tutto ciò che è stato previsto, e poi è solo per farlo implementare. E poi tutte le prove, le scansioni e tutto quello che serve per restituire agli altri, buona fortuna.
Se questo si traduce in realtà, tutti abbiamo giocato al, sapete, quel vecchio gioco di voci della scuola elementare è un tipo di funzione simile in cui se avete team integrati che lavorano con gli auditor che sanno immediatamente come tradurre questo nella tecnologia specifica e avete la scansione e potete cambiare immediatamente la situazione e inserirla nel set di regole e scansionare e convalidare la tecnologia sia in tempo reale, sia quando incontrate gli auditor. Hai tutte le tue prove tutte insieme proprio lì. E’ un cambiamento radicale. Consente di consegnare i prodotti più velocemente ai clienti, invece di continuare a cambiare la roadmap subito, come ha detto Richard.
Lauren Bradley: Sì. Quindi, per essere più tangibili, voglio dire, come possono i CISO e i leader AppSec quantificare le loro metriche per comprendere le implicazioni in termini di costi o anche solo il successo generale?
Richard Yew: Cosa, sai, è divertente perché parliamo molto del perché, sai cosa, ma lasciamo, approfondiamo il come, perché lo so, questo è ciò per cui molti del nostro pubblico. Non siamo qui per darvi dichiarazioni morbide e di alto livello. Ciò che siamo qui per fornire speriamo è un po ‘di valore per quando si tratta di esattamente come implementarlo.
Quindi forse possiamo estrarre il grafico DevSecOps che abbiamo, e poi possiamo passare a come ottimizzare i passaggi. Va bene. Quindi, come potete vedere i test di sicurezza tradizionali, sapete, tipo di corse in modo lineare, giusto? È, è un po’ come quando stiamo parlando di cascata, come il tuo piano, hai, bellezza, un test, giusto?
Durante la fase di monitoraggio dell’operatore sono stati eseguiti numerosi test di sicurezza. Quindi, è sul lato destro. Quindi, ora che il nuovo concetto è, se passiamo alle prossime immagini, giusto? È che puoi trovare 100 diverse varietà di questo grafico. Come, quando oggi hai solo Google DevSecOps, come ha detto Mike prima, questo concetto è in circolazione, sai, da 7 anni, giusto? Sapete che alcune organizzazioni potrebbero non chiamarlo ciclo. Alcune organizzazioni lo chiamano semplicemente AppSec, giusto? Alcune organizzazioni le chiameranno pipeline di sicurezza. Quindi, questa è una rappresentazione approssimativa di ciò che rappresenta un gasdotto di sicurezza. Giusto? Quindi, fin dall’inizio, hai la fase di pianificazione, giusto?
Avete l’analisi delle minacce basata sulla modellazione delle minacce. Provi ad assicurarti di aver lavorato in tutta questa modellazione mentre stai progettando soluzioni. Così come, mentre codifichi, mentre stai andando a una seconda fase, la tua fase di codifica, giusto? Volete essere sicuri di avere l’aggancio. Vuoi assicurarti di avere un IDE sicuro, che sia mai realmente in tempo reale come gli sviluppatori che scrivono il codice hanno effettivamente catturato alcuni dei problemi in tempo reale. Ovviamente, non è un proiettile d’argento, giusto? Ma è un livello aggiuntivo e stiamo parlando di livelli aggiuntivi nei cicli di difesa in profondità. Ora, man mano che andiamo sempre più avanti nel processo, giusto? Una volta che ti sei impegnato nel codice, giusto? Vuoi essere sicuro di avere un processo: Chi è in grado di fornire una scansione statica di tutto il tuo codice per assicurarsi che controllino la dipendenza automatica, la catena di approvvigionamento, la vulnerabilità, ecc., insieme all’analisi della compensazione del software per creare una visualizzazione software dei materiali che mostrano che tipo di versione del software stai utilizzando? Quanti anni hanno?
Perché, sai, io non ti scherzo, ho appena letto una statistica una settimana o due fa – il 25% dei download di Apache Log4j è ancora fuori dalla versione precedente che contiene ancora una vulnerabilità. Mi sconcerta il fatto che sia ancora una stat, sai, ora che siamo quasi due anni. Non so, erano due anni o tre anni da quando la prima vulnerabilità zero-giorni Apache Log4j è stata annunciata all’inizio di dicembre? Era il 2021? Quindi, è davvero qualcosa che dobbiamo concentrarci su fare meglio e avere questo tipo di conversazione/analisi software in atto per assicurarci che tu sappia esattamente quale versione del software stai eseguendo.
È importante. Quindi, poi ci spostiamo verso i test, giusto? Si desidera assicurarsi di avere test interni, avete i test dinamici, sapete, implementati per garantire che ciò. Siamo in grado di testare l’applicazione in esecuzione e vedere se c’è qualche tipo di vulnerabilità che può essere sfruttata.
Lo sai che di solito si fa attraverso il fuzzing. Ora, cosa non viene mostrato qui in un ciclo DevSecOps tradizionale? Perche’ tutto questo sembra una pratica standard del settore, giusto? Mentre ci muoviamo fino in fondo per implementare, monitorare, rispondere. Storicamente, mettereste Web Application Firewall, bot manager, titoli API e tutte le loro soluzioni di protezione API per applicazioni Web nella fase di risposta e monitoraggio, giusto? Questo è quando monitorate il vostro traffico di produzione, assicuratevi che non vi sia alcun exploit verso.
Ma ciò che è importante considerare è spostare alcune delle protezioni API delle applicazioni Web in uso. Spostali anche a sinistra. Metteteli in questo caso, nella foto, è un passo avanti. Metteteli nella fase di test mentre state eseguendo il test dinamico di sicurezza delle applicazioni, giusto? Perché non li metti alla prova attraverso il tuo meccanismo di sicurezza di produzione? Quindi, sapete, in realtà, quanta vulnerabilità esiste tra il codice, quante di queste vulnerabilità possono essere mitigate, perché l’importante è che cerchiamo sempre di trovare modi per migliorare il ciclo di vita attuale delle app, rendendo effettivamente più veloce lo sviluppo. Una pratica generale quando si trova una vulnerabilità di sicurezza durante il test è che si ferma il treno. Torna indietro, vero? Correggi il codice e rilascialo di nuovo. Ripasserai di nuovo gli otto passi. Ma cosa succede se ti dicessi che forse c’è un modo per dirti: “Ehi, non fermiamo il treno?”
Continuiamo il treno. Rilasciamo questo facendo una sorta di test aggiuntivo con soluzioni di sicurezza davanti al passaggio quattro che vi permetterà di sapere con largo anticipo cosa applicare virtualmente in produzione in modo da non dover fermare il vostro treno. Continui a prendere il treno. Mantenete la vostra velocità.
Si rilascia il codice con la patch virtuale in atto per attenuare la vulnerabilità e poi si corregge nel ciclo successivo, si spera che si verifichi molto rapidamente. Questo è anche uno di questi modi, i modi innovativi che vogliamo educare e collaborare con i nostri clienti per cercare di migliorare il flusso di lavoro di sicurezza CICD esistente.
Michael Grimshaw: Mi piace, Richard. Mi piace che tu chiami il fatto di tirare, tirarlo a sinistra. Quindi solo al tuo punto è che se il tuo piano di gioco è, oh, mettiamo questo in produzione e poi ci preoccuperemo di esso. Avrete problemi e qualcosa che può mitigare che può coprire il vostro backside, sia attraverso il vostro processo di sviluppo, distribuzione e operazioni. Mi piace quello che hai chiamato. E un’analogia, e un’analogia simile, direi, essere come Chaos Monkey. Ecco il punto. Se hai Chaos Monkey che lavora in produzione, e l’unica volta che hai a che fare con Chaos Monkey è quando è in produzione, avrai una terribile esperienza di sviluppo e operativa.
È necessario pianificare, progettare e progettare questo progetto molto prima che arrivi in produzione. Altrimenti, sarai in miseria.
Quantificare le metriche per comprendere le implicazioni in termini di costi e il successo
Richard Yew: Sì, e Lauren, mi piace rispondere alle domande precedenti, come possiamo misurare il successo ora che guardiamo solo all’intero ciclo di vita di DevSecOps e come possiamo ottimizzarlo. Qual è la migliore pratica, giusto?
Molto velocemente. Quindi dobbiamo seguire il successo. Quindi, ovviamente, è necessario essere in grado di quantificare il successo. Giusto. Quindi, sai, ci sono alcune delle metriche che potrebbero aiutare se sei un leader della sicurezza e stai cercando di misurare il successo dei programmi di sicurezza delle applicazioni, una delle cose che puoi guardare, è anche cosa, quanta copertura delle applicazioni hai, giusto?
Ad esempio, oltre il 90/95% di tutte le vostre applicazioni o applicazioni presenti in Internet all’interno delle vostre organizzazioni è coperto dallo stesso processo? Avete lo stesso processo standardizzato che copre? Giusto. Che tutto, tra cui composizione software, analisi, SAS, test, test, test, sapete, come applicazioni web, protezioni API.
Avete predisposto questi elementi per tenere traccia della copertura? Con quale frequenza rilasciate e con quale frequenza dovete tornare indietro? In quale fase a causa della vulnerabilità di sicurezza rilevata e con quale frequenza è necessario eseguire il rollback nella fase di produzione rispetto alla frequenza con cui è necessario eseguire il rollback durante la fase di commit del codice in cui si esegue l’analisi statica, perché ovviamente si esegue il rollback delle produzioni.
Sarà molto più costoso che correggere il codice dopo un po’ di analisi statica del codice. Giusto. Le altre due statistiche lì, si vuole sicuramente misurare come, come Lauren ha accennato prima. Il tempo medio di rilevamento di ciò che chiamiamo MTTD è di 200 giorni. Quindi, credo che con questo processo con il processo giusto con il processo di spostamento a destra a sinistra, si possa ridurre drasticamente nel frattempo per rilevare, molto più breve. Quindi, cercate di iniziare a mettere insieme le metriche per rilevare quanto tempo ci vuole da un’intercettazione di vulnerabilità al rilevamento di un edificio all’interno delle vostre organizzazioni.
E anche implementare nel frattempo la risposta, giusto? MTTR nel frattempo per risolvere le risoluzioni, giusto? La media del settore è di 70 giorni, quindi sono 70 giorni dopo che la vulnerabilità è stata trovata, giusto? Sfruttato, l’organizzazione impiega in media 70 giorni per risolverlo. Ma con questo primo monitoraggio, quanto velocemente si può risolvere? Non appena si trova una versione vulnerabile dei log per J che utilizza il codice nell’analisi della composizione del software, con quale rapidità è possibile applicare una patch virtuale con un firewall o con quale rapidità è possibile aggiornare le librerie per utilizzare un software diverso, giusto? Quindi, misurando questo in un’organizzazione molto matura, ho parlato con alcune organizzazioni che hanno effettivamente quello di cui stiamo parlando quattro ore di tempo medio per risolvere il tempo per l’evento log4j.
Questo è estremamente impressionante. E questo parla della maturità dei loro processi DevSecOps. Quindi, ho visto tutti i tipi. E ho visto organizzazioni di clienti che hanno tipo settimane o anche mesi di tempo per risolvere problemi critici come log4j. Quindi, è molto importante tenere a mente quelle metriche mentre cerchi di migliorare il processo nel suo complesso.
Michael Grimshaw: E ci sono altri KPI che voglio inserire qui è che, come sul lato piattaforma, quando si tratta di infrastrutture o in molti casi, qualsiasi cosa ingegneria, costo è sempre stato un elemento importante qui. Ma negli ultimi anni con i tassi di interesse in aumento, sapete, il picco è fino al denaro VC e molto di questo si sta prosciugando, ma il nome del gioco e l’ambiente in aumento dei tassi di interesse sono molto redditizi.
E c’è un aspetto qui. Mi piace questo tecnico. Chiaramente, sai, direttore dell’ingegneria delle piattaforme. Mi piace il lato tecnico, ma soprattutto negli ultimi anni, una parte enorme di se lavori in piattaforma, come ho detto, infrastrutture e cose del genere, l’aspetto finanziario e nel chiarire e fornire feedback al tuo CFO, così come il tuo CTO è diventato imperativo.
E quindi il KPI è intorno a un costo e il fatturato è, questo è un altro, questo è un aspetto molto importante anche in questo caso. E voglio solo richiamare l’attenzione su alcune cose come questa, per esempio, sul lato delle entrate. Se ti siedi con una discussione sulla linea rossa, se hai un cliente che sta cercando di acquistare il tuo acquisto, ma il tuo prodotto, attraverserai una linea rossa di sicurezza perché la sicurezza è nella mente di tutti e i tuoi clienti vorranno assicurarsi che siano protetti.
Vorranno minimizzare il loro rischio qui. E se vieni da lui con la mentalità vecchia scuola. Oh, sì, sviluppiamo cose e poi, lasciamo fare, ci assicuriamo che l’infosec li analizzi e tutto il resto. Sono stato in un sacco di discussioni rosse e discussioni sui contratti, e questo semplicemente non vola più.
Il livello dei questionari e dei questionari del reparto rischi e dell’ufficio legale del cliente è passato a un livello di dettaglio completamente diverso negli ultimi cinque anni, per non parlare di 10 anni. Inoltre, la possibilità di disporre di una soluzione “shift-left” completamente integrata per avere applicazioni Web e protezione API, tutto questo. Quando parli con gli avvocati di altre persone, questo muove l’ago in grande modo. Cosa significa? Ciò significa che consente di concludere le trattative più velocemente. E una delle cose se non stai praticando Shift Left o stai solo pensando che è infosec come un add-on, ti incoraggio a tornare indietro e guardare i tuoi rapporti di chiusura e dove si sono guastati e guardare specificamente alle discussioni sulla linea rossa di sicurezza perché questi tipi di prodotti problema troppo spesso sono visti come un centro di costo. Non lo sono, possono sbloccare le entrate e possono farti risparmiare un’enorme quantità di denaro.
In precedenza nel podcast, abbiamo coperto molti dei risparmi sui costi per quanto riguarda i costi interni, ma ci sono entrate nelle implicazioni beta qui che penso sia importante richiamare perché è lì che ci sono così tanti occhi in questo mondo in aumento dei tassi di interesse.
Conclusione
Richard Yew: Questo è un punto eccellente. Sono contento che abbiamo un po’ di cappello scambiato, sai, come mettere i miei cappelli SDLC e si mette il vostro, il vostro cappello da lavoro. Questo è fantastico. Spero che tutte queste cose che abbiamo condiviso offrano un po’ di valore al nostro pubblico.
Lauren Bradley: Grazie mille a entrambi. Penso che sia una grande nota su cui finire. Abbiamo trattato l’importanza di cambiare marcia e di come introdurre in modo efficace le applicazioni Web e la protezione API nel ciclo di vita DevOps. E naturalmente, come misurare efficacemente il successo. Ci sono meno falsi positivi? Qual è la risoluzione temporale media? Quanto velocemente spedite il software? E state guadagnando più entrate?
Tutte queste metriche sono fondamentali per il successo di un’azienda. Quindi, apprezzo entrambi, Michael e Richard, per essere venuti con me oggi. È stato un vero piacere e grazie anche al nostro pubblico per essere stato presente su Beyond the Edge. Ci vediamo nel prossimo episodio.
