In cosa consiste il ruolo dei Distinguished Engineer

Clarke Rodgers (00:11):
Paul, grazie mille per essere qui oggi.

Paul Vixie (00:13):
Sono lieto di essere qui.

Clarke Rodgers (00:15):
Saresti così gentile da raccontarci qualcosa del tuo background? Sei l’illustre innovatore e leader di pensiero che in una certa misura ha contribuito a inventare Internet nel DNS. Per favore, illustraci il tuo percorso.

Paul Vixie (00:30):
Ho avuto un ruolo nelle fasi iniziali, ma non sono Al Gore, non sono io che l’ho inventato. Riguardo al DNS, inizialmente ho cercato di risolvere il problema da solo. Alla fine degli anni Ottanta, lavoravo in un’azienda di minicomputer: il software era terribile e il protocollo non era molto chiaro. Si può quindi affermare che io abbia agito per legittima difesa, poi l’idea ha preso piede e ho fondato un’azienda per mantenerla. Successivamente, quando ho lasciato quell’azienda, ho creato una startup nel settore della sicurezza.

Nel frattempo, durante tutto questo, sono stato inserito nella Internet Hall of Fame e ho completato un dottorato di ricerca a Keio, alla Keio University in Giappone; una strana conclusione, considerato che nel 1980 avevo abbandonato le superiori.

Clarke Rodgers (01:18):
Wow. Entriamo un po’ nel dettaglio. Come mai hai lasciato la scuola superiore e come sei entrato nel settore della tecnologia?

Paul Vixie (01:28):
All’epoca svolgevo piccoli lavori part-time nel campo dei minicomputer. Il mio consulente scolastico mi ha annunciato che sarei stato bocciato proprio perché passavo tutto il mio tempo nel laboratorio informatico.

Clarke Rodgers (01:43):
Wow.

Paul Vixie (01:44):
Ho capito che la situazione non sarebbe migliorata, quindi tanto valeva abbandonare. Successivamente ho cambiato lavoro, come è inevitabile che accada in gioventù. Ma sì, tutto è iniziato dal mio pessimo rendimento scolastico dovuto al fatto che passavo troppo tempo a programmare.

Clarke Rodgers (02:00):
Beh, penso che alla fine per te sia andata bene così.

Paul Vixie (02:03):
Sì, non rimpiango tutte le strane decisioni che ho preso.

Clarke Rodgers (02:08):
Potresti parlarmi un po’ del tuo ruolo in AWS?

Paul Vixie (02:13):
Ho due ruoli, forse tre. Sono stato assunto come Vice President e Distinguished Engineer, pertanto appartengo a un gruppo assai ristretto di persone molto esperte. È un ruolo che concede una grande autonomia. Il compito di un Vice President e Distinguished Engineer è scovare i problemi e analizzarli a fondo. È molto raro che qualcuno mi dica: “Paul, abbiamo davvero bisogno che tu faccia una certa cosa”. Quindi è un grande onore essere libero di agire in un’azienda di queste dimensioni, soprattutto a 25 anni di distanza e senza sapere come siamo arrivati qui. È stato un cambiamento davvero importante.

Durante l’estate, sono stato nominato Deputy CISO presso AWS e casualmente mi è stato chiesto di dirigere l’Ufficio del CISO, ossia un gruppo di Solutions Architect di livello dirigenziale. Se a un incontro con il cliente partecipa anche un suo dirigente, normalmente vorremmo che anche il nostro CISO fosse presente; il problema, però, è che abbiamo un solo CISO e molti clienti. In sostanza, noi Deputy CISO siamo una specie di squadra di riserva del CISO vero e proprio, una manciata di persone che rappresentano l’assoluta eccellenza nel rispettivo campo di specializzazione. Io stavo già lavorando con loro, integrando le nostre conoscenze e attività per entrare in contatto con i clienti. È per questo che sono stato scelto per guidare quella squadra.

Clarke Rodgers (03:44):
C’è stato qualcosa che più d’altro ti ha spinto verso AWS?

Paul Vixie (03:47):
Sì: la descrizione del lavoro. In altre parole, se mi avessero chiesto di venire qui e di essere il vicepresidente di una cosa o un’altra e di assumermi la responsabilità di una determinata funzione, avrei detto: “Sì, sono in grado, è una cosa che ho già fatto”. Ma questa è principalmente una posizione tecnologica, almeno la parte di Distinguished Engineer del mio lavoro è fondamentalmente quella di un libero professionista che collabora a livello dirigenziale. E per capire perché è stato emozionante, l’ultima volta che ho inserito la parola “ingegnere” nel mio curriculum è stata anche l’ultima volta che ho ricevuto una lettera di offerta da qualcuno che non fossi io stesso, e bisogna risalire al 1993. Sono stato soltanto il CEO di varie startup e sì, sono sempre stato un CEO che programmava, ma non ero comunque un ingegnere professionista. Non era il mio lavoro principale in nessuna delle mie aziende.

Tornare sulla pista originale su cui mi sarei trovato senza tutte quelle startup ed essere assunto come ingegnere con funzioni di consulente è stato lusinghiero. Non pensavo di essere ancora in grado di farlo. Hanno praticamente dovuto convincermi. Ma dopo aver sentito la descrizione della posizione, non riuscivo a smettere di pensarci e mi dicevo: “Sì, la verità è che voglio davvero rimettermi in gioco”. Ma non lo sapevo. Non avevo idea di essere appetibile: sono una figura minore nel settore di Internet e della sicurezza e la mia fama di sovvertitore di regole mi precede. Personalmente, mi sarei considerato troppo discutibile per questo lavoro. Ma loro la pensavano diversamente. Finora hanno avuto ragione.

Clarke Rodgers (05:22):
Quindi, sei qui da un po’. Sei riuscito a curiosare in giro. Quali sono state le tue impressioni in merito alla cultura della sicurezza di AWS?

Paul Vixie (05:32):
Nelle mie varie startup, mi è capitato di vendere ad aziende come questa. La governance aziendale è praticamente la stessa ovunque, ma nel nostro caso il team addetto alla sicurezza è qui da così tanto tempo che è corretto affermare che la sicurezza è alla base di tutto, e non si tratta soltanto di un modo di dire. Traspare in ogni casella dell’organigramma, da ogni piano operativo e in tutte le priorità dei budget.

In altre parole, ovviamente siamo qui per soddisfare i clienti, che è il presupposto di qualsiasi azienda; ma la differenza è che non faremo nulla per i nostri clienti che li porti anche a correre rischi sotto il profilo della sicurezza. Non tralasciamo mai la sicurezza. Questo è ciò che è diverso qui.

Clarke Rodgers (06:20):
Quindi, nel tuo ruolo di Distinguished Engineer, quando ti immergi in profondità in un problema, ad esempio con un team di assistenza, come funziona dietro le quinte? Possono sorgere conflitti quando si discute, ad esempio, dell’opportunità di rilasciare nuove funzionalità o correggere invece un problema legato alla sicurezza? Oppure vi limitate a imporre la risoluzione del problema di sicurezza come prioritaria? Che piega prendono queste discussioni?

Paul Vixie (06:42):
Non riceviamo lamentele del tipo, “Se blocchi questo lancio sulla base dei risultati di alcuni test di sicurezza delle applicazioni e così via, sarà troppo tardi. Perderemo la nostra finestra, e questo sta già avvenendo”. Questo non succede. È intenzionalmente ed esplicitamente vietato. A volte, quando le nostre indicazioni sono vive raccomandazioni ma non ordini tassativi, può capitare che io o qualcuno che rappresenta l’organizzazione della sicurezza di AWS affermi: “Questo creerà dei problemi e sarà molto più costoso risolverlo in seguito”. Nel nostro caso, i team di assistenza hanno autonomia sotto questo profilo.

Possono decidere le loro priorità, ma sanno che se solleviamo un possibile problema di sicurezza, il fatto che si verifichi è solo questione di tempo. In seguito dovranno dare delle spiegazioni. Quindi sì, a volte nascono delle tensioni, perché ovviamente tutti hanno un capo, e se il capo dice “Dobbiamo avere la tal cosa entro una certa data”, si fa il possibile per rispettare la scadenza e siamo sensibili a quell’aspetto. Non vogliamo sconvolgere i piani altrui. Tuttavia, sappiamo che per le persone con cui lavoriamo la priorità è soddisfare le proprie metriche, mentre noi rappresentiamo solo il secondo requisito più importante.

Clarke Rodgers (08:09):
Passiamo al tuo altro lavoro quotidiano: la direzione dell’Ufficio del CISO. Immagino che offra un bel colpo d’occhio sui nostri clienti e ti permetta di interagire con loro in tutto il mondo, in presenza o a distanza. Uno dei progetti a cui hai partecipato in AWS è AWS CISO Circles. Potresti raccontarci qualcosa del programma e della tua esperienza al riguardo?

Paul Vixie (08:30):
La prima volta che ho sentito parlare dei CISO Circles è stata quando mi hanno detto: “Ehi, Paul, potresti andare a...” (in quel caso era Madrid) “e partecipare a un CISO Circle?” Quindi ho dovuto chiedere: “Che cos’è e in che cosa consiste la mia partecipazione?” All’epoca ero qui soltanto da un anno e mi chiedevo se fosse più opportuno mandare una persona con maggiore esperienza e una conoscenza più approfondita dell’azienda e della sua storia. Ad ogni modo sono andato ed è stato fantastico, perché si era riunito un gruppo di CISO di un settore particolare. Le conversazioni sono soggette a un accordo di riservatezza: si può parlare in totale libertà perché le altre persone presenti non ripeteranno ciò che hai detto.

Clarke Rodgers (09:20):
La Chatham House Rule.

Paul Vixie (09:21):
Sì, è la Chatham House Rule, e in alcuni casi si tratta di concorrenti. Erano CISO di aziende che operano nello stesso settore o nella stessa regione e normalmente non avrebbero condiviso le proprie idee o esperienze. Ma erano nostri ospiti e noi eravamo lì presenti per moderare il dibattito; abbiamo fornito spunti di riflessione, presentando vari aspetti delle tecnologie, e successivamente abbiamo incoraggiato la discussione, che alla fine si è trasformata in un dibattito tra di loro.

È stato bello da vedere, perché una delle cose che ogni azienda di medie e grandi dimensioni deve essere in grado di fare è trarre vantaggio dalle esperienze dei propri concorrenti. Inoltre, non dovremmo sentirci al riparo se il nostro assetto di sicurezza è migliore, perché se io e te lavoriamo nello stesso settore e subisci un attacco, questo ha comunque delle conseguenze su di me e probabilmente significa che sarò io la prossima vittima. Quindi, in questo modo...

Clarke Rodgers (10:24):
Ossia condividendo informazioni e buone prassi...

Paul Vixie (10:26):
Esatto, dobbiamo stare fianco a fianco in alcune aree, anche se in altre ci facciamo concorrenza. Questi CISO hanno finito per conoscersi, comprendendo quanta fiducia potevano concedere senza mettere a rischio i segreti della loro azienda e via dicendo. E l’intento è che mantengano i contatti tra loro dopo l’evento. Inevitabilmente, questo significa che qualcuno dirà: “Oh, beh, quel giorno ho avuto questa terribile esperienza con alcune API nel cloud” e qualcun altro dirà: “Beh, per me hanno funzionato”, e se finiscono per lamentarsi l’un l’altro di noi, se ce lo meritiamo, allora dovremmo accettare anche questo.

Non possiamo migliorare il servizio nei confronti dei nostri clienti se non sappiamo cosa non va. Quindi, per noi, questo programma risulta essere una fonte importantissima di business intelligence. Capita che qualcuno dica: “Oh, mi piacerebbe avere...”, e a volte si è in grado di rispondere: “In realtà, ciò che desideri esiste già”. Siamo un’azienda molto grande, innoviamo molto e creiamo nuove funzionalità e nuove tecnologie a un ritmo con cui nessun cliente potrebbe mai tenere il passo. Voglio dire, io stesso faccio fatica a stare al passo, pur trattandosi del mio lavoro.

Quindi, dobbiamo avere l’opportunità di dialogare con i clienti per sapere quali sono i problemi specificatamente suoi e quali quelli del settore, cosa stanno facendo e come lo stanno facendo, così come quali sono i loro punti deboli. Abbiamo persone che si occupano proprio di questo, sebbene i clienti non abbiano ancora compreso che dovrebbero trovare il tempo per incontrarsi regolarmente. Se il CISO Circle aiuta a farlo accadere, poco per volta, spero che l’iniziativa si diffonda con il passaparola e diventi una consuetudine.

Clarke Rodgers (11:59):
Fantastico. Bene, Paul, grazie mille per essere stato qui con me oggi.

Paul Vixie (12:02):
È stata una piacevole chiacchierata. Grazie ancora per avermi invitato.