Como ampliar a responsabilidade pela segurança em toda a sua organização

Clarke: (00:05)
Megan, muito obrigado por participar do nosso programa.

Megan: (00:07)
Claro, com certeza.

Clarke: (00:08)
Então, você poderia nos contar um pouco sobre sua experiência e como você chegou à AWS?

Megan: (00:13)
Exerci diferentes funções na área de segurança por mais de 15 anos. Comecei como especialista em segurança da rede para um hospital. Em seguida, juntei-me a um varejista global com sede em Seattle e o auxiliei no desempenho de diferentes funções de engenharia e arquitetura de segurança. Depois nos tornamos clientes da AWS em 2014 e ajudei na definição de uma estratégia de segurança na nuvem e na implementação dos controles de segurança. Posteriormente, ingressei na Slalom e fiz parte de sua equipe de desenvolvimento, segurança e operações, auxiliando clientes em toda a América do Norte a fazer o mesmo: definir uma estratégia de segurança na nuvem e implementar controles de segurança. Por fim, ingressei na AWS como arquiteta de soluções empresariais para o Noroeste do Pacífico e entrei para a equipe de especialistas em segurança.

Clarke: (01:02)
Incrível!

Megan: (01:03)
Então, estou aqui há cerca de quatro anos. Pois é.

Clarke: (01:04)
Ótimo.

Megan: (01:04)
Obrigada.

Clarke: (01:05)
Então, acho que você começou com uma formação em ciência da computação. O que a atraiu para a área de segurança?

Megan: (01:12)
Foi algo realmente interessante. Inicialmente, eu estava cursando engenharia mecânica e estagiei na Boeing por três verões, tendo a oportunidade de trabalhar com os engenheiros de ferramentas da linha 767-400. E perguntei a eles, se estivessem indo para a universidade naquele momento, o que estudariam? E eles responderam: ciência da computação. Então, pensei, “Ok”. E todos eles disseram isso de maneira enfática. Então eu disse, “Ok, vou fazer um curso de segurança computacional ou de ciência da computação”. E adorei. Foi muito bom. Era para resolver desafios, certo?

Clarke: (01:47)
Certo.

Megan: (01:47)
Metade da turma desistiu do curso porque não era o que eles esperavam. E eu apenas continuei. E uma das disciplinas eletivas era em segurança digital, e isso me pareceu muito interessante. Fiz essa disciplina e fiquei fissurada. Achei realmente muito interessante. São somente mais desafios a serem resolvidos, com constantes mudanças. E então criei um IDS como projeto final para obtenção do meu diploma em ciência da computação. Criei um pequeno programa que analisaria capturas de pacotes de rede e determinaria comportamentos de rede prejudiciais. É algo muito bom.

Clarke: (02:21)
Incrível! Isso a conduziu para uma grande carreira, obviamente.

Megan: (02:23)
Pois é.

Clarke: (02:24)
Então, segundo sua função na AWS, você é arquiteta de soluções de segurança sênior. O que isso significa? E quais são suas principais responsabilidades nessa função?

Megan: (02:33)
Eu auxilio clientes com a segurança da AWS. Eu os auxilio fornecendo orientações sobre como criar a base, definir as barreiras de proteção, implementar controles de segurança, além de ajudá-los a entender: “O que é o modelo operacional para a nuvem? Qual é a aparência desse modelo?” Além disso, ajudo com a instrução de clientes em eventos, workshops de criação, sessões com criadores, bem como no setor interno. Temos alguns programas internos nos quais realizamos ensaios de setores internos e instruímos as equipes sobre os diferentes aspectos da segurança. Isso faz com que de, talvez, 100 níveis de segurança, eles evoluam para 300 níveis, a fim de que possam ser mais eficazes nas conversas com os clientes.

Clarke: (03:20)
Então, Megan, na AWS, temos uma cultura de segurança muito forte e temos muitos mecanismos para ajudar na aplicação dessa cultura. Você tem algum mecanismo de preferência?

