Riformulare la sicurezza come un vantaggio strategico

Clarke (00:05):
Merritt, grazie mille per essere qui con noi oggi.

Merritt (00:08):
Grazie a te per l'invito.

Clarke (00:09):
Ci racconti un po' del tuo background? Cosa ti ha portato in AWS e di cosa ti occupi nel tuo ruolo attuale?

Merritt (00:15):
Sì. Lavoro in AWS da quasi quattro anni ormai. Provenivo dal Governo degli Stati Uniti e mi occupavo di sicurezza per conto del popolo americano. Ho lavorato in tutti e tre i rami. Sono arrivata alla sicurezza perché sapevo che c'erano dei grossi problemi incombenti e non avevamo alcun modo efficace per affrontarli. Quindi mi sono laureata in giurisprudenza, principalmente perché sapevo che ci sarebbe stato utile. Ma avevo anche la sensazione che le tematiche di questo scenario erano più importanti del comprendere una particolare minaccia in un determinato momento o la conoscenza di un protagonista e così via. E di conseguenza, ho finito per lavorare in quelle che considero aree di sicurezza poco interessanti. Ovvero, tutto quello che è alla base dell'infrastruttura ma che conta molto dietro le quinte. Penso che sia questo che mi ha davvero spinto ad arrivare qui.

Clarke (01:08):
È una grande storia. Puoi dirmi qualcosa in più sull'ufficio del CISO e sul suo scopo in un quadro più ampio rispetto ad AWS?

Merritt (01:17):
Sì. Sono una responsabile dell'ufficio del CISO. Il CISO (Chief Information Security Officer) in AWS è molto simile a quello di qualsiasi altra azienda. Steve Schmidt, il mio capo, si occupa non solo della sicurezza interna, ovvero di come si protegge AWS, ma anche di come garantiamo la sicurezza di tutti i servizi che forniamo come azienda. E questo è un punto davvero interessante da considerare perché si pensa a come proteggere e consentire ai dipendenti di avere un attrito minimo ma al tempo stesso di lasciarli essere un team di sviluppo. E poi si cerca di fare in modo che i tuoi team di sviluppo facciano la cosa più sicura, nel modo più semplice. Quindi, è qui che il mio ruolo mi permette davvero di avere un po' di empatia e credibilità, penso a quando parlo con i clienti, perché passo circa metà del mio tempo cercando di migliorare la nostra sicurezza qui in AWS e l'altra metà parlando con i clienti. A volte si tratta di parlare in pubblico, ma più spesso si tratta di conversazioni da CISO a CISO, parlare con gruppi di sicurezza e capire come arrivare alla maturità aziendale. Molte volte la sicurezza è uno di quei fattori chiave che consentirà loro di andare avanti più velocemente e in modo più maturo. Immagino che l'altro lato della medaglia sia che spesso la sicurezza può essere percepita come un bloccante. E che non sia mai sufficiente. Non solo perché i team di sicurezza devono crescere e non dire più di no, ma anche perché di questi tempi, soprattutto nel cloud, nel momento in cui si inizia a sviluppare qualcosa, si mettono in discussione l'identità e le autorizzazioni e il modo in cui queste vengono costruite in relazione al resto dell'architettura e al resto di Internet. E quindi ci sono proprietà di sicurezza intrinseche per tutto ciò che si costruisce. E questo significa che dobbiamo considerare la sicurezza in tutte le nostre conversazioni e dobbiamo spiegare ai clienti come la implementiamo.

Clarke (03:23):
Ho capito. Quindi, nelle conversazioni con i clienti CISO, tra le altre responsabilità che hai, immagino che un CISO possa dire: "Adoro il prodotto X o Y, ma vorrei che le cose stessero diversamente". Questo rientra nello stack di sicurezza di cui sei anche responsabile. In che modo un cliente chiede, attraverso una conversazione del genere, di tornare ai team dei prodotti dei servizi di sicurezza per implementare effettivamente una funzionalità?

Merritt (03:51):
Come saprai, i team di assistenza costruiscono, implementano e distribuiscono continuamente nuove funzionalità. E quindi non è proprio un problema di stare al passo con ciò che hanno deciso o hanno potuto investire nell'offerta. È più una questione di come stiamo risolvendo il problema, se non lo stiamo risolvendo nel modo giusto e così via, quindi riprendo la conversazione e inizio a lavorarci su. Ma molto di quello che faccio è capire, uno, cosa sta veramente chiedendo il cliente e come aiutarlo a raggiungere lo step successivo. Quindi, mi chiedo "Come possiamo farlo?” Credo che molto del valore che i clienti si aspettano da una conversazione con me sia:: "Come fa il tuo team a ottenerlo?" Non credo che non porti a nulla, ma penso davvero che l'empatia sia un valore aggiunto. 

Clarke (04:51):
Ben detto. Quindi, quando i clienti chiedono "Come fa AWS a fare questa cosa?" Quali sono alcuni dei più comuni "Come da AWS a..." Dal punto di vista della sicurezza, che tipo di domande ricevi dai clienti?

Merritt (05:07):
Il lato dell'innovazione è di gran lunga quello più interessante da mostrare. "In che modo i tuoi team di sviluppo innovano e in che modo il tuo team di sicurezza si rapporta con i team di sviluppo senza si scontrarsi?" Penso che questo sia un aspetto davvero notevole di ciò che facciamo, perché di' quello che vuoi sul tipo di rapido ritmo di innovazione che perseguiamo sfacciatamente, questo a volte significa che rilasciamo i prodotti a una velocità troppo elevata o che la gente ha difficoltà a capire le cose nuove. Ma alla fine quello che facciamo è, per la natura di alcuni di questi meccanismi, come un team di piccole dimensioni (per intenderci, che possa essere sfamato con due pizze) che ha una risonanza di sicurezza, giusto? Quindi, con un team di piccole dimensioni, che è solo per connotare che sei isolato in qualche modo intenzionalmente, per prendere rapidamente una decisione aziendale, sotto quel team, hai delle decisioni aziendali in merito alla sicurezza. Quindi solo una piccola manciata di persone saprà come funzionano i componenti al riguardo. Questo è il modo in cui lavoriamo. Quello di cui stiamo davvero parlando è il modo in cui abbiamo integrato la sicurezza nei prodotti che rilasciamo. E quindi non si tratta tanto di relazionarsi con loro quanto di una squadra di sicurezza che ha il compito di intervenire per riformare questa struttura. Sono davvero loro che dicono: "Come hai trasformato la tua azienda in una che sprizza sicurezza come parte del prodotto che stai vendendo?"

Clarke (06:38):
Ha senso. Quindi, quando ho delle conversazioni con i clienti, una delle cose che tendono a sollevare, e immagino che anche tu ti trovi di fronte alla stessa domanda, è: "Capisco il valore di DevSecOps. Comprendo quanto è importante investire risorse nell'ingegneria e nella sicurezza operativa e in tutti gli altri elementi della sicurezza. Ma come posso davvero creare un'organizzazione di sicurezza di livello mondiale come fa AWS?"

Merritt (07:05):
Beh. Penso che questa domanda abbia molte forme, giusto? Potrebbe essere "Non so se abbiamo mai applicato il nostro piano di risposta agli incidenti" o "Non so se abbiamo un piano di risposta agli incidenti". E ancora, penso che molto di questo dipenda dai controlli che attraversano il ciclo di vita delle tue risorse. Stavo per dire infrastruttura, ma è qualcosa che costruisci attraverso quel processo, giusto? Dai tuoi controlli protettivi, investigativi e riparativi. E uno degli elementi qui, ovviamente, su cui torniamo sempre è l'automazione. Quindi, ad esempio, nel nostro team, il nostro team di sicurezza AWS, non chiudiamo mai il ticket di un problema finché non abbiamo eseguito uno script di correzione, se possibile. Quindi l'automazione resta solo una parola finché non viene implementata in modo osservabile. Ma alla fine, ciò di cui abbiamo bisogno sono solo dei modi per dimensionare le operazioni. E grazie a quei controlli protettivi, investigativi e riparativi, il nostro reparto di sorveglianza 24 ore su 24 è come una babysitter per tutte le automazioni. Quindi dall'abbracciare la prossima generazione di centri operativi di sicurezza deriva molta libertà. Non fraintendermi, lo so che può sembrare un faro nella notte, ma in diversi modi, da qualche parte si deve iniziare. Ci guadagnerai. E abbiamo costruito un team di sicurezza risolvendo sia grandi problemi che piccoli problemi. Iniziare da qualche parte, giusto? Assumi persone che amano l'automazione, assumi un team di sicurezza diversificato che la pensa in modo differente, che risolva problemi con codice diverso, con un'automazione diversa e poi arrivaci anche con il consenso della tua leadership. Si tratta di un aspetto estremamente importante per questo processo, in cui si parla dell'investimento che l'impresa, o l'entità, dovrei dire, sta facendo, perché il settore pubblico opera in modo analogo in termini di processo di sicurezza. E ancora, questo deve essere implementato in modi e comportamenti specifici. Quindi, quando la gente viene da me e mi dice: "Come faccio a creare un team di sicurezza di livello mondiale?" Oppure "Come faccio a costruire una cultura dell'innovazione?" È quello che fai ripetutamente. Ci sono cose a cui possiamo relazionarci e creare qualche aggancio. Ad esempio, in quel DevSecOps, integriamo in proporzione un ingegnere della sicurezza nei team, in questo momento è un ottavo, ma potrebbe essere... Va su e giù, in un certo senso valutiamo se è il numero giusto. Facciamo errori ogni volta che succede qualcosa che non sarebbe dovuto accadere o semplicemente non va esattamente secondo i piani. A tal proposito, i vicepresidenti devono essere presenti in quelle riunioni indette per stabilire la causa di un errore. Non mandiamo un giovane ingegnere a farsi carico del peso maggiore. Avere questo tipo di ecosistema di responsabilità, non per gli individui che ne rappresentano il peso maggiore ma per l'organizzazione, avere l'arco di apprendimento che cresce nel tempo è davvero il nostro obiettivo. Ed è qualcosa che penso non accada per caso. Devi integrare quei meccanismi.

Clarke (10:22):
E immagino che il trucco sia lo sviluppo di quel meccanismo che rafforza il comportamento che stai cercando.

Merritt (10:28):
Esatto. Quindi, ad esempio, se scegli di rendere molto aperte le autorizzazioni dei tuoi dipendenti, cosa che facciamo in Amazon secondo una determinata decisione aziendale, allora dovrai avere, o almeno decidere di avere una registrazione e un monitoraggio molto dettagliati su ciò che accade. E poi hai un calcolo con soglia e delle aggravanti che si verificano ciclicamente e questo significa che occorre investire nella leadership perché devono sapere che risponderanno al telefono per motivi di sicurezza. Il 100% dei dirigenti dirà di avere a cuore la sicurezza, ma in realtà sanno che dovranno faticare per ottenerla, che dovranno capire che verranno chiamati per questo, è importante. E significa anche che il team di sicurezza avrà una sorta di ruolo intrecciato nell'azienda stessa.

Clarke (11:26):
Ho capito. Prima lo hai menzionato nella tua risposta sugli investimenti, giusto? Molti dei nostri CISO dei clienti e dirigenti dei clienti vengono da noi e dicono: "Beh, dobbiamo fare determinati investimenti nelle nostre capacità". Dal punto di vista della sicurezza, nel corso degli anni AWS è stato molto chiaro sul concetto dei cinque punti fondamentali per la base di sicurezza minima, ovvero identità, controlli investigativi, sicurezza dell'infrastruttura, protezione dei dati e risposta agli incidenti. Pertanto quando un CISO del cliente dice "Ho un budget e uno staff limitati ma ho bisogno di tutti e cinque gli elementi. Da dove inizio con i miei investimenti, dov'è il miglior rapporto qualità-prezzo tra quei cinque fattori?"

Merritt (12:09):
Ricevo un discreto numero di CISO che dicono: "Inizio con un solo carico di lavoro o con cento?" Giusto. E penso che la risposta sia iniziare da qualche parte e renderlo significativo. Inizia con molti carichi di lavoro, ma non eseguirli nell'ombra. Eseguili come se fossero sotto un microscopio di sicurezza, perché credo che avrai le eredità di sicurezza che rappresentano effettivamente un elemento di differenziazione per la tua azienda o la tua entità dal punto di vista della piattaforma. Farò solo il backup, e sembrerà sciocco, ma ricordiamoci che cos'è il cloud. 20 anni fa, le persone eseguivano queste cinque fasi semplicemente controllando la presenza di server fasulli sotto le scrivanie delle persone. Non lo facciamo più, o almeno se sei nel cloud non lo fai. E uno dei motivi che sappiamo essere un'eredità di sicurezza è che AWS si assume la responsabilità di quei livelli inferiori dello stack. Sfruttare il cloud per un dimensionamento cloud della sicurezza è una delle urgenze che vedo che i clienti non sfruttano per niente. Se hanno un budget limitato, è un motivo in più per cui dovrebbero arrivare a questo stato in cui possono sfruttare questo dimensionamento. Se dovessi sceglierne una, direi che l'identità è la più difficile. Devo ancora parlare con un cliente che dice: "Adoro il mio provider di identità. E penso che insieme lavoriamo davvero bene."

Clarke (13:40):
Quindi, se sei a corto di soldi, suggerisci degli investimenti nelle identità?

Merritt (13:45):
Penso che se hai un budget limitato, dovresti parlare con l'azienda di quali sono i tuoi obiettivi e del motivo per cui la sicurezza è un fattore di differenziazione del business. E non sto parlando solo di sicurezza relativa a ciò che produci, ma di sicurezza come parte del tuo stesso prodotto. Quindi se sei un rivenditore, se sei una compagnia petrolifera e del gas, se fai parte di... qualunque cosa, settore automobilistico, farmaceutico, media e intrattenimento, fusioni e acquisizioni, tutto quello di cui le persone si preoccupano in questo periodo, come dovrebbero, è la sicurezza di come si fa impresa. Quindi non si tratta solo delle persone che forniscono prodotti per la sicurezza e non si tratta solo di: "Oh, ti stai prendendo cura dei nostri dati internamente nei tuoi ruoli HR?" Si tratta di come offri la sicurezza come parte integrante del tuo prodotto e non ci sono dubbi su questo. Si tratta del modo in cui costruisci la tua impresa reale e degli obiettivi che stai perseguendo. E al punto in cui ti trovi, il budget che devi rispettare deve tenerne conto. E non credo che dovremmo più considerare la sicurezza un centro di costo. Sono stanca di tutto questo perché, in realtà, è una fonte di opportunità e una grande risorsa per il business e nessuno vuole intraprendere alcuna azione né interagire con l'azienda o con un governo se non si è certi dei risultati. Se non ci credi, è destinato al fallimento. E so che c'è un obiettivo in movimento perché è un processo e ci stiamo lavorando, ma c'è bisogno di impegnarsi con la nostra parte migliore.

Clarke (15:24):
Quindi, su quella linea di sicurezza, essendo un fattore abilitante del business, come fa un CISO e un'organizzazione che vede l'organizzazione del CISO come un centro di costo, come fa quel CISO a resistere o trasmettere quel messaggio al consiglio di amministrazione o ad altre persone che prendono decisioni per la propria organizzazione?

Merritt (15:42):
Consideriamo un paio di elementi. Uno è semplicemente la trasformazione generale che avviene nelle aziende quando scelgono di crescere. In realtà penso che le aziende in generale siano troppo ossessionate dal costo di un trasloco senza esaminare quanto costerebbe invece rimanere dove sono. A questo punto, dovresti tenere in considerazione i costi se rimani dove ti trovi e cosa stai pagando per non spostarti e per non fare cose che invece potrebbero essere vantaggiose. Francamente, capisco che ci vuole della sfrontatezza e parecchia energia per arrivarci, ma un approccio del genere inizierà a produrre dei vantaggi quasi immediatamente. E diventerà anche uno dei modi in cui la tua organizzazione può davvero crescere come impresa. Penso che alla fine tutto ciò che ritarda questo processo sia solo una perdita di tempo. E allo stesso modo, per rispondere alla tua domanda, penso che le persone che percepiscono tutto questo come un centro di costo facciano parte del passato. 

