Estendere la responsabilità della sicurezza a tutta l'organizzazione

Clarke (00:05):
Megan, grazie per essere qui con me oggi.

Megan: (00:07)
Certamente.

Clarke (00:08):
Potresti parlarci un po' del tuo background e di come sei arrivata in AWS?

Megan: (00:13)
Ho ricoperto diversi ruoli di sicurezza per oltre 15 anni, iniziando come specialista della sicurezza di rete per un ospedale. Poi sono entrata a far parte della squadra di un rivenditore globale con sede a Seattle, coprendo diversi ruoli di progettazione e architettura della sicurezza. Siamo quindi diventati clienti di AWS nel 2014 e ho contribuito a impostare la strategia di sicurezza del cloud e ad implementare i controlli di sicurezza. E poi, mi sono unita a Slalom e ho fatto parte del loro team di dev sec ops e ho aiutato i clienti di tutto il Nord America a fare la stessa cosa: impostare la strategia di sicurezza del cloud e implementare i controlli di sicurezza. Infine, sono entrata in AWS come solution architect aziendale per l'area pacifico nord-occidentale per poi entrare nel team di specialisti della sicurezza.

Clarke (01:02):
Grandioso.

Megan: (01:03)
Sono qui da quasi quattro anni. Beh.

Clarke: (01:04)
Ottimo!

Megan: (01:04)
Grazie.

Clarke: (01:05)
Quindi, hai iniziato con una formazione in informatica, immagino. Che cosa ti ha portato alla sicurezza?

Megan: (01:12)
Era molto interessante. All'inizio stavo per intraprendere un percorso di ingegneria meccanica e ho svolto uno stage presso Boeing per tre estati, quindi ho avuto modo di lavorare con gli ingegneri di attrezzaggio della linea 767-400. E ho chiesto loro "Se doveste tornare a scuola oggi, cosa vi piacerebbe studiare?" Mi hanno risposto informatica. E così, ho detto "Okay". E, clamorosamente, lo hanno detto anche loro. Così ho detto: "Va bene, farò un corso di sicurezza informatica o informatica". E mi è piaciuto tantissimo. È stato molto divertente. Un po' come risolvere dei puzzle.

Clarke: (01:47)
Giusto.

Megan: (01:47)
Metà della classe ha abbandonato perché non era il suo genere. Io ho continuato. Uno dei corsi facoltativi era sulla sicurezza digitale e mi sembrava così interessante. E ho seguito quel corso e ne sono rimasta affascinata. Ho pensato che fosse davvero stimolante. Sono solo altri puzzle da risolvere, in continua evoluzione. Quindi ho creato IDS come progetto senior per la mia laurea in informatica. Ho creato un piccolo programma che analizzava le acquisizioni di pacchetti di rete e determinava comportamenti pericolosi della rete. È stato molto divertente.

Clarke: (0221):
Grandioso. Ha portato a una grande carriera, ovviamente.

Megan: (02:23)
Beh.

Clarke: (02:24)
Quindi, in AWS sei un solutions architect di sicurezza senior. Cosa significa? E quali sono le principali responsabilità che hai in questo ruolo?

Megan: (02:33)
Aiuto i clienti con la sicurezza di AWS. Fornisco loro indicazioni su come costruire le basi, impostare i guardrail, implementare i controlli di sicurezza, aiutandoli anche a capire: "Qual è il modello operativo per il cloud? A cosa assomiglia?" Aiuto anche a formare i clienti in occasione di eventi, creo workshop, sessioni di builder e campo interno. Ci sono alcuni programmi interni per cui abbiamo saggi sul campo interno, li istruiamo sui diversi aspetti della sicurezza. Quindi, li portiamo da forse 100 livelli di sicurezza a 300 livelli, in modo che possano essere più efficaci nelle conversazioni con i clienti.

Clarke: (03:20)
Quindi, Megan, in AWS, abbiamo una cultura della sicurezza molto forte e abbiamo numerosi meccanismi per rafforzare quella cultura. Hai qualche meccanismo preferito in particolare?

