Microsoft 365 / Investigar alertas de seguridad y responder a incidentes
Cuando reciba una alerta de seguridad de Microsoft 365, revise la hora del evento, la fuente de detección, los usuarios, dispositivos y mensajes afectados, y las alertas relacionadas antes de cerrarla. La gravedad por sí sola no basta para decidir. Varias alertas relacionadas pueden agruparse en un incidente; investigue tanto la alerta individual como el conjunto del incidente.
Diferencia entre alertas e incidentes
Una alerta registra una actividad sospechosa detectada. Un incidente reúne alertas y pruebas relacionadas para ayudar a comprender el desarrollo del ataque. La guía de Microsoft para investigar incidentes de Defender explica cómo revisar conjuntamente las alertas, actividades, activos y pruebas. Las vistas y funciones de investigación automatizada disponibles dependen de los productos y las licencias de la organización.
Prepare el acceso y elija la pantalla de investigación
Abra Incidentes y alertas → Alertas en el portal de Microsoft Defender. Incluso si puede verlos con permisos de lector de seguridad, no significa que pueda realizar acciones de respuesta como bloqueo de cuentas o aislamiento de dispositivos. Primero, verifique el modelo de permisos de Defender de su organización, el alcance de las responsabilidades y las licencias del producto, y designe al personal de investigación y respuesta.
La experiencia de casos de incidentes está en vista previa, y la experiencia de incidentes heredada sigue estando disponible. Si su organización utiliza casos de incidentes, abra Cases → Incident en la interfaz en inglés, seleccione el caso y revise sus alertas, activos, evidencias y actividades. Una navegación diferente no significa por sí sola que los registros estén ausentes. Utilice la guía de investigación de casos de incidentes de Microsoft para ajustar las instrucciones a la pantalla y permisos disponibles. En el modelo unificado de control de acceso basado en roles (RBAC), Security Data Read permite ver e investigar, mientras que Security Data Manage también permite la gestión de casos; acciones de respuesta específicas tienen sus propios requisitos de permisos y carga de trabajo.
Lista de verificación de respuesta inicial
- Abra la lista de incidentes o alertas en el portal de Microsoft Defender. Designe al personal responsable dentro del equipo y registre el número de incidente para evitar el manejo duplicado del mismo caso.
- Verifique la gravedad, el tiempo de detección y las cuentas, correos electrónicos y dispositivos afectados. No confirme una violación real basándose únicamente en el título de la alerta.
- En los detalles del incidente, revise las alertas relacionadas, la cronología de actividad, las pruebas y los resultados de las acciones automatizadas. Consulte el significado de los estados y las clasificaciones en la guía de Microsoft para investigar alertas.
- Si existe una alta probabilidad de una amenaza real y el daño está en curso, notifique de inmediato al personal responsable según los procedimientos de respuesta a incidentes de la organización y determine el alcance del impacto y las medidas de aislamiento/bloqueo aprobadas. Preserve la evidencia necesaria para la investigación mientras contiene la amenaza; no demore innecesariamente la contención urgente.
- Registre la causa y las acciones tomadas, y verifique si la misma actividad existe para otros usuarios o dispositivos. Monitoree para asegurar que las alertas no se repitan después de que se hayan tomado las medidas.
Registre evidencia y construya una línea de tiempo de la investigación
Registre no solo el nombre de la alerta, sino también el ID de alerta/incidente, el producto de detección, los tiempos de actividad inicial y más reciente y sus zonas horarias, así como la información de identificación del usuario, dispositivo o correo electrónico objetivo. Verifique las entidades reales para evitar confundir archivos con el mismo nombre o cuentas similares. No abra URL o adjuntos maliciosos directamente en las PC de trabajo diarias.
Vincule cronológicamente eventos confirmados como 'correo recibido → alerta relacionada con un enlace → inicio de sesión → acceso a datos'. No suponga que todos los eventos ocurrieron; distinga entre la evidencia existente y los hechos desconocidos. Por ejemplo, incluso si un usuario niega haber hecho clic, se deben verificar los registros relevantes y una filtración de contraseña no debe confirmarse únicamente con base en los registros de clics.
Investigue si existen alertas que afecten a otros usuarios relacionadas con el mismo remitente, archivo o URL. Esto se debe a que, incluso si se cierra una alerta que afecta a una cuenta, la misma actividad puede continuar en otra cuenta. Almacene los materiales en un lugar aprobado para la gestión de incidentes y no publique el correo electrónico original, la información del usuario ni los registros de acceso en canales públicos.
Cómo evaluar una alerta de phishing
| Situación confirmada | Qué revisar o hacer primero |
|---|---|
| El mensaje está en cuarentena y no se entrega al usuario | Verifique el resultado de la cuarentena y si fue entregado a otros destinatarios. Determine si es un ataque detectado/bloqueado |
| Llegó a la bandeja de entrada, pero la acción del usuario no está confirmada | Investigue el identificador del mensaje y el alcance de la entrega, y deje que el personal de seguridad determine la necesidad de eliminar o bloquear el mensaje |
| Se confirmó que el usuario ingresó una contraseña en la página enlazada | Priorice la respuesta debido a un posible compromiso de la cuenta. Proceda a bloquear el acceso, verificar las sesiones y los métodos de autenticación según los procedimientos aprobados |
| Se confirmó la ejecución maliciosa o el daño en curso en el dispositivo | Transfiera inmediatamente a la persona responsable de prevenir daños en curso y verifique el estado de finalización del aislamiento y las acciones aprobadas. |
Pueden ser necesarias acciones en múltiples servicios. Para la entrega de correo electrónico, consulte seguimiento de mensajes, y para inicio de sesión y autenticación, proceda a registros de inicio de sesión de Microsoft Entra. Cambiar únicamente la contraseña del usuario no es suficiente; el personal correspondiente debe definir el alcance de la investigación para garantizar que no queden métodos de autenticación sospechosos, reglas de reenvío y permisos de aplicaciones intactos.
Incluso cuando aparezcan acciones automáticas, distinga entre los estados solicitado, pendiente, fallido y completado. Dependiendo del producto, las funciones de investigación o respuesta automática pueden no estar disponibles, y solo ver un botón de respuesta en el portal no significa que la tarea se haya realizado. Preserve la evidencia y ejecute el bloqueo urgente simultáneamente, sin retrasar innecesariamente la prevención de daños en curso.
¿Podemos ignorarlo inmediatamente si parece un falso positivo?
No. Compare la evidencia con la explicación de la persona responsable para determinar si un cambio de política o una tarea operativa normal causó la alerta. Si clasifica una alerta como un falso positivo, registre la evidencia y el alcance que lo respalda. Evite desactivar reglas de alerta de forma generalizada, ya que podría dejar de detectar ataques reales. Cuando el mismo falso positivo se repita, considere un ajuste de alcance estrecho respaldado por la investigación.
Distinga una alerta que detectó y bloqueó correctamente una amenaza real de una alerta que identificó incorrectamente actividad normal como maliciosa. La ausencia de daños no convierte por sí sola una alerta en un falso positivo. Para una prueba aprobada o tarea operativa, compare la solicitud de trabajo, el tiempo de ejecución, el objetivo y la evidencia, luego registre la clasificación y determinación apropiadas. En la vista de alertas, Verdadero positivo, Actividad informativa prevista y Falso positivo representan diferentes conclusiones. Si se justifica el ajuste o la supresión, limite los objetivos afectados y establezca una fecha de expiración o revisión.
Verifique la recuperación antes de cerrar el incidente
- Estado actual de las cuentas/dispositivos afectados y presencia de alertas adicionales
- Acciones automáticas/manuales tomadas y cualquier acción que necesite ser revertida
- Finalización de notificaciones a usuarios y registros internos de incidentes
- Personas responsables de tareas para prevenir recurrencias, tales como políticas, capacitación y métodos de autenticación
El registro de cierre del incidente debe incluir los síntomas iniciales, el alcance del impacto, la evidencia de respaldo, los resultados reales de las acciones automatizadas y manuales, y el trabajo de seguimiento restante. Cambiar una alerta a Resuelta no elimina por sí mismo una amenaza. Cierre el incidente después de verificar que las cuentas y dispositivos afectados estén protegidos y que las operaciones comerciales se hayan recuperado. Revise por separado cualquier bloqueo temporal o cambio de política; la persona responsable solo debe revertir medidas cuando esa reversión esté justificada por las pruebas y se ajuste al alcance aprobado.




