Qué vas a conseguir
Un Sentinel que recibe los registros que importan, genera incidentes que alguien atiende y no se come el presupuesto. Una regla de análisis escrita por ti, una automatización que la asigna y avisa al canal del equipo, y la rutina para investigar y cerrar un incidente con una clasificación que sirva para mejorar las reglas.
Antes de empezar
- Un área de trabajo de Log Analytics en la región que corresponda a tus datos, y el rol Microsoft Sentinel Contributor sobre ella (y Log Analytics Contributor para los conectores).
- Sentinel se usa desde el portal de Microsoft Defender (operaciones de seguridad unificadas), junto con los incidentes de Defender XDR. Las rutas de esta guía son las de ese portal.
- Una idea del presupuesto: se paga por GB ingerido. Hay orígenes gratuitos (actividad de Azure, auditoría de Office 365, alertas de Defender) y otros que no lo son (inicios de sesión de Entra ID, eventos de seguridad de Windows).
- La guía de Azure Monitor y Log Analytics (próximamente) explica el área de trabajo por dentro; aquí basta con saber escribir una consulta KQL sencilla.
1. Los conectores que importan
- Empieza por identidad (Entra ID) y correo y documentos (Microsoft 365): es por donde entra la mayoría de los ataques en un tenant de oficina.
- Los eventos de Windows se recogen con el agente de Azure Monitor y una regla de recopilación de datos. El conjunto Común basta para empezar; *Todos los eventos* multiplica el coste sin multiplicar las detecciones.
- Comprueba que llegan datos antes de escribir ninguna regla:
SigninLogs| where TimeGenerated > ago(1h)| summarize Inicios = count() by ResultTypeResultType Inicios0 1 28450126 3750074 1253003 4ResultType 0 es un inicio correcto; el resto son códigos de error de Entra ID (50126: credenciales incorrectas; 50074: falta completar MFA; 53003: bloqueado por Conditional Access).
2. La primera regla: entra una cuenta de emergencia
Las cuentas de emergencia no se usan nunca (guía de Global Admin y PIM). Si alguien entra con una, tiene que saberse en minutos. Primero, una watchlist con sus nombres para no escribirlos dentro de la regla:
let breakglass = _GetWatchlist("breakglass") | project UserPrincipalName;SigninLogs| where UserPrincipalName in~ (breakglass)| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ResultType, UserAgent- Una regla NRT se ejecuta cada minuto. Para la mayoría de reglas basta una programada cada 5 o 15 minutos; las NRT se reservan para lo que no puede esperar.
- La asignación de entidades es lo que permite después ver la cuenta y la IP como objetos en la investigación, y que Sentinel relacione este incidente con otros de la misma IP.
3. La automatización: asignar y avisar
El playbook es una aplicación lógica de Azure: recibe el incidente y publica en Teams con el enlace. Las reglas de automatización ordenan el trabajo; los playbooks hacen cosas fuera de Sentinel (avisar, deshabilitar una cuenta, abrir un ticket en Jira Service Management).
4. Un incidente de principio a fin
Lunes, 07:12. El canal de seguridad recibe: *Cuenta de emergencia brk-admin-02 desde 198.51.100.23*.
- Abrir el incidente (*Investigación y respuesta › Incidentes y alertas › Incidentes*): ver la alerta, las entidades (cuenta e IP) y la línea temporal.
- ¿Fue un cambio planificado? El registro de cambios dice que no hay prueba de las cuentas de emergencia programada esta semana.
- ¿Qué hizo esa IP?
SigninLogs| where TimeGenerated > ago(24h) and IPAddress == "198.51.100.23"| summarize Usuarios = dcount(UserPrincipalName), Fallos = countif(ResultType != "0"), Correctos = countif(ResultType == "0") by bin(TimeGenerated, 1h)TimeGenerated Usuarios Fallos Correctos27/10/2026 05:00 143 141 027/10/2026 06:00 211 208 127/10/2026 07:00 1 0 1Muchos usuarios distintos, casi todo fallos y un acierto: un ataque de difusión de contraseñas (password spray) que acertó con la contraseña de una cuenta de emergencia.
- Contener: deshabilitar la cuenta, revocar sus sesiones (
Revoke-MgUserSignInSession), cambiar la contraseña, bloquear la IP en una ubicación con nombre de Conditional Access y revisar en *AuditLogs* qué hizo la cuenta en esos minutos. - Clasificar y cerrar: *Verdadero positivo — actividad sospechosa*, con un comentario de lo que se hizo y las acciones pendientes (por qué la cuenta de emergencia podía entrar solo con contraseña).
La clasificación no es burocracia: los incidentes cerrados como *Falso positivo* te dicen qué reglas hay que afinar, y los *Benignos* (actividad sospechosa pero esperada, como una prueba planificada) qué excepciones faltan.
5. El coste
Usage| where TimeGenerated > ago(30d) and IsBillable == true| summarize GB = round(sum(Quantity) / 1000, 1) by DataType| sort by GB descDataType GBSecurityEvent 412.6AADNonInteractiveUserSignInLogs 188.3SigninLogs 41.2Syslog 19.8SecurityEventarriba del todo suele ser un conjunto de eventos demasiado amplio o un servidor ruidoso: se ajusta la regla de recopilación.- Las tablas que solo se consultan en una investigación pueden ir al plan Basic o Auxiliary, mucho más barato, a cambio de consultas más limitadas.
- Con un volumen estable, un nivel de compromiso diario abarata el GB.
6. Lo que revisas cada mes
- Reglas que no han generado ningún incidente en 90 días (¿siguen llegando los datos que miran?) y reglas que generan tantos que nadie los lee.
- El estado de los conectores y de las reglas: la tabla
SentinelHealthy la página de cada conector dicen cuándo dejaron de llegar datos. - Tiempo medio hasta asignar y hasta cerrar los incidentes de gravedad alta.
- La factura de ingesta frente al mes anterior, por tabla.
Siguientes pasos
- Las plantillas de reglas de cada solución del Centro de contenido: se activan, se prueban y se afinan en lugar de escribirlas desde cero.
- UEBA (análisis de comportamiento de usuarios y entidades): detecta lo raro para cada usuario, no lo raro en general.
- Inteligencia de amenazas: indicadores de IP y dominios cruzados con tus registros.
- La alerta de copias borradas o inmutabilidad cambiada de la guía de DR/BCP, como segunda regla propia.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A Sentinel that receives the logs that matter, raises incidents someone actually handles, and doesn't eat the budget. An analytics rule written by you, an automation that assigns it and notifies the team channel, and the routine to investigate and close an incident with a classification that helps improve the rules.
Before you start
- A Log Analytics workspace in the region your data belongs in, and the Microsoft Sentinel Contributor role on it (plus Log Analytics Contributor for the connectors).
- Sentinel is used from the Microsoft Defender portal (unified security operations), alongside the Defender XDR incidents. The paths in this guide are that portal's.
- A rough budget: you pay per GB ingested. Some sources are free (Azure activity, Office 365 audit, Defender alerts) and others are not (Entra ID sign-ins, Windows security events).
- The Azure Monitor and Log Analytics guide (coming soon) explains the workspace from the inside; here it is enough to be able to write a simple KQL query.
1. The connectors that matter
- Start with identity (Entra ID) and mail and documents (Microsoft 365): that is where most attacks on an office tenant come in.
- Windows events are collected with the Azure Monitor agent and a data collection rule. The Common set is enough to start; *All events* multiplies the cost without multiplying the detections.
- Check data is arriving before writing any rule:
SigninLogs| where TimeGenerated > ago(1h)| summarize SignIns = count() by ResultTypeResultType SignIns0 1,28450126 3750074 1253003 4ResultType 0 is a successful sign-in; the rest are Entra ID error codes (50126: wrong credentials; 50074: MFA not completed; 53003: blocked by Conditional Access).
2. The first rule: an emergency account signs in
Emergency accounts are never used (Global Admin and PIM guide). If someone signs in with one, it has to be known within minutes. First, a watchlist with their names so they aren't written inside the rule:
let breakglass = _GetWatchlist("breakglass") | project UserPrincipalName;SigninLogs| where UserPrincipalName in~ (breakglass)| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ResultType, UserAgent- An NRT rule runs every minute. For most rules a scheduled one every 5 or 15 minutes is enough; NRT is kept for what can't wait.
- Entity mapping is what later lets you see the account and the IP as objects in the investigation, and lets Sentinel relate this incident to others from the same IP.
3. The automation: assign and notify
The playbook is an Azure Logic App: it receives the incident and posts to Teams with the link. Automation rules organise the work; playbooks do things outside Sentinel (notify, disable an account, open a ticket in Jira Service Management).
4. An incident from start to finish
Monday, 07:12. The security channel receives: *Emergency account brk-admin-02 from 198.51.100.23*.
- Open the incident (*Investigation & response › Incidents & alerts › Incidents*): see the alert, the entities (account and IP) and the timeline.
- Was it a planned change? The change log says no emergency account test is scheduled this week.
- What did that IP do?
SigninLogs| where TimeGenerated > ago(24h) and IPAddress == "198.51.100.23"| summarize Users = dcount(UserPrincipalName), Failures = countif(ResultType != "0"), Successes = countif(ResultType == "0") by bin(TimeGenerated, 1h)TimeGenerated Users Failures Successes27/10/2026 05:00 143 141 027/10/2026 06:00 211 208 127/10/2026 07:00 1 0 1Many different users, almost all failures and one hit: a password spray attack that guessed an emergency account's password.
- Contain: disable the account, revoke its sessions (
Revoke-MgUserSignInSession), change the password, block the IP with a Conditional Access named location, and review in *AuditLogs* what the account did in those minutes. - Classify and close: *True positive — suspicious activity*, with a comment on what was done and the pending actions (why the emergency account could sign in with only a password).
The classification is not bureaucracy: incidents closed as *False positive* tell you which rules need tuning, and *Benign* ones (suspicious but expected activity, such as a planned test) which exceptions are missing.
5. The cost
Usage| where TimeGenerated > ago(30d) and IsBillable == true| summarize GB = round(sum(Quantity) / 1000, 1) by DataType| sort by GB descDataType GBSecurityEvent 412.6AADNonInteractiveUserSignInLogs 188.3SigninLogs 41.2Syslog 19.8SecurityEventat the top is usually an event set that is too broad or a noisy server: adjust the collection rule.- Tables that are only queried during an investigation can go to the Basic or Auxiliary plan, much cheaper, in exchange for more limited queries.
- With a steady volume, a daily commitment tier lowers the price per GB.
6. What you review each month
- Rules that haven't raised an incident in 90 days (is the data they look at still arriving?) and rules that raise so many that nobody reads them.
- Connector and rule health: the
SentinelHealthtable and each connector's page say when data stopped arriving. - Mean time to assign and to close high-severity incidents.
- The ingestion bill against the previous month, per table.
Next steps
- The rule templates in each Content hub solution: enable, test and tune them instead of writing from scratch.
- UEBA (user and entity behaviour analytics): it detects what is unusual for each user, not what is unusual in general.
- Threat intelligence: IP and domain indicators matched against your logs.
- The alert for deleted backups or changed immutability from the DR/BCP guide, as your second rule of your own.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →