Capítulo 36 — Operações de segurança e blue team: desempenho e escala
Mapa da aula
Aula 36 publicada. Mapa, exemplo, EX106.
flowchart TD
N0["36.1 Eventos por segundo"]
N1["Laboratório — dimensionando o pipeline"]
N2["36.2 Lendo o resultado"]
N3["36.3 Picos"]
N4["36.4 Reduzindo o volume"]
N5["36.5 Desempenho das consultas"]
N6["36.6 Testes de escala"]
N7["Visibilidade de custos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX106"]
Desenho lógico
flowchart LR
N0["36.1 Eventos por segundo"]
N1["Laboratório — dimensionando o pipeline"]
N2["36.2 Lendo o resultado"]
N3["36.3 Picos"]
N4["36.4 Reduzindo o volume"]
N5["36.5 Desempenho das consultas"]
N6["36.6 Testes de escala"]
N7["Visibilidade de custos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX106"]
[36.1 Eventos por segundo]
|
v
[Laboratório — dimensionando o pipeline]
|
v
[36.2 Lendo o resultado]
|
v
[36.3 Picos]
|
v
[36.4 Reduzindo o volume]
|
v
[36.5 Desempenho das consultas]
|
v
[36.6 Testes de escala]
|
v
[Visibilidade de custos]
|
v
[Exemplo resolvido] --> [Exercício EX106]
Objetivos de aprendizagem
Você vai (1) dimensionar a ingestão e o armazenamento do SIEM a partir das taxas das fontes; (2) planejar para os picos; (3) medir o desempenho das consultas; (4) decidir o que filtrar, resumir ou mover de camada.
36.1 Eventos por segundo
A ingestão é medida em eventos por segundo (EPS). Somar as fontes dá a média; os picos durante incidentes ou no horário comercial podem ser várias vezes maiores. O EPS médio define a base para armazenamento e licenciamento; o EPS de pico define o tamanho dos coletores e do processamento. Um sistema dimensionado só para a média vai atrasar ou descartar eventos justamente quando a atividade dispara, muitas vezes durante um incidente. Os engenheiros medem o EPS por fonte ao longo de várias semanas para ver padrões diários, semanais e sazonais. Amara registra os resultados por fonte em uma tabela.
Laboratório — dimensionando o pipeline
"""Events-per-second and storage sizing for a SIEM (synthetic sources)."""
sources = {"portal_web": 900, "windows_events": 1400, "firewall": 2600, "dns": 1100} # average EPS
bytes_per_event = 550
peak_factor = 2.5
eps = sum(sources.values())
gb_day = eps * bytes_per_event * 86400 / 1e9
print(f"average EPS={eps} peak EPS={eps*peak_factor:.0f}")
print(f"raw GB/day={gb_day:.1f} 90-day hot TB={gb_day*90/1000:.1f}")
Execute com python3 lab_capacity.py. Saída verificada:
average EPS=6000 peak EPS=15000
raw GB/day=285.1 90-day hot TB=25.7
36.2 Lendo o resultado
Quatro fontes dão 6.000 EPS em média e 15.000 em um pico de 2,5×. A 550 bytes por evento, o volume bruto é de 285,1 GB por dia, e 90 dias na camada quente exigiriam 25,7 TB — muito acima da camada de 12 TB, o que confirma a necessidade da divisão em camadas decidida no capítulo 26. A aritmética: 6.000 eventos por segundo vezes 86.400 segundos vezes 550 bytes dá cerca de 285 GB por dia. Noventa dias disso ficam muito além da camada quente. A taxa de pico importa para o processamento, mas não para o armazenamento, já que o armazenamento segue o total diário. A comparação torna a divisão em camadas uma necessidade, e não uma opção.
36.3 Picos
Os pipelines precisam suportar os picos sem descartar dados prioritários. Os buffers absorvem picos curtos; picos prolongados exigem capacidade ou degradação controlada. Um buffer funciona como um reservatório: enche durante o pico e esvazia quando a taxa cai. Se um pico dura mais do que o buffer comporta, os eventos precisam ser descartados ou processados mais devagar. A degradação controlada decide quais eventos saem primeiro, mantendo intactos os de autenticação e de outras fontes prioritárias. Os tamanhos dos buffers são definidos a partir dos picos mais longos medidos em cada fonte no último ano, com uma margem, e a margem é conferida de novo sempre que entra uma fonte nova importante.
36.4 Reduzindo o volume
Opções: filtrar eventos sem valor para detecção ou investigação, resumir fontes de alto volume (por exemplo, fluxos de firewall em agregados por hora) e dividir o armazenamento em camadas. Cada redução é conferida contra as necessidades de detecção e de investigação antes de ser aplicada. Filtrar remove eventos por completo, então exige o máximo de cuidado: algo que parece inútil agora pode importar numa investigação futura. Resumir mantém o padrão, mas perde detalhes, como os fluxos individuais. A divisão em camadas mantém tudo, mas move os dados mais antigos para um armazenamento mais barato. Cada escolha é registrada com o motivo e as verificações feitas.
36.5 Desempenho das consultas
Regras que varrem longos intervalos de tempo ou campos não indexados deixam tudo lento. Os engenheiros medem o tempo de execução das regras e reescrevem as mais lentas. Uma regra que pesquisa trinta dias de logs de firewall a cada cinco minutos repete um trabalho enorme e disputa recursos com as buscas dos analistas. Os engenheiros listam as regras por tempo de execução e uso de recursos e então reescrevem as piores, por exemplo estreitando o intervalo de tempo ou usando campos indexados. A melhoria é medida antes e depois. Um relatório de tempos de execução sai toda semana e nomeia as cinco regras mais lentas.
36.6 Testes de escala
Antes da alta temporada, a equipe reproduz um dia de logs sintéticos em velocidade 3× no SIEM de teste para verificar se as regras acompanham. Reproduzir a três vezes a velocidade normal simula um pico pesado sem esperar que ele aconteça. O teste observa os atrasos das regras, o tamanho das filas e os eventos descartados. Se as regras ficam para trás, a equipe acrescenta capacidade ou otimiza as consultas antes da temporada movimentada, e não durante ela. Os resultados são comparados com o teste do ano anterior. O dia sintético inclui uma rajada simulada de incidente, para que o teste reflita a carga irregular de um dia movimentado real.
Visibilidade de custos
Amara publica o custo mensal por fonte, para que os responsáveis vejam quanto custam os seus logs. Equipes que enviam logs de depuração verbosos muitas vezes os reduzem ao ver a conta, sem nenhum pedido do SOC.
Exemplo resolvido
Com esse volume, a divisão em camadas anterior, 90 dias no SIEM com firewall e DNS indo para o lake depois de 14 dias, já não cabe, então Amara a aperta: o plano dela mantém os eventos do portal, do Windows e de DNS na camada quente por 30 dias e move os eventos de firewall para o lake depois de 7 dias, mantendo na camada quente os resumos por hora. O armazenamento quente cai para cerca de 10 TB. Antes de aplicar, ela verifica que nenhuma detecção usa eventos brutos de firewall com mais de 7 dias.
Caso sintético. As taxas e os tamanhos vêm do script do laboratório.
Erros e limites
Os bytes por evento variam por fonte; meça cada fonte em vez de usar uma média única.
Exercícios
- EX106 — Resultado do dimensionamento. Informe o EPS médio, o EPS de pico, os GB/dia e os TB quentes para 90 dias. Rubrica: 3 = 6.000; 15.000; 285,1; 25,7; 2 = três; 1 = um; 0 = nada.
- EX107 — Redução de volume. Cite três formas de reduzir o volume armazenado. Rubrica: 3 = filtrar, resumir, dividir em camadas; 2 = duas; 1 = uma; 0 = nada.
- EX108 — Verificação de segurança. O que Amara verificou antes de mover de camada os eventos de firewall? Rubrica: 3 = nenhuma detecção usa eventos brutos de firewall com mais de 7 dias; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Dimensione a partir de taxas medidas, planeje para os picos e reduza o volume só depois de conferir as necessidades de detecção e de investigação.
Continue estudando — capítulo 36 de 50
← Capítulo 35 (rascunho) · Índice de capítulos do curso · Capítulo 37 (plano; texto em tradução) →
Resoluções
Respostas-modelo para EX001–EX108 (as de EX109–EX150 estão na edição em inglês até a tradução dos capítulos correspondentes). Amara Osei, Paolo Ricci, a Kingsbridge Engineering University, a Lindqvist Freight e todos os números são sintéticos. As respostas dos laboratórios citam saídas verificadas. Qualquer resposta que atenda à rubrica recebe a mesma pontuação.
EX001. O acúmulo varia segundo dB/dt = A(t) − C(t): chegadas por hora menos alertas resolvidos por hora.
EX002. Atinge o pico de 65 alertas às 13:00, porque as chegadas ficaram acima da capacidade de 60 das 10:00 às 12:00 e só se igualaram a ela às 13:00.
EX003. Cerca de 40 minutos: há 40 alertas à frente dele, e o turno resolve 60 por hora.
EX004. Contém as contas que falharam e depois tiveram sucesso a partir da rede atacante, as mais propensas a terem sido adivinhadas corretamente.
EX005. 7 × 6 × 5 = 210, portanto as regras não conseguem cobrir todas as combinações e precisam ser escolhidas com base no conhecimento de ameaças.
EX006. Exige pelo menos um sucesso no mesmo conjunto, transformando um alerta genérico de spraying num alerta específico de possível comprometimento.
EX007. É dobrada num único registro de 5 minutos, de modo que a rajada fica visível, mas seu ritmo e sua forma se perdem.
EX008. Pode colocar os eventos daquele servidor na ordem errada em relação aos de outros, e é por isso que as orientações de gestão de logs enfatizam a sincronização de tempo.
EX009. Mais dados exigem mais servidores, energia, refrigeração e espaço de armazenamento, todos fisicamente limitados e caros.
EX010. Deve pulá-las com segurança e registrar quantas foram puladas, para que a perda de dados fique visível.
EX011. Como a resposta correta é conhecida de antemão, qualquer diferença revela um defeito no código, e não algo nos dados.
EX012. Evita instalar pacotes de terceiros não revisados em máquinas sensíveis e já está disponível em qualquer lugar onde o Python esteja.
EX013. O que foi observado, quando (com fuso horário), quais ativos, o que foi feito e o que continua desconhecido.
EX014. Para que todo leitor entenda o mesmo grau de certeza a partir da mesma palavra.
EX015. Dá horário, escala, impacto, ações tomadas e uma mudança proposta, sem o detalhe campo a campo de que os analistas precisam.
EX016. O armazenamento é a integral da taxa de ingestão ao longo da janela de retenção; hoje, 120 GB × 90 dias = 10,8 TB.
EX017. Cerca de 15,4 TB, já que a ingestão diária chega a aproximadamente 171 GB, o que excede a camada de 12 TB.
EX018. A política e a lei definem a retenção mínima; a matemática estima o custo e orienta as camadas dentro desses limites.
EX019. A taxa de verdadeiros positivos é a chance de um alerta quando um ataque acontece; a precisão é a chance de um alerta ser um ataque real.
EX020. 0,153, ou seja, cerca de um alerta em sete é real: aproximadamente 180 verdadeiros contra 998 falsos a cada 100.000 rajadas.
EX021. Porque os alarmes falsos dominam com essa taxa-base baixa, reduzi-los à metade eleva a precisão para cerca de 0,27, muito mais do que um pequeno ganho de sensibilidade.
EX022. Componentes no kernel veem com confiabilidade a atividade de processos e arquivos, mas um defeito ali pode derrubar a máquina inteira.
EX023. O buffer do agente encheu enquanto o enlace estava saturado pela rajada, então os eventos mais antigos foram descartados.
EX024. Equilibram a visibilidade contra o custo de CPU e memória e testam as configurações em máquinas parecidas com as de produção.
EX025. Um dicionário, porque cada nome de usuário aponta diretamente para sua contagem, com buscas e atualizações rápidas.
EX026. O código usava "maior que", enquanto o projeto queria "pelo menos"; os dois foram alinhados em ≥ 5 e o teste foi mantido.
EX027. Mantém pequeno o uso de memória, enquanto carregar milhões de linhas de uma vez pode esgotá-la.
EX028. Monitorar apenas o que a finalidade de segurança exige e acessar conteúdo, como o corpo de e-mails, somente com aprovação por caso.
EX029. Não havia investigação autorizada, então ela remeteu o gestor à política e ao processo de RH.
EX030. A faixa também atendia um parceiro logístico, então um bloqueio temporário com revisão em 24 horas evitou interromper tráfego legítimo.
EX031. Os atacantes espalham as tentativas por muitos endereços nas mesmas redes, então agrupar revela rajadas que as contagens por endereço escondem.
EX032. 203.0.113.0/24, porque suas seis falhas atingiram seis nomes de usuário diferentes, uma tentativa cada, e sete nomes de usuário aparecem ali ao todo.
EX033. Requisitou uma alteração de endereço às 10:07, o que sugere que a conta foi tomada.
EX034. Porque a configuração de auditoria de que a regra depende, como o registro da linha de comando dos processos, não está ativada ali.
EX035. Concedem mais privilégio, que é o que os atacantes buscam, então as mudanças merecem atenção.
EX036. O modelo do servidor foi atualizado por meio de uma mudança, e um processo de teste inofensivo confirmou que as linhas de comando passaram a ser registradas.
EX037. Para que toda regra e toda consulta usem um único nome para cada conceito, em vez de lembrar as variantes de cada fonte.
EX038. O portal guardava texto em hora local, enquanto os logs internos usavam UTC; converter os horários do portal na ingestão consertou a junção.
EX039. Os campos que as detecções e os analistas mais consultam, como usuário, host e endereço de origem.
EX040. A regra registra as correspondências sem alertar, para que seu ruído possa ser medido antes de os analistas serem acionados.
EX041. Com uma exceção estreita, que usa o user agent assinado da ferramenta de carga e uma verificação de calendário.
EX042. Uma descrição, o autor, referências, gatilhos benignos conhecidos e orientação de resposta.
EX043. Dados de clientes podiam ser vistos, um endereço foi alterado e o serviço de login ficou lento sob a rajada.
EX044. Clientes que reutilizam senhas; a limitação de taxa e a autenticação multifator reduzem o risco.
EX045. Entrega principalmente Detect e Respond, apoiando-se em Identify para o conhecimento dos ativos e informando Govern.
EX046. Gastar muito em ferramentas e negligenciar pessoas e processos.
EX047. Logs do portal entregues em até 2 minutos, latência da regra abaixo de 5 minutos e reconhecimento pelo analista em até 8 minutos.
EX048. A rajada foi reconhecida 11,5 minutos depois da injeção, dentro da meta, e o reconhecimento pelo analista foi a etapa mais lenta.
EX049. Ajustes grandes ou rápidos demais passam do ponto; passos pequenos, com tempo para observar os efeitos, evitam isso.
EX050. Uma fila sobrecarregada leva os analistas a fechar alertas às pressas, o que esconde perdas e permite mais comprometimento, acrescentando ainda mais carga.
EX051. No máximo um passo de limiar a cada quinze dias e nenhuma elevação depois de qualquer evento de teste perdido; a regra se estabilizou em 6 falhas, com 8 alertas falsos por dia e todos os eventos de teste pegos.
EX052. Porque o tráfego legítimo que atravessa uma fronteira é limitado e bem conhecido, as travessias incomuns se destacam.
EX053. Os logs do balanceador de carga não eram encaminhados; foram acrescentados, e os logs web agora registram um cabeçalho com o endereço do cliente que o balanceador sobrescreve, para que os clientes não possam forjá-lo.
EX054. Ficam numa zona separada, com contas de administrador dedicadas e protegidas por autenticação multifator.
EX055. Porque muitos ataques usam credenciais roubadas, mas válidas, que só os logs de identidade revelam.
EX056. Pedidos de MFA repetidos que o usuário nega e uma troca inesperada do dispositivo de MFA registrado.
EX057. Acrescentou uma confirmação por e-mail ao cliente e manteve um alerta ao analista apenas quando a confirmação falhava.
EX058. As prioridades de engenharia seguem o que a empresa precisa proteger — dados de clientes, entregas, pagamentos —, e não o que as ferramentas conseguem fazer.
EX059. Seu software antigo não consegue rodar agentes de endpoint, então o monitoramento de rede é a única opção.
EX060. Com apenas dois analistas à noite, cada alerta encaminhado a eles precisa valer o tempo limitado que têm.
EX061. Funcional: correlacionar falhas e sucessos por rede; não funcional: latência do alerta abaixo de 5 minutos.
EX062. "Os alertas devem ser gerados em até 5 minutos após o evento que os aciona, medidos por eventos sintéticos cronometrados mensais."
EX063. O requisito, sua fonte, o elemento de projeto que o atende e o teste que o verifica.
EX064. Coleta, transporte, análise e normalização, enriquecimento, armazenamento, detecção, alerta e gestão de casos.
EX065. O inventário de ativos não continha os dispositivos dos depósitos, então não havia com o que enriquecer.
EX066. Cada célula vazia virou um item do backlog com um responsável nomeado.
EX067. As fontes de dados de que precisa, as detecções existentes e a confiança nelas.
EX068. Porque nada as sinaliza, a cobertura de detecção desaparece sem que ninguém perceba.
EX069. A detecção de tomada de conta depende dessa única alimentação, que já quebrou antes.
EX070. Limiar 5 com sucesso: 2, 0, 1; limiar 6 com sucesso: 1, 0, 2; limiar 5 sem sucesso: 3, 2, 0.
EX071. Uma detecta tentativas, para o trabalho diurno de ajuste; a outra detecta comprometimento provável e aciona o turno da noite.
EX072. O ataque das 10:10 não tinha tido sucesso, então não havia comprometimento para acionar o plantão; a regra de tentativas ainda o registra.
EX073. Monitoramento de fluxos na fronteira, um sensor de detecção de rede e regras de firewall mais estritas com registro das conexões negadas.
EX074. Descobriram que o firewall da fronteira já registrava os fluxos, então os logs do firewall com regras de permissão superaram a compra de um sensor.
EX075. Permitir cinco serviços, registrar as negações, alertar quando um dispositivo de depósito tentar um destino novo mais de três vezes numa hora, revisar semanalmente; o risco principal é a falha da alimentação de logs.
EX076. Os dados recentes de alto valor ficam no SIEM para busca rápida, enquanto os dados volumosos e mais antigos vão para um lake mais barato.
EX077. Acrescenta cobertura noturna e um conhecimento de ameaças mais amplo, mas conhece menos o contexto local e depende de acordos de escalonamento claros.
EX078. Contexto, opções consideradas, a decisão e suas consequências.
EX079. Detecção: a regra de possível tomada de conta; resposta: bloquear a conta e invalidar suas sessões.
EX080. Um teto de 20 contas por hora, acima do qual a automação pausa e aciona o engenheiro de plantão.
EX081. Porque bloquear uma faixa pode cortar clientes ou parceiros legítimos, o que exige julgamento humano.
EX082. Um SIEM de teste com dados sintéticos reproduzidos, depois a produção em modo só monitoramento e depois o alerta completo.
EX083. Um campo extra vindo de uma atualização do balanceador; o analisador foi ampliado e as linhas foram mantidas como casos de teste.
EX084. Torna cada mudança revisável, reversível e consistente entre os ambientes.
EX085. Média de 10,2 minutos, mediana de 7 minutos, percentil 90 de 16,4 minutos.
EX086. Os tempos são assimétricos; um caso longo infla a média, enquanto a mediana mostra o caso típico e o percentil 90, a cauda que ameaça a meta.
EX087. Combiná-la com medidas de qualidade, como a revisão regular de uma amostra de alertas fechados.
EX088. A verificação confere se a regra corresponde à sua especificação; a validação confere se ela de fato ajuda a detectar ameaças reais em operação.
EX089. Que a regra dispara com 5 usuários e um sucesso, fica em silêncio com 4, exige um sucesso mesmo com 9 usuários e fica em silêncio sem atividade.
EX090. O alerta não trazia o ID do cliente porque o modelo de roteamento usava um nome de campo antigo.
EX091. Para descobrir problemas, como a dependência da impressora, antes que afetem os quarenta depósitos.
EX092. O serviço de impressão foi permitido com um motivo documentado, e os outros depósitos foram conferidos em busca das mesmas impressoras antes do grupo seguinte.
EX093. O laptop de um prestador numa rede de depósito; a TI então impôs o controle de acesso à rede para dispositivos visitantes.
EX094. Porque um pipeline pode estar no ar enquanto perde eventos em silêncio, deixando o SOC às cegas.
EX095. Os logs de depuração de baixo valor devem ser descartados antes dos de autenticação e de outros logs prioritários, usando filas de prioridade.
EX096. O syslog sobre UDP descartava pacotes sob carga; mudar para o encaminhamento TCP com um buffer local elevou a completude para 99,96%.
EX097. Porque isolá-los pode parar operações do negócio, como o despacho, então é preciso aprovação antes.
EX098. Consultar diretamente as fontes críticas com contas somente leitura, seguindo os runbooks, e registrar as ações offline.
EX099. Contas de acesso direto expiradas, runbooks que citavam servidores desativados e nenhum responsável nomeado pela decisão noturna de isolar o despacho.
EX100. Para que uma "alta" do SOC vire, de forma confiável, um P2 da TI com resposta conhecida em quatro horas.
EX101. Ela só pode aplicar bloqueios e invalidar sessões, e toda chamada que faz é registrada.
EX102. Uma mudança de firewall tinha bloqueado a entrega ao atendimento ao cliente; o caminho de falha alertou o plantão, que corrigiu antes de um novo teste passar.
EX103. Cinco regras produziam 55% dos alertas noturnos, e três nunca tinham levado a um incidente.
EX104. Com uma janela dedicada de revisão matinal de 30 minutos e um limite para essa fila.
EX105. Acionar só para ativos críticos ignoraria os 60% dos sistemas que o inventário não tinha classificado.
EX106. 6.000 EPS em média, 15.000 no pico, 285,1 GB por dia e 25,7 TB para 90 dias na camada quente.
EX107. Filtrar eventos sem valor, resumir fontes de alto volume e mover os dados mais antigos para um armazenamento mais barato.
EX108. Que nenhuma regra de detecção dependia de eventos brutos de firewall com mais de sete dias.