Home Blogs DevSecOps: Spostare a sinistra per evitare di spostare la roadmap dei prodotti a destra – Edgio
Applications

DevSecOps: Spostare a sinistra per evitare di spostare la roadmap dei prodotti a destra – Edgio

About The Author

Outline

Benvenuto nel quarto episodio di Beyond the Edge, un podcast dedicato all’esplorazione delle sfide dinamiche affrontate dalle moderne aziende digitali.

In questo episodio, la nostra conduttrice, Lauren Bradley, Global Campaign Manager, parla con Michael Grimshaw, direttore della Platform Engineering di Edgio, e Richard Yew, Senior Director of Product Management di Edgio Security Platform, riguardo al cambiamento a sinistra. Nello specifico, in che modo la cultura e la tecnologia cambiano man mano che le applicazioni Web e la protezione API diventano parte integrante e nativa del ciclo di vita DevOps.

"La sicurezza è come la farina per cuocere la torta, e quando la sicurezza è fatta bene, non si può vedere. L'intero punto della sicurezza è che quando è fatto bene, avrebbe dovuto essere inserito e non è visibile."

Un’introduzione al podcast Beyond the Edge di Edgio episodio 4: DevSecOps: Shift Left to avoid Shifting Your Product Roadmap Right condotto da Lauren Bradley, Global Campaign Manager di Edgio.

Lauren Bradley: Ciao, e benvenuto in Beyond the Edge, dove analizziamo i dettagli delle moderne aziende digitali. Sono Lauren Bradley, il tuo co-pilota per questo episodio, e oggi esploreremo l’argomento del cambiamento a sinistra, in particolare come la cultura e la tecnologia cambiano quando la protezione delle applicazioni web e delle API diventano parte integrante del ciclo di vita DevOps.

Cominciamo con una statistica scioccante del Ponemon Institute. Oggi, la maggior parte delle aziende impiega più di 200 giorni per rilevare persino una violazione. Se non stai rilevando una violazione abbastanza velocemente, ti costerà molto. IBM ha scoperto che il costo dei bug fissi rilevati durante la fase di test può essere 15 volte superiore a quello riscontrato durante la progettazione.

Quindi, per dirla in parole povere, più si aspetta di prendere un problema, più vi costerà. E, non stiamo parlando solo di soldi, rilavorazioni, tempo ed energia alla fine possono cambiare le roadmap dei prodotti. Quindi, in che modo potete spostarvi efficacemente a sinistra ed evitare di sprecare risorse preziose e bloccare i vostri progressi?

Oggi, insieme a noi, abbiamo Michael Grimshaw, direttore di Platform Engineering di Edgio, e Richard Yew, Senior Director of Product Management di Edgio Security Platform. Benvenuto, Michael e Richard. E’ bello averti su.

Michael Grimshaw: Grazie, Lauren. E’ bello essere qui. Grazie.

Lauren Bradley: Potete raccontarmi un po’ di voi stessi e dei vostri pensieri iniziali su questo argomento? Mike, inizieremo con te.

Michael Grimshaw: Assolutamente. Prima di tutto, vorrei iniziare ringraziando te, Lauren, per avere un tale interesse. In questo argomento molto importante e, e stai scavando e accelerando e le conversazioni che abbiamo avuto e stiamo avendo intorno a questo, incluso 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 davvero apprezzare l’interesse. Mi chiamo Michael Grimshaw. Sono il Direttore di Platform Engineering qui a Edgio. Per quelli di voi che non hanno familiarità con la piattaforma, o hanno una grande familiarità con la piattaforma in termini di settore, sta davvero pensando in termini di unificazione delle vostre applicazioni e infrastrutture in unità coerenti.

E, vengo alla piattaforma con un pesante background di sicurezza, e questa è un’area di cui sono abbastanza appassionato perché muove l’ago in modo così grande, per quanto riguarda la sicurezza, per quanto riguarda la redditività, e molte delle aree che sono così importanti per il nostro settore.

E posso andare in giro per DevSecOps, ma lasciate 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 di sviluppo del software e traducendolo nel business.