Clarke (16:53):
Beh. Penso che tu abbia spiegato perfettamente come il non fare qualcosa sia ugualmente rischioso rispetto ad altri rischi che le aziende stanno prendendo in considerazione.

Merritt (17:01):
Non direi ugualmente, direi spesso più costoso. E quando parli con il consiglio di amministrazione, questa è una delle cose a cui pensare. Quando le persone parlano di parametri di sicurezza, spesso, trovo che li abbiano gamificati. Dicono: "Abbiamo detto che la scorsa settimana abbiamo visto 100 persone bussare alla porta e questa settimana sono solo 70". Ed è come bussare alla porta né qui né là. Ovviamente questi numeri sono fittizi. Me li sono inventati. Ma il punto è che i tuoi parametri di sicurezza dovrebbero fornire un vero arco del miglioramento nel tempo. E se non lo sono, allora sono i parametri sbagliati. Perché con chi stai davvero giocando? È il tuo momento di gettarti nella mischia.

Clarke (17:50):
Il ransomware è un argomento importante in questi giorni ed è una grande preoccupazione per i clienti. So che hai una certa esperienza in questo settore. Quali sono i consigli che puoi dare alle organizzazioni di sicurezza dei clienti sulle cose che devono fare per prepararsi a un evento ransomware?

Merritt (18:07):
Beh. Effettivamente se ne parla molto ultimamente anche se il ransomware non è affatto un concetto nuovo. Risale almeno al 1989. C'è stata una conferenza sulla salute in cui un utente malintenzionato stava distribuendo unità disco etichettate con "aids" perché si trattava di una conferenza sanitaria. E così è diventato noto come "ransomware aids", perché quando lo inserivi nell'unità disco, crittografava i file e chiedeva di inviare un assegno di 89 dollari a una casella postale a Panama. Quindi immagino che il punto sia che in teoria il ransomware non è una novità ma nella pratica lo è a causa dell'ascesa delle criptovalute e la possibilità per le persone di monetizzare il fatto che sono riusciti ad entrare nella tua rete.

Clarke (18:58):
E il ransomware è un servizio, no?

Merritt (19:01):
Sì. E la mercificazione di esso è certamente un fattore importante. Inoltre, i regimi di privacy dei dati hanno reso davvero costoso la denuncia delle aziende che hanno subito una violazione. Esiste una forma di ransomware in cui si bloccano i tuoi dati e c'è una forma in cui viene eseguita la funzione xFill su di essi. E anche se disponi di backup, minaccia di rivelare di aver ottenuto l'accesso. E questo di per sé potrebbe già essere classificata come una violazione, soprattutto se hai a che fare con dati regolamentati, come tutti noi. Quindi penso che ciò che sta accadendo sia rilevante. Per rispondere alla tua domanda, credo che non esista una soluzione unica e definitiva per il ransomware. Il ransomware richiede che tutto sia in ordine. Tutto, a cominciare dal ridurre al minimo la probabilità che le persone entrino sulla tua rete, per passare a identità e patch, privilegi minimi e segmentazione fino ad avere backup immutabili. Quindi cose come il backup AWS o il cloud e le porte, che ti consentono di avere un nuovo punto di backup nel tempo e infine la capacità di ripristino del backup. 

Clarke (20:23):
Quindi, in linea con una sorta di temi caldi, un altro argomento importante per i clienti è il concetto di zero trust. Quindi cosa significa per te zero trust e come lo articoli con i clienti? E in che modo AWS può aiutare i clienti a ottenere lo zero trust se, in effetti, è qualcosa che devono fare?

Merritt (20:42):
Certo. Penso che zero trust possa essere un'utile lente concettuale con cui considerare i tuoi controlli di sicurezza. Giusto. Penso... Per prima cosa, se chiediamo a qualsiasi persona cosa significa zero trust otterremo una definizione diversa. Per me zero trust connota non l'idea che questa tazza da caffè non sia connessa a Internet, ma l'idea che dovresti ridurre, possibilmente fino a zero, il livello di fiducia che dovremmo dare a un utente della rete in base alla sua posizione nella rete. Quindi, fondamentalmente, che sia un software o una persona, dovremmo ridurre la nostra dipendenza da questa idea di perimetro tradizionale. Ma ovviamente "il perimetro è morto, lunga vita al perimetro", no? E penso che nel cloud e in AWS, il nostro approccio non sia quello di fare di questa una scelta binaria tra i tradizionali controlli incentrati sul perimetro come una VPN o un VPC e i controlli a grana fine incentrati sull'identità che operano all'interno come i gruppi di sicurezza, Naples e così via, piuttosto dobbiamo farli funzionare effettivamente insieme, di fatto farli aumentano ed essere consapevoli l'uno dell'altro. Un esempio potrebbe essere una policy dell'endpoint VPC, in cui sono presenti sia il perimetro che le autorizzazioni a grana fine. Questi due fattori sono consapevoli di potenziarsi a vicenda e possono essere pensati attraverso alcuni dei nostri strumenti inerenti al cloud perché stiamo costruendo un'infrastruttura come codice. Allo stesso modo, possiamo pensare alla sicurezza come codice. Quindi qualcosa come un analizzatore degli accessi o un ispettore, ad esempio può garantire la raggiungibilità della rete senza inviare alcun pacchetto su di essa. Quindi l'idea è che bisognerebbe accoppiare questo tipo di scelta di difesa in profondità, immagino, ma suona un po' vecchio stile. È un po' come "mettere la serratura alla porta e alla finestra". Ma porta e finestre hanno scopi differenti. E in effetti, fanno parte della stessa logica che utilizziamo quando analizziamo la sicurezza.

Clarke (22:57):
Merritt, grazie per aver passato del tempo con noi oggi. Qualche pensiero di chiusura?

Merritt (22:59):
Beh, penso che spesso la gente viene da me con quelle che pensano siano domande CISO profonde e tecniche. Ma in realtà quello che stanno chiedendo è: "Come posso convincere la mia organizzazione ad avere lo slancio e i mezzi per apportare un cambiamento?" E penso che ciò dipenda dall'investimento, sia letterale che metaforico, che un'entità fa nel rendere la sicurezza un'entità di prima classe. Quindi quando diciamo che la sicurezza è processo zero, o qualunque altro aforisma usiamo, non intendiamo farlo diventare un motto. Intendiamo che venga integrato nella cultura di tutto ciò che facciamo. Uno dei modi che usiamo è fare in modo che Steve Schmidt riporti direttamente al CEO e che la sicurezza non sia mai surclassata o soppressa da altri interessi commerciali. Per le persone che sperano di emulare alcune delle priorità che siamo stati in grado di mostrare, mi sento di dire che l'unico modo per farlo è farlo. E per farlo, bisogna iniziare. E il modo per iniziare è allineare la tua attività a questi obiettivi. Uno dei modi per arrivarci o per consentire alla tua organizzazione di avvicinarsi, è costruire quel team di livello mondiale. Credo che sia un tale luogo comune in questo momento che il talento è difficile da trovare; mi piacerebbe assumere persone che la pensano in modo diverso, che hanno un aspetto diverso e codificano in modo diverso perché è la cosa più giusta per il settore e per l'intero ecosistema. La sicurezza ha molti punti di contatto sulle comunità vulnerabili, sui modi in cui interagiamo con la tecnologia, sui modi in cui risolviamo i problemi e rafforziamo aziende ed entità. Se non lo facciamo qui, allora dove? E quindi direi che questo è un invito all'azione per tutti noi, per rendere il posto di lavoro inclusivo e rendere più forti le varie entità.

Clarke (25:02):
Merritt. Grazie mille per le tue intuizioni e per essere stata con noi oggi.