Reglas de automatización y retención

Una regla de automatización se dispara cuando se crea un incidente, cuando se actualiza o cuando se crea una alerta, y solo ejecuta sus acciones si se cumplen sus condiciones. Sus acciones sin código incluyen cambiar el estado o la severidad, asignar un dueño, añadir una etiqueta o una tarea, y ejecutar un cuaderno de estrategias (playbook) cuando hace falta algo más complejo.

Para casi todo se prefiere automatizar sobre el incidente, que es el expediente con todas las alertas y entidades. El disparador por alerta queda para las alertas de reglas que no crean incidentes.

Una regla de automatización puede tener una fecha de vencimiento: después de esa fecha se deshabilita sola. Es lo adecuado para ruido que se sabe temporal, como una prueba de seguridad autorizada o un mantenimiento: la regla cierra los incidentes que genera la prueba y se apaga cuando termina. Una regla de ese tipo que sigue activa después de su ventana puede esconder un incidente real.

En la consola, reglas_automatizacion trae las cuatro reglas en orden de ejecución. Hoy es viernes 6 de noviembre de 2026.

Las reglas de automatización corren una después de otra y nunca en paralelo, según su número de orden. Cada una evalúa sus condiciones sobre el estado actual del incidente, es decir, ya modificado por las anteriores. Por eso una regla puede no ejecutarse: una anterior cambió la propiedad que su condición revisa.

incidentes_entrantes trae dos incidentes de la mañana. Sigue el incidente INC-4351, de severidad Media, por las cuatro reglas en orden.

Una regla de automatización puede ejecutar un cuaderno de estrategias (playbook, hecho con Azure Logic Apps). Para eso no usa tu cuenta: usa una cuenta de servicio de Microsoft Sentinel, y esa cuenta necesita permisos explícitos sobre el grupo de recursos donde vive el cuaderno. Conceder esos permisos exige el rol de Propietario sobre ese grupo de recursos.

Los cuadernos a los que Sentinel no tiene permiso aparecen deshabilitados en la lista al configurar la acción.

Los datos de Defender XDR se pueden consultar hasta 30 días hacia atrás. Las tablas que se envían a Sentinel y que tienen retención configurada se consultan hasta los días que se hayan configurado. Una pregunta de investigación que pide datos más viejos de lo conservado ya no tiene respuesta, y la lección va a la lista de lo que hay que configurar antes del próximo incidente.

retencion_tablas trae dónde se conserva cada tabla en este espacio ficticio y consultas_pendientes trae tres preguntas del equipo con la tabla y los días hacia atrás.