Definição do papel de engenheiros ilustres

Clarke Rodgers (00:11):
Paul, muito obrigado pela sua participação hoje comigo.

Paul Vixie (00:13):
É um prazer estar aqui.

Clarke Rodgers (00:15):
Por gentileza, fale um pouco sobre seu histórico como inovador ilustre e líder de pensamento que ajudou a inventar a Internet até certo ponto no DNS. Explique para a gente.

Paul Vixie (00:30):
Tive um papel inicial, mas eu não sou Al Gore, não a inventei. E, com o DNS, comecei meio que tentando consertá-lo sozinho. Trabalhava em uma empresa de minicomputadores no final dos anos 80, o software era péssimo, e o protocolo não era muito bem compreendido. Portanto, foi em legítima defesa, e depois a ideia deu certo e eu abri uma empresa para mantê-la. Em seguida, quando saí daquela empresa, criei uma startup na área de segurança.

Em algum momento durante todo esse processo, entrei no Hall da Fama da Internet e concluí um doutorado na Universidade de Keio, no Japão, o que é um destino estranho, já que tudo isso começou quando abandonei o ensino médio em 1980.

Clarke Rodgers (01:18):
Uau! Vamos falar um pouco sobre isso. O que fez você abandonar o ensino médio e depois o que causou a mudança em direção à área da tecnologia?

Paul Vixie (01:28):
Na época, eu trabalhava meio período em pequenos empregos na área de minicomputadores. Quando meu orientador disse: “Sim, você vai repetir de ano”, foi porque eu passei o meu tempo todo no laboratório de informática.

Clarke Rodgers (01:43):
Uau!

Paul Vixie (01:44):
Percebi que a situação provavelmente não iria melhorar e que eu deveria simplesmente dar o fora. Mais tarde, deixei aquele emprego, como acontece inevitavelmente nessa idade. Mas sim, foi tudo por eu ser um aluno com notas ruins porque passava muito tempo programando.

Clarke Rodgers (02:00):
Acho que acabou funcionando para você no final.

Paul Vixie (02:03):
Estou feliz com todas as decisões estranhas que foram tomadas.

Clarke Rodgers (02:08):
Por gentileza, conte um pouco sobre sua função aqui na AWS.

Paul Vixie (02:13):
Tenho duas funções, talvez três. Fui contratado como vice-presidente e engenheiro ilustre, ou seja, um grupo muito pequeno de pessoas muito experientes. Essa função é bem autônoma. Para ser vice-presidente e engenheiro ilustre, a descrição do seu trabalho é encontrar problemas e encará-los. É muito raro alguém dizer: “Paul, realmente precisamos que você faça uma determinada coisa”. Em uma empresa desse porte, é uma grande honra ter essa liberdade, especialmente vinte e cinco anos após o acontecimento e sem saber como eu cheguei até aqui. Foi algo muito importante.

Durante o verão, fui nomeado CISO adjunto da AWS e, por coincidência, fui convidado a liderar o Office of the CISO. Você pode pensar no Office of the CISO como arquitetos de soluções de nível executivo. Quando há uma conversa com um cliente em que alguém do nível executivo vai estar presente, normalmente queremos colocar nosso CISO nessa sala. O problema é que só temos um CISO e há muitas salas, então somos uma espécie de banda de apoio para o CISO, ou seja, meia dúzia de pessoas que estão absolutamente no topo do campo, no topo do jogo. E eu já vinha trabalhando com eles, aliás, me integrei a eles para conseguir contato com os clientes. Acho que foi por isso que fui escolhido para liderar a equipe.

Clarke Rodgers (03:44):
Houve algo que realmente te atraiu para a AWS?

Paul Vixie (03:47):
Foi a descrição do cargo. Em outras palavras, se tivesse sido convidado a vir aqui e fosse vice-presidente de uma coisa ou outra e responsável por uma determinada função, eu teria dito: “Sim, já estive lá, fiz isso”. Mas esse é principalmente um cargo de tecnologia. Pelo menos a parte do meu trabalho de engenheiro ilustre é basicamente como um colaborador individual de nível executivo. E, para entender por que isso foi tão empolgante, a última vez que tive a palavra “engenheiro” no meu cargo também foi a última vez que alguém além de mim me escreveu uma carta de oferta e isso terminou em 1993. Fui apenas CEO de startups e, sim, sempre fui um CEO que programava, mas ainda não era realmente um engenheiro profissional. Esse não era meu trabalho principal em nenhuma das minhas empresas.

Portanto, me senti muito lisonjeado por poder voltar ao caminho original onde eu estaria sem todas essas startups e ser simplesmente um engenheiro colaborador. Não achava que ainda seria capaz de fazer isso. Eles meio que tiveram que me convencer. Mas, assim que descreveram o cargo, fiquei refletindo sobre a oferta e cheguei à conclusão: “Sim, você está afim de voltar”. Eu não sabia. Não tinha ideia de que poderia ser empregado, pois sou uma figura pública de pouca importância nos setores de Internet e segurança e sou conhecido como sendo um pouco “lança-bombas”. Eu teria me considerado polêmico demais para esse trabalho. Eles pensaram o contrário. Até o momento, eles acertaram.

Clarke Rodgers (05:22):
Você já está aqui há algum tempo. Já teve a oportunidade de dar uma olhada por aí. Quais foram suas impressões especificamente sobre a cultura de segurança na AWS?

Paul Vixie (05:32):
Nas minhas várias startups, eu vendia para empresas como esta. A governança corporativa é praticamente a mesma em todos os lugares, com a diferença que, aqui, a equipe de segurança está presente há tanto tempo que podemos afirmar que a segurança é a maior das prioridades, e isso não é apenas uma afirmação. Isso se reflete em todos os níveis do organograma, nos planos operacionais e nas prioridades de orçamento.

Em outras palavras, é claro que estamos aqui para atender aos clientes, assim como esperamos que qualquer outra empresa faça. A diferença é que não faremos algo para nossos clientes que também os faça perder a segurança. Nunca deixamos a segurança de fora. Isso é o que há de diferente aqui.

Clarke Rodgers (06:20):
Quando você está se aprofundando com uma equipe de serviço, por exemplo, neste cargo de engenheiro ilustre, pode nos dar alguns detalhes dos bastidores, se há conflito durante uma discussão sobre o lançamento de um recurso versus uma correção de segurança? Ou é apenas: “Não, há uma correção de segurança que precisa ser lançada”. Como são essas discussões?

Paul Vixie (06:42):
Não recebemos reclamações do tipo: “Puxa, se você bloquear este lançamento por conta de algum resultado de teste de segurança de aplicação, e por aí vai, isso nos atrasará demais. Perderemos nossa janela, e isso já está em andamento.” Isso não acontece. É intencional e explicitamente proibido que isso aconteça. O que acontece é que, às vezes, quando algo é “necessário”, mas não “absolutamente necessário”, eu ou outra pessoa que esteja representando a AWS Security vamos dizer: “Isso vai causar problemas e será muito mais caro consertar depois”. As equipes de serviço aqui têm autonomia nesse nível.

Eles podem decidir o que é importante, mas sabem que, se houver um problema de segurança, o fato de falarmos com eles sobre isso será um assunto registrado. Eles terão que dar algumas explicações. Então, sim, às vezes há tensão porque, obviamente, todo mundo tem um chefe e, se o chefe diz que temos que ter isso até uma determinada data, então você precisa obedecer, e nós somos sensíveis a isso. Não queremos destruir nada. Mas entendemos que as pessoas com quem trabalhamos têm o objetivo principal de atingir suas métricas, e nós somos a segunda diretriz principal.

Clarke Rodgers (08:09):
Vamos agora falar sobre seu outro trabalho diário, que é administrar o Office of the CISO. Você tem bastante exposição aos nossos clientes e interage com eles em todas as partes do mundo, seja presencialmente ou virtualmente. Um dos veículos dos quais você participou na AWS é o AWS CISO Circles. Você poderia compartilhar um pouco sobre isso e qual foi a sua experiência?

Paul Vixie (08:30):
Minha introdução ao CISO Circles foi o convite: “Paul, você poderia ir para...” (neste caso foi Madri) “e participar de um CISO Circle?” Eu tive que dizer: “O que é isso e como seria minha participação?” Naquela época, eu estava aqui há apenas um ano. Talvez isso exigisse alguém com mais experiência do que eu sobre quem somos e como chegamos aqui. Acabei indo e foi ótimo, pois tivemos um monte de CISOs de um setor específico se reunindo no mesmo lugar. E a coisa toda está sob uma espécie de NDA: espera-se que você possa falar livremente porque as outras pessoas na sala não vão repetir o que você disse.

Clarke Rodgers (09:20):
Regras da Chatham House.

Paul Vixie (09:21):
Regras da Chatham House, e essas pessoas são, em alguns casos, concorrentes. São CISOs de empresas que estão no mesmo setor, talvez na mesma região, e que normalmente não compartilhariam ideias ou experiências. Porém, como elas estavam na nossa casa e nós estávamos lá, acabamos meio que moderando a discussão, semeando a discussão com algumas apresentações sobre várias tecnologias e, em seguida, incentivando discussões, estimulando desafios e, no final das contas, promovendo o que acabou sendo uma discussão entre eles.

Foi bonito de ver, porque uma das coisas que qualquer empresa de médio a grande porte precisa ser capaz de fazer é se beneficiar com as experiências de seus concorrentes. E não deveríamos tentar competir com base em quem é mais seguro, porque, se você e eu estamos no mesmo setor e você é roubado, isso ainda me prejudica e provavelmente significa que eu serei o próximo. Dessa forma...

Clarke Rodgers (10:24):
Compartilhando informações e melhores práticas...

Paul Vixie (10:26):
Sim. Precisamos ficar lado a lado em algumas áreas, mesmo enquanto competimos em outras. Eles acabaram se conhecendo, descobrindo quanta confiança poderiam oferecer sem arriscar os segredos da empresa e assim por diante. E a intenção é que eles mantenham contato uns com os outros após o evento. E, claro, inevitavelmente isso significa que alguém dirá: “Tive uma experiência terrível com alguma API na nuvem naquele dia”, e outra pessoa dirá: “Ela funciona para mim” e, se acabam reclamando uns com os outros sobre nós, bem, se isso acontecer, devemos aceitar isso também.

Não seremos capazes de melhorar o atendimento aos nossos clientes se não soubermos o que está errado. Portanto, acaba sendo uma grande fonte de inteligência de negócios para nós. “Quem me dera ter...” e, às vezes, você diz: “Na verdade, isso existe”. Somos uma empresa muito grande e inovamos muito, e criamos novos recursos ou novas tecnologias em um ritmo que nenhum cliente conseguiria acompanhar. Quero dizer, é meu trabalho fazer isso, e tenho dificuldade em acompanhar o ritmo.

Então, precisamos ter uma interface com os clientes em que alguém saiba quais são os problemas deles e do setor, o que estão fazendo e como estão fazendo, além de quais são seus pontos problemáticos. Acontece que temos pessoas que estão fazendo isso, e os clientes não sabem que deveriam estar reservando tempo para se reunirem regularmente. E, se o CISO Circles ajuda isso a acontecer, individualmente ou em grupos bem pequenos, espero que ele se espalhe de boca em boca e se torne um movimento.

Clarke Rodgers (11:59):
Fantástico. Paul, muito obrigado pela sua participação.

Paul Vixie (12:02):
Foi um prazer. Obrigado novamente por me receber.