Operar Sophos XDR Custom Detection y Suppression Rules

En Security Operations > Rules se gestionan reglas de detection propias y Suppression Rules. Las primeras crean detections a partir de eventos normalizados; las segundas marcan detections coincidentes como suprimidas en una fase temprana. Ambas cambian el proceso de investigación y requieren condición aprobada, alcance preciso y responsable.

La guía de Cases y reglas Classic explica la vista Classic, que sigue siendo distinta. Sus requisitos Super Admin, de cantidad o de 20 minutos no se trasladan a Security Operations.

Antes de crear una regla

Definir propósito, fuente, esquema, coincidencias esperadas y casos deliberadamente excluidos. Con eventos históricos adecuados en Data Lake Search, comprobar que la condición tenga sentido. Una prueba aprobada emplea cuenta dedicada u otros datos autorizados; no se genera actividad maliciosa real.

Coincidir en una búsqueda histórica no prueba idéntico efecto en una regla activa. Los motores difieren y algunos campos enriquecidos aparecen después. La aceptación requiere por tanto una coincidencia y una no coincidencia esperadas. Antes del cambio documentar consulta, nombre, descripción, severity, activación y resultados anteriores.

Crear una Custom Detection Rule

Primero crear una consulta Advanced Search adecuada en Security Operations > Data Lake Search, dirigida a eventos normalizados de un esquema apropiado. Después:

1. Copiar la consulta validada y abrir Security Operations > Rules.
2. Elegir Create Rule encima de Custom Rules.
3. Introducir la consulta en Rule Criteria.
4. Especificar Name claro, Mitre Attack Categories adecuadas y Description comprensible.
5. Seleccionar severity justificada y crear mediante Create Rule.

Una nueva Custom Rule queda activada al crearse. Aprobación y responsable deben existir antes. Es distinto al valor predeterminado de un Custom Parser nuevo. No activar una condición ilimitada en producción para experimentar.

Streaming no es una búsqueda guardada

Las Custom Rules trabajan con datos en streaming. Los campos primitivos no reciben automáticamente los valores predeterminados que pueden existir después en el Data Lake. Las condiciones NULL deben considerar valores realmente ausentes. No se admiten patrones glob; también se restringen construcciones regex como backreferences, patrones recursivos, aserciones arbitrarias de ancho cero de tipo look-around y código integrado. No presentar una expresión Search que funciona como regla garantizada sin validarla.

Los campos lógicos como @user pueden expandirse a campos del esquema seleccionado. Sin embargo, una regla solo coincide con un esquema. Algunos campos añadidos después no están disponibles: por ejemplo hostname, enriquecimientos geo/blacklist de auth/netflow/dns_query y WHOIS del esquema DNS. Verificar los campos requeridos en el contexto de la regla, sin sustituirlos por campos Search de nombre parecido.

Circuit breaker y responsabilidad del cliente

Las Custom Rules pueden crear como máximo 5.000 detections por hora o 100.000 en 24 horas. Si se supera, el circuit breaker desactiva la regla y Sophos informa al autor por correo. Reducir luego el alcance; no reactivar la regla sin cambios. Un flujo de alertas que cesa puede significar una regla desactivada, no riesgos resueltos.

Los Cases creados automáticamente por reglas del cliente son customer-managed y no desencadenan investigación MDR automática. Los esquemas Antivirus, Email, NIDS y Thirdparty describen además is_custom_alert=true: estos Custom Alerts se envían al tenant para su gestión, no a la cola del servicio MDR; su severity no cambia. Esto no excluye globalmente de MDR todo registro de un Custom Parser. Crear y validar parsers explica la normalización previa.

Mantener la suppression deliberadamente acotada

Suppression sirve para repeticiones legítimas confirmadas, no para ocultar actividad sin explicar. Las reglas del tenant solo afectan a él; las Global son gestionadas por Sophos y de solo lectura. Documentar dudas sobre una regla global y aclararlas por el soporte normal.

Una detection suprimida recibe ese estado pronto, antes de poder desencadenar respuestas automatizadas posteriores. Por ello podrían no ejecutarse playbooks o aislamiento de hosts. Antes de aprobar, aclarar qué actividad legítima se identifica y qué respuesta de seguridad se impide deliberadamente.

Crear suppression mediante consulta

1. Validar la condición con detections existentes en Data Lake Search.
2. Elegir Create Rule en Security Operations > Rules > Suppression Rules.
3. Introducir la condición en Rule Criteria.
4. Usar See potential matches with current data como vista previa de plausibilidad.
5. Definir nombre, descripción y estado de resolución previsto y crear con Create Rule.

Las nuevas reglas de suppression también se activan por defecto. Alcance, aprobación y reversión deben preceder a Create Rule.

Alternativamente abrir una detection concreta y Actions > Create Suppression Rule. Elegir deliberadamente las entities prerrellenadas; varias condiciones se combinan con AND. Escapar correctamente los caracteres regex especiales introducidos a mano. No deducir suppression universal de una única coincidencia esperada.

Por qué pueden diferir vista previa y regla activa

La vista previa usa Advanced Search sobre detections terminadas y enriquecidas. Suppression actúa mientras se crean. Campos como enrichment_details, status y case no están disponibles; para valores de terceros usar el esquema de eventos thirdparty, no third_party_details. Todos los criterios deben ser verdaderos a la vez en el momento de suppression. Un registro terminado puede combinar condiciones antes verdaderas solo por separado.

See potential matches no garantiza por tanto el efecto. Tras crear, editar, activar o desactivar una regla esperar al menos diez minutos antes de evaluar. Las detections generadas inmediatamente después del cambio no prueban de forma fiable el estado nuevo.

IPv4-CIDR es posible en suppression aunque Detection Search no admita consultas CIDR. Probar primero la consulta sin rango y después adaptarla a la regla. Las direcciones IPv6 pueden compararse normalizadas; IPv6-CIDR e IPv4-mapped IPv6 no se admiten actualmente en suppression. No trasladar sin revisar la sintaxis de rangos del firewall.

Verificar, documentar y revertir

Pulsar el nombre muestra criterios y detalles. Si hubo coincidencias en los últimos siete días aparecen número, última coincidencia y evolución. En suppression, History también muestra cambios. La ausencia de gráfico puede indicar simplemente que no ocurrió el evento esperado.

Incluir detections de Custom Rules mediante Custom Detections en la lista. Las suprimidas ya clasificadas se muestran con Triaged Detections; desde detalles puede abrirse una búsqueda adecuada. Verificar coincidencias y no coincidencias esperadas, esquema/fuente y la respuesta deseada o deliberadamente ausente.

Enabled activa o desactiva. Archive desactiva y retira de la lista predeterminada. Showing Archived Rules permite abrir una archivada; Restore la devuelve desactivada. No activar una restaurada sin nueva aceptación. La demora documentada de suppression también importa al desactivar.

Si falla la aceptación, desactivar solo la propia regla afectada y comprobar el estado anterior documentado. Cases, exportaciones o detections suprimidas ya creados no desaparecen automáticamente. Las detections suprimidas pueden añadirse a Cases y cambiar su etiqueta cuando sea necesario. No desactivar protección global o reglas ajenas para que el test propio funcione.

La entrega operativa incluye fuente/esquema, criterios y versión, autor, aprobación, pruebas de coincidencia/no coincidencia, severity/resolución, activación, seguimiento del circuit breaker y fecha de revisión. La aceptación de integraciones sigue siendo necesaria: una regla silenciosa no repara una fuente ausente.