Capítulo 19 — Identidade e criptografia
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 A identidade como novo perímetro"]
N1["19.2 Autenticação e autorização"]
N2["19.3 Sinais de MFA"]
N3["19.4 Hashing"]
N4["19.5 Cifragem e assinaturas"]
N5["19.6 Ataques de identidade vistos pelo defensor"]
N6["19.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 A identidade como novo perímetro"]
N1["19.2 Autenticação e autorização"]
N2["19.3 Sinais de MFA"]
N3["19.4 Hashing"]
N4["19.5 Cifragem e assinaturas"]
N5["19.6 Ataques de identidade vistos pelo defensor"]
N6["19.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[19.1 A identidade como novo perímetro]
|
v
[19.2 Autenticação e autorização]
|
v
[19.3 Sinais de MFA]
|
v
[19.4 Hashing]
|
v
[19.5 Cifragem e assinaturas]
|
v
[19.6 Ataques de identidade vistos pelo defensor]
|
v
[19.7 Caso]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) explicar autenticação, autorização e métodos multifator; (2) relacionar eventos de identidade à detecção; (3) descrever hashing, cifragem e assinaturas nas ferramentas do SOC; (4) reconhecer ataques baseados em identidade do ponto de vista do defensor.
19.1 A identidade como novo perímetro
Muitos ataques hoje usam credenciais válidas em vez de explorações técnicas. Os logs de autenticação — sucessos, falhas, desafios de MFA, emissão de tokens — estão, por isso, entre os dados mais valiosos de um SOC. Com serviços em nuvem e trabalho remoto, não há uma única borda de rede que todo acesso atravesse. São as credenciais que concedem acesso, por isso os atacantes as compram, adivinham ou roubam. Os logs dos sistemas de identidade mostram quem tentou entrar, de onde, com que resultado e qual segundo fator foi usado, o que os torna centrais para identificar o mau uso.
19.2 Autenticação e autorização
A autenticação prova quem um usuário é; a autorização decide o que ele pode fazer. O portal autentica os clientes por senha; os funcionários da Lindqvist usam single sign-on com MFA. Os logs de autorização mostram o acesso a funções sensíveis, como alterar um endereço de entrega. Uma senha correta satisfaz a autenticação, mas o portal ainda decide se aquele cliente pode ver um determinado pedido. Os logs de cada etapa respondem a perguntas diferentes: os de autenticação mostram quem entrou, os de autorização mostram o que tentaram fazer. Um atacante que entra com sucesso muitas vezes aparece depois nos logs de autorização por meio de ações incomuns.
19.3 Sinais de MFA
O MFA reduz o sucesso do credential stuffing. Seus logs acrescentam sinais: pedidos de MFA repetidamente negados pelo usuário podem indicar que alguém tem a senha; uma troca súbita do dispositivo de MFA merece verificação. Pedidos negados sugerem que a senha é conhecida por outra pessoa, já que o usuário real está recusando um acesso que não iniciou. Pedidos repetidos enviados em sequência rápida podem ser uma tentativa de vencer o usuário pelo cansaço até que ele aprove um. Um novo dispositivo de MFA registrado logo depois de um acesso vindo de um lugar desconhecido merece revisão imediata.
19.4 Hashing
Um hash criptográfico dá uma impressão digital de tamanho fixo dos dados. Os SOCs usam hashes para identificar arquivos e verificar se a evidência exportada não foi alterada. As senhas devem ser armazenadas com funções de hash de senha lentas e com salt, para que bancos de dados roubados resistam à quebra. Um hash de arquivo permite aos analistas procurar o mesmo arquivo em muitas máquinas sem mover o próprio arquivo. A evidência exportada que recebe um hash na exportação pode ser conferida depois por qualquer pessoa. O hashing de senhas é diferente: funções projetadas para ser lentas e com salt tornam cada palpite caro, de modo que um banco de dados roubado não pode ser conferido rapidamente contra bilhões de palpites.
19.5 Cifragem e assinaturas
A cifragem protege a confidencialidade em trânsito (TLS) e em repouso. As assinaturas digitais provam origem e integridade: software assinado, lotes de logs assinados. Ferramentas de teste de carga assinadas, como no capítulo 14, permitem às regras fazer exceções confiáveis. A cifragem em trânsito impede que alguém na rede leia os logins; a cifragem em repouso protege os dados armazenados se um disco for roubado. As assinaturas respondem a outra pergunta: isto veio de quem diz ter vindo, sem alterações? Uma regra pode excluir com segurança os testes de carga de uma ferramenta cuja assinatura é verificada e, ainda assim, alertar sobre uma cópia não assinada que usa o mesmo nome.
19.6 Ataques de identidade vistos pelo defensor
Credential stuffing, password spraying e roubo de tokens deixam rastros nos logs de identidade. O trabalho do defensor é coletar esses logs e conhecer os padrões normais, não reproduzir os ataques. O credential stuffing testa pares vazados de nome de usuário e senha em muitas contas; o password spraying testa algumas senhas comuns contra muitas contas; o roubo de tokens reutiliza um token de sessão sem precisar da senha. Cada padrão parece diferente nos logs, e as detecções são construídas a partir dessas visões defensivas, com dados sintéticos, e não a partir de tentativas reais.
19.7 Caso
Depois do incidente, a Lindqvist oferece MFA opcional aos clientes e alerta sobre alterações de endereço logo após um login vindo de uma rede nova. O MFA opcional protege os clientes que o escolhem; o alerta de alteração de endereço protege todos, porque uma mudança do endereço de entrega muitas vezes é o que um atacante quer depois de entrar numa conta. O alerta combina dois sinais, uma rede nova e uma alteração sensível, embora sua primeira semana mostre com que frequência clientes honestos que se mudam também correspondem aos dois. A equipe de segurança planeja revisar a adesão ao MFA depois de seis meses. Os clientes são informados de como ativá-lo.
Exemplo resolvido
Amara projeta uma regra: "alteração de endereço até 10 minutos depois de um login bem-sucedido a partir de uma rede não vista para aquele cliente em 90 dias". No modo só monitoramento, ela dispara 12 vezes numa semana; 11 são clientes que se mudaram e entraram a partir da rede da nova casa. Ela acrescenta, para essas alterações, uma etapa de confirmação por e-mail ao cliente em vez de um alerta ao analista, mantendo o alerta apenas quando a confirmação falha.
Caso sintético. As regras e as contagens são inventadas.
Erros e limites
Os logs de identidade de provedores externos podem chegar atrasados ou sem alguns campos; confira os tempos de entrega.
Exercícios
- EX055 — Por que logs de identidade. Por que os logs de autenticação estão entre os dados mais valiosos do SOC? Rubrica: 3 = os ataques muitas vezes usam credenciais válidas; os logs mostram seu uso; 2 = parcial; 1 = vago; 0 = nada.
- EX056 — Sinais de MFA. Dê dois sinais de detecção relacionados ao MFA. Rubrica: 3 = pedidos negados repetidamente; novo dispositivo de MFA; 2 = um; 1 = vago; 0 = nada.
- EX057 — Projeto da confirmação. Como Amara reduziu o ruído da regra de alteração de endereço? Rubrica: 3 = confirmação por e-mail ao cliente; alerta só quando a confirmação falha; 2 = parcial; 1 = regra apagada; 0 = nada.
Síntese
Os eventos de identidade e as ferramentas criptográficas são material central do SOC; projete as detecções em torno de como os usuários legítimos se comportam.
Continue estudando — capítulo 19 de 50
← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →