Elevar o nível de segurança na AWS e além dela

Clarke (10:27):
Imagino que nem todos os desenvolvedores que trabalham na segurança da AWS começam necessariamente com um histórico de engenharia de segurança extremamente robusto. Quais os tipos de mecanismos são implementados para elevar esses desenvolvedores ao nível necessário para a segurança da AWS, principalmente em relação às ferramentas de desenvolvimento ou até mesmo aos produtos de segurança direcionados ao cliente?

Eric (10:50):
Bem, essa pergunta pode ser respondida de diferentes formas. Por um lado, a segurança na Amazon é uma disciplina dos desenvolvedores. Não é possível fazer tudo o que precisamos fazer. Não podemos escalar os negócios, se o fizermos somente por meio da adição de engenheiros à equipe. Portanto, uma grande parte do nosso trabalho é a criação de ferramentas. Isso faz parte do desenvolvimento de software, da mesma forma que seria feito em qualquer outra equipe da Amazon, exceto que estamos criando ferramentas de segurança. Portanto, muitos dos nossos engenheiros não são engenheiros de segurança e não têm histórico de trabalho no setor de segurança. Não é necessário que eles tenham nenhuma expertise específica em segurança para integrar a equipe. Alguns deles são realmente interessados em segurança, outros apenas gostam do trabalho e da equipe que integram e estão satisfeitos com o trabalho que fazem, mas não têm nenhum interesse específico em segurança. Isso não é um problema.

Eric (11:37):
Todo o domínio da segurança envolve entender as premissas estabelecidas por alguns desenvolvedores e como violar essas premissas para levar o sistema a um estado inesperado. O que acontece quando eu insiro uma unidade de disco inteira de dados nesse campo? O que acontece quando eu giro o botão para 11? O que acontece quando eu insiro um número negativo nesse campo? Na minha experiência, aqueles que têm essa mentalidade pensam assim inerentemente, e é muito difícil ensinar essa mentalidade.

Eric (12:18):
Assim, quando encontramos alguém com essa mentalidade, os conhecimentos de segurança específicos podem ser ensinados. Todas as tecnologias do dia a dia podem ser ensinadas facilmente. Nada do que agora eu faço diariamente existia quando eu estava na faculdade. Portanto, os fundamentos que eu aprendi quando estudante ainda se aplicam, porém nenhuma das tecnologias específicas são hoje aplicáveis. Nós temos na verdade um programa muito robusto para atualizar as pessoas que têm essa tendência específica em relação à segurança.

Eric (12:46):
Sendo assim, sua pergunta tem duas respostas. Por um lado, algumas pessoas não precisam de nenhuma atualização em relação à segurança. É uma tarefa padrão do desenvolvimento, uma função padrão dos desenvolvedores. E eles se destacam. Alguns deles expressam interesse em segurança. Isso é ótimo e é incentivado por nós, mas isso não é necessário. Por outro lado, encontramos pessoas que são inclinadas a descobrir como eu consigo criar os problemas que eu crio. E, ao perguntar “Como eu crio os problemas”, podemos naturalmente responder “Como resolver esses problemas para poder criá-los novamente?” Assim, podemos ensinar a essas pessoas todas as habilidades específicas necessárias para esse trabalho.

Clarke (14:03):
Sendo assim, ou acredito que ao contrário disso, muitos de nossos clientes, à medida que tentam consolidar uma expertise de segurança em suas comunidades de desenvolvimento, podem escolher designar um especialista em segurança para uma “equipe de desenvolvimento regular”, a fim de ajudar a aumentar o nível da segurança nessa equipe e adquirir uma mentalidade de campeão de segurança. A ideia é que, se temos um número limitado de profissionais de segurança, possamos espalhá-los pelas equipes de desenvolvimento e, eventualmente, obter o padrão de segurança desejado. Isso é semelhante na AWS e na Amazon, quero dizer, como encaramos isso, uma vez que a segurança é incorporada à nossa ética, que todos percebem que “têm uma certa responsabilidade pela segurança de suas aplicações e, portanto, seguirão o processo”? Você pode falar um pouco sobre como isso funciona?

Eric (14:58):
Claro. Na AWS, a segurança é a nossa principal prioridade. Acreditamos fundamentalmente que, como a escalabilidade, a disponibilidade, a baixa latência e a baixa instabilidade, a segurança também faz parte da experiência do cliente. Ela é parte de tudo o que desenvolvemos. Apesar disso, a expertise em segurança não é comum. Não temos nem metade dos engenheiros de segurança que precisaríamos ter. Eu adoraria que cada desenvolvedor em nossa equipe fosse também um especialista em segurança. Mas não tenho essa expectativa. Achei interessante você usar o termo campeão de segurança, porque esse é literalmente o nome do nosso programa interno, no qual encontramos pessoas com um foco maior na segurança integradas nas equipes de serviço. Temos treinamento e suporte para esses indivíduos, a fim de elevar a competência deles em relação à segurança, para que possam influenciar suas equipes de serviço.

Eric (16:38):
Assim, quando uma importante decisão precisar ser tomada, eles não precisarão tomá-la sozinhos, com o sentimento “já que eu sou o único campeão de segurança, considero que não estamos prontos para o lançamento ou que precisamos de algum trabalho extra”. Existe todo um departamento de segurança com o qual eles podem contar e podemos trabalhar juntos, partindo de um princípio de obsessão pelo cliente, para descobrir o que é melhor para eles. Se lançarmos um serviço inseguro, esse é o resultado inadequado para os clientes, mas se não lançarmos o serviço... Da mesma forma como um serviço que não existe não satisfaz nenhum cliente, é preciso encontrar um bom equilíbrio. E integrando uma expertise em segurança à equipe de serviços e à equipe de segurança da AWS, que demonstre profunda cooperação com a equipe de serviços, mas que atue em uma função semelhante a de um auditor, podemos tomar decisões melhores e muito mais rápidas.

Clarke (17:28):
E eu imagino que isso alivie... Em muitas conversas que eu tenho com os clientes, percebo que o departamento de segurança é considerado como o departamento que precisa ser evitado ou ignorado, para que as aplicações sejam lançadas. Com esse modelo sobre o qual acabamos de falar, me parece que a ponte de confiança é estendida e que todos percebem que “a segurança faz parte do trabalho, e que é assim que operamos na Amazon”, no nosso caso. E o resultado é que o produto lançado oferece uma segurança muito maior.
 
Eric (18:00):
Há algum tempo, tentávamos definir uma declaração de missão. Como por exemplo, o que a segurança da AWS faz? E a nossa melhor conclusão foi que lançamos aplicações com segurança. Acredito que essa resposta captura bem o motivo da nossa existência. A empresa não existe para fazer segurança. O nome da empresa é Amazon Web Services, e não Amazon Security. Portanto, nosso objetivo é lançar esses serviços da Web, para que sejam distribuídos aos clientes. Se não os lançamos, não estamos executando nossa missão. Não estamos fazendo o que nos propomos fazer. Ou seja, nossa missão é viabilizar os negócios. Não somos a razão dos negócios. E esses negócios não existirão se a sua segurança não for exemplar. Porém, somos apenas uma faceta dos negócios.
 
Eric (18:44):
E, para nós, o mais importante é o patrocínio executivo que conseguimos obter. Está claro que a segurança é extremamente importante e que ela passa de cima para baixo. E como não estamos dizendo que “Somos a equipe de segurança e vocês precisam nos ouvir. Prestem atenção...” Então isso não é um problema. Definimos o tom, desde o CEO até todos os setores da empresa. Todos sabem a importância da segurança.
 
Clarke (20:04):
Obrigada. Em relação à análise de um programa de segurança, especificamente com desenvolvedores e outros indivíduos que criam código na AWS, quais são algumas das principais métricas que vocês usam para medir a eficácia do programa de segurança em toda a comunidade de desenvolvimento da AWS?
 
Eric (20:57):
Nós aplicamos métricas em dois locais.
 
Eric (21:43):
Não é necessário medir o tempo gasto para fechar um tíquete. O tíquete levará o tempo que for preciso para ser fechado. O que medimos é a nossa capacidade de resposta. Temos SLAs (acordos de serviço) para o primeiro envolvimento com o cliente. Por exemplo, se você enviar um e-mail para a equipe de segurança da AWS, estabelecemos publicamente que você receberá uma resposta humana em 24 horas. E nós medimos isso. Contamos com gráficos e tabelas, que eu analiso toda semana, mostrando “Quanto tempo levamos para responder às pessoas que nos enviam e-mails”. Assim, nossa capacidade de resposta é muito importante. Primeiro porque se você não responder prontamente, perderá a confiança das pessoas. Segundo, porque se você responder prontamente, normalmente é uma indicação de que outras coisas boas estão acontecendo.
 
Eric (22:25):
Aplicamos também uma mentalidade semelhante a tíquetes expirados.
…
Tudo é um tíquete. Sendo assim, temos milhares de automações integradas ao sistema de tíquetes para garantir que se um tíquete expirar (medimos o tempo entre a correspondência da equipe de serviço e a correspondência da equipe de segurança para sabermos quando os tíquetes tornam-se estagnados), saberemos quando estivermos bloqueados na equipe de serviço ou quando a equipe de serviço estiver bloqueada em nós, podendo rapidamente selecionar os tíquetes que precisam de atenção imediata. Isso nos fornece os dados necessários para introspecção ou retrospecção e para detectar qual dos processos que não estão funcionando, onde precisamos fazer mudanças na equipe e onde precisamos investir em ferramentas melhores. Assim, medimos os processos de segurança e descobrimos o que promove os melhores resultados para a segurança.
 
Eric (23:20):
Outro ponto que medimos mais consistentemente é que o importante não é somente acertar. Gastamos muito tempo na segurança de aplicações para criar um bom serviço, mas a Amazon jamais lança algum produto ou serviço e depois o abandona. Estamos sempre adicionando recursos e respondendo ao feedback de clientes. Nosso serviços mudam rapidamente com base nesse feedback. Nossa meta não é lançar com segurança, mas sim manter a segurança em todo o ciclo de vida do serviço. Isso significa que o que você fizer durante a avaliação inicial da segurança de aplicações poderá envelhecer rapidamente e perder o valor. Parte do processo de segurança de aplicações é determinar quais invariâncias e declarações queremos que sejam verdadeiras no serviço, e então determinar como verificaremos isso nas variantes do código.
 
Eric (24:10):
Assim, se um serviço tiver que sempre recusar uma solicitação formatada dessa forma, um canário deverá estar implementado para chamar esse serviço em tempo real na produção, com essa solicitação específica formatada para garantir que ela seja recusada. E então medimos os canários. Qual a área de superfície que eles cobrem? Com qual frequência são executados? Com qual frequência eles falham? Com qual frequência eles obtêm resultados anômalos? Medimos esses processos, validando nossa postura de segurança. Não medimos a segurança fornecida. É muito difícil medir isso. Medimos as regressões no nível de segurança já estabelecido. Isso é muito importante porque sempre haverá problemas de segurança. Nossas equipes são inovadoras, estão sempre criando serviços novos e interessantes que antes não tínhamos que proteger. E isso é mais um ponto que mantém a minha motivação para trabalhar todos os dias.
 
Clarke (26:00):
Fantástico! Outra pergunta relacionada a isso, do ponto de vista do cliente, temos clientes muito avançados, que usam infraestrutura como código por meio de um pipeline CICD na produção. Por outro lado, temos clientes exclusivamente no console, que estão realizando atividades de apontar e clicar. Na minha experiência, a maioria dos nossos clientes são intermediários, tentando obter essa infraestrutura como o “nirvana” do código. Qual o conselho você daria às lideranças dos clientes para incentivar um foco maior na engenharia, e não nos aspectos de apontar e clicar no funcionamento de uma infraestrutura?
 
Eric (26:42):
Eu nunca desenvolvi nada que fosse bonito. Eu já criei coisas das quais tenho muito orgulho, coisas que tiveram ótima recepção no mercado, tanto no mercado público de serviços da AWS como no mercado interno no qual os clientes são as nossas equipes de serviços e outros membros da Amazon. Mas tudo isso são sistemas que começaram de uma pequena ideia, que se desenvolveram como o que acreditávamos ser uma coisa muito pequena que encantaria os clientes, e que depois reiteramos isso o mais rápido que conseguimos. E com o tempo elas cresceram. É essa iteração que proporciona essas ferramentas maravilhosas. As pessoas envolvidas com essas ferramentas as consideram um monstro Frankenstein. É tudo uma mistura muito grande, com um pedaço disso e daquilo, como se tivessem sido construídas pelo MacGyver. Mas elas são, na verdade, ferramentas maravilhosas e incrivelmente eficazes. E como elas foram desenvolvidas para as tarefas que estão realizando, passo a passo de forma incremental, elas conseguem fazer o trabalho que precisam fazer.
 
Eric (27:42):
E, quando um novo membro integra a equipe ou quando estamos falando com um cliente sobre como atuamos internamente, eles podem ver essa variedade de ferramentas que temos, todos esses mecanismos que desenvolvemos, e é realmente impressionante! Parece que seria impossível eu replicar isso. Primeiro que não é necessário replicar. Isso é para administrar nossos problemas de segurança específicos. E segundo, não criamos essas coisas, e sim as desenvolvemos com o tempo, e todas elas começaram muito pequenas. Portanto, essa é a abordagem incremental. Quando estávamos falando sobre métricas, falei sobre a irrelevância das regressões, sobre não precisar solucionar o mesmo problema duas vezes. Isso melhora a cada dia. Todos os dias, você aumenta o nível da segurança incrementalmente e o crescimento exponencial simplesmente acontece.
 
Clarke (29:34):
Para os clientes que estiverem assistindo este vídeo, a mensagem que quero passar é que comecem suas iniciativas de engenharia de forma pequena, e então aumentem gradativamente com o tempo, melhorando-as cada vez mais, em vez de tentar fazer tudo de uma só vez.
 
Eric (29:48):
Com certeza. Essa mentalidade incremental sempre traz resultados. E é necessário que ela conte, por outro lado, com profissionais de segurança sérios. Estamos cercados por riscos diários de todos os lados. Atravessar a rua é um risco, dirigir um automóvel é um risco, conectar seu notebook a uma rede é um risco. Precisamos nos sentir confortáveis assumindo os riscos apropriados. Portanto, a segurança é a arte (e eu gostaria que fosse mais uma ciência, mas acredito ser uma arte) de gerenciar esses riscos, de entender quais riscos são aceitáveis, quais podem ser mitigados e quais são simplesmente inaceitáveis. E, como um profissional de segurança em qualquer função, em qualquer área da segurança, é necessário que você possa falar sobre a gravidade desses riscos.
 
Eric (30:38):
No departamento de segurança, quando falamos sobre segurança, precisamos ser clínicos e precisos. Se você diz, “Essa é a pior vulnerabilidade de segurança que já existiu, e não tem nada que podemos fazer para corrigi-la”, você acaba de perder uma grande parte da sua credibilidade. Você encerrou todas as áreas da discussão. Não podemos mais negociar um caminho futuro. Você acaba de fechar todos os caminhos possíveis. Porém, se você disser “Esse é um problema preocupante. Estou bastante preocupado com esse impacto específico”, aí teremos três caminhos futuros. Eu gosto do primeiro. Apesar de mais caro, ele oferece este benefício. Vamos falar sobre o que precisamos fazer aqui. É preciso, é clínico e abre a discussão. Estou trazendo a minha expertise para que possamos ter uma conversa sobre o assunto. O engenheiro que estiver desenvolvendo essa ferramenta de segurança precisa ter isso em mente. É preciso que eles pensem: “Como estou melhorando esses negócios?” e não, “Meu Deus, isso é um desastre, é mesmo terrível!”.