Clarke Rodgers:
È davvero interessante. Hai guidato il programma di sicurezza in AWS, quindi hai una profonda conoscenza di AWS, delle sue vulnerabilità, delle minacce e del suo livello di rischio. Avanzando al ruolo di CSO, ora puoi esplorare le realtà di amazon.com e di altre entità interne come Whole Foods, Prime Video, MGM e Twitch, tra le altre.
Come hai fatto a familiarizzare con il profilo di sicurezza e la propensione al rischio di ciascuna di queste diverse entità e poi come hai integrato queste informazioni? In che modo hai determinato che il profilo di rischio appropriato per una divisione, come Whole Foods o AWS, fosse adatto anche per le altre? Come hai sincronizzato tutti questi elementi?
Steve Schmidt:
Beh, prima di tutto, una delle cose che adoro del mio lavoro è la diversità delle attività che gestiamo. Spesso le persone mi dicono che è insolito per qualcuno nel settore della sicurezza rimanere nello stesso ruolo per sedici anni. Perché? È proprio la varietà del lavoro in questa azienda che mi spinge a continuare. C'è un'opportunità costante di apprendimento, è davvero entusiasmante.
Non sono più giovanissimo e la gente mi chiede spesso quanto tempo ancora intendo lavorare, se ho intenzioni di andare in pensione. E io rispondo che mi sto divertendo troppo per smettere. È davvero stimolante. E questo perché si passa dalla gestione del più grande fornitore di servizi cloud al mondo, all'installazione di satelliti nello spazio, fino alla gestione di catene di supermercati; la diversità di queste sfide è notevole dal punto di vista aziendale, ma offre anche l'interessante opportunità di sfruttare le dimensioni dell'azienda per ridurre i costi di gestione.
Considerando che le operazioni di sicurezza non sono economiche, la possibilità di scalare su una realtà vasta come Amazon permette di abbassare i costi unitari.
Clarke Rodgers:
Sì, certo.
Steve Schmidt:
Quindi ogni azienda trae vantaggio dalle dimensioni delle altre aziende. Quindi, trovare modi per permettere a un negozio di alimentari di beneficiare delle stesse misure di sicurezza di un'azienda che gestisce satelliti è fattibile in molti ambiti, come nella gestione delle vulnerabilità.Il processo di installazione di patch su un sistema informatico, in fondo, non cambia sostanzialmente tra la costruzione di satelliti e la gestione di un supermercato.
Questo ci permette di operare a un livello che una singola azienda non potrebbe permettersi e di elevare gli standard per tutti. Il mio lavoro è anche questo: garantire che ci sia uno standard uniforme in tutta l'azienda e a prescindere che si tratti di gestione delle vulnerabilità, di risposta agli incidenti, o di qualunque altro aspetto tipico di un'organizzazione di sicurezza.
Quindi è importante individuare quali elementi specifici devono essere implementati per le singole aziende considerando le esigenze individuali. In questo modo, evitiamo di applicare una soluzione universale, che altrimenti farebbe lievitare i costi. Ad esempio, in un'azienda alimentare, la perdita di un'unità può avere un impatto economico relativamente limitato, mentre la perdita di un satellite rappresenta l'esatto opposto.
Clarke Rodgers:
Sì, certo.
Steve Schmidt:
Quindi dobbiamo adattare la situazione di sicurezza per i singoli componenti.
Clarke Rodgers:
In che modo... Mi spiego meglio. I responsabili della sicurezza delle informazioni supervisionano i programmi di sicurezza per ciascuna di queste aziende affiliate. Come vi assicurate che siano effettivamente responsabili della gestione delle loro attività di sicurezza?
Steve Schmidt:
Una delle strategie su cui Amazon pone grande enfasi in tutta l'organizzazione è il concetto di "proprietario a thread singolo". Ciò significa avere una persona il cui compito è concentrarsi esclusivamente su un singolo aspetto di un'area. Per quanto riguarda la sicurezza, è per questo che abbiamo un CISO dedicato per ogni singola divisione. Il motivo è duplice:
innanzitutto, desideriamo che ci sia qualcuno che si occupi esclusivamente di sicurezza ogni giorno, che sia Amy Herzog a occuparsi dei dispositivi e dello spazio Kuiper, o Chris Betz per AWS. Allo stesso tempo, impieghiamo metriche comuni per tutte queste divisioni. Ad esempio, conduco una revisione aziendale mensile sulla gestione delle vulnerabilità che copre l'intera azienda e utilizza gli stessi dati, metodologie e formati di presentazione.
Questo ci permette di avere una visione uniforme che è coerente per ogni divisione. In questo modo possiamo realizzare due obiettivi principali. Il primo è garantire che soddisfiamo gli standard di sicurezza richiesti e il secondo è assicurare una visibilità completa in ogni angolo dell'azienda. Spesso, quando emergono problemi, le persone tendono a minimizzare, pensando che non siano gravi o che riguardino solo una piccola parte dell'operato.
È in questi frangenti che si verificano le vulnerabilità. Mantenendo una supervisione generale di alto livello su tutto, ci assicuriamo di adottare le misure necessarie in ogni parte dell'azienda.
Clarke Rodgers:
E poi ci sono i sistemi centralizzati sotto l'ombrello della sicurezza di Amazon, o AMSEC, di cui tutti possono beneficiare.
Steve Schmidt:
Quindi, ci sono molti aspetti che sono fondamentalmente identici in tutte le nostre divisioni. Il modo in cui raccogliamo determinati tipi di dati, come li analizziamo o li riportiamo, è comune. Invece di costringere ogni singola azienda a ripetere le stesse operazioni, abbiamo deciso di centralizzare questi processi. Questo approccio ci permette di risparmiare risorse come il tempo degli sviluppatori.
Pensando alla gestione su larga scala, torniamo all'esempio della gestione delle vulnerabilità: per gestire un sistema di raccolta dati efficace, hai bisogno di ingegneri disponibili. Se hai mai gestito un team di guardia, saprai che per avere una copertura reperibile continua, considerando ferie e altri impegni, hai bisogno di circa sette persone se vuoi davvero organizzarlo in modo efficace.
Clarke Rodgers:
Vogliamo che le persone possano andare in vacanza.
Steve Schmidt:
Esatto. Quindi, centralizzando la gestione per un gruppo diversificato di aziende da un unico luogo, riusciamo a operare più efficacemente. Grazie alla centralizzazione delle risorse otteniamo strumenti di qualità superiore a un costo inferiore.
Clarke Rodgers:
Quali metodi hai adottato o creato per comunicare al consiglio di amministrazione di Amazon lo stato della sicurezza nelle varie divisioni aziendali?
Steve Schmidt:
Il consiglio di amministrazione di Amazon è davvero interessante per vari motivi. Innanzitutto, ci sono pochi consigli di amministrazione che vantano un acume tecnico comparabile a quello del consiglio di Amazon. Inoltre, Amazon ha deciso diversi anni fa di creare un sottocomitato per la sicurezza. A differenza di molte altre realtà dove la sicurezza potrebbe riferire al comitato di revisione, ad esempio, Amazon ha un gruppo dedicato di persone il cui unico compito è occuparsi di sicurezza all'interno del consiglio di amministrazione.
Questo è estremamente vantaggioso, ma comporta anche frequenti controlli e così abbiamo dovuto sviluppare un meccanismo di reporting che si evolve nel tempo per due motivi principali. Il primo è che miglioriamo continuamente nel nostro modo di creare report. Il secondo motivo è che il consiglio diventa sempre più informato nel tempo, ponendo domande mirate con il desiderio di conoscere dettagli più specifici su aspetti particolari del settore. Riteniamo essenziale riferire specificamente su particolari componenti dell'azienda ogni volta che ci rivolgiamo a loro. Domandiamo: stiamo rispettando i nostri standard di sicurezza in determinate aree?
Inoltre, i membri del consiglio hanno temi di particolare interesse; vogliono saperne di più su determinati ambiti dell'azienda o su nuove iniziative che considerano particolarmente rischiose, ecc. Ciò ci consente di mantenere un componente di reporting costante e al tempo stesso flessibile, adattandola in base agli interessi specifici dei membri del consiglio.
Aggiungiamo anche una sezione che chiamiamo “attualità” dove prendiamo eventi di rilievo che sono stati trattati nei media, li analizziamo e traiamo lezioni o punti salienti specifici per noi, e li presentiamo al consiglio come informazione aggiuntiva alla fine di ogni sessione. Questo include incidenti rilevanti nel settore, spiegando perché non ci hanno colpito
e quali investimenti ci hanno protetto. Credo che questo approccio apporti un enorme valore al consiglio. In primo luogo, permette di comprendere che ci troviamo in una posizione solida e, in secondo luogo, aiuta anche nelle decisioni di investimento future. Ad esempio, quando evidenziamo come il nostro investimento precoce (dieci anni fa) nell'autenticazione a più fattori ci abbia protetti da minacce che hanno colpito altre grandi aziende, il consiglio può apprezzare il valore di tali investimenti e considerare quali altri investimenti pianificare oggi che potrebbero proteggerci in futuro.
Clarke Rodgers:
Molti dei nostri clienti CISO prestano molta attenzione al consiglio di amministrazione. Alcuni di loro hanno meno tempo a disposizione di altri per interazioni dirette. E come hai già sottolineato, il nostro consiglio è davvero unico proprio per la sua competenza in materia di sicurezza. Che suggerimenti daresti ai tuoi colleghi CISO o CSO per comunicare in modo efficace con i consigli di amministrazione, trasmettere con chiarezza i messaggi chiave, adottare un linguaggio in linea con quello dei dirigenti, ecc.?
Steve Schmidt:
La prima cosa che ho sentito spesso dai membri del consiglio, e che apprezzano particolarmente nel nostro approccio, è l'attenzione che mettiamo nell'evitare il gergo tecnico. Molte persone nei ruoli di CISO hanno un background tecnico e tendono a voler riportare le informazioni nei termini in cui le pensano...
Clarke Rodgers:
Nei dettagli, nei bit e nei byte.
Steve Schmidt:
Esattamente, rispecchiano il modo in cui loro concepiscono e analizzano la situazione. Ma dobbiamo ricordare che, in questo contesto, il consiglio di amministrazione è il nostro “cliente”. Quindi dobbiamo adattare la comunicazione alle loro esigenze, non alle nostre, e trovare modi per spiegare i concetti in un contesto che sia rilevante e comprensibile per quel consiglio specifico.
Quindi, il primo punto fondamentale è adottare un meccanismo di reporting coerente, anziché modificarlo di volta in volta, perché la coerenza rende più semplice l'interpretazione e più difficile distorcerne il significato. Il secondo è individuare le due o tre metriche davvero essenziali da comunicare ogni volta,
evitando di sovraccaricare il consiglio con troppi dati. Per esempio, noi riferiamo sistematicamente sulla gestione delle vulnerabilità, che consideriamo il controllo di sicurezza operativo più critico. Infine, è utile distinguere chiaramente tra le metriche chiave e altri elementi di interesse aggiuntivi, che possono aiutare il consiglio a valutare dove investire: questa separazione intenzionale tra le componenti del reporting rende il messaggio più efficace e strategico.
Clarke Rodgers:
E se investiamo qui, riduciamo il rischio di qua?
Steve Schmidt:
Esatto, si tratta di bilanciare la riduzione dei rischi attuali con quella dei rischi futuri, e quest'ultima è spesso la sfida più complessa per chi lavora nella sicurezza, perché non abbiamo prove concrete a cui fare riferimento. Spesso ci viene chiesto: È davvero urgente?
Dobbiamo intervenire subito? È necessario un intervento così in grande? Possiamo farlo in modo più contenuto? Sono domande legittime, e proprio per questo è fondamentale costruire nel tempo una base solida di consapevolezza all'interno del consiglio. Dobbiamo essere in grado di portare esempi reali di minacce che, pur non essendo identiche, sono simili a quelle che potremmo affrontare, spiegando perché pensiamo che ci riguarderanno in un determinato arco di tempo. Solo così possiamo giustificare l'esigenza di intervenire subito o pianificare azioni nei prossimi due o tre anni.
Clarke Rodgers:
Ok ho capito. In Amazon siamo noti per la nostra capacità di innovare, lavoro a ritroso, ascoltare i nostri clienti, ecc. Come leader della sicurezza, hai spesso molte opzioni a disposizione (specialmente se i CISO riportano direttamente a te) e una delle decisioni più importanti riguarda la scelta tra acquistare soluzioni già pronte o sviluppare strumenti internamente. Questa decisione, spesso, dipende dalla capacità di scalare:
molte soluzioni commerciali non sono progettate per operare alla scala di Amazon, e questo può rendere necessario sviluppare soluzioni su misura. Nell'ultimo anno abbiamo condiviso pubblicamente esempi di strumenti sviluppati internamente, come Madpot, Mithra e Sonaris. Come CSO, come giustifichi l'investimento in termini di risorse ingegneristiche per sviluppare strumenti di questo tipo e altri che non sono stati resi pubblici? Come stabilisci che vale davvero la pena investire su una soluzione proprietaria? E soprattutto, come dimostri il valore concreto che l'azienda potrà ottenere da questo investimento?
Steve Schmidt:
Certo. Partiamo con una distinzione fondamentale tra strumenti acquistati e strumenti sviluppati internamente. Questo è un punto di partenza cruciale. In generale, tendiamo ad acquistare soluzioni quando si tratta di componenti standardizzati. Per esempio, per il rilevamento e la risposta sugli endpoint (EDR), ci affidiamo a soluzioni commerciali già esistenti. Perché? Perché i laptop Mac, Windows o Linux che utilizziamo sono gli stessi utilizzati da molte altre aziende.
Anche se il software può variare, non è un elemento che realmente ci differenzia. Al contrario, investiamo nello sviluppo interno quando possiamo costruire qualcosa che nessun altro è in grado di offrire. Prendiamo Madpot, ad esempio: è un sistema progettato per operare su una scala che solo realtà come la nostra possono raggiungere. È qui che decidiamo di concentrare i nostri sforzi e risorse.
Il processo con cui arriviamo a questi investimenti segue un approccio simile a quello di altri ambiti: si parte con un prototipo, si testa, si osserva cosa funziona e cosa no. È normale non azzeccare tutto al primo tentativo, quindi si corregge, si adatta, si evolve, ecc. Madpot, ad esempio, è oggi un progetto di grande successo, ma non è nato da un giorno all'altro. Ha richiesto anni di sviluppo, ed è iniziato con l'iniziativa di un singolo ingegnere curioso, che ha avuto un'intuizione e ha deciso di esplorare un'idea promettente.
Da lì si è evoluto in un motore che ci consente di raccogliere, elaborare e sfruttare in tempo reale dati di intelligence sulle minacce, da cui traggono beneficio anche i nostri clienti attraverso gli strumenti di sicurezza che utilizziamo. E questo è un punto essenziale, perché per esempio molti clienti dicono di voler un “feed grezzo” di intelligence sulle minacce,
e magari poi cambiano idea. Ma in realtà ciò di cui hanno davvero bisogno sono dati pertinenti, filtrati e contestualizzati per il loro ambiente specifico. Il resto è solo rumore e con la mole di informazioni in circolazione oggi, è inefficiente e poco utile gestirlo senza infrastrutture adatte.
Per questo motivo, molti dei nostri clienti hanno scoperto di apprezzare moltissimo l'idea di utilizzare l'intelligence sulle minacce come parte integrante di un servizio gestito. Questo consente loro di non dover perdere tempo a setacciare enormi quantità di dati o a gestire informazioni prive di contesto, perché quel contesto non è stato applicato trasversalmente su più clienti.
Infine, il contesto è fondamentale. Ed è proprio in questo contesto che la nostra visibilità centralizzata rappresenta un vero punto di forza, rendendo evidente il valore strategico dello sviluppo interno rispetto all'adozione di strumenti standardizzati e facilmente reperibili sul mercato.
Clarke Rodgers:
Esatto, e credo che la proposta interna, per usare questo termine, sia chiara: questo tipo di investimento ci consente di proteggere meglio AWS e allo stesso tempo di offrire un valore aggiunto concreto ai nostri clienti. In altre parole, è una doppia vittoria.
Steve Schmidt:
E, come da tradizione nel linguaggio di Amazon, partiamo sempre dai clienti: questo approccio consente a tutti loro di migliorare la propria sicurezza. Al contempo, porta beneficio anche alla nostra organizzazione, perché la maggior parte delle nostre business unit sono anch'esse clienti di AWS. In definitiva, è una strategia vantaggiosa su tutti i fronti.