Microsoft Sentinel, SIEM, SOAR y Respuesta a Incidentes

radio_button_uncheckedshort_text1. Introducción: de la centralización de registros a la respuesta orientada por contexto

La administración de seguridad comenzó con registros producidos por separado por servidores, sistemas operativos, cortafuegos y aplicaciones. A medida que las organizaciones conectaron más redes y servicios, se volvió inviable analizar cada registro manualmente. Surgieron plataformas de gestión de eventos y, luego, soluciones SIEM, capaces de centralizar datos, correlacionar señales y apoyar investigaciones. Con el crecimiento del volumen de alertas, el SOAR agregó automatización y orquestación para que los equipos de seguridad respondieran con mayor rapidez y consistencia.

Esta evolución contribuye directamente a la continuidad de los servicios digitales, la protección de los datos personales y la reducción del impacto de los ataques. Hospitales, escuelas, bancos, empresas y organismos públicos dependen de sistemas que generan millones de eventos. Transformar estos registros en un contexto que pueda ser investigado permite descubrir amenazas más temprano, priorizar lo que realmente importa y reducir el tiempo entre la detección y la contención.

Microsoft Sentinel materializa este enfoque en una solución nativa en la nube. Recoge datos de fuentes de Microsoft y no Microsoft, realiza análisis, produce alertas, organiza incidentes, permite la búsqueda proactiva y automatiza respuestas. El valor real aparece cuando estos componentes forman un ciclo: una investigación mejora la detección; la detección activa una automatización; la automatización libera al analista para investigar casos más complejos.

Pregunta-guía

Si un único inicio de sesión fallido puede ser normal, ¿en qué momento cientos de fallos, una IP anónima y un cambio privilegiado pasan a representar un incidente? El SIEM existe para reunir señales dispersas y ofrecer contexto para esa decisión.

radio_button_uncheckedshort_text2. SIEM, SOAR, XDR y el papel del SOC

2.1 Security Operations Center (SOC)

SOC es la función organizacional responsable de monitorear, detectar, investigar y responder a amenazas. Puede ser un equipo interno, un servicio tercerizado o un modelo híbrido. Personas, procesos y tecnología necesitan actuar juntos: herramientas sin procedimientos generan inconsistencia; procesos sin telemetría generan decisiones tardías; automatización sin supervisión puede amplificar errores.

2.2 Definiciones esenciales

Trampa de prueba

SIEM no es solo almacenamiento de registros. SOAR no es solo un script. XDR no reemplaza automáticamente la visibilidad amplia del SIEM. Cada concepto resuelve una parte diferente de las operaciones de seguridad.

radio_button_uncheckedshort_text3. Qué es Microsoft Sentinel

Microsoft Sentinel es el SIEM nativo en la nube de Microsoft y una plataforma de operaciones de seguridad. Su propuesta es ofrecer recolección escalable, análisis, detección, investigación, hunting, visualización y respuesta automatizada en entornos multicloud y multiplataforma. Al ser un servicio en la nube, reduce la necesidad de mantener la infraestructura tradicional de un SIEM local, pero aún requiere arquitectura de datos, gobernanza, permisos, reglas y procesos operativos bien definidos.

3.1 Componentes funcionales

3.2 Nativo de la nube no significa automático por defecto

El Sentinel ofrece contenido listo, pero la organización necesita elegir fuentes, retención, cobertura, permisos, detecciones, responsables y criterios de respuesta. Recopilar todo sin un objetivo puede aumentar el costo y el ruido. Recopilar poco puede crear puntos ciegos. Una implementación madura comienza con casos de uso: qué activos críticos existen, qué amenazas son relevantes, qué datos sustentan la detección y qué acción se tomará cuando surja la señal.

Actualización de plataforma

La experiencia actual converge en el portal Microsoft Defender, reuniendo Sentinel, Defender XDR y recursos de IA. Microsoft anunció que, después del 31 de marzo de 2027, Sentinel dejará de tener soporte en el portal de Azure. Para el SC-900, memorice principalmente las capacidades, no la posición exacta de los menús.