Ora, parlando di quello che faccio… Ovviamente, come ha detto Lauren, dirigo le nostre organizzazioni di gestione dei prodotti per la sicurezza presso Edgio. Quindi, la mia vita quotidiana implica lavorare con il team R&D, il team di progettazione per garantire che stiamo offrendo valore ai nostri clienti. E, sapete, tutto ciò che ovviamente includerebbe, come ottimizzare la nostra pratica di sviluppo, la nostra sicurezza, la pratica ci CD. per garantire che siamo effettivamente in grado di fornire prodotti sicuri.

Giusto. In questo modo, i nostri clienti ricevono valore, rispettano i tempi e i budget previsti e garantiscono ai nostri clienti un’esperienza eccellente. Quindi, il mio obiettivo in questo è quello di guardare davvero l’intero DevSecOps, 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: Al tuo punto, Richard, lascia che mi lasci solo rubare la palla lì se non ti dispiace.

E penso solo che uniamo quello che intendiamo con DevSecOps e spostiamo il turno a sinistra, giusto? C’era Gartner, ecco le cose per alcune persone che ascoltano questo DevSecOps, e i termini si spostano a sinistra, a destra, ecc. potrebbero sembrare relativamente nuovi. Questo non è nuovo, sai, non è come, oh, la cosa più recente più calda che ha colpito solo un anno fa.

No, è da un bel po’ che si fa la pasticceria nel settore. Gartner aveva un rapporto del 2017 sul ciclo di vita di DevSecOps. Era solo un’estensione del DevOps, la tendenza DevOps del settore, che si limitava a includere la sicurezza nell’infosec nel ciclo di feedback e nel ciclo di vita dello sviluppo del software.

E così, come ho detto, Gartner scriveva, scriveva 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. È, solo un’estensione di ciò su cui stiamo lavorando da anni. E in effetti, DevSecOps è che prende il modello simile di DevOps, in quanto si ha un lato di sviluppo e un lato operativo.

E al punto cruciale, sta crescendo in tutte le vostre esigenze di sicurezza il prima possibile, voglio dire, dall’inizio della progettazione, costruiamo l’intero processo fino a dove i vostri sviluppatori sulla nave a sinistra sono sul lato dello sviluppo, scusatemi, shift right è più sul lato dell’osservabilità delle operazioni. Oggi ci concentreremo sullo spostamento a sinistra, ma fondamentalmente sta preparando i test delle scansioni e della convalida, già all’estrema sinistra. E il più presto possibile nel ciclo di vita dello sviluppo nel vostro SDLC. Quindi, per esempio, una delle cose di cui parla, e ancora una volta, questo risale a più di sette anni fa, sono cose come 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 fornito è la creazione e la scansione di sicurezza negli IDE che i vostri sviluppatori utilizzano. È solo un esempio, e CE ne sono molti.

In modo che mentre stanno scrivendo il loro codice, ottengono un feedback immediato. Oh, ho appena lasciato la porta aperta per, sai, credential stuffing o sequel injection, e si presentano come un errore di sintassi, hanno un errore di sicurezza proprio qui 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ì.

Più economico, più veloce, più facile all’inizio. Richard, stavi per dire qualcosa.

Perché lo spostamento è così importante quando si tratta di costi?

Richard Yew: Oh, si’. Si’. Come penso che il costo sia in realtà molto importante da parlare, sai, beh, tutti conoscono molti costi operativi, sai, qualsiasi organizzazione, è come lo sviluppo, giusto? Il processo di ricerca e sviluppo.

Quindi, quando si tratta di costi, questo è il motivo per cui 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 colpire a casa il motivo per cui questo è così importante perché, sai, abbiamo i dati.

Si’. Questo, secondo la nostra ricerca, mostra che sai, se stai correggendo una vulnerabilità di sicurezza che è stata trovata dopo il rilascio del codice e le produzioni costano 15 volte più di quanto non sai quando si trova 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à della sicurezza.

Ecco perché dobbiamo attuare la difesa in profondità. Ma è molto importante che tu sappia, mentre guardi le otto fasi, sai, in generale, dei cicli del debito, dei cicli di vita da, sai, piano, codice, costruisci, prova, tutto il modo per apprezzare monitorare e operare. Giusto. Li guardi più a destra, sai, come quando trovi una vulnerabilità della sicurezza, più costosa sarà la sua, sai.

Per consentire alle organizzazioni di 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 sacco di codici alle produzioni piuttosto che dire, sai, come eseguire un’attività di sicurezza dinamica delle applicazioni nell’ambiente di staging per rilevarla prima di inviare il codice alla produzione, giusto?

Richard Yew: Potreste essere in grado di risolvere questi problemi o di implementare una sorta di applicazione di patch virtuali in anticipo prima di rilasciare una riduzione del codice per mitigarli. Ma, ancora una volta, è molto importante capire che la sicurezza deve essere introdotta fin dal primo passo del processo, anche prima di iniziare a scrivere il codice prima di inserire qualsiasi cosa nell’IDE e iniziare a pensare a modellare le minacce. Ehi, quale parte del progetto potrebbe essere potenzialmente suscettibile allo sfruttamento?

Implicazioni quotidiane per DevOps e i team di sicurezza

Lauren Bradley: Sì, e quelli sono davvero buoni punti, ragazzi. Dal punto di vista degli utenti, cosa può significare, al di fuori dei costi, in termini monetari, che cosa può significare per un DevOps o un team di sicurezza da sperimentare nella loro vita quotidiana se non stanno implementando questo direttamente dall’inizio?

Inoltre, vorrei parlare di come la implementiamo efficacemente nel ciclo di vita DevOps.

Michael Grimshaw: Ottima domanda. Ottima domanda. E, permettetemi di essere molto schietta nella mia risposta iniziale. Sono tutti nel settore, ogni CEO, CTO, CFO, tutti, ingegneri, utenti – ciò che tutti vogliamo è solo un proiettile magico che possiamo fare, ciò che facciamo quotidianamente.

E poi abbiamo un proiettile di sicurezza magico che basta girare l’interruttore e tutto il vostro lavoro viene improvvisamente reso sicuro. Questo è ciò che tutti vogliono, ma questa non è la realtà. Cioè, la gente CE lo chiede. Voglio chiedere loro, come va il tempo in terra fantasy? Ho sentito che è bello. Questo tipo di anno è, e se vi avvicinate alla vostra sicurezza, la vostra infosec, così come il vostro sviluppo, poiché si tratta solo di un’innovazione. Sai, “oh, comprerò alcuni strumenti che sto andando a perfezionare dopo che abbiamo tutto sviluppato, costruito e distribuito, e andrà avanti e rendere tutto sicuro”, stai acquistando un peso cartaceo molto costoso, ad essere onesto con te.

Ed è per questo che, sai, è stato menzionato, si tratta di persone, processi, e attrezzature. Ecco perché la coerenza di questo approccio è così importante. Sei tu, siamo anni lontani, decenni, se mai fosse possibile. Ad essere onesti, abbiamo imparato molte lezioni dall’idea di progettare qualcosa e mettere uno strumento di sicurezza e tu sei, sei bravo 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 a un certo punto della loro carriera si sono trovati in una situazione in cui una nuova funzionalità o un nuovo servizio o qualcosa del genere, o anche solo una patch e un aggiornamento sono stati distribuiti. Sembra tutto a posto. Sta andando tutto bene. E poi improvvisamente ricevete una chiamata da uno dei vostri clienti o infosec ricevete una chiamata da uno dei clienti. “Siamo appena stati impegnati”, o “abbiamo appena avuto un incidente di sicurezza”, o qualcosa del genere. E il motivo è perché, ok, l’hai distribuito, ma forse le scansioni non erano terminate, o non hai fatto scansioni, o non le hai messe a punto correttamente, e hai appena introdotto una vulnerabilità di sicurezza enorme.

Forse influisce su di te, ma, cosa più importante, influisce sui tuoi 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 parte. Ma si tratta anche di rimuovere la responsabilità per la tua azienda e quella dei tuoi clienti.

Incorporare la sicurezza in DevOps – è come cucinare una torta!

Richard Yew: Assolutamente. Sai, parlando di, sai, parlando di cuocerlo, 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 conosciuto in Edgio per essere il tipo di analogia.

Mi piace lanciare un mucchio di analogie in giro e, sai, ho sentito questo grande. Le analogie, credo, servirebbero come base solida per spingere per le giuste culture all’interno di qualsiasi organizzazione, come tutti sappiamo, in quanto addetti alla 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.

Per dire che le persone sono importanti per la sicurezza dell’azienda, giusto? Perché, sai, come leader della sicurezza, non è solo come, è come se le persone pensassero spesso alla sicurezza, come aggiungere ulteriori livelli di processo nel flusso di lavoro, ma sai, il modo giusto di pensare a questo è che come la sicurezza può accelerare il business?

In che modo la sicurezza può effettivamente generare maggiori entrate, perché questo è un buon modo per giustificare molte implementazioni di sicurezza aggiuntive che è necessario eseguire per garantire la sicurezza dell’organizzazione. Quindi, una delle analogie che ho sentito è stata grandiosa è che sai, la sicurezza non dovrebbe essere trattata come una ciliegina sulla torta, sai, come si fa a cuocere dalla torta e si mettono tutte le ciliegie come un ultimo passo, sai, questo è di solito ciò che le persone fanno quando non hanno una sicurezza, un flusso di lavoro ICD, e semplicemente implementano firewall e, sai, protezione API, qualunque sia l’ultima fase della fase di produzione. Quello che dovrebbe essere, la sicurezza, è come farina, sai, avrebbe dovuto essere qualcosa fin dall’inizio.

La sicurezza è come farina per te per cuocere la torta. E poi, quando la sicurezza è fatta bene, non puoi vederla. 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, sai, ho usato per aiutare a mostrare al business perché questo è importante è che avere un forte processo di sicurezza, culture della tecnologia di sicurezza, è come avere forti freni. In un’auto da corsa, sai perché ogni supercar là fuori ha dei freni grandi, davvero grandi, fantasiosi perché permette loro di affrontare le curve più velocemente.

Consente loro di frenare duramente. Permette loro di andare più veloce e di girare più duramente, giusto? Permette loro di vincere la gara. Quindi, avere freni forti è importante quanto avere un motore forte, giusto? Questo è il modo in cui dovremmo guardare alla sicurezza su un argomento filosofico. Sai, ovviamente, parliamo molto di alti livelli, giusto? Quindi, ovviamente vogliamo, sai, un po’ approfondire la questione. In sostanza, ok, tutto questo va bene, ma come faremo a implementarlo?

Michael Grimshaw: Sì. Penso che sia un grande richiamo alla frenata. La frenata potente offre il controllo. C’è la corrente o la strada che abbiamo davanti è piena di curve, tornanti, e tutto questo, e c’è, certo, ci sono subito dove lo si abbina e non si toccano i freni, ma per navigare tutto, che, quel freno, credo, amore, adoro entrambe queste analogie, Richard, perché quell’analogia di frenata ti dà il controllo, ti dà un controllo più preciso 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 è da questo tizio 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 all’azienda, soprattutto con coloro che sono nuovi a questo tipo di concetto.

Team problematici e isolati e roadmap dei cambi di marcia

Richard, parli di come, hai detto, sai, se, se, DevSecOps e’ finito, giusto? Non lo vedi. E ovviamente, una di queste evidenti visibilita’ e’ il costo. Sono anche squadre composte. Sembra anche che ci sia una disconnessione tra le squadre quando ci sono questi problemi che sorgono e perché non sono stati catturati prima?

Quali processi, quale comunicazione non stava avvenendo per risolverli in modo rapido o efficace? Quindi, la mia domanda per voi è, sapete, nella vostra esperienza, quale di… Sapete, c’è, c’è probabilmente una mancanza di trasparenza. C’è un processo decisionale lento, c’è il potenziale per sprecare risorse.

Quando avete team isolati, quali sono i problemi più problematici quando i team operano in silos secondo voi?

Richard Yew: Sì, prendo questo. Credo che una cosa che, sai, ho vissuto personalmente nella mia vita passata, giusto, è che sai, e questo è quando, sai, quando parliamo di prodotti come, sai, come una sorta di pianificazione, è importante che a volte si ha un team di sicurezza che non è in qualche modo incorporato all’interno della R&S, come all’interno dell’organizzazione CTO.

A volte in molte organizzazioni, osserviamo silos tra 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.

Alla fine hai scoperto che un’organizzazione deve essere conforme. A volte, gli esempi specifici sono che ci sono dei team che eseguono le scansioni una o due volte all’anno. Qual è il risultato di quelle scansioni? Beh, mi sarà detto, “Ehi Richard, dobbiamo rallentare il prossimo trimestre perché abbiamo appena trovato un centinaio di diversi bug di sicurezza grandi e piccoli, sai, tipo forse, tipo 20, come tra i primi 20 sono gravità uno e due e oltre, mentre il resto, sai, si tratta di, devi concentrarti sulla riparazione di quelle cose. “

E c’è uno SLA all’interno dell’organizzazione da risolvere, sapete, quello che è successo è che facendo questo, essenzialmente avete preso la mia roadmap e li avete buttati al prossimo trimestre. Quindi, non spostandoci a sinistra, non mettendo davvero a punto questo processo, semplicemente facendo queste cose solo sul lato destro, stiamo essenzialmente spingendo la nostra roadmap, che è, sapete, deliverable che generano entrate, potenzialmente che potrebbero aiutare ad espandere la nostra attività. Abbiamo intenzione di spostarlo potenzialmente a destra in modo che possiamo effettivamente, sai, 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, dover spostare gli elementi della roadmap di un trimestre. Quindi, tutte le pianificazioni di rilascio dei nuovi prodotti, funzionalità e funzionalità devono essere modificate, giusto? Perché non ti sei spostato a sinistra nella tua pratica.

E alcune di queste cose avrebbero potuto essere migliorate grazie a collaborazioni migliori, soprattutto tra i team di sicurezza delle applicazioni all’interno di un’organizzazione e ancora 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, partner commerciali HR integrati in diverse business unit.

Ora esiste un concetto di Application Security BP. Quindi, inizierai a sentire questi termini come APP SEC BP che, potrebbe diventare pratica dove hai persone che lavorano. Quasi come un manager semi-integrato del team di progettazione per garantire che fornisca le istruzioni, 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 un ID sicuro, implementando tutte le attività “black-box”, durante il processo per garantire che, sai, siamo in grado di catturare alcuni di questi problemi prima, sai, proprio nelle prime fasi 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 dove 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, okay, 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. So che dal lato della piattaforma, quando parlo con i miei fornitori, voglio sapere qual è la roadmap perché, ok, forse devo andare dai miei revisori e devo ottenere il controllo di compensazione fino a quando non rilasciate qualcosa sulla roadmap. Beh, se me l’hai appena detto, ok, quello che mi aspettavo di essere consegnato in un quarto saranno tre quarti. Inizierò a guardare altri fornitori. Perché? Perché ho degli obblighi nei confronti dei miei revisori che devo rispettare.

E mi piace anche, Richard, che tu abbia parlato dei 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 bel mezzo di un PCI, SOC, ISO, FedRAMP, uno qualsiasi di questi vari framework di conformità, e non hai davvero integrato, stai ancora operando 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 verso il lato ingegneristico che si spera di implementare tutto ciò che intendeva, e poi questo è solo per farlo implementare. E poi tutte le prove, le scansioni e tutto quello che dovete fornire agli altri, buona fortuna.

Se questo si traduce effettivamente attraverso, abbiamo tutti giocato, sai, quel vecchio gioco di voci della scuola elementare è un tipo di funzione simile in cui se hai team integrati che lavorano con gli auditor che sanno immediatamente come tradurre questo nella tecnologia specifica e hai la scansione e puoi girarlo immediatamente e metterlo nel tuo set di regole, esegui la scansione e convalida sia in tempo reale, sia quando incontri con i revisori. Hai tutte le tue prove tutte insieme proprio lì. E’ un cambiamento radicale. Vi consente di consegnare le cose più velocemente ai vostri clienti invece di come ha detto Richard, continuate subito a cambiare la vostra roadmap.

Lauren Bradley: Quindi, per essere più tangibili su questo, voglio dire, come possono i CISO e i leader AppSec quantificare le loro metriche per comprendere le implicazioni sui costi o anche solo il successo generale?

Come implementate il processo DevSecOps?

Richard Yew: Cosa, sai, è divertente perché parliamo molto del perché, sai cosa, ma andiamo, approfondiamo il come, perché lo so, questo è ciò per cui molti del nostro pubblico. Non siamo qui per darti dichiarazioni soffici e di alto livello. Quello che siamo qui per fornire, speriamo, è un po ‘di valore per quando si tratta esattamente di come implementarlo.

Quindi forse possiamo estrarre il grafico DevSecOps che abbiamo, e poi possiamo semplicemente passare attraverso come ottimizzare i passaggi. Va bene. Quindi, come potete vedere i test di sicurezza tradizionali, sapete, come se fossero eseguiti 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 molti test di sicurezza. Quindi, è dalla parte giusta. Quindi, ora che il nuovo concetto è, se passiamo alle prossime foto, giusto? È che è possibile trovare 100 diverse varietà di questo grafico. Tipo, quando oggi hai solo Google DevSecOps, come ha detto Mike prima, questo concetto è stato in circolazione, sai, per 7 anni, giusto? Sai che alcune organizzazioni potrebbero non chiamarlo quel ciclo. Alcune organizzazioni lo chiamano AppSec, giusto? Alcune organizzazioni le chiameranno pipeline di sicurezza. Quindi, questa è una rappresentazione approssimativa di ciò che rappresenta una pipeline di sicurezza. Giusto? Quindi, fin dall’inizio, hai la fase di pianificazione, giusto?

Si dispone dell’analisi delle minacce di modellazione delle minacce. Cerchi di assicurarti di aver cucinato tutta questa modellazione mentre stai progettando soluzioni. Quindi come, mentre codifichi, mentre stai andando a una seconda fase, la tua fase di codifica, giusto? Volete assicurarvi di avere l’agganciato. Vuoi assicurarti di avere un IDE sicuro, che è mai realmente in tempo reale mentre 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, mentre andiamo sempre più avanti nel processo, giusto? Una volta che ti sei impegnato nel codice, giusto? Si desidera assicurarsi di disporre di un processo, che sia in grado di fornire, uh, una scansione statica di tutto il codice per assicurarsi che verifichi la dipendenza automatica, la supply chain, la vulnerabilità, ecc. insieme all’analisi della compensazione del software per creare una vista software dei materiali che mostri che tipo di versione del software stai usando? Quanti anni hanno?

Perché, sai, non ti scherzo, ho appena letto una statistica una o due settimane fa – il 25% dei download di Apache Log4j è ancora fuori dalla versione precedente che contiene ancora una vulnerabilità. Mi sconcerta che è ancora una statistica, sai, ora che siamo quasi due anni. Non lo so, erano due o tre anni da quando la prima vulnerabilità zero-days Apache Log4j è stata annunciata all’inizio di dicembre? Era il 2021? Quindi, è davvero qualcosa che dobbiamo concentrarci sul fare meglio e avere questo tipo di conversazione/analisi software in atto per assicurarci di sapere esattamente quale versione del software stai eseguendo.

E’ importante. Quindi, passiamo ai test, giusto? Si desidera assicurarsi di avere test interni, avete i test dinamici, sapete, implementati per garantire che. Siamo in grado di testare l’applicazione in esecuzione e vedere se c’è un qualsiasi tipo di vulnerabilità che può essere sfruttata.

Sai che di solito si fa attraverso il fuzzing. Ora, cosa non viene mostrato qui in un ciclo DevSecOps tradizionale? Perché sembra una pratica standard del settore, giusto? Mentre ci muoviamo fino in fondo per implementare, monitorare, rispondere. In passato, si applicherebbe il Web Application Firewall, il bot manager, i titoli API e tutte le loro soluzioni di protezione API per le applicazioni web nella fase di risposta e monitoraggio, giusto? Questo è quando si monitora il traffico di produzione, si assicura che non ci sia alcun exploit verso.