Megan: (03:29)
Claro, com certeza. Então, um dos processos que temos é registrar um “sev two”. Não importa qual cargo você ocupe na empresa, se você acha que existe um problema de segurança, o processo é registrar uma ordem de serviço, chamada de “sev two”. Há um engenheiro de segurança por trás disso, o qual ajudará a avaliar se existe mesmo um problema ou não e assumirá a partir daí. Não há qualquer problema se não for uma questão de segurança. Isso é ótimo. E é irrepreensível. Na verdade, nossa intenção é que ninguém se sinta preocupado ou intimidado por pensar que há um problema de segurança. Queremos saber a respeito. Queremos reagir a isso, de uma forma boa, de uma forma positiva. E isso é apoiado pelo nível de liderança, o que é muito bom. Acho que, na maioria das vezes, onde há treinamento e conversa sobre segurança com sua própria liderança, é como se todos pensassem positivamente. Então, acho que isso gera uma cultura de transparência em relação à segurança e uma abertura que acredito que nunca vi em nenhum lugar antes. Eu realmente aprecio isso.

Clarke: (04:44)
Certo. Então, quando você está em contato com todos os diferentes clientes, com os quais você lida nos diversos níveis em toda a organização do cliente, há áreas específicas de enfoque nas quais você os incentiva para ajudá-los a tentar criar sua própria cultura de segurança? Novamente, o tipo de cultura de segurança irrepreensível?

Megan: (05:01)
Claro, com certeza. E consigo perceber isso em algumas áreas. Costumo encorajar os clientes a pensar em operar suas equipes de segurança como se estivessem ajudando os negócios, ajudando os desenvolvedores, em situações que, se eles ajudarem, serão facilitadas. Isso é a coisa certa a se fazer do ponto de vista da segurança, quase abrindo caminho para que, se eles estiverem operando dentro do modelo adequado e houver transparência em relação a esses requisitos de segurança, eles poderão agilizar a comunicação e não atingir uma tonelada de bloqueadores, por assim dizer. Acredito que isso gera um bom equilíbrio entre as área de segurança e desenvolvimento, uma vez que elas estão trabalhando juntas. E realmente gosto de observar esse trabalho nos clientes. Eu definitivamente pude observar isso em alguns casos de clientes. E acho que isso fornece uma boa maneira de operar do lado da segurança e do lado do desenvolvimento, devido a eles estarem trabalhando juntos e ajudarem uns aos outros.

Clarke: (06:00)
Então, a segurança não é o departamento do “não”, mas, na verdade, está tentando ajudar outras áreas e obter êxito?

Megan: (06:05)
Sim, com certeza.

Clarke: (06:07)
Do ponto de vista da liderança do cliente, o que os líderes mais antigos de uma empresa podem fazer para ajudar a promover essa cultura de segurança que estamos tentando construir nos relacionamentos com os clientes?

Megan: (06:20)
Bem, acredito que seja muito diferente de antigamente, certo? A equipe de segurança não é mais a única responsável pela segurança. Não pode ser. Os desenvolvedores precisam ter essa responsabilidade. Na verdade, gosto de orientar os clientes sobre: “Ei, existe o modelo de responsabilidade compartilhada entre a AWS e o cliente”. Com isso, você estende esse modelo de responsabilidade compartilhada por todos os diferentes controles de segurança e aspectos de segurança na nuvem para o resto de sua organização e torna as responsabilidades de cada funcionário transparentes para todos.

Clarke: (06:53)
Certo.

Megan: (06:53)
E isso ajuda a facilitar a realização e implementação das coisas. Então, acredito que ampliar o modelo de responsabilidade compartilhada em sua própria organização, para que seja tangível para todos, é um modelo realmente eficaz.

Clarke: (07:05)
Incrível! Então, tenho certeza de que muitos de seus clientes têm muito menos especialistas em segurança do que gostariam. Quais são algumas das coisas que você observou nas quais as equipes de segurança podem ampliar sua atenção e influência para todo o restante da organização do cliente?

Megan: (07:22)
Bem, existem algumas coisas. Acredito que, em primeiro lugar, nem sempre encontramos o profissional adequado para o trabalho. Então, às vezes, isso significa ampliar um pouco o horizonte e pensar: “Ei, se você tem pessoas na equipe de segurança que não necessariamente entendem sobre a nuvem, mas estão interessados nela, dê a oportunidade para que aprendam”. E se você tiver desenvolvedores ou pessoas da equipe de DevOps interessados em segurança, mas não necessariamente com experiência, dê a oportunidade para que aprendam. Forneça esse treinamento. Acredito que existam muitas ferramentas disponíveis que possibilitam isso. Uma das minhas maneiras favoritas é assistir aos vídeos antigos do re:Invent e do re:Inforce e realizar uma sessão de 30 a 45 minutos sobre as práticas recomendadas de segurança que são fundamentais. E muitos dos vídeos disponíveis são, especificamente, com clientes. Isso os transforma em bons exemplos de como os clientes estão implantando as coisas e nos ajudam a pensar de forma criativa, o que acredito que pode realmente ajudar. Além disso, a certificação profissional ou associada de arquiteto de soluções da AWS é uma ótima maneira de aprender esses conceitos fundamentais. E, é claro, a certificação de especialista em segurança também é muito boa.

Clarke: (08:39)
Então, os últimos 18 meses, mais ou menos, foram difíceis para todos. Tivemos a pandemia e, com ela, mais pessoas passaram a trabalhar de forma remota. A pandemia meio que levou as pessoas a aumentar ou diminuir a adoção da nuvem? O que você consegue perceber nos clientes?

Megan: (08:54)
Claro, com certeza. Percebi que diversos clientes grandes precisaram aumentar sua adoção da nuvem para lidar com a forma como as coisas se alteraram. O negócio de varejo online realmente expandiu porque os ambientes físicos tiveram que fechar. E acredito que podemos perceber alguns padrões interessantes com isso. Acho que aprendemos algumas lições com isso, com base na análise de como outros clientes construíram sua segurança básica inicial e sua estratégia de várias contas. Se eles conseguiram aproveitar a automação para isso, eles se saíram muito bem porque poderiam apenas criar mais contas e implementar a automação. Entretanto, eles já tinham a automação para criar essas bases de segurança e seus controles já existiam. Considerando que, se isso não fosse automatizado, é claro que nós buscaríamos ajudá-los a criar algumas contas sem utilizar a automação e entender suas necessidades o mais rápido possível. Porém, se isso fosse feito manualmente, seria apenas um processo trabalhoso e lento. E, então, acredito que verificar se tudo está... Se todas essas barreiras de proteção e suas várias contas estiverem automatizadas, vai ser muito importante. E este foi apenas um exemplo muito bom de como o mundo real impõe essas mudanças. Por exemplo, quando comecei como cliente da AWS, tínhamos apenas duas equipes de desenvolvimento atuando. Seis meses depois, eram 20 equipes de desenvolvimento, os sistemas estavam em produção e todas as outras pessoas desejavam se juntar a nós na plataforma. Portanto, aprendi esse ensinamento cedo e acredito que muitos clientes tiveram que passar por isso.

Clarke: (10:31)
Então, por esse motivo, você teve que realizar um retrabalho para realmente alcançar o nível de segurança que você desejava obter.

Megan: (10:35)
Sim, exatamente.

Clarke: (10:37)
Então, um pouco nessa mesma linha de pensamento: equipes de segurança, equipes de segurança nas contas dos clientes. Existe uma maneira de esse tipo de segurança abrir caminho para que os clientes adotem a nuvem?

Megan: (10:50)
Acredito que já vi isso em clientes que, muitas vezes, pensam na segurança por último. Não precisa ser assim. Acho que, se eles puderem utilizar a estrutura de segurança que adotaram no local e assumir os controles, apenas atualizando para a nuvem, fazendo algum mapeamento e, essencialmente, colocando essas barreiras de proteção previamente no lugar, será muito mais fácil. Eles estarão preparados para quando precisarem realizar a implantação. E, se não houver ninguém pressionando você, isso é ótimo. Você pode ter o tipo de métricas definido. Você pode configurar a automação sem ter alguém pressionando, como, por exemplo, “Ei, vamos logo”. E também acredito que isso nos dá a oportunidade, como equipe de segurança, de sermos transparentes sobre os requisitos de segurança e ajudar os desenvolvedores a entender o que eles precisam criar e quais especificações a equipe de segurança espera. E penso, novamente, como isso pode mudar o relacionamento entre as equipes de desenvolvedores e de segurança, e apenas... É uma relação mais eficaz e eficiente, a qual só vai ajudar a implementar os recursos de negócios que os desenvolvedores estão tentando criar.