3.3 Nivel de análisis y lago de datos de Microsoft Sentinel

Microsoft Sentinel organiza los datos de seguridad en dos niveles complementarios. El nivel de análisis conserva los datos operativos utilizados en alertas casi en tiempo real, hunting e investigación de incidentes. El lago de datos ofrece almacenamiento de largo plazo, en formato abierto, para reunir grandes volúmenes de datos y analizarlos con KQL, análisis de grafos, Microsoft Modeling Language, notebooks y herramientas de IA. Los datos pueden reflejarse entre ambos niveles, y la retención en el lago de datos puede alcanzar 12 años, según la configuración y las licencias.

3.4 Grafo y servidor MCP hospedado

El Grafo de Microsoft Sentinel representa usuarios, dispositivos, recursos, datos, actividades y acciones del atacante como nodos y relaciones conectadas. De este modo, los analistas y agentes de IA pueden evaluar impacto, exposición y posibles rutas de ataque sin depender únicamente de filas aisladas. El servidor hospedado de Model Context Protocol (MCP) proporciona herramientas orientadas a escenarios para explorar datos, clasificar incidentes, realizar threat hunting y crear agentes de Microsoft Security Copilot. Usa Microsoft Entra para la identidad, se integra de forma nativa con los datos de Sentinel y Microsoft Defender y evita que el cliente tenga que implementar una infraestructura MCP independiente.

radio_button_uncheckedshort_text4. Conectores de datos e ingestión

Un SIEM depende de la telemetría. Microsoft Sentinel ofrece más de 350 conectores preparados y también admite conexiones personalizadas o sin código. Estos conectores guían o automatizan la entrada de registros de servicios Microsoft, recursos de Azure, sistemas locales, otras nubes, dispositivos de red, productos de seguridad y aplicaciones SaaS. Algunas fuentes envían datos directamente; otras utilizan agentes, Syslog, Common Event Format (CEF), API, reglas de recopilación o integraciones específicas. La normalización ayuda a comparar eventos que llegan con esquemas diferentes.

4.1 Lo que un conector puede proporcionar

• Instrucciones de implementación, permisos y requisitos previos.
• Tablas o destinos en los que se almacenarán los registros.
• Parsers y normalización para hacer que los eventos de fuentes diferentes sean más consistentes.
• Reglas analíticas, hunting queries, workbooks y otros contenidos relacionados.
• Indicadores de integridad, volumen y última recepción de datos.

4.2 Content hubs y soluciones

El Content hub funciona como catálogo de soluciones. Una solución puede agrupar varios artefactos para un producto o escenario, evitando que el analista cree todo desde cero. Instalar una solución no garantiza que los datos estén llegando ni que todas las reglas deban ser habilitadas sin ajuste. El contenido necesita ser configurado, probado y adaptado al entorno.

Principio operativo

Sin datos relevantes e íntegros, la mejor regla analítica no detecta nada. Antes de ajustar alertas, confirme cobertura, latencia, esquema, volumen, retención y calidad de la fuente.

radio_button_uncheckedshort_text5. Organización de los datos, Log Analytics y KQL

5.1 Tablas, columnas y registros

Los datos de seguridad se organizan en tablas. Cada fila representa un registro, y las columnas almacenan atributos como hora, usuario, dirección IP, dispositivo, acción y resultado. Ejemplos comunes incluyen registros de inicio de sesión, actividad de Azure, eventos de seguridad y alertas. La tabla correcta depende del conector y del tipo de dato ingerido.

5.2 Lenguaje de Consulta Kusto (KQL)

KQL es el lenguaje de consulta utilizado para buscar y transformar datos en Sentinel y en otros servicios basados en Azure Data Explorer y Azure Monitor. Es declarativo: el analista describe qué datos desea filtrar, resumir, combinar y proyectar. En el SC-900, lo más importante es reconocer que KQL respalda consultas, hunting y muchas reglas analíticas; no es necesario dominar sintaxis avanzada.

SigninLogs | where TimeGenerated > ago(1h) | where ResultType != 0 | summarize Fallos=count() by UserPrincipalName, IPAddress | where Fallos >= 10 | order by Fallos desc La consulta anterior busca entradas fallidas en la última hora, agrupa los intentos por usuario e IP, mantiene grupos con al menos diez fallos y ordena los resultados. No prueba un ataque: puede representar contraseña antigua, aplicación mal configurada o password spray. El contexto de la investigación decide.

radio_button_uncheckedshort_text6. Reglas analíticas y detección de amenazas

Reglas analíticas transforman datos en señales de seguridad. Definen qué buscar, con qué frecuencia evaluar, qué período consultar, cómo mapear entidades y cuándo crear alertas e incidentes. Una detección útil debe equilibrar sensibilidad y precisión: reglas demasiado abiertas generan fatiga de alertas; reglas demasiado restrictivas dejan pasar amenazas.

6.1 Tipos y enfoques de detección

6.2 Elementos de una regla

• Consulta o fuente que define la lógica de detección.
• Frecuencia de ejecución y ventana de observación.
• Umbral que determina cuándo el resultado se convierte en alerta.
• Severidad, tácticas y técnicas MITRE ATT&CK.
• Mapeo de entidades, como cuenta, host, IP, URL, archivo y proceso.
• Agrupamiento de alertas y creación de incidentes.
• Supresión y ajustes para reducir duplicidad o ruido.

6.3 IA, Fusion y correspondencia con inteligencia sobre amenazas

Sentinel combina tres enfoques generales de detección. La detección basada en reglas busca patrones conocidos y condiciones definidas. La detección mediante IA y aprendizaje automático establece líneas base de comportamiento y usa capacidades como Fusion para correlacionar señales de menor gravedad, procedentes de varias fuentes, en un incidente coherente. La correspondencia con inteligencia sobre amenazas compara direcciones IP, dominios, URL, hashes y otros indicadores observados con infraestructura maliciosa conocida. La cobertura se puede asignar al marco MITRE ATT&CK, mientras que las soluciones del Content hub empaquetan conectores, reglas, consultas de hunting, analizadores, workbooks y playbooks para escenarios comunes.

Calidad de detección

Una regla debe ser verificable y accionable. Antes de habilitarla ampliamente, valida si los datos existen, si se ha considerado el comportamiento legítimo y si el SOC sabe qué investigar y cómo responder.

radio_button_uncheckedshort_text7. Eventos, alertas, incidentes, entidades y evidencias

7.1 ¿Por qué correlacionar?

Un invasor puede generar señales en momentos y productos diferentes: correo electrónico de phishing, inicio de sesión anómalo, creación de proceso, acceso a archivo y comunicación de red. Correlacionar estas señales reduce la fragmentación y ayuda a reconstruir la cadena de ataque. Sin embargo, correlacionar no significa certeza; el analista aún necesita validar la línea de tiempo, la legitimidad de las acciones y el alcance afectado.

Trampa de prueba

Las alertas son señales; los incidentes son casos organizados para investigación. Un incidente puede contener una o varias alertas y puede terminar clasificado como falso positivo, actividad esperada o incidente verdadero.

radio_button_uncheckedshort_text8. Investigación y respuesta a incidentes

La investigación transforma un conjunto de señales en entendimiento operativo. El analista busca responder: qué ocurrió, cuándo comenzó, qué entidades participaron, cuál fue el vector inicial, qué acciones se ejecutaron, qué activos fueron afectados y qué contención es necesaria. Sentinel ofrece incidentes, línea de tiempo, relaciones entre entidades, consultas, comentarios, tareas e historial de acciones para organizar este trabajo.

8.1 Ciclo simplificado de respuesta

1. Selección: verificar severidad, contexto, duplicidad, criticidad del activo y credibilidad de la señal. 2. Investigación: reconstruir línea de tiempo, consultar datos adicionales y evaluar entidades y evidencias. 3. Contención: limitar el daño, por ejemplo aislando el dispositivo, bloqueando indicador o deshabilitando credencial. 4. Erradicación: eliminar persistencia, malware, reglas maliciosas, vulnerabilidades o configuraciones utilizadas en el ataque. 5. Recuperación: restaurar operaciones con monitoreo reforzado y validación del estado seguro. 6. Aprendizaje: registrar causa, impacto, decisiones y mejoras en reglas, playbooks y controles preventivos.

8.2 Métricas importantes

radio_button_uncheckedshort_text9. Threat hunting e investigación proactiva

Threat hunting es la búsqueda proactiva de amenazas que aún no han generado una alerta confiable. En lugar de esperar que se active una regla, el analista parte de una hipótesis basada en inteligencia, cambios en el entorno, comportamiento inusual o técnica adversaria. El resultado puede confirmar actividad legítima, revelar un incidente o generar una nueva detección automatizada.

9.1 Hunting query, hunt y bookmark

Hunting no debe confundirse con la investigación aleatoria. Una hipótesis clara define el comportamiento esperado, los datos necesarios, los criterios de validación y la acción posterior. Sin esta disciplina, las consultas pueden producir muchos resultados sin generar conocimiento o mejora operativa.

radio_button_uncheckedshort_text10. Workbooks, visualizaciones y monitoreo

Los workbooks son experiencias interactivas de visualización y análisis basadas en datos. Pueden combinar consultas, gráficos, tablas, métricas, filtros y textos explicativos para acompañar la postura operativa, tendencias de incidentes, actividad de identidades, cobertura de fuentes o rendimiento de las detecciones. Las soluciones instaladas por el Content hub frecuentemente incluyen workbooks listos para fuentes específicas.

10.1 Los workbooks no son reglas de detección

10.2 Visualización útil

• Define el público y la decisión que el panel debe apoyar.
• Muestra tendencia y contexto, no solo números aislados.
• Permite filtrar por período, severidad, origen, entidad o ambiente.
• Evita el exceso de gráficos y métricas sin la acción correspondiente.
• Documenta consultas, límites y posibles lagunas de datos.

Ejemplo

Un workbook puede mostrar fallas de autenticación por país y usuario. Ayuda a observar tendencias, pero no bloquea el acceso ni crea necesariamente un incidente. Una regla analítica o política de identidad realiza esa otra función.

radio_button_uncheckedshort_text11. SOAR: reglas de automatización y playbooks

El Sentinel implementa capacidades SOAR principalmente a través de reglas de automatización y playbooks. Las reglas de automatización gestionan el flujo de tratamiento de incidentes y alertas en un punto central. Pueden asignar responsables, cambiar la severidad o el estado, agregar etiquetas, crear tareas y ejecutar playbooks en un orden definido.

Los playbooks son flujos de trabajo construidos en Azure Logic Apps. Utilizan disparadores, condiciones, conectores y acciones para interactuar con el Sentinel y sistemas externos. Un playbook puede ejecutarse automáticamente mediante una regla de automatización o manualmente por un analista sobre un incidente, alerta o entidad.

radio_button_uncheckedshort_text12. Diseñando automatizaciones seguras y confiables

La automatización puede reducir el tiempo de respuesta, pero también ejecuta acciones a escala. Por eso, debe ser tratada como software de producción: tener propietario, control de versiones, pruebas, monitoreo, manejo de errores, permisos mínimos y procedimiento de reversión. La decisión de automatizar depende de la confianza en la detección y del impacto de la acción.

12.1 Ejemplo: posible compromiso de cuenta

7. Una regla analítica identifica varias fallas seguidas de inicio de sesión exitoso desde infraestructura anónima. 8. Sentinel crea una alerta, mapea la cuenta y la dirección IP y agrupa la señal en un incidente. 9. Una regla de automatización agrega la etiqueta “Identidad”, asigna el incidente a la fila correspondiente y crea tareas de revisión. 10. Un playbook consulta la reputación de la IP, datos de riesgo de la identidad y actividad reciente de la cuenta. 11. Si se cumplen los criterios de alta confianza, el playbook revoca sesiones y notifica al equipo; la desactivación de la cuenta puede requerir aprobación humana. 12. El analista valida el impacto, concluye la contención y registra el resultado para ajustar la regla y el playbook.

