Reglas de detección

Para qué sirve

Crear, probar y gestionar reglas que generan alertas automáticas a partir de consultas SQL. Esta página cubre la lista, el asistente de creación (5 pasos) y la edición.

Antes de empezar

• Necesitás permisos de administrador sobre /management/detection-rules.
• Conviene tener listo el SQL de detección (podés generarlo en Logs y usar Create Detection Rule).
• Para que la regla notifique, primero creá un canal de notificación (Slack, Discord, etc.).

Resultado esperado

Consejos

• La Detection Query usa el mismo SQL Presto que Logs: probala primero ahí y traela con Create Detection Rule.
• Usá Test Query en el paso 5 (Review & Test) antes de crear la regla para confirmar que el SQL devuelve lo esperado.
• Para guardar, la query debe ser SELECT … FROM … WHERE … sin cláusulas extra. El motor agrega filtros de tiempo automáticamente.
• Severidades: Low, Medium, High, Critical. Rule Type y MITRE ATT&CK se configuran al editar la regla, no en la creación.

La lista de Detection Rules

• Tarjetas de resumen arriba: Total Rules, Active Rules, Custom Rules, Critical Rules, High Severity.
• Buscador: por nombre, ID o descripción (escribí y Search; Clear para limpiar).
• Filtros: Severity (All/Critical/High/Medium/Low), Status (All/Enabled/Disabled), Type (All/Custom/Built-in).
• Columnas (configurables): Rule Name, Type, Severity, Status, MITRE Techniques, Lookback, Actions. Export descarga las reglas filtradas en JSON.
• Cada fila tiene un switch para habilitar/deshabilitar la regla al instante.

Acciones por regla (menú ⋯)

• View Details — abre el panel lateral con el detalle de la regla.
• Edit Rule — abre el diálogo de edición (ver más abajo).
• Delete Rule — pide confirmación en Delete Detection Rule (acción irreversible).

Crear una regla — asistente de 5 pasos (Add Rule)

• Add Rule abre el diálogo Add Detection Rule (Step {N} of 5, con Back / Next). Los pasos son: Detection Logic → Rule Management → Basic Info → Details → Review & Test. Cada paso valida sus campos obligatorios (marcados con *) antes de dejarte avanzar.

Paso 1 · Detection Logic

• Detection Query * — el SQL Presto que define la detección (obligatorio). Debe ser SELECT … FROM … WHERE … únicamente: el motor agrega filtros de tiempo y origen automáticamente. Antes de guardar, quitá ORDER BY, LIMIT, OFFSET, GROUP BY y HAVING (podés probar la query con esas cláusulas en el paso 5, pero no se pueden guardar).
• Herramientas del editor: Format SQL, SQL Help, Lists (inserta referencias {{nombre_tabla}} a lookup tables de Management → Lookup Tables) y Query Builder. Atajo: Ctrl+Space para autocompletar.
• Con Lists, usá el modo Reference ✦ recommended para que la regla se mantenga sincronizada cuando actualices la lista (ver Lookup Tables).
• Si venís desde Logs, aparece el aviso Query Preloaded con la consulta precargada.
• Lookback window (minutes) — cuántos minutos hacia atrás busca cada ejecución de la regla. Default 10; debe ser mayor que 0. No define cada cuánto corre la regla, solo qué ventana de eventos evalúa.

Paso 2 · Rule Management

• Configurá cómo se empaquetan los eventos coincidentes en alertas y hacia dónde se envían las notificaciones.
• Events per alert — cuántos eventos coincidentes se agrupan en cada alerta. Default 1; debe ser al menos 1. Usá 1 para una alerta por evento; un valor alto (p. ej. 999) agrupa muchos eventos en un solo ticket resumen.
• Notification Channel — opcional al crear. Solo aparecen los canales habilitados (se muestran como nombre (tipo)). Canal fallback cuando ninguna Notification Rule coincide (por severidad o por regla de detección). Ver Notificaciones.

Paso 3 · Basic Info

• Rule Name * — nombre descriptivo de la regla (obligatorio).
• Severity * — Low, Medium, High o Critical. Default Medium.
• Enable rule immediately — switch para activar la regla apenas se crea (encendido por defecto).
• Al crear, la regla se guarda como tipo Behavioral (Custom).

Paso 4 · Details

• Description * — qué detecta la regla y por qué importa (obligatorio).
• Resolution Steps * — acciones recomendadas cuando la regla dispara (obligatorio).

Paso 5 · Review & Test

• Resumen final: nombre, severidad, tipo (Behavioral), query, resolución, estado, Lookback window y Alert delivery (Events per alert y Notification Channel).
• Test Query — ejecuta el SQL con la misma ventana de lookback que en producción y muestra hasta 10 registros coincidentes (o un mensaje si no hay actividad reciente, lo cual es normal). Podés probar queries que aún tengan cláusulas prohibidas; para guardar, la query debe quedar limpia (SELECT … FROM … WHERE …).
• Confirmá con Create Rule (muestra Creating... mientras procesa). Si la query no es válida para guardar, aparece una advertencia en ámbar.

Editar una regla (Edit Detection Rule)

• Desde el menú ⋯ → Edit Rule se abre Edit Detection Rule con cinco bloques.

Editar · Basic Information

• Rule Name, Rule Type, Severity y Rule Status (Active/Inactive).

Editar · Security Detection

• Description y Resolution.

Editar · Event Configuration

• Detection Query, Lookback window (minutes) y MITRE ATT&CK Techniques (IDs separados por coma, p. ej. T1078, T1040).
• La query debe cumplir las mismas reglas de guardado: SELECT … FROM … WHERE … sin ORDER BY, LIMIT, OFFSET, GROUP BY ni HAVING.

Editar · Alert delivery

• Events per alert — cuántos eventos coincidentes se agrupan en cada alerta. Default 1; al menos 1.
• Notification Channel — canal fallback para alertas de esta regla. Opcional; recomendado si no tenés reglas de enrutamiento en Notification Rules. Ver Notificaciones.

Editar · Rule Metadata

• Solo lectura: Rule ID, Created By, Date Created (UTC), Last Modified By, Date Modified (UTC). Cerrá con Save Changes.

Ver también