Clarke: (12:10)
Certo. Imagino que há um certo nível de confiança que é criado quando você vê a equipe de segurança entrar na nuvem antes de você e, como desenvolvedor ou proprietário do produto, você pensa: “Bem, realmente não tenho mais desculpa se a equipe de segurança está fazendo isso”.

Megan: (12:25)
Exatamente. Acredito que uma das coisas que percebi funcionar muito bem com os clientes é que se eles fornecem esses requisitos de segurança e dão exemplos, como um lado Wiki interno de “Como é uma política de acesso e identidade segura?”, “O que é um grupo de segurança seguro versus o que é ruim?” e exemplos realmente tangíveis, eles são bem-sucedidos. E, é exatamente disso que estamos falando. Nenhum protagonismo em comparação com papéis secundários para suas políticas de acesso ou esse tipo de coisa. A outra coisa é quando as equipes de segurança se disponibilizam… então, se uma equipe de desenvolvimento for bloqueada, por qualquer motivo… Assim, por exemplo, se um cliente estiver enfrentando dificuldades com um requisito de segurança específico, se a equipe de segurança se disponibilizar durante o horário comercial uma vez por semana ou em um canal do Slack, isso poderá realmente facilitar todo o processo para os desenvolvedores. Eles têm uma equipe de referência. Muitas vezes, eles desenvolvem amizades com essas pessoas para que eles, não necessariamente, tenham que ficar esperando e bloqueados por 24 horas, ou algo assim. Eles podem apenas fazer um encaminhamento de feedback rápido. E, talvez, também sejam feedbacks como “Ei, nossa documentação é muito complicada” ou “Precisamos especificar algo”, ou se estamos pedindo às equipes para inicializar um agente de segurança em um host, por que não escrevemos um script para eles e o disponibilizamos em um repositório de código?

Clarke: (14:02)
Então, com tudo o que você acabou de compartilhar conosco, estou percebendo algumas habilidades que talvez uma equipe de segurança comum não tenha. Então, se analisarmos as equipes de segurança tradicionais, elas estão executando o IDS e diferentes serviços de rede, sistemas de patches, seja qual for o caso, mas estou ouvindo de você e, por favor, corrija-me se estiver errado, que as equipes de segurança atuais precisam realmente entender como os ciclos de desenvolvimento funcionam e, talvez, até como codificá-los?

Megan: (14:33)
Claro, com certeza. Acredito que nós não... Dependendo da experiência do profissional de segurança, você pode não ter uma experiência de desenvolvedor ou um diploma de CS e isso não é necessário, mas acredito que aprender um pouco de programação em Python nunca fez mal a ninguém e a formação sobre a nuvem é bastante simples de aprender. O Ansible é apenas um arquivo de configuração YAML. Acredito piamente que, operando de forma semelhante a uma equipe de desenvolvimento e usando as práticas ágeis com um backlog, um proprietário do produto que está gerenciando uma prioridade do ponto de vista da segurança só vai ser ajudado. Em primeiro lugar, é necessário entender como os desenvolvedores trabalham, mas essa também é uma maneira realmente eficiente de se trabalhar. Quando eu trabalhava com isso, era assim que fazíamos as coisas porque, especialmente do ponto de vista da segurança, as coisas estão mudando muito rápido, os requisitos de negócios mudam rapidamente. De repente, você precisa aumentar a escala verticalmente e mudar a maneira como estava operando. Então, isso ajuda você a redefinir, com eficiência e em um ritmo regular, quais devem ser as prioridades.

Clarke: (15:39)
Então, é quase como se a segurança fosse realizada como um serviço dentro de uma organização?

Megan: (15:44)
Sim, sem dúvida.

Clarke: (15:46)
Ótimo. Então, vamos mudar de assunto um pouco e focar algumas das coisas que estão nas notícias ultimamente. Em relação ao ransomware... você não precisa procurar muito e ouvirá uma história de ransomware após a outra. O que você está percebendo com base nos clientes e que tipo de conselho você dá a eles em relação às técnicas de mitigação de ransomware?

Megan: (16:11)
Provavelmente, tive mais de 20 conversas diretas com os clientes nos últimos dois meses sobre ransomware. Adoro ter essas conversas porque eles dizem: “Ei, queremos entender o que são as mensagens da AWS”. E isso só me mostra que eles pensam em nós como parceiros, o que é incrível. Então, geralmente, o que faço é passar as dez práticas recomendadas porque não existe uma solução definitiva para o ransomware. Você realmente precisa ter um programa de segurança forte, controles de segurança sólidos e garantir que tudo esteja operando com eficiência. Porém, com certeza existem algumas áreas principais a serem abrangidas, por isso conversamos sobre a estratégia de várias contas e o acesso com privilégio mínimo. A única área em que eu realmente insisto é: você tem credenciais de IM estáticas e de longa duração em algum lugar? Se você tem, é hora de analisar essas credenciais com atenção e determinar, em primeiro lugar: elas ainda precisam existir? Podemos reprojetá-las? E, se elas realmente são obrigatórias, como em alguns casos de acesso híbrido em que elas são necessárias, vamos buscar minimizar o acesso anexado a essa credencial para que as pessoas que as utilizam possam executar muito pouco no ambiente e, em seguida, vamos monitorar quando elas são usadas e mantê-las como um risco. Coloque-as no registro de riscos. Não deixe isso passar. E, se houver uma oportunidade de se livrar delas no futuro, livre-se delas. Elas tendem a ser um dos principais riscos que conseguimos observar e queremos ter certeza de que somos proativos em ajudar os clientes a evitar dias difíceis, por assim dizer.

Clarke: (17:44)
Então, pelo que entendi, a mitigação de ransomware é apenas fazer o básico de segurança muito, muito bem. É uma análise justa?

Megan: (17:52)
Sim, é sim. A aplicação de patches não é um conceito novo. E você pode fazer isso na AWS de muitas maneiras diferentes. Você pode extrair e substituir com o grupo do Auto Scaling, além de reiniciar seus sistemas do pipeline CI/CD. Você pode usar o Systems Manager. Neste momento, o Systems Manager se assemelha à metade das operações e à metade das ferramentas de segurança. É incrível o que você pode fazer com ele. Então, sim. Há muitas opções. E, também falamos sobre elas. Acredito que outra coisa que os clientes me perguntaram sobre isso e gerou uma boa conversa é: “Ei, costumávamos fazer backups locais isolados da Internet. Literalmente tínhamos backups em fita que eram armazenados em um caminhão Iron Mountain para que ninguém pudesse acessá-los. Como fazemos isso na AWS?”. Bem, tudo é uma API, então está conectado, mas há maneiras de, se você examinar a segurança, chegar ao limite de segurança como a conta da AWS. Então, você pode criar uma conta separada com um limite diferente… e enviar seus backups para essa conta. Você pode fazer automação com mecanismos do tipo inserir/extrair para obter uma conta de destino para os backups. E então, você tem uma conta separada na qual realiza a extração de uma fonte confiável e conhecida, e pode usar coisas como o bloqueio de objetos do S3, o qual é gravado uma vez e realiza a leitura de muitos WORMs nesse bucket do S3, e alguns controles e segurança realmente fortes, com acesso minimizado até mesmo para alguns administradores da conta. E então, temos o AWS Backup, que foi anunciado acho que há duas semanas, ou bem recente, com o AWS Backup Vault Lock, que permite que você realize ações semelhantes, como gravar apenas uma vez e ler várias vezes, quando aplicado ao Vault. Portanto, de forma simplificada, o que isso faz é impedir que você faça alterações nesses backups depois de estarem concluídos. Ou seja, você não pode excluir nada. Assim, com o AWS Backup Vault Lock, você pode definir políticas, políticas de acesso e impedir que as pessoas façam alterações nelas. Logo, é essencialmente semelhante ao bloqueio de objetos do S3, uma vez que os dados são armazenados e passam a estar fora dos limites por um determinado período de tempo.

Clarke: (20:05)
Entendi. Então, além de algumas das ferramentas e práticas recomendadas que você mencionou, uma coisa que não comentou ainda foi a respeito da preparação da resposta a incidentes. Qual a importância disso e o que os clientes devem fazer nessa área?

Megan: (20:19)
Quando temos essas discussões, especificamente sobre ransomware, sempre pergunto aos clientes: “Você realmente realizou um exercício de mesa sobre um evento de segurança de ransomware?” Porque exercícios de mesa são fundamentais. Caso você nunca tenha trabalhado com resposta a incidentes, pode ser uma situação estressante. O exercício de mesa oferece a oportunidade de trabalhar com muitos dos problemas com os quais você não precisa lidar durante um evento real em que você deseja apenas se concentrar e fazer suas investigações sem nenhum problema. E com o exercício de mesa, você vai passar por essa prática fundamental, verificando, por exemplo, como sabemos que o evento aconteceu? Temos acesso a todas as nossas contas da AWS para realizar as investigações de que precisamos? Onde perceberíamos o evento? Ele passaria pelo nosso centro de operações de segurança? Temos um manual que descreve todas as atividades que as equipes precisam realizar para que possam responder de forma consistente e obter os dados de que precisam para tomar essas decisões? E então, estamos atraindo as partes interessadas adequadas? Porque, se temos um evento de segurança, precisamos saber como nos comunicar com nossos clientes, com os clientes deles. E isso resolve muitos problemas, e nossa equipe de serviço profissional pode ajudar os clientes também. Já fizemos isso várias vezes e a prática leva à perfeição, certo? Portanto, acredito que sempre que houver preocupação sobre um determinado cenário, meu conselho será: “Bem, pratique.” E então, não vai ser tão amedrontador. É tão simples quanto praticar e tornar-se melhor em alguma coisa.

Clarke: (21:55)
Então, você mencionou outras partes interessadas. Isso não é apenas um exercício para a equipe de segurança?

Megan: (22:00)
Não, de jeito nenhum.

Clarke: (22:01)
Quais são algumas das outras partes interessadas que deveriam estar participando desses exercícios de mesa?

Megan: (22:06)
Certo. Bem, definitivamente, a equipe jurídica geralmente se envolve, bem como a equipe de privacidade e de gerenciamento de segurança e, dependendo do tipo de exercício e do incidente em que você está trabalhando, pode ser viável o envolvimento da equipe de suporte técnico, ou de equipes de aplicações e desenvolvimento, para auxiliar no entendimento caso fôssemos realizar algum tipo de mitigação, por exemplo. Quais seriam os impactos de downstream que isso causaria?

Clarke: (22:36)
Quero dizer, você consegue perceber como todos os níveis de uma hierarquia de clientes se envolvem? Isto é, o CEO estaria em algum desses exercícios de mesa? Ou pessoas de outros níveis? Até onde esse exercício pode chegar?

Megan: (22:50)
Pois é. Acredito que também tenha a questão de quem quer se envolver e entender o processo porque quando você realmente enfrenta um evento de segurança, geralmente é confidencial. Você deseja ter certeza de que apenas as pessoas adequadas saberão sobre isso, quem precisa estar ciente para que a comunicação possa acontecer de maneira intencional. Mas, por se tratar de um exercício, não há razão para não envolver pessoas que desejem se envolver. E, se o CEO estiver interessado, deixe-o participar, com certeza.

Clarke: (23:21)
Impressionante.

Megan: (23:22)
Todos podem aprender algo com isso.

Clarke: (23:24)
Então, outro grande tópico que está nas notícias hoje em dia e que os clientes estão sempre perguntando é o conceito de confiança zero. O que significa confiança zero para você?

Megan: (23:34)
Pois é. Bem, antigamente, para controles de acesso e segurança em nosso ambiente, dependíamos muito do perímetro da rede. Enquanto hoje, o que desejamos fazer é autenticar e autorizar chamadas na camada da API. Portanto, o que isso significa é que, seja um usuário obtendo acesso ao nosso ambiente, seja uma chamada de API para API, desejamos garantir que tudo seja autenticado e autorizado em cada etapa do caminho para essa comunicação de rede.

Clarke: (24:10)
Megan, obrigado pela presença hoje.

Megan: (24:12)
Pois é. Obrigada. Foi muito bom.