Operar Sophos XDR Custom Detection e Suppression Rules

Em Security Operations > Rules gerem-se regras de detection próprias e Suppression Rules. As primeiras criam detections a partir de eventos normalizados; as segundas marcam cedo detections correspondentes como suprimidas. Ambas alteram o processo de investigação e exigem condição aprovada, âmbito restrito e responsável.

O guia de Cases e regras Classic explica a vista Classic, ainda diferente. Os seus requisitos Super Admin, de quantidade ou de 20 minutos não são transferidos para Security Operations.

Antes de criar uma regra

Definir objetivo, fonte, esquema, correspondências esperadas e casos deliberadamente excluídos. Com eventos históricos adequados em Data Lake Search, verificar se a condição faz sentido. Um teste aprovado utiliza conta dedicada ou outros dados autorizados; não gera atividade maliciosa real.

Uma correspondência na pesquisa histórica não prova o mesmo efeito numa regra ativa. Os motores diferem e certos campos enriquecidos surgem depois. A aceitação exige, portanto, uma correspondência e uma não correspondência esperadas. Antes da alteração, documentar consulta, nome, descrição, severity, ativação e resultados anteriores.

Criar uma Custom Detection Rule

Criar primeiro uma consulta Advanced Search adequada em Security Operations > Data Lake Search, destinada a eventos normalizados de um esquema apropriado. Depois:

1. Copiar a consulta validada e abrir Security Operations > Rules.
2. Escolher Create Rule acima de Custom Rules.
3. Introduzir a consulta em Rule Criteria.
4. Definir Name claro, Mitre Attack Categories adequadas e Description compreensível.
5. Selecionar severity justificada e criar com Create Rule.

Uma nova Custom Rule fica ativa quando é criada. Aprovação e responsável devem existir antes. É diferente da configuração predefinida de um Custom Parser novo. Não ativar uma condição ilimitada em produção para experimentar.

Streaming não é uma pesquisa guardada

As Custom Rules trabalham com dados em streaming. Os campos primitivos não recebem automaticamente os valores predefinidos que podem existir depois no Data Lake. As condições NULL devem considerar valores realmente ausentes. Padrões glob não são suportados; também há restrições a construções regex como backreferences, padrões recursivos, asserções arbitrárias de largura zero do tipo look-around e código incorporado. Não apresentar uma expressão Search funcional como regra garantida sem verificar.

Campos lógicos como @user podem expandir para campos do esquema selecionado. Contudo, uma regra corresponde apenas a um esquema. Alguns campos acrescentados depois não estão disponíveis: por exemplo hostname, enriquecimentos geo/blacklist de auth/netflow/dns_query e WHOIS do esquema DNS. Verificar os campos necessários no contexto da regra, sem os substituir por campos Search de nome semelhante.

Circuit breaker e responsabilidade do cliente

As Custom Rules podem criar no máximo 5 000 detections por hora ou 100 000 em 24 horas. Ao exceder, o circuit breaker desativa a regra e a Sophos informa o autor por e-mail. Restringir depois o âmbito; não reativar a regra inalterada. Um fluxo de alertas interrompido pode significar uma regra desativada, não riscos resolvidos.

Cases criados automaticamente por regras do cliente são customer-managed e não desencadeiam investigação MDR automática. Os esquemas Antivirus, Email, NIDS e Thirdparty descrevem ainda is_custom_alert=true: estes Custom Alerts vão para tratamento pelo tenant, não para a fila do serviço MDR; a severity não muda. Isto não exclui genericamente de MDR todos os registos de um Custom Parser. Criar e validar parsers explica a normalização anterior.

Manter a suppression deliberadamente restrita

Suppression destina-se a repetições legítimas confirmadas, não a ocultar atividade inexplicada. As regras do tenant só afetam o próprio tenant; as Global são geridas pela Sophos e só de leitura. Documentar dúvidas sobre uma regra global e esclarecê-las pelo suporte normal.

Uma detection suprimida recebe cedo esse estado, antes de poder desencadear respostas automatizadas posteriores. Assim, playbooks ou isolamento de hosts podem não ocorrer. Antes da aprovação, esclarecer que atividade legítima é identificada e que resposta de segurança é deliberadamente impedida.

Criar suppression através de consulta

1. Verificar a condição em detections existentes em Data Lake Search.
2. Escolher Create Rule em Security Operations > Rules > Suppression Rules.
3. Introduzir a condição em Rule Criteria.
4. Usar See potential matches with current data como pré-visualização de plausibilidade.
5. Definir nome, descrição e estado de resolução pretendido e criar com Create Rule.

As novas regras de suppression também ficam ativas por predefinição. Âmbito, aprovação e reversão devem preceder Create Rule.

Em alternativa abrir uma detection concreta e Actions > Create Suppression Rule. Escolher deliberadamente as entities pré-preenchidas; várias condições são combinadas com AND. Escapar corretamente caracteres regex especiais introduzidos manualmente. Não deduzir suppression universal de uma única correspondência esperada.

Porque podem divergir pré-visualização e regra ativa

A pré-visualização usa Advanced Search sobre detections terminadas e enriquecidas. Suppression atua durante a criação. Campos como enrichment_details, status e case não estão disponíveis; para valores de terceiros usar o esquema de eventos thirdparty, não third_party_details. Todos os critérios devem ser verdadeiros em simultâneo no momento de suppression. Um registo final pode combinar condições anteriormente verdadeiras apenas em separado.

See potential matches não garante, portanto, o efeito. Após criar, editar, ativar ou desativar, aguardar pelo menos dez minutos antes de avaliar. Detections geradas imediatamente após a alteração não testam fiavelmente o novo estado.

IPv4-CIDR é possível em suppression apesar de Detection Search não suportar pesquisa CIDR. Testar primeiro a consulta sem intervalo e adaptá-la depois à regra. Endereços IPv6 podem ser comparados normalizados; IPv6-CIDR e IPv4-mapped IPv6 não são atualmente suportados por suppression. Não transferir sem revisão a sintaxe de intervalos da firewall.

Verificar, documentar e reverter

Clicar no nome mostra critérios e detalhes. Se houver correspondências nos últimos sete dias, aparecem número, última correspondência e evolução. Em suppression, History também mostra alterações. A ausência de gráfico pode indicar apenas que o evento esperado não ocorreu.

Incluir detections de Custom Rules através de Custom Detections na lista. As suprimidas já triadas tornam-se visíveis com Triaged Detections; nos detalhes pode abrir-se uma pesquisa adequada. Verificar correspondências e não correspondências esperadas, esquema/fonte e a resposta pretendida ou deliberadamente ausente.

Enabled ativa ou desativa. Archive desativa e retira da lista predefinida. Showing Archived Rules permite abrir uma arquivada; Restore devolve-a desativada. Não ativar uma regra restaurada sem nova aceitação. A latência documentada de suppression também importa ao desativar.

Se a aceitação falhar, desativar apenas a própria regra afetada e verificar o estado anterior documentado. Cases, exportações ou detections suprimidas já criados não desaparecem automaticamente. Detections suprimidas podem ser acrescentadas a Cases e ter a etiqueta alterada se necessário. Não desativar proteção global ou regras alheias para fazer o teste próprio funcionar.

A entrega operacional inclui fonte/esquema, critérios e versão, autor, aprovação, provas de correspondência/não correspondência, severity/resolução, ativação, monitorização do circuit breaker e data de revisão. A aceitação de integrações continua a ser necessária: uma regra silenciosa não repara uma fonte ausente.