Traduzido do 日本語 • Ver original 
"Há alertas demais, ninguém está mais olhando para eles"
"Recebo mais de 100 notificações todos os dias, mas quase todas são falsos positivos."
"Eu coloquei o Sentinela lá, mas percebi o incidente manualmente."
SIEM não é um "coloca e pronto".
A qualidade do projeto operacional pode ser tanto um "SIEM utilizável" quanto um "dispositivo ruidoso".
1. Por que Sentinel é "barulhento"
Se você ativar todas as regras padrão do Sentinel, receberá centenas de alertas por dia, dependendo do seu ambiente.
Existem três causas principais.
- Limiar de regra muito baixo: acionado até mesmo por operações normais
- Contexto não é considerado: regras que ignoram as características do sistema empresarial
- Notificar não projetado: Todos os alertas voam para todos
Se isso continuar, os representantes vão cair em "Fadiga de Alerta" e ignorar notificações realmente perigosas.
2. Três abordagens para melhorar a qualidade das regras
(1) Categorizar Prioridade de Regras
A premissa principal é que nem todas as regras são tratadas com o mesmo peso.
Regras de Análise no Sentinel podem ser configuradas com Severidade.
- Alta: Resposta imediata necessária (tomada de controle de conta, ransomware, etc.)
- Médio: Verifique durante o horário comercial (localização de login anormal, etc.)
- Baixo/Informativo: Avaliações semanais são suficientes
Basta notificar que o Alto em Chamados e o Baixo apenas se acumulam no Log Analytics Workspace, reduzindo drasticamente o ruído.
(2) Sintonizando com o Ambiente
É perigoso usar as regras padrão como elas são.
Por exemplo, a regra "Detecção de login tarde da noite" será ativada quando o acesso a sites internacionais for normal para empresas globais.
Vamos verificar o seguinte para cada regra:
- Quando acionar (condição de gatilho)
- Isso é normal ou anormal no seu ambiente?
- Posso definir uma lista de exceções?
3. Design de Notificações: Quem, o Quê e Onde Receber
O design de destino para alertas é o próprio fluxo operacional.
Erros comuns: "Enviar todas as notificações por e-mail para todos"
Em vez disso, projete assim:
- Alertas Altos → canais específicos do Microsoft Teams + menções diretas aos representantes + chamadas de plantão, como o PagerDuty
- Alertas médios → apenas notificações no Teams (confirmado no próximo dia útil)
- Alertas baixos → agregados em relatórios semanais e enviados por e-mail
Você pode usar Logic Apps e Playbooks para automatizar a atribuição de destinatários com base no conteúdo dos seus alertas.
4. Defina os limites da responsabilidade
Se você não especificar quem vai responder a quais alertas e em quantos minutos, o SIEM é moleza.
Decida antecipadamente quem investigará e quem decidirá parar o sistema depois que o Sentinela levantar um alerta.
5. Melhoria contínua para tornar o "monitoramento rotativo"
Só porque você afinou uma vez, as regras não serão ideais para sempre.
- À medida que novos sistemas e serviços são adicionados, novos padrões de falsos positivos são criados
- Mudança no modo de operação de ataque reduz a cobertura das regras de detecção
Crie um sistema para revisar mensalmente a "Taxa de Falsos Positivos", "Taxa de Resposta a Alertas" e "Taxa de Desempenho do SLO".
6. Aproximação da Segurança da Colorkrew
Na Colorkrew Security, focamos no "suporte pós-implementação" do Sentinel.
**SIEM é uma ferramenta. É o poder do design operacional que o torna "monitoramento giratório". **
Trabalhamos juntos para criar um sistema a partir do desenho de regras, design de notificações, delimitação de responsabilidades e formulação de SLO.