Blindando sua nuvem: Respondendo as ameaças - AWS Cloud Experience - Security

1. Blindando sua nuvem:
Respondendo as ameaças
Rafael Koike
Sr Consultant – Professional Services

2. O que esperar desta sessão?
1. Antes do incidente
1. Padrões macro
2. Teoria vs Prática
1. Exemplos de ataques
2. “Blast radius” e compartimentalização
3. Colete os dados para investigação
4. Exemplo
5. Municie-se de dados
2. Depois do incidente
1. Movendo rápido demais
2. Teoria vs Prática
1. Construindo uma (potencial) pasta de caso
2. Antes de agir, pergunte sí mesmo
3. Desvantagens da incerteza
4. Uma estratégia inabalável

3. ANTES DO INCIDENTE

4. Aumento significativo em ataques Web
2015 2016

5. Adote padrões de design otimizados para
resiliência
• SQL injections of varying seriousness
• (first crude floor(), rand() functions, then deeper concat)
• Progressive Elasticsearch traversals
• (telltale ‘_search?q=random.’ ‘match_all,’ Java methods)
• Omnipresent SSH brute-force (where targets exposed)
• (Unlikely to succeed in keyed locales, but see below
• Occasional WordPress blog attacks; more on this later

6. Como estes ataques se parecem?
• Envolva-se desde o estágio de
design
• Limite o ”blast radius” do incidente
para restringir a movimentação
lateral
- Limite o use/reuso de credenciais
- Isole as aplicações
• Esteja preparado
- Faça o snapshot das configurações
continuamente
- Configure Contas e chaves especificas para
Resposta a incidentes
- Instale ferramentas de resposta a incidentes
nas suas imagens padrão e habilite a coleta
de logs
- Garanta que voce possa interpretar os logs

7. Compartimentalização e ”Blast radius”
• Contas AWS distribuidas, regiões, zonas
• (Unidades de negócios, país, região, continente, aplicação, etc.)
• (AWS Roles são com certeza uma boa prática)
• (Manter o usuário root ”sagrado” e MFA são mandatórios)
• Amplie via Layer-7 (simple Elastic Load Balancing or full WAF/WSM)
• Então os tradicionais ACL, security-group, até mesmo .htaccess
• Por último, protections in the app/endpoint-logic itself
• (custom throttling, asymmetric keys, chroot jail(?))

8. Colete os dados de investigação antes de
um incidente
• Estabeleça um padrão de logs
”normais” antes do incidente
• Garanta que seus logs são
imutáveis – armazene em outra
conta de forma que hackers não
possam alterá-lo ou apagá-lo
• Voce estará pronto quando seus
logs estiverem:
- Fáceis de acessar
- Pesquisável
- Visibilidade da núvem
- Continuamente monitorado
AWS CloudTrail
AWS Config
System and app logs
Network telemetry

9. Examplo: modo de acesso e user agent
AWS CloudTrail

10. Colete os dados para investigação (1 de 2)
• – Registre ”tudo”
• (syslog, auth.log, MS Event/Sys/Security are a start)
• (Apache/IIS webservers, Nginx, firewall/proxy too)
• (Don’t forget meta usage… CloudTrail API/RBAC, etc.)
• (Even DHCP, switch, VPN, if your storage can take it)
• – Duplique, triplique, não altere/destrua seus logs
• (Pelo menos duas cópias dos logs originais, host-local, S3, outro)
• (Se voce escolher não critografar os logs, pelo menos faça o checksum)
• (Não poupe aqui, eles são a sua cadeia-de-custódia legal)

11. Colete os dados para investigação (2 de 2)
• – Reconstrução do evento:
• (As vezes útil para… conhecer a origem, seja um IP ou Regex)
• (Mesmo vendo “os últimos 3 vieram do $PROVIDER” pode ajudar)
• – Outras dicas úteis:
• (É apenas uma sondagem casual simples, ou uma atividade mais direcionada?)
• (Não tenha medo de usar o Google… Outros já viram isto antes?)
• – Lembra-se dos ataques casuais de WordPress anteriormente?
• (Acontece que as credenciais normalmente são utilizadas em outros blogs/e-
mails)

12. Indo além dos logs até o nível de detalhes
dos pacotes
Reconstruindo
requsição de tabela
bem-sucedida
inspecionando
sessões HTTP
completas e dados
de resposta *
* Requires IDS or full network packet capture tools

13. DEPOIS DO INCIDENTE

14. Passo 1: Corte a conexão o mais rápido possível
bem… talvez…
Na verdade, vamos dar um ou dois minutos

15. Desvantagens de mover muito rápido
• “There was a mistake made in the 2
hours after the attack” James B.
Comey Jr., the director of the F.B.I.,
told lawmakers at a hearing on the
government’s attempt to force Apple
to help “unlock” the iPhone.
• F.B.I. personnel apparently believed
that by resetting the iCloud password,
they could get access to information
stored on the iPhone. Instead, the
change had the opposite effect –
locking them out and eliminating other
means of getting in.

16. Antes de agir, pergunte a si mesmo:
• Qual a gravidade dos dados que foram
expostos?
• Qual é o seu objetivo principal?
• Existe alguma desvantagem em se
observar silenciosamente as ações do
atacante?
Start

17. Desvantagens da incerteza

18. Construindo um (potencial) arquivo de
caso
• – As probabilidades são que você não está vendo o incidente em "tempo real”
• – Volte, tente construir uma cronologia e um baseline comportamental
• – Não-repúdio é muito importante tambem (nós *não* fizemos XYZ)
• – Não tenha medo de fazer a sua própria investigação com ferramentas open-
source
• (Google, Reddit, Stack Overflow, até mesmo um userid/email)
• – Tenha em mente: Voce é o Tom Cruise, este é o Minority Report
• (Aja como se essa pessoa cometeu ou vai cometer um crime)
• (Construir uma pasta de arquivos do incidente pode servir no futuro como
evidência)

19. Deployment and management
O impacto vai depender do ambiente e dos dados
Security group
Development
Production

20. Como agir na fase de desenvolvimento?

21. Antes de agir, pergunte para sí mesmo:
• Regra de duas pessoas (separação de tarefas) Um indivíduo
sozinho não pode ser responsável ou ter acesso a um processo
completo.
• Compartilhamento de credenciais, todos os usuários devem ter
credenciais individuais, mantenha o “root” seguro
• Mova a empresa para a era do MFA (non-SMS!)
• Confie mas valide: Analise auth.log, syslog, CloudTrail, etc. (Foco em
particular em… inclusões, criações, edição de privilégios)
• Eu acredito que 60% deste trabalho é “learning the new normal”
(Familiaridade com os: ”top talkers”, typical activity, patterns)

22. Antes de agir, pergunte para sí mesmo:
o Assuma que em algum momento voce pode sofrer um incidente
o Use snapshots sempre que possível
o Se possível, observe o atacante sem interrompelo para tentar entender a extensão
do incidente e a intenção do atacante
o Use as ferramentas de networking da nuvem para isolar os sistemas comprometidos
e orquestrar os esforços de recuperação
o Execute periodicamente simulações (sem aviso prévio ) com o seu time de
resposta a incidentes

23. Uma estratégia inabalável (1 de 3)
• Misha says “blast zone”; I say “shields around the Enterprise”
• You cannot stop it all; you will eventually be compromised
Common threats
(Easily blocked)
Deeper or directed threats
(Defensible w. more resources)
Threats infeasible to fully prevent
(Didn’t foresee, too expensive)

24. Uma estratégia inabalável (2 de 3)
Must demonstrate, uphold
pre/post-incident risk
tolerance
Compartmentalization
(firewalls (layer-3, layer-7), filtering, separate credentials)
Sensors and
Instrumentation
(network traffic, user/behavioral… see it, escalate it)
Evidentiary chain-of-
custody logs, daily review
Extra cloud
countermeasures
Extra layer
Layer 3
Layer 2
Layer 1

25. Uma estratégia inabalável (3 de 3)
• – Simplest test: If unsure, try your detection/filtration out
• – Sven picks a casual SQL crawl or peculiar Jenkins entry
• (Then ask “who did this, and when, for what purpose”)
• (Do *not* accept “we don’t know” or “no logs available”)
• (Incomplete, inconclusive results = clear indicator, dig in)
• – Part of our job, as security champion, is stakeholder buy-in
• (Fire drills establish operational tempo, raise seriousness)
• – If you don’t do it, an auditor/underwriter will do it later

26. Perguntas?

27. OBRIGADO!!

28. Lembrem-se de preencher as avaliações!