Capítulo 23 — Operações de segurança e blue team: análise de ameaças e falhas
Mapa da aula
Aula 23 publicada. Mapa, exemplo, EX067.
flowchart TD
N0["23.1 Análise de ameaças"]
N1["23.2 Cobertura de técnicas"]
N2["23.3 Análise de falhas"]
N3["23.4 Falhas silenciosas"]
N4["23.5 Combinando as visões"]
N5["23.6 Revisão"]
N6["23.7 Evitando vieses"]
N7["Ameaças internas e de fraude"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX067"]
Desenho lógico
flowchart LR
N0["23.1 Análise de ameaças"]
N1["23.2 Cobertura de técnicas"]
N2["23.3 Análise de falhas"]
N3["23.4 Falhas silenciosas"]
N4["23.5 Combinando as visões"]
N5["23.6 Revisão"]
N6["23.7 Evitando vieses"]
N7["Ameaças internas e de fraude"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[23.1 Análise de ameaças]
|
v
[23.2 Cobertura de técnicas]
|
v
[23.3 Análise de falhas]
|
v
[23.4 Falhas silenciosas]
|
v
[23.5 Combinando as visões]
|
v
[23.6 Revisão]
|
v
[23.7 Evitando vieses]
|
v
[Ameaças internas e de fraude]
|
v
[Exemplo resolvido] --> [Exercício EX067]
Objetivos de aprendizagem
Você vai (1) analisar as ameaças relevantes para a organização com o ATT&CK; (2) analisar os modos de falha do sistema de monitoramento; (3) combinar as visões de ameaças e de falhas em prioridades; (4) documentar as análises para revisão.
23.1 Análise de ameaças
A análise de ameaças da Lindqvist pergunta que adversários miram empresas de logística e que técnicas usam. Relatórios públicos e os grupos do ATT&CK mostram abuso de credenciais, phishing contra funcionários, ransomware e fraude por meio de contas de clientes. Começar pelos adversários que miram o setor mantém a análise ancorada no que de fato acontece a empresas semelhantes. Para uma empresa de logística, a fraude de entregas e o desvio de pagamentos são tão relevantes quanto o roubo de dados. Os grupos do ATT&CK documentam técnicas vistas em campanhas reais, o que transforma uma preocupação genérica com ransomware em comportamentos específicos que o SOC pode procurar.
23.2 Cobertura de técnicas
Para cada técnica relevante, a equipe registra as fontes de dados necessárias, as detecções existentes e a confiança. Os mapas de cobertura mostram forças (abuso de credenciais no portal) e lacunas (movimento lateral nas redes dos depósitos). A confiança registra quão segura a equipe está de que uma detecção funcionaria, com base em testes, e não em sua mera existência. Uma regra escrita, mas nunca testada, recebe confiança baixa. O mapa de cobertura torna as prioridades visíveis para gestores que não sabem ler regras: forte numa área, fraco em outra, com a evidência por trás de cada classificação.
23.3 Análise de falhas
O próprio sistema de monitoramento falha: fontes silenciam, analisadores quebram depois de atualizações, tabelas de enriquecimento ficam desatualizadas, regras são desativadas e esquecidas. Uma tabela de modos de falha e efeitos lista cada falha, seu efeito sobre a detecção, como ela seria notada e sua probabilidade. O formato vem da análise de segurança da engenharia, onde é usado para máquinas e instalações. Aplicado ao monitoramento, cada linha pergunta: se esta parte falhar, que detecções param de funcionar, com que rapidez saberíamos e quão provável é? Um analisador que quebra depois de uma atualização é provável e pode passar dias despercebido, então fica no topo da lista.
23.4 Falhas silenciosas
As piores falhas são as silenciosas: uma fonte para de enviar e nada alerta. Elas recebem uma detecção própria, tratada no capítulo 47. O silêncio é perigoso porque a ausência de alertas parece igual à ausência de ataques. Uma fonte que normalmente envia dez mil eventos por hora e de repente não envia nenhum deveria, ela mesma, disparar um alarme. Volumes esperados por fonte, com alertas para quedas grandes, transformam o silêncio num sinal visível. Algumas fontes são naturalmente silenciosas à noite, então os limiares comparam cada hora com a mesma hora das semanas anteriores, e não com uma média diária fixa.
23.5 Combinando as visões
A prioridade é mais alta onde uma técnica importante depende de um componente frágil — por exemplo, a detecção de tomada de conta dependendo de uma única alimentação de logs do balanceador de carga. A análise de ameaças mostra o que importa; a análise de falhas mostra o que é frágil. A interseção das duas é onde uma única falha deixaria o SOC cego para uma técnica importante. A alimentação do balanceador de carga é um exemplo claro: se ela parar, a detecção de tomada de conta se degrada. A resposta é uma segunda alimentação ou um monitoramento cerrado da existente. Amara marca essas interseções em vermelho no mapa de cobertura.
23.6 Revisão
As análises são revisadas pelos analistas, pelas operações de TI e pelo gabinete do CISO, e retomadas depois de incidentes ou de grandes mudanças. Os analistas sabem em quais detecções se confia na prática; as operações de TI sabem quais componentes são frágeis; o gabinete do CISO conhece as prioridades do negócio. Cada visão corrige as outras. Retomar a análise depois de incidentes a mantém atual, já que um incidente muitas vezes revela uma técnica ou um modo de falha que a revisão original deixou passar. Cada revisão produz uma versão datada, com uma lista curta de mudanças e de quem as pediu, para que leitores posteriores vejam como a visão da equipe sobre ameaças e falhas evoluiu com o tempo.
23.7 Evitando vieses
As equipes dão peso demais aos incidentes recentes. Usar o ATT&CK como lista de verificação ajuda a considerar técnicas que ainda não atingiram a Lindqvist. Depois do incidente do portal, a atenção se concentra no abuso de credenciais, e é tentador gastar todo o esforço ali. Uma lista de verificação obriga a equipe a olhar de forma sistemática para outras técnicas, como o mau uso de ferramentas de gerenciamento remoto nos depósitos, que ainda não causaram problemas. A dor recente é um sinal útil, mas um guia completo ruim. Cada técnica deixada de fora é marcada com um motivo curto.
Ameaças internas e de fraude
Nem toda ameaça é externa. Funcionários com acesso a contas de clientes poderiam fazer mau uso dele, e fraudadores podem usar recursos legítimos do portal. Essas ameaças dependem mais de logs de negócio, como alterações de endereço e reembolsos, do que de telemetria técnica.
Exemplo resolvido
Entrada da tabela de falhas de Amara: "A alimentação de logs do balanceador de carga para → nenhum alerta de tomada de conta → notado só por acaso → probabilidade média (a alimentação quebrou duas vezes no ano passado) → prioridade alta. Ação: monitoramento de heartbeat e um segundo caminho de alimentação."
Caso sintético. As análises são inventadas.
Erros e limites
Os relatórios de ameaças descrevem a experiência de outros; adapte-os ao seu ambiente.
Exercícios
- EX067 — Registro de cobertura. O que é registrado para cada técnica relevante? Rubrica: 3 = fontes de dados, detecções, confiança; 2 = dois; 1 = um; 0 = nada.
- EX068 — Falha silenciosa. Por que as falhas silenciosas são as piores? Rubrica: 3 = nada alerta, então a detecção desaparece sem ser notada; 2 = parcial; 1 = vago; 0 = nada.
- EX069 — Prioridade combinada. Por que a alimentação do balanceador de carga foi classificada como alta? Rubrica: 3 = uma detecção importante depende de uma única alimentação frágil; 2 = parcial; 1 = aleatório; 0 = nada.
Síntese
Combine a cobertura de ameaças com a análise de falhas do sistema de monitoramento para definir as prioridades.
Continue estudando — capítulo 23 de 50
← Capítulo 22 (rascunho) · Índice de capítulos do curso · Capítulo 24 (rascunho) →