12.2 Niveles de automatización

radio_button_uncheckedshort_text13. Integración con Microsoft Defender XDR

Microsoft Defender XDR reúne señales nativas de endpoints, identidades, correo electrónico, aplicaciones y otros productos Defender. La integración con Sentinel permite combinar esta profundidad XDR con la amplitud del SIEM, que recibe datos de Microsoft y no Microsoft. Los incidentes y eventos se pueden sincronizar e investigar en el portal de Microsoft Defender, reduciendo el cambio de herramientas.

13.1 Beneficios de la unificación

• Fila de incidentes e investigación más consolidadas.
• Correlación entre señales del ecosistema Defender y fuentes externas.
• Hunting avanzado sobre datos integrados.
• Mejor contexto de entidades y cadena de ataque.
• Automatización y respuesta coordinadas.
• Acceso a experiencias integradas del Security Copilot, cuando esté licenciado y habilitado.

Diferencia esencial

Defender XDR ofrece detecciones y respuestas profundas en dominios protegidos. Sentinel amplía la recopilación, correlación, hunting y SOAR para un ecosistema más amplio. La integración combina profundidad y amplitud.

radio_button_uncheckedshort_text14. Microsoft Security Copilot en el contexto de Sentinel

Microsoft Security Copilot utiliza IA generativa y datos de seguridad para ayudar a los analistas. En el contexto de Sentinel y del portal Microsoft Defender, puede resumir incidentes, explicar scripts y comandos, evaluar archivos sospechosos, resumir identidades y dispositivos, generar informes y consultas KQL, consolidar inteligencia sobre amenazas y orientar la investigación y la respuesta. Esta integración presenta el contexto con mayor rapidez, pero no sustituye el criterio del analista: los resultados deben compararse con las evidencias, permisos y procedimientos de la organización.

14.1 Experiencias insertada y autónoma

En la experiencia insertada, los incidentes de Sentinel se unifican con los incidentes de Microsoft Defender XDR en el portal Microsoft Defender, lo que permite usar Copilot durante la investigación sin cambiar de herramienta. En el portal autónomo de Microsoft Security Copilot, Sentinel se conecta como origen de datos mediante los plugins Microsoft Sentinel y Natural language to KQL for Microsoft Sentinel. Esta experiencia conversacional permite preguntar por incidentes, entidades, reputación y datos almacenados. Las licencias, la capacidad, los permisos y la incorporación determinan la disponibilidad en ambas experiencias.

14.2 Capacidades dirigidas por el analista

14.3 Lenguaje natural, plugins y promptbook

En el portal autónomo, Natural language to KQL for Microsoft Sentinel convierte una intención en una consulta inicial sobre los datos de Sentinel y Advanced Hunting. Los plugins conectan Copilot con los orígenes autorizados, mientras que un promptbook encadena una secuencia reutilizable de prompts. El promptbook de investigación de incidentes de Sentinel, por ejemplo, reúne el incidente, las alertas, las entidades y el contexto para acelerar la clasificación sin convertir la salida en una decisión automática.

14.4 Agentes autónomos de IA

14.5 Control humano y salvaguardas

• Las respuestas pueden contener inferencias incorrectas o información incompleta.
• El acceso respeta permisos, pero el usuario debe evitar exponer datos más allá de lo necesario.
• Las consultas generadas necesitan ser ejecutadas e interpretadas por alguien que entienda el entorno.
• Las acciones de contención siguen exigiendo responsabilidad y supervisión humana.
• Los prompts claros deben indicar objetivo, contexto, fuente y formato esperado.
• Los agentes y las respuestas automatizadas deben operar con alcance, auditoría, permisos mínimos y puntos de aprobación definidos.

Principio de responsabilidad

