Microsoft Sentinel: Guía de investigación de incidentes para analistas principiantes

Antes de la investigación: Preparativos básicos

Un analista necesita los permisos adecuados para ver, asignar y modificar un incidente. Microsoft especifica Sentinel Responder como uno de los roles requeridos para la investigación. Los permisos deben seguir el Principio de mínimo privilegio, y en una organización real es importante separar la visualización de datos sensibles de las acciones de respuesta, como el aislamiento de un activo o la deshabilitación de un usuario.

Asegúrese de que el incidente incluya entidades útiles. El mapeo de entidades en una regla de análisis permite al sistema identificar Cuentas, Hosts, IPs, URLs, Archivos o Procesos. Sin mapeo, la investigación gráfica y los enlaces al contexto serán limitados. Además, verifique que los conectores de datos estén sanos y que no haya un retraso significativo en la ingesta.

Antes de abrir un incidente, defina el SLA o el objetivo de triage, el propietario y los criterios de escalada. Un incidente sin propietario puede esperar incluso cuando la gravedad es alta.

Paso 1: Leer la cola de incidentes

En la cola de incidentes, se realiza la priorización inicial. No se conforme solo con la gravedad. Verifique la hora de creación, la última actividad, el producto, las tácticas, el número de alertas, las entidades, el propietario y el estado. Conecte esto con la criticidad del activo y la identidad del usuario. Un evento medio en una cuenta privilegiada puede recibir una prioridad más alta que un evento alto en un activo aislado en un laboratorio.

Paso 2: Abrir el incidente y comprender la historia

Lea el resumen y la lista de alertas. Varias alertas pueden ser el resultado de la misma regla o de diferentes productos. Verifique si el agrupamiento de alertas consolidó una actividad lógica o creó un incidente demasiado amplio. Preste atención al rango de tiempo: una alerta tardía puede extender el incidente y ocultar el inicio de la actividad.

Abra cada alerta principal y lea el origen de la detección, la descripción, la consulta o la evidencia, el umbral y las entidades. Pregunte: ¿cuál fue la condición que realmente se activó? ¿Se basa en un indicador, anomalía, comportamiento o correlación? ¿Cuál es el nivel de certeza? ¿Qué datos no se verificaron?

Evite el sesgo del título. Una alerta llamada "Cuenta comprometida" aún requiere verificación. Un nombre dramático no es evidencia.

Paso 3: Entidades y relaciones

Las entidades son los anclajes de la investigación. Comience con la cuenta, el host o la IP principal y verifique los Insights: actividad anterior, alertas adicionales, membresía en grupos, inicios de sesión, hosts relacionados y Threat intelligence. No confíe solo en el gráfico; muestra las relaciones que el sistema pudo mapear, no toda la realidad.

Para cada entidad, cree una breve ficha de investigación: identificador, tipo, propietario, criticidad, última buena conocida, actividad anómala y fuentes de datos. Cuando existan nombres similares, asegúrese de seguir el ID de objeto o SID y no solo el nombre para mostrar.

Preguntas para una cuenta de usuario

• ¿La cuenta es privilegiada o una cuenta de servicio?
• ¿Se activó MFA y cuál fue el resultado de la autenticación?
• ¿El IP, el dispositivo y el país son conocidos?
• ¿Existen fallos, restablecimientos, consentimientos o cambios de permiso?
• ¿El usuario confirma la actividad a través de un canal de comunicación confiable?

Preguntas para el host

• ¿La estación está administrada y actualizada?
• ¿Cuál es el árbol de procesos y la línea de comandos es anómala?
• ¿Existen conexiones, archivos o indicadores de persistencia?
• ¿Una alerta adicional de EDR o sensor de red apoya la historia?
• ¿El aislamiento de la estación afectará un servicio crítico?

Paso 4: Evidencia y línea de tiempo

La evidencia centraliza los hallazgos que el sistema vinculó al incidente. Verifique el origen, la hora y el valor. Distinga entre eventos sin procesar, evidencia de alertas y enriquecimiento. Un indicador que aparece en Threat Intelligence no es suficiente si no se encuentra una conexión con la actividad del activo.

La línea de tiempo organiza alertas, marcadores y acciones. Úsela para identificar el inicio, la expansión y la respuesta, pero también construya su propia línea de tiempo cuando haya fuentes externas a Sentinel. Normalice UTC, documente la hora del evento frente a la hora de ingesta y marque las brechas.

Las tareas pueden asegurar que el analista verifique los pasos necesarios: verificación de usuario, búsqueda de inicios de sesión, verificación de host, contacto con TI y adición de clasificación. Una tarea completada no significa que el resultado sea correcto; el ticket debe incluir lo que se verificó y lo que se encontró.

Paso 5: Búsqueda complementaria en los registros

La interfaz de incidentes proporciona contexto, pero una consulta complementaria en los registros suele ser el corazón de la investigación. Comience con la entidad y la ventana de tiempo, amplíe un poco antes y después de la actividad, y busque eventos que la apoyen o la contradigan.

let TargetUser = "student@contoso.example";
let StartTime = datetime(2026-08-01 08:30:00);
let EndTime = datetime(2026-08-01 10:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated asc

Después de la autenticación, verifique la actividad de auditoría, punto final, DNS o nube según la historia. No se extienda a todas las tablas sin un propósito. Cada consulta debe responder a una pregunta: ¿Hubo éxito? ¿Se creó una sesión? ¿Se realizó un cambio de permiso? ¿La estación creó un proceso o conexión anómala?

Escenario: Usuario e IP sospechosos

1. El incidente incluye una alerta sobre un inicio de sesión desde un país nuevo y otra alerta sobre una regla de bandeja de entrada creada.
2. El triaje identifica que el usuario trabaja en finanzas y que la actividad comenzó fuera del horario habitual.
3. En las entidades se verifican la IP, la cuenta y la aplicación. La IP no es una VPN conocida, y la cuenta no debería operar desde el país identificado.
4. KQL muestra varios fallos, un éxito con un método MFA anómalo y un cambio de buzón posterior.
5. El analista revisa los registros de auditoría, las sesiones, los consentimientos de OAuth y la actividad adicional del usuario. Se pone en contacto con el usuario a través de un canal verificado.
6. Después de confirmar que la actividad no es suya, el incidente se clasifica como True Positive y se escala a IR. Se realizan acciones de contención según el Playbook y la autorización.
7. El ticket documenta la línea de tiempo, las consultas, la evidencia, las acciones, los propietarios y las recomendaciones para mejorar la detección.

Clasificación, respuesta y cierre

La clasificación debe distinguir entre Verdadero Positivo, Falso Positivo y Positivo Benigno, de acuerdo con el modelo organizacional. Agregue una Razón y un Comentario que expliquen la evidencia. Un cierre sin justificación perjudica la sintonización y las métricas.

Si se requiere una respuesta, realícela según el Playbook: cancelar sesiones, restablecer credenciales, aislar el punto final, bloquear indicadores, guardar evidencia o contactar a los equipos. Las acciones irreversibles o con impacto comercial requieren la aprobación adecuada.

Antes de cerrar, asegúrese de que el alcance se haya verificado, que la actividad no continúa, que todas las tareas se hayan completado, que las lecciones aprendidas se hayan transmitido al propietario de la detección y que se hayan abierto acciones para corregir la causa raíz.

Lista de verificación de la investigación

• ✓Propietario y prioridad definidos.
• ✓Se leyó la lógica de cada alerta y no solo el título.
• ✓Cuentas, hosts e IPs verificados mediante identificadores estables.
• ✓Evidencia y línea de tiempo verificadas con las zonas horarias correctas.
• ✓Consultas complementarias realizadas en las fuentes relevantes.
• ✓Se separaron hechos, suposiciones e interpretación.
• ✓Clasificación y gravedad actualizadas con justificación.
• ✓Acciones de respuesta documentadas con tiempo y ejecutor.
• ✓Tareas de seguimiento creadas para sintonización o endurecimiento.

Errores comunes

• Asumir que todas las alertas en un incidente pertenecen al mismo ataque.
• Depender del gráfico de investigación sin verificar los registros sin procesar.
• Ignorar el retraso en la ingesta o la falta de una fuente de datos.
• Cerrar un Falso Positivo solo porque el usuario es conocido.
• Ejecutar búsquedas amplias sin una pregunta de investigación.
• Realizar una contención significativa sin comprender el impacto comercial.
• Cerrar un incidente sin enviar comentarios al propietario de la regla.

Resumen y CTA

Construya en un laboratorio un incidente simulado con una cuenta, una IP y dos alertas. Escriba cinco preguntas de investigación, una consulta para cada pregunta y una línea de tiempo corta. El objetivo no es presionar todas las opciones de la interfaz, sino mostrar cómo cada acción cambia una decisión. Luego, vaya al artículo de reglas de análisis para comprender cómo un incidente de calidad comienza con una detección que se puede investigar.

Preguntas frecuentes