Ma quello che è qualcosa da considerare è quello di spostare effettivamente alcune di queste protezioni API delle applicazioni Web che avete in atto. Spostali anche a sinistra. Metteteli su in questo caso, nella foto, è un passo avanti. Metteteli nella fase di test mentre state eseguendo il test dinamico della sicurezza delle applicazioni, giusto? Perché non li testate attraverso il vostro meccanismo di sicurezza di produzione? Quindi, sapete, in realtà quanto di una vulnerabilità esiste tra il codice, quante di queste vulnerabilità possono essere mitigate, perché l’importante è che cerchiamo sempre di trovare modi per migliorare questo ciclo di vita attuale delle app rendendo effettivamente più veloce lo sviluppo. Una pratica generale quando si rileva una vulnerabilità della sicurezza durante il test consiste nell’arrestare il treno. Torna indietro, vero? Se ripari il codice, li ririlasci. Ripetete di nuovo gli otto passi. Ma se ti dicessi che forse c’è un modo per te di dire: “Ehi, non fermiamo il treno?”

Continuiamo a tenere il treno in moto. Rilasciamolo avendo una sorta di test aggiuntivo con soluzioni di sicurezza di fronte al passaggio quattro che vi permetterà di sapere con largo anticipo cosa applicare virtualmente patch nella produzione in modo da non dover fermare il vostro treno. Continui a tenere il treno. Mantenete la vostra velocità.

Si rilascia il codice con la patch virtuale per mitigare la vulnerabilità e si corregge nel ciclo successivo, auspicabilmente, che si spera avvenga molto rapidamente. Questo è anche uno di questi modi, i modi innovativi che vogliamo, sapete, 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, tirare questo in turno a sinistra. Quindi solo al tuo punto è se il tuo piano di gioco è, oh, mettiamolo in produzione e poi ci preoccuperemo di esso. Avrete problemi e avrete 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, sarebbe come Chaos Monkey. Ecco il punto. Se hai Chaos Monkey che lavora nella produzione, e l’unica volta che hai a che fare con Chaos Monkey è quando è in produzione, avrai un’esperienza di sviluppo e operativa orribile.

È necessario pianificare, progettare e progettare per questo prima che arrivi in produzione. Altrimenti, sarai in miseria.

Quantificazione delle metriche per comprendere le implicazioni in termini di costi e il successo

Richard Yew: Sì, e Lauren, mi piace rispondere alle domande precedenti, come misuriamo il successo ora che guardiamo l’intero ciclo di vita DevSecOps e come possiamo ottimizzarlo. Qual è la BEST practice, giusto?

Molto velocemente. Quindi dobbiamo monitorare 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, quanto della copertura delle applicazioni hai, giusto?

Ad esempio, avete più del 90/95% di tutte le vostre applicazioni o applicazioni presenti su Internet nelle vostre organizzazioni che rientrano nello stesso processo? Avete lo stesso processo standardizzato di copertura? Giusto. Che tutto, compresa la composizione del software, l’analisi, SAS, il test, test, test, sapete, come applicazioni web, protezioni API.

Avete messo in atto questi elementi per tenere traccia della copertura? Con quale frequenza rilasciate e con quale frequenza dovete eseguire il rollback? In quale fase a causa della vulnerabilità di sicurezza individuata e della frequenza con cui è necessario eseguire il rollback nella fase di produzione rispetto alla frequenza con cui è necessario eseguire il rollback durante, fase di commit del codice in cui stai facendo l’analisi statica perché ovviamente il rollback delle produzioni.

Sarà molto più costoso che riparare il codice dopo un po ‘di analisi del codice statico. Giusto. Le altre due statistiche lì, sicuramente volete misurare come, come ha accennato Lauren 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 Right Shift Left, si possa ridurre drasticamente nel frattempo per rilevare, a molto più breve. Quindi, provate a mettere insieme le metriche per rilevare quanto tempo ci vuole dalla divulgazione di una vulnerabilità al rilevamento di quella creazione all’interno delle organizzazioni.

E anche implementare nel frattempo la risposta, giusto? MTTR intanto per risolvere il intanto alle risoluzioni, giusto? La media del settore è di 70 giorni, quindi sono 70 giorni dopo che la vulnerabilità è stata trovata, giusto? Sfruttato, un’organizzazione impiega ancora in media 70 giorni per risolverlo. Ma con questo inizio di tracciamento, quanto velocemente puoi risolvere? Non appena trovate una versione vulnerabile dei log per J che utilizza il vostro codice nell’analisi della composizione del software, quanto rapidamente potete applicarli tramite un firewall virtuale o aggiornare le vostre librerie per utilizzare un altro software, giusto? Quindi, misurando questo in un’organizzazione molto matura, ho parlato con alcune organizzazioni che in realtà hanno quello che stiamo parlando di quattro ore di tempo medio per risolvere il tempo per l’evento log4j.

E’ 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 settimane o addirittura mesi di tempo per risolvere problemi critici come log4j. Quindi, è molto importante tenere a mente queste 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 della piattaforma, quando si ha a che fare con le infrastrutture o in molti casi, qualsiasi cosa ingegneria, costo è sempre stato un elemento importante qui. Ma negli ultimi anni con l’aumento dei tassi di interesse, sapete, il picco è fino al denaro VC e molto di questo si sta esaurendo, ma il nome del gioco e l’aumento del tasso di interesse è un picchiaduro molto redditizio.

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 stai lavorando in piattaforma, come ho detto, infrastrutture e cose del genere, l’aspetto finanziario e nel chiarire e fornire feedback al tuo CFO, così come al tuo CTO, è diventato imperativo.

E quindi il KPI è intorno a un costo e il fatturato è, questo è un altro, questo è un aspetto molto importante anche qui. E voglio solo sottolineare alcune cose come questa, per esempio, sul lato delle entrate. Se sei seduto con una discussione sulla linea rossa, se hai un cliente che sta cercando di acquistare il tuo acquisto, ma il tuo prodotto, passerai attraverso 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 venite da lui con la mentalità della vecchia scuola. Oh, sì, sviluppiamo le cose e poi, lasciamo, ci assicuriamo che la nostra infosec le analizzi e tutto il resto. Sono stato in un sacco di discussioni di linea rossa e discussioni di contratto, e questo semplicemente non vola più.

Negli ultimi cinque anni, per non parlare di 10 anni, il livello dei questionari e dei questionari provenienti dal reparto rischi e dall’ufficio legale del cliente è stato ulteriormente approfondito. Inoltre, la possibilità di disporre di una soluzione shift-left completamente integrata per applicazioni Web e protezione API, tutto questo. Quando parli con gli avvocati di altre persone, questo muove l’ago in modo grande. Cosa significa? Ciò significa che consente di chiudere le trattative più velocemente. E una delle cose se non stai praticando shift left o stai solo pensando che sia infosec come add-on, ti Consiglio di tornare indietro e guardare i tuoi rapporti di chiusura e dove si sono disgregati e in particolare guardare le discussioni sulla linea rossa di sicurezza perché questi tipi di problemi di prodotti 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 gran parte dei risparmi sui costi per quanto riguarda i costi interni, ma ci sono entrate in implicazioni beta qui che penso sia importante sottolineare perché è lì che ci sono così tanti occhi in questo mondo dei tassi di interesse in aumento.

Conclusione

Richard Yew: Questo è un punto eccellente. Sono contento che abbiamo un po’ cambiato cappello, sai, come mettere i miei cappelli SDLC e si mette il vostro, il vostro cappello da lavoro. E’ magnifico. Spero che tutte queste cose che abbiamo condiviso forniscano un po’ di valore al nostro pubblico.

Lauren Bradley: Grazie mille a entrambi. Penso che questa sia una bella nota su cui finire. Abbiamo trattato l’importanza dello spostamento a sinistra e come integrare efficacemente 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 sua risoluzione temporale? Quanto velocemente spedite il software? E state guadagnando più entrate?

Tutte queste metriche sono vitali per il successo di un’azienda. Quindi, apprezzo entrambi voi, Michael e Richard, per essere venuti con me oggi. È stato un vero piacere e grazie anche al nostro pubblico per aver partecipato a Beyond the Edge. Ci vediamo nel prossimo episodio.