Capítulo 32 — Operações de segurança e blue team: confiabilidade | Engenharia Operações de segurança e equipe azul

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 32 publicada. Mapa, exemplo, EX094.

flowchart TD
  N0["32.1 Metas de confiabilidade"]
  N1["32.2 Pontos únicos de falha"]
  N2["32.3 Redundância"]
  N3["32.4 Degradação controlada"]
  N4["32.5 Medindo a completude"]
  N5["32.6 Orçamentos de erro"]
  N6["32.7 Caso"]
  N7["Monitorando os monitores"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX094"]

Desenho lógico

flowchart LR
  N0["32.1 Metas de confiabilidade"]
  N1["32.2 Pontos únicos de falha"]
  N2["32.3 Redundância"]
  N3["32.4 Degradação controlada"]
  N4["32.5 Medindo a completude"]
  N5["32.6 Orçamentos de erro"]
  N6["32.7 Caso"]
  N7["Monitorando os monitores"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]

[32.1 Metas de confiabilidade]
    |
    v
[32.2 Pontos únicos de falha]
    |
    v
[32.3 Redundância]
    |
    v
[32.4 Degradação controlada]
    |
    v
[32.5 Medindo a completude]
    |
    v
[32.6 Orçamentos de erro]
    |
    v
[32.7 Caso]
    |
    v
[Monitorando os monitores]
    |
    v
[Exemplo resolvido] --> [Exercício EX094]

Objetivos de aprendizagem

Você vai (1) definir metas de confiabilidade para o pipeline de monitoramento; (2) identificar pontos únicos de falha; (3) projetar redundância e degradação controlada; (4) medir a disponibilidade e a completude dos dados.

32.1 Metas de confiabilidade

O pipeline tem como meta 99,5% de disponibilidade e 99,9% de completude das fontes prioritárias. A completude — a fração dos eventos esperados que chega — importa tanto quanto o tempo no ar, porque um pipeline funcionando com dados faltando ainda deixa o SOC às cegas. O tempo no ar sozinho engana: um pipeline pode estar rodando enquanto descarta em silêncio uma parte dos eventos. A completude mede o que de fato chega. Para fontes prioritárias, como os logs de autenticação, 99,9% significa no máximo um evento perdido em mil, o que mantém baixa a chance de perder o evento-chave de um ataque e ainda é alcançável com uma engenharia razoável.

32.2 Pontos únicos de falha

O pipeline da Lindqvist tem um coletor por local e uma única alimentação de logs do balanceador de carga. Se qualquer um falhar, uma fonte inteira desaparece. Um coletor por local significa que um defeito de hardware ali silencia todas as fontes daquele local até ser consertado. A alimentação única do balanceador de carga significa que a detecção de tomada de conta depende de um único caminho. Listar esses pontos é o primeiro passo; decidir quais eliminar depende do custo e das detecções que cada um sustenta. Amara lista os dois na análise de falhas, com as detecções que cada um sustenta, o que mostra que a alimentação carrega a detecção mais importante.

32.3 Redundância

Dois coletores por local, em modo ativo-passivo, e um segundo caminho de alimentação para os logs do balanceador eliminam os principais pontos únicos. A redundância custa dinheiro, então vai primeiro para onde o valor de detecção é maior. Ativo-passivo significa que um coletor trabalha enquanto o outro espera, assumindo se o primeiro falhar. Isso é mais simples do que dividir a carga entre os dois e evita eventos duplicados. Começar pelos locais e alimentações que sustentam as detecções mais importantes dá a maior proteção por unidade de orçamento, e as fontes de menor valor vêm depois, se o orçamento permitir.

32.4 Degradação controlada

Quando o SIEM está sobrecarregado, o pipeline deve descartar primeiro os logs de depuração de baixo valor, e não os logs de autenticação. Filas de prioridade implementam isso. Quando falta capacidade, algo precisa ser perdido; a pergunta é o quê. Os logs de depuração raramente são necessários para a detecção, enquanto os de autenticação são centrais. As filas de prioridade permitem ao pipeline descartar primeiro os eventos de baixa prioridade sob pressão. O descarte é registrado, para que o SOC saiba quais dados faltam naquele período. As prioridades são definidas por fonte na configuração do pipeline e revisadas quando novas fontes entram.

32.5 Medindo a completude

Comparar os eventos contados nas fontes com os eventos armazenados no SIEM mostra a perda. Um relatório diário de reconciliação lista as fontes abaixo de 99,9%. As fontes podem informar quantos eventos enviaram, e o SIEM sabe quantos armazenou; a diferença é a perda no caminho. Onde as fontes não conseguem informar contagens, os coletores podem contar o que receberam. O relatório diário lista a razão de cada fonte, e qualquer uma abaixo da meta é investigada pelo responsável pela fonte. O relatório vai aos responsáveis pelas fontes toda manhã e é resumido semanalmente para Paolo.

32.6 Orçamentos de erro

Se a disponibilidade cair abaixo da meta, os novos recursos ficam em pausa e o trabalho de confiabilidade tem prioridade até que o orçamento se recupere. Uma meta de 99,5% deixa 0,5% do tempo como margem para indisponibilidade. Isso dá uma regra clara e acordada de antemão para equilibrar trabalho novo e estabilidade, em vez de uma nova discussão cada vez que algo quebra. O orçamento é reiniciado a cada trimestre; com 99,5%, a margem é de cerca de onze horas por trimestre. Os gerentes de produto e os líderes do SOC acordam essa regra de antemão, para que pausar o trabalho em recursos quando o orçamento se esgota seja rotina, e não uma disputa.

32.7 Caso

Na primeira semana de reconciliação, os servidores web do portal mostram 99,95% de completude; o firewall dos depósitos mostra 97,8%, por causa de um caminho de syslog sobre UDP que descarta pacotes sob carga. O syslog sobre UDP envia mensagens sem confirmação, então os pacotes descartados sob carga simplesmente se perdem. Uma perda de 2,2% significa que cerca de uma negação em quarenta e cinco nunca chega ao SIEM. Mudar o firewall dos depósitos para TCP ou para um agente de encaminhamento com confirmação e buffer resolveria o problema, e o relatório de reconciliação vai mostrar se a completude sobe acima da meta.

Monitorando os monitores

Coletores, analisadores e o próprio SIEM informam métricas de saúde — profundidade das filas, erros de análise, atraso de ingestão — a um sistema de monitoramento separado. Se o SIEM não está saudável, não se pode confiar nele para alertar sobre a própria falha, então os alertas de saúde seguem por um caminho independente até o engenheiro de plantão.

Exemplo resolvido

Amara passa o firewall dos depósitos para o encaminhamento de logs sobre TCP, com um buffer local. A completude sobe para 99,96%. Ela acrescenta a mudança ao registro de confiabilidade e mantém o relatório de reconciliação rodando diariamente.

Caso sintético. Os números são inventados.

Erros e limites

As verificações de completude dependem de contagens exatas nas fontes, que alguns dispositivos não fornecem.

Exercícios

EX094 — Completude. Por que a completude é tão importante quanto a disponibilidade?
Mostrar critérios de avaliação
Rubrica: 3 = o pipeline pode rodar com dados faltando e ainda deixar o SOC às cegas; 2 = parcial; 1 = menos importante; 0 = nada.
EX095 — Ordem de degradação. Sob sobrecarga, que logs devem ser descartados primeiro?
Mostrar critérios de avaliação
Rubrica: 3 = depuração de baixo valor antes de autenticação; filas de prioridade; 2 = parcial; 1 = aleatório; 0 = nada.
EX096 — Correção do firewall. O que causou os 97,8% de completude, e o que os corrigiu?
Mostrar critérios de avaliação
Rubrica: 3 = descartes do syslog sobre UDP; encaminhamento TCP com buffer; 99,96%; 2 = parcial; 1 = ignorado; 0 = nada.

Síntese

Um monitoramento confiável precisa de metas tanto para o tempo no ar quanto para a completude, de redundância onde o valor é maior e de degradação controlada.

Continue estudando — capítulo 32 de 50

← Capítulo 31 (rascunho) · Índice de capítulos do curso · Capítulo 33 (rascunho) →