Conecta primero la identidad: los registros de inicio de sesión y de auditoría de Microsoft Entra ID, o el System Log de Okta. Después el endpoint, la auditoría del correo, el cortafuegos y la VPN, y los planos de control cloud. Los servidores y las aplicaciones, al final. El orden sigue cómo entran de verdad en una pyme —una contraseña válida en manos ajenas— y no gasta volumen en fuentes sin detección.
Un SIEM llega vacío. Elegirlo es otra decisión y la cubre nuestra página de SIEM para pymes, con los criterios que importan con 10-300 personas. Esto va de las semanas siguientes a la firma: qué conectar, en qué orden y cómo saber que funciona antes de seguir.
¿Por qué la identidad primero?
Porque el incidente que llega a una empresa de 30 personas suele ser una credencial válida en manos ajenas, y se ve en identidad. Microsoft lo separa en dos registros. Los registros de inicio de sesión cubren cuatro tipos —usuario interactivo, no interactivo, principal de servicio e identidad administrada— y describen quién inició sesión, con qué cliente y contra qué recurso. Los registros de auditoría recogen los cambios del tenant (usuarios, grupos, aplicaciones, licencias) con el valor antiguo y el nuevo de cada propiedad. En Okta el equivalente es el System Log: un rastro de auditoría de los eventos de la organización, con actor, tipo de evento y objetivo.
Sin ellos ves que una máquina hizo algo, no que una cuenta lo hizo desde una dirección que nadie aquí usa. El volumen lo marcan los inicios no interactivos —renovaciones de token en segundo plano— que Microsoft agrupa en una sola fila con un contador. Un matiz para tus reglas: en clientes confidenciales, la IP de un inicio no interactivo es la de la emisión original del token, no la de la renovación. Deja la lógica de ubicación para los interactivos.
Detección resultante: varios inicios interactivos fallidos contra una cuenta, luego uno correcto desde otro país y, en la hora siguiente, un cambio sobre esa cuenta en auditoría: un ataque de contraseñas que acaba en secuestro.
¿Qué añade el endpoint que la identidad no puede dar?
El ejecutable, su proceso padre y sus argumentos. La identidad dice que una cuenta actuó; el endpoint, qué se ejecutó y con quién habló. Coge el flujo de tu EDR antes que los registros de Windows en bruto: el agente ya filtra y etiqueta. Es lo que alimenta el EDR con respuesta activa.
Si recoges eventos de Windows directamente, comprueba una cosa antes: en el evento 4688, «Se ha creado un nuevo proceso», el campo de línea de comandos viene vacío por defecto hasta que activas la directiva «Include command line in process creation events». Sin argumentos, ese flujo no separa la administración de un ataque. Es además la fuente de host con más volumen: el paso que más mueve tu cifra diaria.
Detección resultante: un proceso de documento de oficina o una utilidad de compresión que lanza un intérprete (PowerShell, wscript, mshta) con un argumento codificado o una descarga.
Correo: ¿por qué el tercero y qué exactamente?
Por el correo sale el dinero, y el fraude aparece en unas pocas actividades de buzón, no en el contenido. En Microsoft 365, las actividades del registro de auditoría de Microsoft Purview incluyen las de un buzón comprometido: MailItemsAccessed, New-InboxRule, Set-InboxRule y UpdateInboxRules, Add-MailboxPermission y los envíos en nombre de otro usuario. Es poco volumen; el seguimiento completo de mensajes es mucho mayor y no aporta nada accionable el primer mes.
Un detalle documentado te ahorra una tarde: la auditoría no recoge los cmdlets que empiezan por Get-, Search- o Test-. Prueba el conector creando una regla, no leyéndola. El filtrado vive en protección de correo; el SIEM necesita la auditoría.
Detección resultante: una regla de bandeja creada o modificada en la hora siguiente a un inicio desde una red desconocida, que mueve mensajes con «factura» o «pago» a una carpeta que nadie abre.
Cortafuegos y VPN: ¿completos o filtrados?
Filtrados, y la división la da el propio fabricante. PAN-OS, como ejemplo documentado, separa sus registros por tipo: los de tráfico anotan el inicio y el fin de cada sesión, y los de amenazas, filtrado de URL, autenticación, configuración y GlobalProtect son flujos aparte. Llévate completos los pequeños: acceso remoto y cambios de configuración son baratos y traen señal. Filtra el tráfico a denegaciones de perímetro y salidas.
Detección resultante: un acceso remoto correcto de un usuario cuyos inicios interactivos de esos 15 minutos vienen de otro país. Funciona solo porque la identidad entró primero.
Planos de control cloud: la fuente útil más barata
Son pequeños y describen lo que hace un atacante para conservar el acceso. AWS CloudTrail registra cuatro tipos de evento —gestión, datos, actividad de red e Insights— y, por defecto, un trail registra los de gestión pero no los de datos ni los de Insights. Los de gestión son los que quieres. Los de datos, «actividades a menudo de gran volumen» en ese documento, se añaden por tipo de recurso: deja ese interruptor.
Detección resultante: una clave de acceso nueva para una identidad que nunca tuvo ninguna, o el registro desactivándose.
¿Por qué los servidores y las aplicaciones van al final?
Una excepción: si la autenticación sigue en un Active Directory local, el registro del controlador de dominio es tu fuente de identidad y pasa al primer paso. El resto —servidores de ficheros, hipervisores, el ERP, la aplicación con formato propio— va al final porque nada interpreta sus campos ni hay regla que los lea. Es almacenamiento, no detección.
El orden, con sus contrapartidas
| Fuente | Qué detecta que no detecta nada más | Volumen | Prioridad |
|---|---|---|---|
| Identidad (Entra ID, Okta) | Secuestro de cuenta, ataques de contraseñas, cambios de privilegio y MFA | Bajo si los inicios no interactivos van agrupados | 1 — semana 1 |
| Endpoint / EDR | Qué se ejecutó: procesos, argumentos, conexiones | El mayor de host; filtra en el agente | 2 — semana 2 |
| Auditoría de correo | Reglas de bandeja, accesos delegados, lecturas masivas | Pequeño; el seguimiento de mensajes es la parte grande | 3 — semana 2 |
| Cortafuegos y VPN | Accesos remotos, salidas maliciosas, cambios en el equipo | El tráfico domina; quédate con las denegaciones | 4 — semana 3 |
| Plano de control cloud | Creación de claves, cambios de rol, registro desactivado | Bajo en gestión; en datos, no | 5 — semana 3 |
| Consultas DNS | Balizas y dominios maliciosos conocidos | Grande; pide una lista con la que comparar | 6 — tras el día 30 |
| Servidores y aplicaciones | Contexto en una investigación | Suele pedir un analizador propio | 7 — cuando haga falta |
¿Qué no deberías ingerir todavía?
- Depuración y trazas. Responden preguntas de ingeniería y son la vía rápida a una sorpresa de volumen.
- Flujos de red detallados, tráfico interno y eventos de datos cloud. Útiles con un programa de detección maduro, ilegibles sin él.
- Lo que nadie pueda atar a una pregunta. Si nadie sabe qué alerta o búsqueda alimenta, es almacenamiento: un mapeo de campos, un analizador que se rompe con la siguiente actualización y alertas que afinar.
¿Cómo compruebas que una fuente funciona de verdad?
«Conectada» en una consola significa que llegaron datos una vez. Verifica cada fuente con un evento tuyo:
- Identidad: falla un inicio en una cuenta de prueba y busca esa cuenta y ese motivo; mira que llegan los dos tipos.
- Endpoint: ejecuta un comando inofensivo con un argumento distintivo y busca ese argumento, no el binario.
- Correo: crea una regla con un nombre reconocible en un buzón de prueba y busca ese nombre.
- Cortafuegos y VPN: provoca una salida denegada, edita una regla y busca las dos entradas.
- Cloud: crea y borra una credencial fuera de producción; busca los dos eventos.
- Todas: pon una alerta de silencio; una fuente que calló hace tres semanas se parece a una semana tranquila.
Una secuencia de 30 días
- Días 1-2: lista las fuentes candidatas, pon un responsable y escribe qué pregunta responde cada una.
- Días 3-4: conecta inicio de sesión y auditoría de identidad; verifica con un inicio fallido.
- Días 5-7: escribe tres detecciones: ubicación inesperada, ráfaga de fallos con acierto y cambio de privilegio o MFA fuera de ventana.
- Días 8-11: conecta el endpoint, confirma las líneas de comandos y anota la cifra diaria.
- Días 12-14: conecta la auditoría del correo y publica la detección de reglas de bandeja.
- Días 15-18: conecta cortafuegos y VPN con el filtro puesto y añade la regla de acceso remoto frente a ubicación.
- Días 19-22: conecta los eventos de gestión cloud y añade creación de claves y registro desactivado.
- Días 23-26: pon alertas de silencio y recorre una alerta pasada solo con datos del SIEM, anotando lo que falte.
- Días 27-30: revisa qué saltó. Las reglas con solo falsos positivos se afinan o se borran. Añade la fuente que faltaba.
¿Qué significa «hecho» el día 30?
Cuatro cosas. Identidad, endpoint y correo envían, cada una verificada con un evento tuyo y con su alerta de silencio. Cada fuente tiene detrás una detección o una búsqueda. Respondes «desde dónde inició sesión este usuario» y «qué hizo este proceso» en una búsqueda y no en tres consolas, que es para lo que está el módulo SIEM y búsqueda y el motivo de que te ayudemos a priorizar fuentes en el arranque. Y cada alerta de la semana acabó en una decisión: se actuó o se borró.
Servidores, aplicaciones y DNS siguen sin conectar; ese es el estado correcto. Cuatro fuentes entendidas con nueve reglas que funcionan ganan a veinte que nadie lee, y lo segundo es lo que hace que un equipo llame ruidosa a su plataforma cuando el problema era el orden.