Proteggere Internet tramite l'innovazione del cloud

Clarke Rodgers (00:10):
È difficile credere che ci sia stato un tempo, prima di Internet, in cui i problemi di sicurezza erano più semplici e chiari. Il mondo è cambiato drasticamente negli ultimi 40 anni e la connessione online è ormai un elemento centrale delle nostre vite e delle nostre attività. Ciò offre maggiori opportunità, ma comporta anche dei rischi molto più grandi.

Sono Clarke Rodgers, Direttore di Enterprise Strategy presso AWS, e vi accompagnerò in una serie di conversazioni con i leader AWS che si occupano di sicurezza, qui su Executive Insights.

Oggi siamo qui con Paul Vixie, Deputy CISO, Vice President e Distinguished Engineer presso AWS. Paul ci offre una prospettiva unica in merito alla sicurezza di AWS, essendo stato uno dei primi a partecipare all'evoluzione di Internet. Unisciti alla conversazione per discutere di come i leader della sicurezza possano rendere Internet un luogo più sicuro in cui comunicare. Speriamo sarà di vostro gradimento.

Clarke Rodgers (00:57):
Paul, grazie mille per essere qui con me oggi. Lavori nel mondo di Internet da molto tempo ormai. Ti andrebbe di condividere alcune delle tue osservazioni su come è nato e su come siamo arrivati al punto in cui siamo oggi, soprattutto per quanto riguarda la sicurezza?

Paul Vixie (01:11):
Beh, inizialmente la sicurezza era considerata una questione secondaria. Per questo motivo è un aspetto che entra in scena molto più tardi. Eppure, le storie sono vere. È nata come rete del governo degli Stati Uniti ma non è mai stata usata dai militari, almeno non nei primi tempi. E così, si è diffusa la leggenda che i protocolli siano stati progettati per resistere ad attacchi cinetici o altro. Ma non è vero. Si è sempre trattato di un sistema di tipo best-effort. E quando funziona, funziona davvero bene per molte persone. Quando invece non funziona, possono verificarsi alcuni guasti catastrofici che una rete più robusta non avrebbe.

Clarke Rodgers (01:48):
A che punto ti sei detto: “Ops, forse non abbiamo considerato la questione della sicurezza”? E cosa hai capito bisognava fare?

Paul Vixie (01:56):
Ho lanciato l'allarme sin da subito e la mia prima preoccupazione è stata lo spam. Non avevamo alcuna forma di autenticazione, nulla che impedisse alle persone di inviare traffico indesiderato, dal momento che su una rete puramente governativa nessuno avrebbe potuto trarre vantaggio dall'invio di traffico indesiderato.

Quindi, ho lanciato l'allarme già nel '92. Dopo essermi messo in proprio occupandomi di consulenza e così via, ho dato vita al primo progetto anti-spam, che è diventato poi la prima società di anti-spam. Il nostro sistema di reputazione distribuito è stato il primo del suo genere. Vorrei averlo brevettato. Ciò che voglio dire è che quel sistema è ancora ampiamente utilizzato, nonostante l'azienda con cui ho iniziato a combattere lo spam non esista più. Quindi, anche se l'azienda non esiste più, l'idea da cui è nata e le tecnologie sviluppate continuano a vivere, e avevo proprio ragione.

Clarke Rodgers (02:57):
Allora, se esiste, cosa ti rincuora (e io spero ci sia qualcosa) nel vedere che la sicurezza viene presa più seriamente, non solo dai grandi fornitori di servizi cloud, ma anche dalle aziende clienti? Ti dà speranza?

Paul Vixie (03:13):
Nutro una certa speranza, ma anche una certa delusione, perché stiamo facendo troppo poco e troppo tardi. Bisogna aspettare che l'intero mercato si svegli e si accorga del problema. L'allarme non può essere lanciato da una sola azienda o da una sola persona.

Una cosa che mi fa sperare è la diversità di tecnologie che ho incontrato dopo essere arrivato ad Amazon. È emerso che, su larga scala, ci sono problemi che si possono generalizzare e soluzioni che possono essere implementate, cosa che non può essere fatta da aziende più piccole. Ad esempio, quello che abbiamo fatto con i processori Graviton per rendere le nostre macchine virtuali più sicure rispetto ad altre, non l'ha fatto nessuno tranne noi.

Anche il set di chip Nitro e l'hypervisor Nitro, ad esempio, sono soluzioni che abbiamo creato solo noi. Oppure, quando è uscito Log4j, non sono mancati i problemi, ma abbiamo fornito una patch a tutti i nostri clienti nel giro di poche decine di ore, perché abbiamo la capacità di poter crearla e di distribuirla rapidamente in modo globale. Mentre con un sistema meno centralizzato in cui ognuno è responsabile delle proprie risorse, bisogna aspettare che la catena di distribuzione si attivi.

“Quindi, sono fiducioso semplicemente perché quando il fenomeno Internet si è trasformato in un'infrastruttura critica ed è diventato una specie di sistema nervoso digitale globale nonché la fonte dell'economia mondiale, le persone hanno iniziato a prenderlo più seriamente.”

Molte delle cose che abbiamo fatto all'inizio, quando i transistor costavano un dollaro ciascuno, stanno gradualmente scomparendo. E a parte non fare le cose stupide che ci hanno permesso di arrivare più velocemente sul mercato rispetto ai protocolli OSI, non c'è altro modo per risolvere questo problema se non con cloud come il nostro.

Clarke Rodgers (05:09):
Guardando ai prossimi due anni, c'è qualche tecnologia o metodologia di cui sei particolarmente entusiasta e che pensi aiuterà non solo le aziende come la nostra, ma anche i nostri clienti ad andare avanti con i loro carichi di lavoro in materia di sicurezza e conformità?

Paul Vixie (05:31):
Beh, sicuramente una cosa che rincuora è il risultato che stiamo ottenendo con i container. È incoraggiante sapere che ne possiamo avere 10.000 in funzione su un singolo chip e che possiamo avviarne migliaia al secondo in caso di picchi di carico, senza dover chiedere a nessuno di cambiare completamente l'ingegneria del software, perché con il passaggio a questo modello ci libereremo del problema che abbiamo ora, per esempio, con le patch.

Ogni giorno c'è qualcosa che ha bisogno di essere riparata. A meno che non si disponga di un team dedicato a questo compito, lo si rimanda, lo si fa una volta alla settimana, una volta al mese, o giù di lì. E quando lo si fa, potrebbe capitare di dire: “Per far sì che questa patch si adatti al sistema che ho, devo anche aggiornare queste altre cose, il che significa che devo mettere tutto in un laboratorio di prova”. Pertanto, potrebbero passare mesi dal momento in cui si scopre che qualcosa ha disperatamente bisogno di una patch al momento in cui la patch è finalmente disponibile nel sistema.

►  Ascolta il podcast: Gestione delle vulnerabilità in uno scenario di sicurezza Zero Day

Non credo che possiamo raggiungere il glorioso futuro di Star Trek in cui tutto funziona se continuiamo così. Cose come i container, che si tratti di Lambda, Kubernetes, Firecracker consentono di avere la pipeline di compilazione, il cosiddetto CI/CD, di creare un'immagine e di sottoporla ai test, e se li supera, è possibile metterla in funzione.

Non è necessario che la VM disponga di strumenti e logica sufficienti per poterla utilizzare per applicare una patch. Questo è ciò che facciamo oggi e non è un comportamento scalabile. Ha già mostrato qualche cedimento e, nonostante io continui a operare in questo modo perché è quello a cui sono abituato, non raccomando ad altri di farlo. Non c'è motivo di farlo e, anzi, ci sarebbero numerosi vantaggi se potessimo semplicemente dire: “Sì, costruiremo cose e poi non le toccheremo”.

Quindi, l'idea che smetteremo di avere umani coinvolti nel processo è l'altra cosa incoraggiante. E mi dispiace dirlo perché sono stati gli umani ad inventarlo e costruirlo, ma ora dobbiamo ridurre l'elemento umano se vogliamo che la sicurezza non si riduca nel tempo.

La quantità di software e hardware che si frappone tra un essere umano e il valore fornito a un cliente è maggiore di quanto non sia mai stata. Ma la nostra comprensione è rimasta relativamente ferma, e ciò significa che comprendiamo una parte sempre più piccola man mano che essa cresce. Non funziona così. Il nostro compito è capire come assicurarci che la complessità non crei risultati indesiderati. E ancora una volta, ciò dipende dall'avere disciplina e dal tenere gli umani fuori dal meccanismo.

“Mi dispiace dirlo perché sono stati gli umani ad inventarlo e costruirlo, ma ora dobbiamo ridurre l'elemento umano se vogliamo che la sicurezza non si riduca nel tempo.”

Clarke Rodgers (08:18):
Partendo dall'idea dell'accesso umano e delle reti, l'idea di Zero Trust si è evoluta nel corso degli anni. Cosa ne pensi di Zero Trust, sia dal punto di vista di AWS, come pensiamo e implementiamo le cose internamente, ma anche dal punto di vista dei clienti, come dovrebbero considerare Zero Trust?

Paul Vixie (08:39):
L'elemento chiave irriducibile di Zero Trust viene spesso frainteso. Ad esempio, ho sentito persone dire “Basta mettere tutto online, rendere tutto raggiungibile e proteggere i servizi e i server stessi. Proteggi la rete senza avere un perimetro”. Non è questo il punto di Zero Trust e non funziona. È ancora necessario un firewall, solo che una volta all'interno del firewall, non si troverà nessuna affidabilità speciale solo perché si è all'interno del perimetro.

Quindi, bisogna eliminare il presupposto che la raggiungibilità implichi affidabilità. Un tempo si parlava di “esterno croccante” e “interno morbido e appiccicoso”. E noi non vogliamo avere un interno morbido e appiccicoso nonostante abbiamo ancora un esterno croccante. È necessario, quindi, un sistema che meccanizzi l'identità, l'autenticazione e le autorizzazioni su larga scala. Per dire, mentre tu ed io stiamo parlando, ci sono circa un paio di miliardi di eventi di autenticazione al secondo che avvengono sul cloud Amazon.

E il tutto senza utilizzare trucchi a buon mercato, come memorizzare nella cache i risultati recenti e dire, beh, se avevi il permesso un secondo fa, probabilmente lo hai ancora. No, noi controlliamo ogni volta e, a un certo punto, abbiamo stretto i denti e ci siamo detti: “Soltanto questo, e niente di meno, potrà rispondere in modo adeguato e prioritario al problema della sicurezza”.

Tuttavia, la maggior parte dei sistemi è stata progettata con l'idea che, se si riesce a entrare, non disponendo di un controllo degli accessi minuzioso che possa funzionare su scala, è possibile fare tutto ciò che si vuole. Questo è ciò che stiamo cambiando. E ci sono diversi standard di autenticazione. Il nostro è arrivato per primo ed è molto grande, ma non è mai stato pensato per essere uno standard del settore. Così altri cloud hanno cose simili su cui stanno lavorando e ci sono alcuni standard di settore che stanno cercando di nascere.

Per quanto ne so, pur non avendone parlato con il team di assistenza, ci assicureremo che tutti i clienti che vogliono operare in questo modo possano farlo.

Clarke Rodgers (10:49):
Nell'ultimo anno circa, l'IA generativa è stata al centro dell'attenzione dei media e sembra apparire quasi quotidianamente nel mio feed. Qual è la tua opinione in merito dalla prospettiva di un professionista della sicurezza? Come credi che i professionisti della sicurezza utilizzeranno questo tipo di cose per aiutare a proteggere, indagare, ecc.?

Paul Vixie (11:10):
Bisogna guardare oltre il clamore e chiedersi: “Cosa succederà una volta che si sarà calmato?” Spesso non lo sappiamo. È una tecnologia piuttosto nuova e per essa sono stati realizzati molti hardware e software. Ma non si sa mai veramente quale sarà l'impatto di uno strumento finché non viene utilizzato da qualcuno diverso dal suo creatore. Se si vuole usare una chiave inglese come martello, è probabile che non sia lo scopo previsto dal costruttore della chiave, ma in alcune situazioni potrebbe funzionare.

Non abbiamo ancora visto degli elementi chiari relativi a ciò che questo strumento permetterà realmente di fare, una volta che il fenomeno mediatico si sarà esaurito e ci sarà qualcos'altro ad occupare i titoli dei giornali. Detto questo, noi di Amazon ci occupiamo di ricerca, sviluppo e implementazione di soluzioni basate sull'intelligenza artificiale da almeno una dozzina d'anni. Ciò significa che questa non è stata una sorpresa per noi.

Un esempio di qualcosa di simile all'IA generativa lo si può trovare già nel sistema CodeWhisperer che utilizza, appunto, tecniche di IA generativa ma non assomiglia per niente a ciò che sta facendo notizia. Succede su tutti i tipi di sistemi. Ad esempio, quando si esegue il rilevamento delle anomalie, si osservano i flussi di telemetria del sistema, gli eventi che indicano che forse c'è qualcosa che non va o gli eventi che possono indicare che qualcuno ci sta attaccando. Sarà possibile correlarli meglio ora che abbiamo questa tecnologia. Ad ogni modo io sono convinto che ad oggi abbiamo visto a malapena l'1% di ciò che si potrà fare.

►  Guarda il video: Lo stato dell'IA generativa

Quindi, se da un lato detesto tutto il clamore mediatico e vorrei serietà fin dall'inizio, capisco anche che ci siano effettivamente dei meriti. Sto lavorando con alcuni team all'interno dell'organizzazione della sicurezza di AWS che stanno cercando di rispondere a questa esatta domanda: “Cosa possiamo fare per servire meglio i nostri clienti ora che uno strumento come questo è disponibile e compreso su larga scala?”

Clarke Rodgers (13:14):
Inoltre, è possibile aiutare l'operatore di sicurezza umano a svolgere gran parte del lavoro di routine dal punto di vista tecnologico con strumenti di IA generativa?

Paul Vixie (13:25):
Sì, e non intendo spingere su un determinato prodotto, ma il più grande successo di Amazon con il nostro cloud è sempre stato il flusso di lavoro che permettiamo ai nostri clienti di adottare e costruire. Quindi, uno dei primi progetti che abbiamo realizzato nello spazio dei modelli linguistici di grandi dimensioni è stato Bedrock. L'idea alla base si trova nel quesito: chi desidera utilizzare un modello linguistico di grandi dimensioni, vuole anche pagare il costo della formazione? Si vuole dover costruire il modello da zero?

Perché questo può richiedere migliaia o decine di migliaia di ore di costoso tempo al computer. E se fosse possibile scegliere tra diversi modelli precostituiti situati in una specie di menù dove poter selezionare quello che si desidera, senza dover pagare per copiarli nel proprio sistema, ma fosse sufficiente aggiungere una logica al proprio VPC o a qualsiasi cosa si stia facendo nel proprio ambiente cloud con accesso diretto alle API che sanno di avere accesso a questi modelli di abbonamento?

E così, la premessa originale, che all'epoca non conoscevo e che ho dovuto imparare dopo essere arrivato qui, la premessa del cloud si è rivelata essere che avere una quantità elastica di calcolo, quindi quanto realmente necessario, accanto a una quantità elastica di storage, di nuovo, quanto realmente necessario, senza alcuna penalità di accesso, è il modo in cui siamo diventati grandi. Ora abbiamo replicato questo concetto all'interno dell'IA generativa, in modo che le persone che sono forse molto ambiziose nel loro segmento di mercato possano fare con il nostro cloud e gli LLM quello che hanno sempre fatto con il nostro cloud senza LLM. Ed è bellissimo. Mi piace molto, perché la vera forza di questo prodotto sarà l'uso che ne faranno i nostri clienti.

Clarke Rodgers (15:13):
I clienti possono contare sull'affidabilità di tutti gli strumenti di sicurezza che hanno utilizzato per anni e su altri aspetti che possono ora essere applicati a strumenti come Bedrock e a qualsiasi altro strumento in arrivo.

Paul, grazie mille per essere stato qui con me oggi.

Paul Vixie (15:26):
È stato fantastico. Grazie ancora per avermi invitato.