O SOC de um fornecedor fintech operava três plataformas de SIEM em seu ambiente de nuvem híbrida: Microsoft Sentinel para as cargas de trabalho no Azure, Splunk para a infraestrutura on-premise e uma agregação no AWS Security Hub para as cargas de trabalho nativas em nuvem. O número total de regras nas três plataformas passava de quatrocentas regras de correlação e políticas de detecção. A equipe de engenharia de detecção era formada por dois analistas seniores que mantinham as quatro plataformas além de suas atribuições regulares no SOC. As quatrocentas regras haviam sido acumuladas ao longo de seis anos: algumas escritas pela equipe original do SOC para achados de incidentes específicos, a maioria herdada de templates dos fornecedores das plataformas e de integrações de feeds de inteligência de ameaças. As regras personalizadas específicas do cenário de ameaças do setor fintech (manipulação de transações, abuso de API para fraude financeira, credential stuffing contra endpoints de processamento de pagamentos) eram menos de vinte. As trezentas e oitenta restantes eram regras genéricas aplicáveis a qualquer organização. Quando um grupo de ameaça sofisticado e com motivação financeira, que mirava especificamente a infraestrutura fintech, começou a sondar o ambiente do fornecedor, usou técnicas projetadas especificamente para se misturar às operações fintech normais: padrões de chamadas de API compatíveis com o processamento legítimo de pagamentos em alto volume, sequências de autenticação que imitavam fluxos automatizados de conciliação e padrões de acesso a dados indistinguíveis do processamento em lote padrão de fim de dia. As regras de detecção genéricas não geraram nenhum alerta. As vinte regras específicas do setor fintech estavam ajustadas para padrões de ataque mais antigos que a equipe já havia observado. As técnicas do agente de ameaça eram novas.
O que são, de fato, lacunas de engenharia de detecção?
Engenharia de detecção é a disciplina de projetar, criar, testar e manter a lógica de detecção (regras de correlação, análises comportamentais e políticas de detecção de anomalias) que permite a um SIEM e a um SOC identificar atividades maliciosas em um ambiente específico. Lacunas de engenharia de detecção são as deficiências na cobertura da lógica de detecção: regras que não foram escritas para técnicas de ataque específicas, regras herdadas de templates genéricos sem personalização, regras que perderam relevância à medida que o ambiente e o cenário de ameaças evoluíram e regras que nunca são testadas para confirmar que ainda disparam como projetado.
O problema da herança dos padrões da plataforma é a lacuna de engenharia de detecção mais difundida. As plataformas de SIEM vêm com conjuntos de regras padrão: centenas de regras de correlação e políticas de detecção derivadas de inteligência de ameaças geral e de padrões de ataque comuns. Esses padrões oferecem cobertura de detecção imediata, prontos para uso, e são valiosos para capturar ameaças comuns. Eles não foram projetados para os padrões de ataque específicos relevantes para um determinado setor, stack tecnológico ou perfil de agente de ameaça. Organizações que dependem principalmente dos padrões herdados, sem desenvolver lógica de detecção específica do setor e do ambiente, têm uma cobertura de detecção calibrada para o cenário médio de ameaças, e não para o seu cenário real de ameaças.
O problema da degradação das regras agrava a lacuna da herança de padrões. As regras de detecção perdem relevância ao longo do tempo à medida que o ambiente muda, as técnicas de ataque evoluem e os ajustes feitos para reduzir falsos positivos estreitam involuntariamente o escopo de detecção da regra. Uma regra escrita há cinco anos para detectar um padrão de ataque específico pode ter sido estreitada progressivamente por ajustes até disparar apenas em circunstâncias que correspondem exatamente ao incidente original que a motivou, deixando passar o padrão mais amplo que a regra deveria capturar. Programas de engenharia de detecção que revisam e atualizam as regras regularmente mantêm a relevância da detecção. Programas que principalmente adicionam novas regras sem desativar ou renovar as antigas acumulam dívida de detecção.
- Regras padrão da plataforma sem personalização para o setor: cobertura genérica para o cenário médio de ameaças
- Equipe de engenharia de detecção de duas pessoas mantendo quatrocentas regras em várias plataformas
- Degradação das regras: ajustes que reduzem o escopo de detecção ao longo do tempo
- Técnicas específicas do setor não cobertas: o agente de ameaça usa métodos específicos do setor
- Nenhuma cadência de testes das regras: regras não verificadas quanto a ainda dispararem como projetado
Por que isso importa
As lacunas de engenharia de detecção são importantes para TPRM porque a capacidade de detecção do SOC é tão boa quanto as regras que foram criadas e mantidas. Um fornecedor com uma plataforma de SIEM madura e uma implantação abrangente de regras padrão tem a infraestrutura para uma detecção eficaz. Se essa infraestrutura é de fato eficaz contra as ameaças específicas relevantes para os dados do cliente depende de o programa de engenharia de detecção ter criado e mantido regras para essas ameaças específicas. A maturidade da plataforma e a maturidade da engenharia de detecção são dimensões diferentes da mesma capacidade do SOC.
A dimensão da cadeia de suprimentos é especialmente relevante para ameaças específicas do setor. Clientes fintech que compartilham dados com fornecedores fintech enfrentam o mesmo cenário de ameaças específico do setor. Clientes da área da saúde que dependem de fornecedores de tecnologia para a saúde estão expostos aos mesmos agentes de ameaça que miram dados de saúde. Um fornecedor cujo programa de engenharia de detecção cobre padrões de ataque genéricos, mas não tem lógica de detecção específica do setor, é um fornecedor cujo SOC deixará passar as técnicas específicas usadas pelos agentes de ameaça com maior probabilidade de mirar os dados do cliente por meio da relação com o fornecedor.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar o número de regras como indicador da qualidade da engenharia de detecção. O número de regras mede volume. A qualidade da engenharia de detecção mede relevância, manutenção e cadência de testes.
- Número de regras aceito como indicador de cobertura
- Dependência dos padrões da plataforma não avaliada: proporção entre regras personalizadas e herdadas não solicitada
- Capacidade da equipe de engenharia de detecção não avaliada em relação à carga de manutenção das regras
- Cobertura de regras específicas do setor não verificada
- Cadência de testes das regras não perguntada: quando as regras foram validadas pela última vez
Como é uma boa prática
Programas maduros de engenharia de detecção mantêm um inventário de regras que distingue os padrões da plataforma das regras personalizadas, testam regularmente as regras para confirmar que disparam como projetado e priorizam a criação e a manutenção de regras para os agentes de ameaça e as técnicas mais relevantes para o setor e o perfil de ameaças da organização.
- Proporção de regras personalizadas: que parcela das regras é específica do ambiente versus padrões herdados
- Detecção específica do setor: regras escritas para técnicas de ataque específicas do setor
- Testes regulares das regras: regras validadas para disparar diante de padrões de ataque relevantes
- Gestão da dívida de detecção: regras obsoletas desativadas, regras degradadas renovadas
- Roadmap de engenharia de detecção: lacunas conhecidas e cronograma para melhorar a cobertura
Ferramentas
Plataformas de SIEM: Microsoft Sentinel, Splunk, Elastic SIEM com desenvolvimento de regras personalizadas
As plataformas de SIEM oferecem a infraestrutura para o desenvolvimento de regras de detecção personalizadas. Para profissionais de TPRM, perguntar que parcela das regras do fornecedor é escrita sob medida versus padrões da plataforma fornece o indicador de engajamento em engenharia de detecção que o número total de regras não fornece.
Inteligência de ameaças: MITRE ATT&CK, ISACs do setor
A inteligência de ameaças específica do setor, proveniente dos ISACs, e os mapeamentos de técnicas do ATT&CK para grupos de ameaça conhecidos fornecem o material de base para regras de engenharia de detecção calibradas para o cenário específico de ameaças. Para profissionais de TPRM, perguntar se as regras de detecção do fornecedor estão mapeadas para as técnicas do ATT&CK mais associadas aos agentes de ameaça do seu setor é uma pergunta específica sobre relevância.
Desafios de governança
O desafio de governança da engenharia de detecção é a capacidade. Criar e manter regras de detecção de alta qualidade, testadas e específicas do setor exige um tempo significativo dos analistas, que concorre com as operações diárias do SOC. A solução de governança é dedicar capacidade específica à engenharia de detecção, separando o trabalho de desenvolvimento de detecções do trabalho de triagem de alertas, e usar SOAR e testes automatizados para reduzir a carga contínua de manutenção.
- Solicite a proporção entre regras personalizadas e padrão: que parcela é específica do ambiente
- Solicite o número de regras específicas do setor: quantas regras tratam de técnicas específicas do setor
- Solicite a cadência de testes das regras: com que frequência as regras são validadas
- Solicite a última revisão de cobertura do ATT&CK para os agentes de ameaça relevantes para o setor
- Solicite a capacidade dedicada da equipe de engenharia de detecção
Se você faz parte de uma equipe pequena
Faça três perguntas sobre engenharia de detecção ao seu fornecedor de maior risco. Primeira: que percentual das suas regras de detecção é escrito sob medida para o seu ambiente específico versus herdado dos padrões da plataforma? Segunda: vocês têm regras de detecção escritas especificamente para as técnicas de ataque usadas por agentes de ameaça conhecidos por mirar o seu setor? Terceira: quando suas regras de detecção foram testadas pela última vez para confirmar que disparam diante dos padrões que foram projetadas para detectar? Essas três perguntas revelam se as quatrocentas regras são personalizadas e testadas ou herdadas e não verificadas.
- Pergunte a proporção entre regras personalizadas e padrão
- Solicite a cobertura de técnicas de ataque específicas do setor
- Pergunte quando as regras foram testadas pela última vez para confirmar que disparam
- Solicite a cobertura do ATT&CK para os grupos de ameaça relevantes para o setor
O que exigir
Pergunte diretamente:
“Que percentual das suas regras de detecção do SIEM é escrito sob medida para o seu ambiente versus herdado dos padrões da plataforma? E vocês têm regras específicas para as técnicas de ataque usadas por grupos de ameaça conhecidos por mirar o seu setor?”
O que esperar como evidência
- Proporção entre regras personalizadas e padrão
- Número de regras específicas do setor e cobertura de técnicas
- Cadência de testes das regras e data do último teste
- Mapa de cobertura do ATT&CK para os agentes de ameaça do setor
Um fornecedor com quatrocentas regras de detecção deve ser questionado sobre quantas dessas regras foram criadas sob medida para o seu cenário específico de ameaças. Quatrocentas regras padrão e quatrocentas regras personalizadas representam investimentos em engenharia de detecção muito diferentes.
Como comprovar
- Documentação da proporção de regras personalizadas
- Registros da cobertura de detecção específica do setor
- Registros da cadência de testes das regras
- Avaliação da cobertura do ATT&CK
Principal conclusão
Quatrocentas regras. Trezentas e oitenta regras padrão da plataforma. Vinte regras personalizadas para padrões antigos do setor. O agente de ameaça usou técnicas atuais específicas do setor fintech. Zero alertas. A infraestrutura de SIEM era madura. O programa de engenharia de detecção não havia criado as regras para usá-la contra a ameaça específica. O número de regras descreve o investimento em infraestrutura de detecção. A proporção de regras personalizadas e a cobertura de técnicas específicas do setor descrevem se essa infraestrutura foi preparada para detectar as ameaças reais. Os padrões cobrem a média. As regras personalizadas cobrem o específico. O específico é o que importa.