Alzare il livello della sicurezza in AWS e oltre

Clarke (10:27):
Immagino che non tutti gli sviluppatori che lavorano alla sicurezza di AWS abbiano necessariamente iniziato con un forte background di ingegneria della sicurezza. Che tipo di meccanismi avete in atto per portare quegli sviluppatori al livello che avete impostato per la sicurezza di AWS? In particolare, negli strumenti di creazione o forse anche nei prodotti per la sicurezza rivolti ai clienti? 

Eric (10:50):
Bene, ci sono un paio di modi diversi per pensare a questa domanda. Da un lato, la sicurezza in Amazon è una disciplina da builder. Non possiamo fare tutte le cose che dobbiamo fare. Non possiamo scalare con l'azienda se lo facciamo solo aggiungendo ingegneri al team. E così, un'enorme quantità di ciò che facciamo è costruire strumenti. È uno sviluppo software diretto, proprio come si farebbe in qualsiasi altro team di altri settori di Amazon, tranne per il fatto che stai creando strumenti di sicurezza. Per questo motivo, molti dei nostri ingegneri non sono ingegneri della sicurezza e non hanno un background nel campo della sicurezza. Non c'è bisogno di una particolare esperienza nel settore della sicurezza per entrare a far parte del team. Alcuni di loro hanno una passione per la sicurezza, ad alcuni piace proprio il lavoro e il team su cui stanno lavorando e sono molto felici di fare quello che stanno facendo, ma non hanno un particolare interesse per la sicurezza e va bene comunque.

Eric (11:37):
L'intero ambito di sicurezza sta nel capire quali ipotesi hanno fatto alcuni builder e capire quindi come violare tali ipotesi per spingere il sistema in uno stato imprevisto. Cosa succede quando riverso in questo campo i dati di un intero disco rigido? Cosa succede se incremento fino a 11? Cosa succede se inserisco un numero negativo in questo campo? E le persone che la pensano in questo modo tendono, secondo la mia esperienza, a pensarci in maniera spontanea, ed è davvero difficile insegnare quella mentalità.

Eric (12:18):
E così, quando troviamo qualcuno con quella mentalità, possiamo insegnargli tutte le conoscenze specifiche sulla sicurezza e tutte le operazioni tecniche quotidiane e metterlo alla pari molto facilmente. Nessuna delle cose che faccio oggi quotidianamente esisteva quando ero all'università, quindi i fondamenti che ho imparato a scuola si applicano ancora, ma nessuna delle tecnologie specifiche è più usata. E quindi, in realtà abbiamo un programma davvero solido per far crescere quelle persone che hanno quella particolare apertura mentale.

Eric (12:46):
Quindi, la risposta alla tua domanda è duplice. C'è un gruppo di persone per cui non abbiamo bisogno di far crescere nel settore della sicurezza. È un lavoro di sviluppo standard. È un ruolo di builder standard. E sono perfetti così. E alcuni di loro esprimono interesse per la sicurezza, è fantastico, e li incoraggiamo. Ma non è necessario. Dall'altra parte ci sono le persone che sono inclini a imparare, a capire come si rompono le cose. E chiedere "Come posso rompere questa cosa?" porta automaticamente a chiedersi "Come posso modificarla in modo che non possa essere rotta di nuovo?" A queste persone possiamo insegnare tutte le competenze specifiche del lavoro.

Clarke (14:03):
Quindi a quel punto, o al contrario di quel punto, molti dei nostri clienti, mentre stanno cercando di costruire un'esperienza di sicurezza all'interno delle proprie comunità di sviluppo, prendono una via che implica il coinvolgimento di un esperto della sicurezza da inserire in un team di sviluppo regolare e costruire quel livello di sicurezza all'interno del team, per avere fondamentalmente una mentalità da campione della sicurezza. Quindi, l'idea è che abbiamo un numero limitato di professionisti della sicurezza, quindi cerchiamo di distribuirli attraverso i team di sviluppo e alla fine tutti i settori funzionano. È qualcosa di simile in AWS e Amazon, il modo in cui guardiamo le cose, o è perché la sicurezza è incorporata nella nostra etica che tutti si rendono conto: "Ho una certa responsabilità per la sicurezza della mia applicazione, pertanto seguirò il processo"? Potresti parlarci un po' di come potrebbe funzionare?

