O documento discute como empresas podem melhorar sua resiliência em segurança na AWS através da automação. Ele apresenta dez áreas nas quais as equipes de segurança devem investir tempo e descreve como ferramentas como AWS Security Hub, AWS Config, Amazon GuardDuty e AWS WAF podem automatizar processos como resposta a incidentes, remediação e proteção de aplicações.
Olá, sejam bem vindos ao AWS Innovate. Meu nome é Daniel Garcia, eu sou Arquiteto de Soluções especializado em segurança na AWS e hoje vamos falar sobre como melhorar sua resiliência em segurança na AWS utilizado automatização e serviços nativos da plataforma
Aqui está a nossa agenda, iremos começar conversando como a AWS traz democratização da segurança, depois vamos falar sobre as 10 áreas em que a sua equipe deve começar por investir seu tempo para ter o melhor retorno de segurança; em seguida vamos ver 4 casos de uso de automação e por fim veremos alguns serviços que podem ser utilizados para proteger suas aplicações web.
Recursos mais limitados que temos são engenheiros com conhecimento e experiência em segurança – hoje existe uma grande demanda por esse tipo de profissional que não é atendida pela oferta
O que eu quero dizer com democratização da segurança
Dar acesso à funcionalidades e serviços de segurança, independentemente do quanto vc gasta ou dos recursos que vc tem
Conta AWS é mesma para todos
Quando nos aprendemos algo, você também aprende por inferência, este é o beneficio da escala em que operamos
Democracia vem do grego, demo = povo, kratos – domínio, poder – ou seja poder do povo
No caso da AWS, o povo, os clientes, tem acesso aos aprendizados, e todo o resultado do uso de todos os clientes. Você recebe os mesmos direitos, liberdades e vantagens que qualquer outro cidadão na AWS.
90% do que a AWS lança de funcionalidades e serviços vem diretamente do que nossos clientes estão pedindo, e estes clientes são de diferentes mercados e trazem diferentes perspectivas.
Em uma infra-estrutura tradicional, cada cliente está focado no seu próprio negocio, no seu próprio ambiente
Nós ouvimos clientes do mundo inteiro, em todas os tipos de negócios
O que o Nubank, o Mercado Livre, a Amazon.com, o Netflix, ou a Expedia veem em bilhões de casos de uso todos os dias, vocês também se beneficiam do conhecimento e experiência gerado por esse volume
E se beneficiam também através das funcionalidades que implementados na nossa plataforma baseado no feedback destes clientes, muitas vezes através de um único clique ou uma chamada de API
sem a necessidade de instalar, migrar ou atualizar sua infra-estrutura
Vocês já devem ter visto este slide antes, mas como a infra-estrutura da AWS continua crescendo gostamos de incluí-lo nas apresentações
Em qualquer lugar do mundo que vc queira operar, a AWS pode te alcançar de uma região próxima
Nossa infra-estrutura hoje compreende 69 zonas de disponibilidade em 22 regiões geográficas ao redor do mundo
Também já foi anunciado que estamos trabalhando em mais 13 zonas de disponibilidade em 4 novas regiões na Africa do Sul, Espanha, Itália e Indonésia
Nossa rede de cabos tem mais de 4,1 milhoes de kilometros
Em nossa infra-estrutura temos 1 quadrilhão de métricas de infra-estrutura e aplicações observadas através do cloudwatch
só em segurança, conformidade e governança, já são hoje implementados 230 serviços e funcionalidades
Baseado em toda essa experiencia que comentamos, gostaria de compartilhar com vocês uma sugestão de 10 areas por onde os clientes deveriam começar por investir seus recursos que pode trazer o maior retorno para este investimento
A AWS identifica ameaças ao redor da internet e comunica aos clientes quando notamos que algum recurso que o cliente possui possa estar vulnerável a um ataque que está se propagando.
Fazemos isso o tempo todo.
No entanto isso só funciona quando conseguimos efetivamente contato com o clientes.
O endereço de e-mail que vc tem registrado na sua conta, está sendo monitorado, ele é monitorado por um humano ou um Sistema que gera uma notificação quando há uma informação importante alí?
Especialmente para a credencial de root, que é a primeira credencial criada quando uma conta é aberta
A autenticação de multiplo fator é muito simples de se configurar, não tem custo adicional
E Previne de forma simples e rápida uma grande gama de ataques
Segredos, Chaves de acesso, senhas, parametros confidenciais não devem ser armazenados no código
Pergunte aos seus desenvolvedores onde eles armazenam os segredos, se a resposta for no repositório de Código ou git peça para que não façam isso
Armazenar segredos em Código torna difícil de rotacionar, e de saber quem tem acesso à essas informações
No ambiente da AWS os clientes podem utilizar o Secrets manager, SDKs e outras ferramentas que oferecemos
Security Groups são firewalls stateful que limitam o acesso às suas aplicações.
Como em qualquer ambiente o acesso deve ser concedido apenas aos blocos de endereços que realmente precisam ter acesso aos recursos
Pode ser que uma aplicação tenha que estar publicada para toda a internet, no entanto esta decisão deve ser tomada de maneira consciente e intencional
às vezes Desenvolvedores não tomam o cuidado necessário em identificar e restringir o acesso,
no entanto é fundamental que as políticas de controle de acesso estejam sempre de acordo com a necessidade real de exposição dos recursos para previnir riscos desnecessários
A palavra chave aqui é Intencional
Crie políticas que definem como os dados serão processados e quais são as limitações de acesso para cada tipo de conteúdo
Muitas vezes as políticas dizem que não se pode colocar determinados tipos de informação em certos lugares (dados de clientes não podem ser armazenados em serviços de compartilhamento de arquivos públicos, por exemplo).
No entanto este tipo de política não ensina o que ele efetivamente deve ser feito, onde a informação deve ser armazenada.
Então devemos falar: “faça isso ao invés daquilo”
Dessa forma seus usuários saberão o que fazer sem ter que tomar as decisões por conta propria, e que algumas vezes pode ser uma decisão incorreta
Você está com os logs habilitados?
É importante entender que é impossível encontrar logs que foram descartados
No ambiente de núvem não existe desculpa para não guardar os logs, os serviços de armazenamento são especialmente baratos e escaláveis
Existem níveis de armazenamento como por exemplo o Glacier deep archive que custa menos de 1 dólar por Terabyte
Nossa política interna é de armazernar os logs por 10 anos
Portanto sugerimos que colete e armezene seus logs, gerenciando os níveis de armazenamento e ciclo de vida destes logs para economizar em gastos mas ainda ter acesso às informações quando precise delas
A primeira pergunta a se fazer é se vocês estão usando os perfis
Eles são uma forma de dar permissões sem ter que criar credenciais de acesso de longa duração
Os perfis especificam quem tem acesso ao que
Evite ao máximo usar políticas com “asterisco”
Recomendamos que trabalhem constantemente tornar os acessos o mais restritos possível
Sistemas de alarme são ótimos
Se alguém é notificado melhor ainda
Mas se alguém toma uma atitude aí é o melhor dos mundos
Não adianta ter luzes coloridas piscando se ninguem toma uma atitude em relação à elas
As ações podem ser manuais, automatizadas, ou através de integrações com parceiros.
Mais pra frente famos falar em como automatizar uma parte destes processos de resposta a alertas do guardduty
Segredos não rotacionados são vulnerabilidades esperando para serem exploradas
O processo de rotação deve ser automatizado para que possa ser feito periodicamente sem um grande esforço das equipes
Este tipo de prática também previne falhas nos serviços quando recursos expiram, por exemplo certificados digitais
Quando um certificados digital expira muitas vezes alguns processos podem parar, e nós na AWS já fomos impactados por esse tipo de situação
Por esse motivo criamos o AWS certificate manager para tornar o processo de renovação de certificados digitais automático
Time de segurança pode ser de grande valor, ou uma grande barreira para o desenvolvimento
É importante entender que os Desenvolvedores não tem intenção de criar Código ruim, eles querem criar software de boa qualidade
Quando a equipe de segurança se engaja, existem diferentes tipos de abordagens
Você pode se aproximar e dizer que vai tentar melhorar a segurança analizando com o desenvolvedor escreveu o código e buscar formas de ajudar a melhora-lo, e aí receberá um tipo de reação
Agora se chegar dizendo “meu deus, que o Código horroroso”, a reação será completamente diferente
Times de desenvolvimento constantemente veem a equipe de segurança como um adversário, pois ele pode impactar diretamente nos seus objetivos, que geralmente são a entrega de novas funcionalidades de forma rápida
Eu tenho confiança de que se você for analizar o processo completo, desde a escrita do Código até o deployment em produção, certamente encontrará varios processos que podem ser melhorados de maneira significativa para tornar seu ambiente mais seguro
Eu amo automatização, e acredito em uma colocação frequente do nosso CISO, Stephen Schmidt:
Humanos não devem estar em contato com os dados,
Temos que Remover a proximidade das pessoas com os dados, e a razão disso é simples:
Humanos erram:
* Erro de digitação que podem gerar uma queda do sistema, apesar de todo o treinamento feito clicar em um link recebido por e-mail que não deveriam, ou talvez por estar passando por um dia difícil
Tickets – pode parecer uma sugestão obvia, no entanto a maioria do foco hoje em dia é em criar os tickets de forma automatica, o nosso foco é em resolver os tickets de forma automatizada
No nosso negocio são gerados 100.000s tickets todos os anos - 96.4% dos tickets direcionados à equipe de segurança são resolvidos sem o engajamento de um humano
Porque isso é importante? Qual o recurso mais escasso – humanos com conhecimento e experiencia
Muitos de voces são profissionais de segurança – vocês preferem verificar se alguém do time de vendas fechou um bucket do Amazon S3 que tinha sido aberto publicamente ou fazer outra atividade que possa ser muito mais interessante e trazer benefícios concretos para a companhia?
Criar permissões de acesso que restrinjam as ações corretamente é difícil, repetir isto consistentemente centenas de vezes é muito mais difícil
O foco da automação deve ser em redução de escopo de acesso
Sabemos que é fundamental coletar os logs, no entanto o quão rápido Podemos extrair informação útil deles?
Quanto tempo leva entre uma pessoa dizer “oh oh” até a primeira pergunta ser feita aos logs?
Muitas vezes é necessário buscar as informações em vários repositórios, correlacionar informações entre fontes distintas, como por exemplo informação de usuário, contas, endereços IP, domínios, recursos, etc.
O enriquecimento dos logs deve ser feito com antecedencia aos problemas ocorrerem
Você não quer deixar para fazer essas correlações durante o calor de uma incidente em andamento
Detecção de ameaças: não é algo que seja possível de ser feito de forma manual ou “a olho”
Se vc depende de um ser humano sentado em um SOC em algum lugar do mundo para detectar um incidente, você tem um problema
Além de que os seres humanos com conhecimento em segurança são recursos escassos, que vc não quer dispender para fazer algo que um Código poderia fazer muito mais rápido e de maneira muito mais consistente
Em segurança tempo é um recurso crítico
É muito mais efetivo dedicar os “humanos” para tarefas mais desafiadoras ao invés de tomar ações repetitivas
E isso tudo nos leva aos alertas, ou seja, avisar às pessoas certas de que algo está acontecendo
Mas levar ao passo seguinte: será que as ferramentas que vc usa escalam os problemas se ninguem toma uma atitude?
Internamente na AWS desenvolvemos Sistemas que são usados por toda a companhia que fazem escalação automática dos alertas
Se o engenheiro de segurança de plantão não responde a um alerta, o Sistema automaticamente escala para o próximo nivel e assim por diante, até chegar ao nível do nosso CEO Andy Jassy
A escalação continua subindo até que um ser humano responda
Acredito que vc não quer ir para a sala do chefe e ter que dizer que o alarme disparou mas nada foi feito
O AWS Security Hub é um Sistema que permite a verificação e visualização do seu nível de conformidade com o padrão CIS para AWS e de descobertas de segurança e conformidade de outros serviços como o GuardDuty, Inspector ou parceiros da AWS
Ele também permite executar ações personalizadas sobre estas descobertas que é o que vamos ver em seguida
O IAM Access Analyzer é um novo serviços lançado na re:Invent de 2019 que permite encontrar recursos na sua conta ou “zona de confiança”, que estejam compartilhados fora da zona de confiança ou publicamente e
gera alertas para que você possa tomar medidas
O AWS Config é um serviço que permite monitorar, auditar e avaliar as configurações dos recursos da AWS
Ele monitora e grava continuamente os registros das configurações de recursos e permite automatizar a avaliação das configurações usando regras nativas e também regras personalizadas.
O Config também permite que ações automaticas sejam tomadas para remediar uma não-conformidade
Aqui mostramos apenas um exemplo, porém existe uma grande quantidade de outras regras gerenciadas disponíveis para remediação automatizada, como SSH ou RDP aberto para a Internet, CloudTrail desabilitado, etc.
O Amazon GuardDuty é um serviço de detecção de ameaças que monitora continuamente atividades mal-intencionadas ou comportamentos não autorizados no seu ambiente ou workloads na AWS
en 5’ de tiempo de ejecución
O Web Application Firewall é uma ferramenta fundamental para proteger aplicações web de ataques.
Existe uma grande quantidade de ameaças que podem ser prevenidas usando o WAF da AWS como por exemplo ataques de cross-site scripting, SQL Injection, robos que fazem a varredura e roubo de informações do seu site.
Para facilitar a proteção de suas aplicações web a AWS lançou no re:Invent de 2019
Um pacote de regras gerenciadas pela AWS
Estas regras são atualizadas constantemente pelo nosso time de investigação de ameaças
Além das regras da AWS existe uma grande quantidade de regras de parceiros além da capacidade de criar regras personalizadas.
Outro tipo de ameaça comum a aplicações Web disponibilizadas na internet são os ataques de negação de serviço, ou denial of service.
A AWS implementa dois níveis de proteção para ataques de DDoS
um primeiro nível de proteção que chamamos de Shield Standard ou Shield Padrão que está disponível a todos os clientes sem custo adicional
Ele faz a proteção contra os ataques mais comuns nas camadas 3 e 4 e a detecção e mitigação é feita de maneira automatizada
Para clientes que tem necessidade de contratar um serviço de proteção para ataques mais sofisticados, podem usar o Shield Avançado que conta com:
proteções na camada de aplicação web
um time de resposta a incidentes de negação de serviço 24x7
proteção contra custos adicionais na mitigação de ataques e
um dashboard com notificações e visualização de ataques globais
E por fim vamos falar de uma ferramenta da AWS que fornece orientações em tempo real para ajudar a provisionar e manter os seus recursos de acordo com as melhores práticas da AWS
O Trusted advisor valida a configuração em 4 pilares, um deles é a segurança do seu ambiente. Ele irá alertar para uma série de parâmetros de configuração que podem gerar vulnerabilidades, como:
Security Groups abertos para toda internet
Cloudtrail desabilitado
Ausencia de segundo fator de autenticação configurado
E alguns outros.
Com isso eu gostaria de agradecer a atenção de vocês e desejar uma ótima conferencia.