Megan: (03:29)
Certamente. Uno dei processi che abbiamo è archiviare un sev two. Non importa chi sei nell'azienda, se pensi che ci sia un problema di sicurezza, il processo consiste nel presentare un ticket: si chiama sev two. E c'è qualcuno dall'altra parte, di solito un ingegnere della sicurezza, che valuterà se si tratta di un problema o meno, e da lì verranno prese delle decisioni. E se non è un questione di sicurezza non c'è alcun problema. È grandioso ma è anche irreprensibile. L'idea è che non vogliamo che nessuno si senta preoccupato o intimidito pensando che ci sia un problema di sicurezza. Vogliamo saperlo. Vogliamo reagire, in modo positivo. E tutto questo è supportato a livello di leadership, il che è davvero bello. Penso che molte volte quando c'è una formazione sulla sicurezza e si parla con la propria leadership, è come se tutti ci pensassero positivamente. Questo tipo di pensiero genera una cultura di trasparenza sulla sicurezza e un'apertura che non ho mai visto da nessuna parte prima. Lo apprezzo molto.

Clarke: (04:44)
Giusto. Quindi, quando parli con tutti i diversi clienti con cui hai a che fare a diversi livelli all'interno dell'organizzazione del cliente, ci sono particolari aree di interesse per cui li incoraggi a provare a costruire la propria cultura della sicurezza? Di nuovo il tipo di cultura della sicurezza irreprensibile?

Megan: (05:01)
Certamente. Ci sono un paio di aree. Tendo a incoraggiare i clienti a pensare al funzionamento dei loro team di sicurezza. Ad esempio aiutare l'azienda, aiutare gli sviluppatori, dove, se aiutano, possono semplificare le operazioni. La cosa giusta da fare dal punto di vista della sicurezza, spianando la strada asfaltata, così che se viene utilizzato il modello giusto e c'è trasparenza su questi requisiti di sicurezza, possano accelerare e non colpiscano i punti deboli bloccanti, per così dire. E penso che collaborando insieme questo generi un buon equilibrio tra sicurezza e sviluppo. Mi piace davvero scoprire questo lavoro presso i clienti. L'ho visto in un paio di casi. Penso inoltre che fornisca un bel modo di operare dal lato della sicurezza e dal lato dello sviluppo, con due settori che collaborano e si aiutano a vicenda.

Clarke: (06:00)
Quindi, la sicurezza non è il reparto del "no", ma cerca effettivamente di aiutare e avere successo?

Megan: (06:05)
Sì, certo.

Clarke: (06:07)
Dal punto di vista della leadership del cliente, cosa possono fare i leader senior di un'azienda per contribuire a promuovere quella cultura della sicurezza che stiamo cercando di costruire nelle relazioni con i clienti?

Megan: (06:20)
Beh, penso che sia molto diverso dalle operazioni tradizionali, no? Non è solo il team di sicurezza ad essere responsabile della sicurezza, non può esserlo. Gli sviluppatori ne devono far parte. In realtà mi piace spiegare ai clienti "Ehi, c'è il modello di responsabilità condivisa tra AWS e il cliente", ma in realtà estendi quel modello di responsabilità condivisa a tutti i diversi controlli di sicurezza e aspetti della sicurezza per il cloud al resto della tua organizzazione e lo rendi trasparente a tutti ciò che possiedono.

Clarke: (06:53)
Giusto.

Megan: (06:53)
E poi, aiuti a rendere queste cose facili da fare e da ottenere. Quindi, estendere effettivamente il modello di responsabilità condivisa all'interno della propria organizzazione in modo che sia tangibile per tutti, penso sia un modo davvero efficace.

Clarke: (07:05)
Grandioso. Quindi, sono sicuro che molti dei tuoi clienti hanno molti meno esperti di sicurezza di quanti ne vorrebbero avere. Quali sono alcune delle cose che hai visto su cui i team di sicurezza possono in qualche modo espandere la loro attenzione e influenza nel resto dell'organizzazione del cliente?

Megan: (07:22)
Beh, ci sono un paio di cose. Penso, prima di tutto, che non sempre troviamo la persona giusta che cerchiamo per il lavoro. E così a volte, dobbiamo allargare un po' gli orizzonti e pensare, "Ehi, se hai persone che si occupano di sicurezza che non conoscono necessariamente il cloud ma sono interessate, portale su un percorso che arrivi dove vuoi tu". E se hai sviluppatori o persone DevOps che sono interessati alla sicurezza ma non hanno necessariamente quelle competenze, mettili su una strada che arrivi dove vuoi tu. Fornisci la formazione più adatta. Ci sono tanti strumenti che ti permettono di farlo. Uno dei miei modi preferiti è guardare i precedenti video di re:Invent, re:Inforce, organizzare una sessione di 30 minuti e 45 minuti sulle best practice fondamentali per la sicurezza. E molti dei video disponibili specifici dei clienti sono davvero buoni esempi di come i clienti operano e pensare fuori dagli schemi penso possa davvero aiutare. Inoltre, il certificato professionale o associato di solutions architect AWS è un ottimo modo per ottenere quei concetti fondamentali. E poi, ovviamente, la certificazione di specialista in sicurezza è davvero buona.

Clarke: (08:39)
Gli ultimi 18 mesi o giù di lì, sono stati difficili per tutti. C'è stata una pandemia e più persone oggi lavorano da casa. La pandemia ha portato a un aumento o una diminuzione dell'adozione del cloud da parte delle persone? Cosa vedi dai clienti?

Megan: (08:54)
Certamente. Ho visto diversi grandi clienti dover utilizzare sempre di più il cloud per gestire il modo in cui le cose sono cambiate. L'attività di vendita al dettaglio online è esplosa perché i punti vendita fisici hanno dovuto chiudere. E da questo abbiamo potuto creare alcuni modelli interessanti. Abbiamo imparato alcune lezioni per altri clienti che dipendono da come hanno costruito la loro sicurezza di base iniziale e la loro strategia multi-account. Se sono riusciti a sfruttare l'automazione, hanno fatto davvero bene perché in questo modo hanno potuto semplicemente creare più account e implementare l'automazione. Avevano già l'automazione per costruire quelle basi di sicurezza e i relativi controlli erano disponibili. Sempre considerando che, se qualcosa non era automatizzato, naturalmente li avremmo comunque aiutati a costruire senza automazione per farli crescere il più possibile. Ma se fatto manualmente, era solo difficile e lento. Pertanto, assicurarsi che tutto fosse... Tutti quei guardrail, il multi-account automatizzato... insomma, tutti fattori importanti. E questo è solo uno dei tanti esempi di come viene applicato nel mondo reale. Quando ho iniziato come cliente di AWS, avevamo due team di sviluppo. Sei mesi dopo, c'erano 20 team di sviluppo, i sistemi erano in produzione e tutti gli altri volevano adottare la stessa piattaforma. Quindi, ho imparato la lezione presto e credo che molti clienti si debbano trovare in quella stessa condizione.

Clarke: (10:31)
Perché poi hai dovuto eseguire di nuovo tutta la procedura per alzare lo standard di sicurezza che volevi avere.

Megan: (10:35)
Esattamente.

Clarke (10:37):
Quindi, cambiamo argomento: i team di sicurezza, i team di sicurezza all'interno degli account dei clienti. C'è un modo in cui questo tipo di sicurezza può aprire la strada al cloud per i clienti?

Megan: (10:50)
Molte volte per i clienti la sicurezza è l'ultima delle priorità e non dovrebbe essere così. Penso che se riescono a utilizzare il loro framework di sicurezza che hanno adottato in locale e sfruttare i controlli aggiornandoli per il cloud, facendo un po' di mappatura ed essenzialmente mettendo in atto quei guardrail in anticipo, sarebbe tutto molto più semplice. Le persone sarebbero preparate per la l'implementazione. E, se non c'è nessuno che ti pressa, è fantastico. Puoi avere tutti i parametri definiti. Puoi configurare l'automazione senza qualcuno o qualcosa che ti pressi e ti spinga a farlo. Inoltre credo che dia l'opportunità ai team di sicurezza di essere trasparenti sui requisiti di sicurezza, aiutare gli sviluppatori a capire come devono costruire le strutture e quali specifiche aspettarsi. Tutto questo serve a consolidare il rapporto tra sviluppatori e sicurezza e solo... una relazione più efficace ed efficiente aiuterà a implementare le funzionalità aziendali che gli sviluppatori stanno cercando di mettere in piedi.

Clarke: (12:10)
Giusto. Immagino che ci sia un certo livello di fiducia che viene costruito una volta che vedi il team di sicurezza entrare nel cloud prima di te e come sviluppatore o proprietario di un prodotto pensi: "Beh, se lo sta facendo il team di sicurezza non ho davvero più scuse".

Megan: (12:25)
Esatto. Una delle cose che ho visto funzionare davvero bene con i clienti se forniscono questi requisiti di sicurezza e danno l'esempio, è un settore Wiki interno che si pone domande del tipo "Che aspetto ha una policy di accesso e di identità sicura?", "Cos'è un gruppo di sicurezza sicuro e come è fatto quello non corretto?" fornendo esempi tangibili. E stiamo parlando proprio di questo. Nessuna azione o risorsa particolare per le policy di accesso. Un altro fattore importante è la disponibilità dei team di sicurezza... se infatti un team di sviluppo dovesse essere bloccato, per un qualsiasi motivo, ad esempio se un cliente è bloccato su un requisito di sicurezza specifico, se il team di sicurezza si è reso disponibile negli orari lavorativi una volta a settimana o tramite un canale slack, l'intero processo potrebbe risultare più semplice per gli sviluppatori. Hanno una squadra di riferimento. Molte volte sviluppano rapporti di amicizia con queste persone in modo da non dover necessariamente rimanere bloccati per 24 ore o giù di lì. Funzionano da veloce ciclo di feedback. Nello stesso momento possono capire cose del tipo "Ehi, la nostra documentazione è troppo complicata" o "Dobbiamo specificare qualcosa" o se stiamo chiedendo alle persone di eseguire il bootstrap di un agente di sicurezza su un host, perché non scriviamo uno script per loro rendendolo disponibile in un repository di codice?

Clarke: (14:02)
Ma con tutto ciò che ci hai appena raccontato, mi sembra di capire anche che ci sono alcune capacità che forse il tuo team di sicurezza medio potrebbe non avere. Quindi, se diamo un'occhiata a un team di sicurezza tradizionale, che ha eseguito l'IDS e ha diversi servizi di rete, sistemi di patching e qualsiasi altro elemento, ascoltandoti, e per favore correggimi se sbaglio, capisco che i team di sicurezza ora devono capire davvero come funzionano i cicli di sviluppo e forse anche come creare il codice?

Megan: (14:33)
Certamente. Penso che non... A seconda del background del professionista della sicurezza, potresti non avere conoscenze da sviluppatore o una laurea in informatica e questo non è richiesto, ma penso che un po' di programmazione Python non abbia mai fatto male a nessuno e capire come è strutturato un cloud sia abbastanza facile. Ansible è solo un file di configurazione YAML. E penso assolutamente che lavorare come un team di sviluppo, utilizzando le pratiche agili con un backlog, un product owner che gestisce una priorità dal punto di vista della sicurezza e così via, sia solo di aiuto. Per prima cosa, capisci come lavorano gli sviluppatori, ma soprattutto è un modo di lavorare davvero efficiente. Quando ero una praticante, è così che facevamo le cose perché, soprattutto dal punto di vista della sicurezza, tutto cambia così velocemente, anche i requisiti aziendali. All'improvviso devi aumentare la tua infrastruttura, cambiare il modo in cui stavi operando. Quindi, sei quasi obbligato a ridefinire le priorità in modo efficiente con cadenza regolare.

Clarke: (15:39)
Quindi, quasi come eseguire la sicurezza come servizio all'interno di un'organizzazione?

Megan: (15:44)
Sicuramente sì.

Clarke: (15:46)
Ottimo! Quindi, cambiamo un po' argomento e concentriamoci su alcune delle cose che fanno notizia di recente. Allora, il ransomware è molto diffuso ultimamente, si sente parlare di una storia di ransomware dopo l'altra. Che esperienza avete in merito con i clienti e che tipo di consigli date loro per le tecniche di mitigazione del ransomware?