Eric (14:58):
Certo. La sicurezza ha la precedenza su tutto. Crediamo fondamentalmente che, proprio come scalabilità, disponibilità, bassa latenza e basso jitter, la sicurezza faccia parte dell'esperienza del cliente. Fa parte di tutto ciò che costruiamo. Detto questo, l'esperienza nella sicurezza è rara. Non abbiamo neanche lontanamente tutti gli ingegneri della sicurezza che vorremmo avere. Voglio dire, mi piacerebbe se ogni singolo sviluppatore a disposizione fosse anche un esperto di sicurezza. Ma non ci spero troppo. E quindi, penso che sia interessante che tu abbia usato il termine "campione della sicurezza" perché questo è letteralmente il nome del programma che usiamo internamente, dove individuiamo persone attente alla sicurezza integrate nei team di servizi e forniamo loro formazione e supporto in modo da aumentare le loro competenze nel campo della sicurezza perché poi possano trasmettere le loro capacità al team di servizi.

Eric (16:38):
E poi, quando viene presa una decisione importante, queste persone non devono assumere una posizione rigida e dire: "Io, come unico esperto della sicurezza qui, sento che questa applicazione non è pronta per il lancio" o "Dobbiamo fare questo lavoro extra". C'è tutta questa organizzazione di sicurezza a cui si può attingere e possiamo lavorare insieme da una posizione orientata al cliente per capire qual è la cosa migliore per il cliente stesso. Se rilasciamo un servizio non sicuro, il risultato è sbagliato per i clienti, ma se il servizio non viene proprio rilasciato... Un servizio che non esiste comunque non aiuta alcun cliente, quindi dobbiamo trovare il giusto equilibrio. E avendo una certa competenza in materia di sicurezza integrata e profondamente in sintonia con il team di servizi e una competenza in materia di sicurezza nel team di sicurezza di AWS, anch'essa in sintonia con il team di servizi ma che lavora più come auditor, prendiamo decisioni migliori e lo possiamo fare molto più velocemente.

Clarke (17:28):
E immagino che questo allevia... Ancora una volta, da numerose conversazioni avute con i clienti, esce che il dipartimento di sicurezza è considerato il reparto del no oppure è il reparto che devo evitare se voglio lanciare la mia applicazione. Con questo modello di cui hai appena parlato, sembra che quel rapporto di fiducia si sia esteso e tutti si rendano conto: "Beh, la sicurezza è solo una parte del lavoro ed è così che facciamo le cose in Amazon", nel nostro caso. E poi il risultato finale è il rilascio di un prodotto molto più sicuro.
 
Eric (18:00):
Qualche tempo fa stavamo cercando di elaborare una dichiarazione di intenti. Ad esempio, come possiamo spiegare cosa fa la sicurezza AWS? E il meglio che abbiamo escogitato è stato: "rilasciare in modo sicuro". Sono solo quattro parole ma penso che descrivano perfettamente il motivo per cui siamo qui. L'azienda non esiste per implementare la sicurezza. Si chiama Amazon Web Services, non Amazon Security. E quindi, siamo qui per rilasciare questi servizi Web da fornire ai clienti. Se non rilasciamo nulla, non funzioniamo. Non stiamo facendo quello che dovremmo fare. E quindi, siamo qui per consentire lo sviluppo dell'azienda. Non siamo il motivo dell'azienda. E questa azienda non esisterebbe se non ci fosse una sicurezza esemplare, ma questo è solo un aspetto dell'attività.
 
Eric (18:44):
La cosa più importante per noi è la sponsorizzazione esecutiva che otteniamo. Chiaramente, la sicurezza è incredibilmente importante e arriva dall'alto. Attenzione, poiché non stiamo dicendo: "Siamo il team di sicurezza, dovete ascoltarci. Fate attenzione..." Non ho quel problema. Dal CEO in giù, la strada da percorrere è stata definita. Tutti sanno che la sicurezza è importante.
 
Clarke (20:04):
Grazie mille. Quindi, misurando un programma di sicurezza, in particolare con sviluppatori e altri che scrivono codice all'interno di AWS, quali sono alcuni parametri chiave che utilizzi per misurare l'efficacia del programma in tutta la comunità di sviluppo in AWS?
 
Eric (20:57):
Abbiamo due punti in cui applichiamo i parametri.
 