Microsoft Security Copilot acelera el análisis; no transfiere la responsabilidad de la decisión. En incidentes de alto impacto, las evidencias y el proceso aprobado prevalecen sobre la fluidez de la respuesta generada.

radio_button_uncheckedshort_text15. Escenario práctico integrado: ataque a una cuenta privilegiada

Considere una empresa que conecta al Sentinel registros de Microsoft Entra ID, Defender XDR, firewall, servidores Linux y una aplicación financiera. Una cuenta administrativa recibe varios fallos de autenticación, seguidos de un inicio de sesión exitoso en una ubicación inusual. Minutos después, hay un cambio de privilegio y acceso atípico a la aplicación.

15.1 Qué podría salir mal

• El conector de auditoría no estaba activo, ocultando el cambio de privilegio.
• La regla generaba tantos falsos positivos que la alerta fue ignorada.
• El playbook tenía permisos excesivos o falló silenciosamente.
• Los registros tenían retención insuficiente para reconstruir la línea de tiempo.
• El incidente se cerró sin registrar clasificación ni lecciones aprendidas.

Visión sistémica

Sentinel no compensa por sí solo una identidad sin MFA, un dispositivo vulnerable o permisos excesivos. Integra señales y respuesta, pero la reducción de riesgo depende de controles preventivos, detección, personas y procesos.

radio_button_uncheckedshort_text16. Conclusión y revisión para el SC-900

Microsoft Sentinel representa la evolución del SIEM hacia una plataforma nativa de la nube para operaciones de seguridad. Recopila y normaliza datos de diversas fuentes, distribuye el análisis entre el nivel operativo y el lago de datos, aplica reglas, IA, Fusion e inteligencia sobre amenazas, correlaciona señales en incidentes, ofrece investigación y hunting mediante KQL y el Grafo de Sentinel y automatiza respuestas con reglas de automatización y playbooks de Azure Logic Apps.

En mi evaluación, el principal valor del Sentinel no reside en una funcionalidad aislada, sino en la capacidad de transformar telemetría dispersa en un proceso operativo repetible. Una organización madura no mide el éxito por el número de registros o alertas, sino por la cobertura de riesgos relevantes, la calidad de las detecciones, la velocidad de investigación, la consistencia de la respuesta y el aprendizaje continuo.

La integración con Microsoft Defender XDR amplía el contexto entre identidades, endpoints, correo electrónico y aplicaciones. Microsoft Security Copilot acelera resúmenes, análisis, consultas, informes y respuestas guiadas, mientras que los agentes autónomos ayudan a evaluar alertas y detectar lagunas de detección. Aun así, la tecnología no elimina la necesidad de analistas, gobernanza, datos confiables y validación humana.

16.1 Revisión rápida

radio_button_uncheckedshort_text17. Preguntas de repaso

1. ¿Qué recurso de Microsoft Sentinel se utiliza principalmente para conectar fuentes de registros y alertas?

A) Cuaderno de trabajo B) Conector de datos C) Libro de jugadas D) Incidente

Comentario

Respuesta correcta: B. Los conectores de datos integran fuentes al Sentinel y guían la ingestión. Los workbooks visualizan datos; los playbooks automatizan respuestas; los incidentes organizan la investigación.

2. ¿Qué alternativa describe correctamente la relación entre alerta e incidente?

A) Todo evento es un incidente. B) Los incidentes se usan solo para almacenar paneles. C) Una alerta es una señal de posible amenaza, y un incidente organiza una o más alertas y contexto para investigación. D) Las alertas se crean solo mediante playbooks.

Comentario

Respuesta correcta: C. Las alertas representan señales. Los incidentes agrupan alertas, entidades, evidencias y acciones para la clasificación, investigación y respuesta.

3. ¿Qué afirmación diferencia correctamente una regla de automatización de un playbook?

A) Ambos son solo consultas KQL. B) La regla de automatización coordina cuándo y en qué orden ocurren las acciones; el playbook ejecuta un flujo de trabajo basado en Azure Logic Apps. C) Los playbooks solo crean gráficos. D) Las reglas de automatización sirven solo para ingestión.

Comentario

Respuesta correcta: B. La regla administra el flujo de tratamiento y puede llamar a un playbook, mientras que el playbook implementa integraciones y lógica de respuesta.

4. ¿Cuál es el principal objetivo del threat hunting?

A) Sustituir todos los controles preventivos. B) Buscar proactivamente amenazas aún no detectadas, basándose en hipótesis y consultas. C) Crear firmas digitales. D) Configurar redes virtuales.

Comentario

Respuesta correcta: B. Hunting es investigación proactiva sobre datos existentes y puede resultar en incidente, nueva regla o mejora de respuesta.

5. ¿Cuáles son las cuatro áreas operativas centrales de Microsoft Sentinel?

A) Comprar, vender, facturar y archivar B) Recopilar, detectar, investigar y responder C) Crear, compilar, probar e implementar D) Identificar, autenticar, licenciar y eliminar

Comentario

Respuesta correcta: B. Sentinel reúne datos, detecta amenazas, proporciona contexto para investigar y permite respuestas manuales o automatizadas.

6. ¿Para qué sirve un promptbook en Microsoft Security Copilot?

A) Sustituir el lago de datos B) Encadenar una secuencia reutilizable de prompts C) Crear una subred D) Almacenar claves de cifrado

Comentario

Respuesta correcta: B. Un promptbook coordina prompts para reunir, analizar y presentar contexto al analista de forma repetible.

7. ¿Qué enfoque reduce mejor la fatiga de alertas?

A) Tratar todos los eventos como críticos B) Agrupar señales relacionadas, priorizar por gravedad y enriquecer la evaluación C) Deshabilitar registros D) Crear un playbook por cada fila de registro

Comentario

Respuesta correcta: B. La correlación en incidentes, la priorización y el enriquecimiento automatizado reducen el ruido sin eliminar la visibilidad necesaria.

8. ¿Qué afirmación describe mejor Microsoft Security Copilot?

A) Decide y contiene todos los incidentes sin supervisión B) Ayuda a investigar y responder con IA generativa, manteniendo la validación humana C) Es un firewall de red D) Sustituye conectores y reglas analíticas

Comentario

Respuesta correcta: B. Copilot acelera el trabajo con contexto e IA generativa, pero el analista sigue siendo responsable de la validación y de las decisiones finales.

radio_button_uncheckedshort_text18. Glosario y referencias

Glosario esencial

radio_button_uncheckedshort_textReferencias oficiales consultadas

• Microsoft Learn. Guía de estudio para el Examen SC-900: Fundamentos de Seguridad, Cumplimiento e Identidad de Microsoft. Actualizado el 26 de jun. de 2026.
• Microsoft Learn. ¿Qué es Microsoft Sentinel? / ¿Qué es Microsoft Sentinel SIEM? Actualizado en mayo de 2026.
• Microsoft Learn. Conecta fuentes de datos a Microsoft Sentinel utilizando conectores de datos. Actualizado en 2026.
• Microsoft Learn. Threat hunting en Microsoft Sentinel. Actualizado el 15 jun. 2026.
• Microsoft Learn. Automatización en Microsoft Sentinel; Azure Logic Apps para playbooks de Microsoft Sentinel; Crear y administrar playbooks de Microsoft Sentinel. Actualizados en 2026.
• Microsoft Learn. Integración de Microsoft Defender XDR con Microsoft Sentinel. Actualizado en 2026.
• Microsoft Learn. Lago de datos, Grafo de Microsoft Sentinel y servidor MCP hospedado. Actualizado en 2026.
• Microsoft Learn. Integración de Microsoft Security Copilot con Microsoft Sentinel, resumen de incidentes, agentes autónomos y lenguaje natural a KQL. Actualizado en 2026. Nota editorial: el contenido fue escrito para estudio conceptual del SC-900. Los nombres de menús, disponibilidad, licencias y características en versión preliminar pueden cambiar; consulte la documentación oficial antes de tomar decisiones de implementación.