Megan: (16:11)
Probabilmente negli ultimi due mesi ho avuto più di 20 conversazioni proprio con i clienti relativamente al ransomware. E mi piace avere queste conversazioni perché sono tipo "Vogliamo capire qual è la messaggistica di AWS". E questo mi dice solo che ci considerano un partner, il che è fantastico. Ma poiché non esiste una soluzione unica e definitiva per il ransomware, di solito propongo 10 best practice da seguire. Devi davvero avere un programma di sicurezza solido e controlli di sicurezza avanzati e devi essere certo che funzionino in modo efficiente. Ma ci sono sicuramente alcune aree chiave da coprire, quindi esaminiamo la strategia multi-account e l'accesso con privilegio minimo. L'unica area su cui insisto davvero è: ci sono credenziali IM statiche e di lunga durata? Se sì, è tempo di focalizzare su queste credenziali e determinare la prima domanda da farsi: sono ancora necessarie? Possiamo riorganizzare il tutto? E se sono davvero necessarie, perché in alcuni casi come per l'accesso ibrido lo sono, riduciamo al minimo l'accesso a loro associato in modo da limitarle, le consideriamo un rischio e le monitoriamo più facilmente quando vengono utilizzate. Le scriviamo nel registro dei rischi. Non lasciamo correre. E se c'è l'opportunità di sbarazzarsene in futuro, ce ne sbarazziamo. Le credenziali statiche tendono a essere uno dei principali rischi per i clienti e vogliamo essere certi che possiamo aiutarli, prevenendo le loro brutte giornate.

Clarke: (17:44)
Da quello che ho capito, la mitigazione del ransomware è diventata una parte fondamentale della sicurezza. È una valutazione corretta?

Megan: (17:52)
Certo che lo è. Il patching non è un concetto nuovo e puoi effettivamente utilizzarlo in AWS in molti modi diversi. Puoi eliminare e sostituire con un gruppo con scalabilità automatica e riavviare i sistemi dalla pipeline CICD. Puoi utilizzare Systems Manager. Systems Manager è metà strumento operativo e metà strumento di sicurezza. È incredibile cosa puoi farci. Quindi, sì. Ci sono tante possibilità e ne discuteremo. Un'altra cosa che i clienti mi chiedono spesso ed è buona cosa parlarne è: "Facevamo backup fisicamente isolati in locale. Avevamo letteralmente dei backup su nastro, li isolavamo talmente tanto che li rendevamo difficili da recuperare. Come possiamo farlo in AWS?" Allora, tutto quello che facciamo è un'API, e quindi è connesso, ma esistono diversi modi dal punto di vista della sicurezza, ad esempio puoi creare un account AWS separato e inviare i tuoi backup a quell'account. Puoi eseguire l'automazione con meccanismi di tipo push-pull in modo da avere un account di destinazione per i backup. Quindi puoi avere un account separato in cui richiamarli da una fonte nota utilizzando un blocco di oggetti S3, che è un worm di tipo write once, read many sul bucket S3, oltre a sicurezza e controlli avanzati e accesso ridotto a pochi amministratori dell'account. Infine, con Backup AWS, è stato annunciato da un paio di settimane o anche meno, è disponibile AWS Backup Vault Lock che consente di eseguire la logica write once, read many anche sul vault. Una volta eseguito questo strumento, non potrai più apportare modifiche a quei backup. Pertanto non puoi eliminare alcunché. Con AWS Backup Vault Lock puoi configurare policy e policy di accesso e puoi impedire che le persone apportino modifiche. È molto simile al blocco di oggetti S3 per il fatto che i dati sono archiviati lì e sono off limit per un certo periodo di tempo.

Clarke: (20:05)
Ho capito. Ma oltre agli strumenti e alle best practice che hai descritto, non ho ancora sentito nulla riguardo la preparazione della risposta agli incidenti. Quanto è importante e cosa dovrebbero fare i clienti in quell'area?

Megan: (20:19)
Quando abbiamo queste discussioni sul ransomware in particolare, chiedo sempre ai clienti: "Avete mai svolto un'esercitazione di simulazione di un evento di sicurezza del ransomware?" Le esercitazioni di simulazione sono fondamentali. Se non hai mai lavorato nella risposta agli incidenti, non sai quanto può essere stressante. Una simulazione ti dà la possibilità di imparare a risolvere molti dei problemi che possono verificarsi in un evento reale, durante il quale vuoi solo concentrarti e svolgere le tue indagini senza pensare ad altro. Ma con una esercitazione, come facciamo a sapere se l'evento si è realmente verificato? Abbiamo accesso a tutti gli account AWS in modo da poter eseguire le analisi necessarie? Dove possiamo vedere l'evento? Passa attraverso il nostro centro operativo di sicurezza? Abbiamo un registro che indica tutte le operazioni da eseguire in modo da rispondere coerentemente e sono disponibili tutti i dati di cui abbiamo bisogno per prendere determinate decisioni? Infine, stiamo coinvolgendo le giuste parti interessate? Perché se si verifica un evento di sicurezza, dobbiamo sapere come comunicare con i nostri clienti, con i loro clienti. Risolve molti dei problemi che si verificano e il nostro team di servizi avanzati può intervenire e aiutare i clienti a farlo da soli. L'abbiamo fatto diverse volte e la pratica si perfeziona sempre di più. Quindi ogni volta che c'è timore per un determinato scenario, mi ripeto "Beh, esercitiamoci". Alla fine, non è più tanto preoccupante. È come allenarsi e migliorare in qualcosa ogni giorno che passa.

Clarke: (21:55)
Hai citato le altre parti interessate. Quindi non è un semplice esercizio solo per il team di sicurezza!

Megan: (22:00)
No, per niente.

Clarke (22:01):
Quali sono alcune delle altre parti interessate che dovrebbero partecipare a queste simulazioni?

Megan: (22:06)
Beh. Sicuramente viene coinvolto l'ufficio legale, di solito un team per la privacy, la gestione della sicurezza e, a seconda del tipo di esercitazione e dell'incidente su cui stiamo lavorando, potrebbe essere necessario coinvolgere l'help desk e i team di sviluppo e applicazione per capire se è necessario eseguire un qualsiasi tipo di mitigazione, per esempio. Quali sono gli impatti a valle di tutto ciò?

Clarke: (22:36)
Quindi vengono coinvolti tutti i livelli di una gerarchia di clienti? Cioè, anche il CEO potrebbe partecipare a queste esercitazioni? O quali altri livelli? Dove ci si ferma?

Megan: (22:50)
Beh. Penso che vada coinvolto chiunque desideri essere coinvolto e capire il processo perché quando si attraversa effettivamente un evento di sicurezza, di solito è confidenziale. Vuoi assicurarti che lo sappiano solo le persone giuste in modo che la comunicazione possa avvenire in maniera ponderata. Ma per un'esercitazione, non c'è motivo di non coinvolgere tutte le persone che desiderano farne parte. E quindi, sì, anche il CEO se è interessato.

Clarke (23:21):
Complimenti!

Megan: (23:22)
Tutti possono imparare qualcosa.

Clarke: (23:24)
Un altro grande argomento che fa notizia in questi giorni e che i clienti vorrebbero approfondire è il concetto di zero trust. Cosa significa per te zero trust?

Megan: (23:34)
Beh. Tradizionalmente, per i controlli di accesso e di sicurezza nel nostro ambiente, facevamo molto affidamento sul perimetro della rete. Oggi quello che vogliamo fare è in realtà autenticare e autorizzare le chiamate a livello di API. Ciò significa che, indipendentemente dal fatto che si tratti di un utente che accede al nostro ambiente o di una chiamata da API a API, vogliamo assicurarci che per quella comunicazione di rete tutto sia autenticato e autorizzato in ogni passaggio del percorso.

Clarke: (24:10)
Megan, grazie per essere stata con me oggi.

Megan: (24:12)
Beh. Grazie. È stato molto divertente.