Eric (21:43):
Non si misura il tempo di chiusura di un ticket. Il ticket viene chiuso con il tempo necessario perché venga chiuso. Ma ciò che misuriamo è la nostra reattività. Quindi, abbiamo degli SLA in vigore per il primo contatto. Ad esempio, nel caso di invio di un'e-mail alla sicurezza AWS, abbiamo dichiarato pubblicamente che verrà ricevuta una risposta da un operatore entro 24 ore. E misuriamo quel tempo. In realtà abbiamo grafici e diagrammi che guardo ogni settimana che riportano: "Questo è il tempo che ci è voluto per rispondere alle persone che ci hanno inviato una e-mail". E quindi, la reattività conta davvero. Uno, perché se non sei reattivo, le persone perdono fiducia. E due, perché se sei reattivo, tende a significare che stanno per succedere altre cose buone.
 
Eric (22:25):
Un altro punto in cui applichiamo questo concetto è nella data di scadenza dei ticket.
…
Tutto può essere un ticket. E così, abbiamo una massiccia automazione integrata nel sistema di creazione ticket per assicurarci che se un ticket diventa obsoleto e misuriamo sia il tempo tra la corrispondenza del team di servizi che il tempo tra la corrispondenza del team di sicurezza, e quindi sappiamo quando i ticket sono stagnanti, sappiamo se siamo bloccati sul team di servizi o se il team di servizi è bloccato con noi e possiamo far emergere molto rapidamente i ticket che richiedono un'attenzione immediata. Questo ci fornisce anche i dati introspettivi e retrospettivi per capire quali dei nostri processi non funzionano, dove dobbiamo sostituire del personale, dove dobbiamo investire in strumenti migliori. E così, misurando i processi relativi alla sicurezza abbiamo scoperto che ciò porta effettivamente i giusti risultati di sicurezza.
 
Eric (23:20):
L'altra cosa che misuriamo con decisione... non si tratta di farlo bene. Dedichiamo un'enorme quantità di tempo alla sicurezza delle applicazioni per progettare un buon servizio, ma Amazon non lancia mai niente per poi lasciarlo in standby. Aggiungiamo costantemente funzionalità, rispondiamo continuamente ai feedback dei clienti e i nostri servizi cambiano rapidamente in base a tali feedback. Pertanto, il nostro obiettivo non è quello di lanciare in modo sicuro, ma di mantenere la sicurezza per tutta la durata del servizio, il che significa che le operazioni eseguite durante la revisione iniziale della sicurezza dell'applicazione diventano rapidamente obsolete e perdono il loro valore. E così, parte del processo di sicurezza dell'applicazione consiste nel determinare quale invarianza, quali affermazioni vogliamo siano sempre vere per il servizio, e quindi capire come verificarle nelle varianti nel codice.
 
Eric (24:10):
E quindi, se un servizio dovesse sempre negare una richiesta formattata in questo modo, dovrebbe esserci un canary che chiama quel servizio in tempo reale in produzione con quella richiesta formattata singolarmente per assicurarsi che venga negata. E poi misuriamo i nostri canary. Quanta superficie del servizio stanno coprendo? Con quale frequenza vengono eseguiti? Con quale frequenza mancano l'obiettivo? Quante volte ottengono risultati anomali? Misuriamo quindi questi processi, confermando il nostro atteggiamento verso la sicurezza. Non si tratta di misurare la sicurezza fornita, che è difficile da misurare, ma di misurare le regressioni del livello di sicurezza che abbiamo già stabilito. Ciò è particolarmente importante perché ci sarà sempre un altro problema di sicurezza. I nostri team sono innovativi, continuano a proporre nuovi ed entusiasmanti servizi che non abbiamo mai dovuto proteggere in passato. È un'altra delle cose che mi fa venire al lavoro ogni giorno.
 
Clarke (26:00):
Ma è fantastico. Quindi, se pensiamo alla domanda dal punto di vista dei clienti, abbiamo alcuni clienti che sono molto avanzati che stanno realizzando infrastructure-as-code attraverso una pipeline CICD in produzione. Dall'altro lato, abbiamo clienti che utilizzano esclusivamente la console e svolgono attività point and click. In base alla mia esperienza, la maggior parte dei nostri clienti è da qualche parte nel mezzo, cercando di raggiungere il "nirvana" dell'infrastructure-as-code. Quale consiglio daresti alla leadership del cliente per incoraggiare davvero una maggiore concentrazione sull'ingegneria rispetto agli aspetti operativi point and click della gestione di un'infrastruttura?
 
Eric (26:42):
Non ho mai costruito niente di bello. Ho costruito cose di cui sono incredibilmente orgoglioso, cose che sono andate molto bene sul mercato, che si tratti del mercato pubblico dei servizi AWS o del mercato interno in cui i nostri clienti sono i nostri team di assistenza e altri dipendenti Amazon. Ma sono tutti sistemi che sono partiti da un'idea e abbiamo costruito quella che pensavamo fosse la cosa più piccola che potevamo creare per soddisfare i clienti, quindi l'abbiamo iterata il più rapidamente possibile. Ed è cresciuta nel tempo. È quell'iterazione che ti offre strumenti magnifici. Le persone a loro vicine li considerano il mostro di Frankenstein. È quel rifiuto, tutto filo metallico e nastro adesivo, che sembra sia stato costruito da MacGyver. Ma la realtà è che sono strumenti magnifici. Straordinariamente efficaci. E poiché sono stati costruiti per il lavoro che stanno facendo, passo dopo passo, in modo incrementale, svolgono effettivamente il lavoro che devono fare.
 
Eric (27:42):
E così, quando arriva qualcuno, sia che si unisca al team o che sia un cliente a cui spieghiamo come operiamo internamente, vede questa gamma di strumenti che abbiamo, tutti questi meccanismi che abbiamo costruito e viene travolto. Sembra che non ci sia modo di replicarlo. Uno, non è necessario replicarlo. Serve a gestire i nostri problemi di sicurezza specifici. Due, non abbiamo costruito queste cose così come le vediamo, le abbiamo fatte crescere nel tempo e tutte sono iniziate in piccolo. E quindi, è quell'approccio incrementale. Quando abbiamo parlato di parametri, ho detto nessuna regressione, ovvero non dobbiamo risolvere lo stesso problema due volte. Quindi, migliorare ogni giorno. Ogni giorno si aumenta in modo incrementale il livello di sicurezza ed entra in gioco la crescita esponenziale.
 
Clarke (29:34):
Quindi, per i clienti che visualizzano questo approccio, l'idea è essenzialmente di iniziare in piccolo con i propri sforzi di ingegneria e poi semplicemente crescere nel tempo e migliorare ogni giorno di più e non cambiare l'approccio tutto in una volta?
 
Eric (29:48):
Esattamente. Quella mentalità incrementale ci ripaga. E questa stessa mentalità deve essere acquisita dall'altra parte da professionisti della sicurezza che non siano paranoici. Siamo tutti circondati da rischi ogni giorno. Attraversare la strada è un rischio, guidare l'auto è un rischio, collegare il laptop alla rete è un rischio. E quindi, dobbiamo sentirci a nostro agio nell'assumere i rischi appropriati. E quindi, la sicurezza è l'arte, anche se vorrei che fosse più una scienza, ma penso che sia un'arte, di gestire quei rischi, di capire quali rischi sono accettabili, quali possono essere mitigati e quali sono completamente inaccettabili. E quindi, un professionista della sicurezza, con qualsiasi ruolo, in qualsiasi settore della sicurezza, deve essere in grado di discutere di quanto siano gravi questi rischi.
 
Eric (30:38):
Nell'organizzazione della sicurezza, quando parliamo di sicurezza, una descrizione che usiamo spesso è "fredda e precisa". Se dici: "Questa è la peggiore vulnerabilità di sicurezza mai vista e non c'è niente che possiamo fare per risolverla", hai semplicemente perso un'enorme quantità di credibilità. Hai terminato ogni forma di discussione. Non stiamo più negoziando sulla strada da seguire. L'hai appena sbarrata. Se invece dici: "Questo è un problema davvero preoccupante. Sono in pensiero per l'impatto specifico", ecco tre possibili strade da percorrere. Io preferisco la prima, è più costosa ma offre anche un gran vantaggio. Vediamo cosa dobbiamo fare. È fredda, precisa e apre la conversazione. Vi porto la mia esperienza così possiamo avviare una conversazione sull'attività. In questo modo, l'ingegnere che sta costruendo questi strumenti di sicurezza deve ricordarlo. Deve pensare: "Come faccio a migliorare l'attività?" e non: "Oh mio Dio, va tutto storto, va tutto male".