Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los equipos del Centro de operaciones de seguridad (SOC) usan soluciones centralizadas de administración de eventos e información de seguridad (SIEM) y orquestación, automatización y respuesta (SOAR) de seguridad para proteger su patrimonio digital cada vez más descentralizado. Aunque los SIEMs heredados pueden mantener una buena cobertura de los recursos locales, las arquitecturas locales pueden tener una cobertura insuficiente para los recursos en la nube, como en Azure, Microsoft 365, AWS o Google Cloud Platform (GCP). Por el contrario, Microsoft Sentinel puede ingerir datos de recursos locales y en la nube, lo que garantiza la cobertura en todo el patrimonio.
En este artículo se describen los motivos para migrar desde un SIEM heredado y se describe cómo planear las distintas fases de la migración.
Pasos de la migración
En esta guía, aprenderá a migrar el SIEM heredado a Microsoft Sentinel. Siga el proceso de migración a través de esta serie de artículos, en los que aprenderá a navegar por los distintos pasos del proceso.
Nota:
Para un proceso de migración guiado, únase al Programa de migración y modernización de Microsoft Sentinel. El programa le permite simplificar y acelerar la migración, incluida la guía de procedimientos recomendados, los recursos y la ayuda de expertos en cada fase. Para más información, póngase en contacto con el equipo de su cuenta.
¿Qué es Microsoft Sentinel?
Microsoft Sentinel es una solución escalable, nativa de la nube, de administración de eventos e información de seguridad (SIEM) y orquestación, automatización y respuesta de seguridad (SOAR). Microsoft Sentinel ofrece análisis de seguridad inteligente e inteligencia sobre amenazas en toda la empresa. Microsoft Sentinel proporciona una única solución para la detección de ataques, la visibilidad de amenazas, la búsqueda proactiva y la respuesta a amenazas. Más información sobre Microsoft Sentinel.
¿Por qué migrar desde un SIEM heredado?
Los equipos de SOC se enfrentan a un conjunto de desafíos al administrar un SIEM heredado:
- Respuesta lenta a amenazas. Los SIEMs heredados usan reglas de correlación, que son difíciles de mantener e ineficaces para identificar amenazas emergentes. Además, los analistas de SOC se enfrentan a grandes cantidades de falsos positivos, muchas alertas de muchos componentes de seguridad diferentes y volúmenes cada vez mayores de registros. El análisis de estos datos ralentiza a los equipos de SOC en sus esfuerzos por responder a amenazas críticas en el entorno.
- Desafíos de escalado. A medida que aumentan las tasas de ingesta de datos, los equipos de SOC tienen el desafío de escalar su SIEM. En lugar de centrarse en la protección de la organización, los equipos de SOC deben invertir en la configuración y el mantenimiento de la infraestructura, y están enlazados por límites de almacenamiento o consulta.
- Análisis y respuesta manuales. Los equipos de SOC necesitan analistas altamente cualificados para procesar manualmente grandes cantidades de alertas. Los equipos de SOC están sobrecargados y los nuevos analistas son difíciles de encontrar.
- Administración compleja e ineficaz. Los equipos de SOC suelen supervisar la orquestación y la infraestructura, administrar las conexiones entre SIEM y varios orígenes de datos, y realizar actualizaciones y revisiones. Estas tareas suelen estar a expensas de la evaluación y el análisis críticos.
Un SIEM nativo de la nube aborda estos desafíos. Microsoft Sentinel recopila datos de forma automática y a escala, detecta amenazas desconocidas, investiga amenazas con inteligencia artificial y responde a incidentes rápidamente con la automatización integrada.
Planear la migración
Durante la fase de planeación, identificará los componentes SIEM existentes, los procesos de SOC existentes y diseñará y planeará nuevos casos de uso. Un planeamiento exhaustivo le permite mantener la protección de los recursos basados en la nube (Microsoft Azure, AWS o GCP) y sus soluciones SaaS, como Microsoft Office 365.
En este diagrama se describen las fases de alto nivel que incluye una migración típica. Cada fase incluye objetivos claros, actividades clave y resultados y resultados especificados.
Las fases de este diagrama son una guía para completar un procedimiento de migración típico. Es posible que una migración real no incluya algunas fases o que incluya más fases. En lugar de revisar el conjunto completo de fases, los artículos de esta guía revisan tareas y pasos específicos que son especialmente importantes para una migración Microsoft Sentinel.
Consideraciones
Revise estas consideraciones clave para cada fase.
| Fase | Consideración |
|---|---|
| Detectar | Identifique los casos de uso y las prioridades de migración como parte de esta fase. |
| Diseño | Defina un diseño y una arquitectura detallados para la implementación de Microsoft Sentinel. Usará esta información para obtener la aprobación de las partes interesadas pertinentes antes de iniciar la fase de implementación. |
| Implementar | A medida que implemente componentes de Microsoft Sentinel según la fase de diseño y antes de convertir toda la infraestructura, considere si puede usar Microsoft Sentinel contenido integrado en lugar de migrar todos los componentes. Puede empezar a usar Microsoft Sentinel gradualmente, empezando por un producto mínimo viable (MVP) para varios casos de uso. A medida que agregue más casos de uso, puede usar esta instancia de Microsoft Sentinel como entorno de pruebas de aceptación del usuario (UAT) para validar los casos de uso. |
| Operacionalización | Migre el contenido y los procesos de SOC para asegurarse de que la experiencia del analista existente no se interrumpe. |
Identificar las prioridades de migración
Use estas preguntas para anclar las prioridades de migración:
- ¿Cuáles son los componentes, sistemas, aplicaciones y datos de infraestructura más críticos de su empresa?
- ¿Quiénes son las partes interesadas en la migración? Es probable que la migración SIEM afecte a muchas áreas de su empresa.
- ¿Qué impulsa sus prioridades? Por ejemplo, mayor riesgo empresarial, requisitos de cumplimiento, prioridades empresariales, etc.
- ¿Cuál es la escala de migración y la escala de tiempo? Qué factores afectan a las fechas y fechas límite. ¿Va a migrar un sistema heredado completo?
- ¿Tienes las habilidades que necesitas? ¿Está el personal de seguridad entrenado y listo para la migración?
- ¿Hay bloqueadores específicos en su organización? ¿Hay algún problema que afecte a la planificación y programación de la migración? Por ejemplo, problemas como requisitos de personal y formación, fechas de licencia, paradas difíciles, necesidades empresariales específicas, etc.
Antes de comenzar la migración, identifique los casos de uso clave, las reglas de detección, los datos y la automatización en el SIEM actual. Enfoque la migración como un proceso gradual. Sea intencionado y reflexivo sobre lo que migra primero, lo que deprioritiza y lo que realmente no es necesario migrar. Es posible que el equipo tenga un número abrumador de detecciones y casos de uso que se ejecutan en el SIEM actual. Antes de comenzar la migración, decida cuáles son útiles activamente para su negocio.
Identificación de casos de uso
Al planear la fase de detección, use las siguientes instrucciones para identificar los casos de uso.
- Identifique y analice los casos de uso actuales por amenaza, sistema operativo, producto, etc.
- ¿Cuál es el ámbito? ¿Desea migrar todos los casos de uso o usar algunos criterios de priorización?
- Identifique qué recursos de seguridad son más críticos para la migración.
- ¿Qué casos de uso son eficaces? Un buen punto de partida es examinar qué detecciones han producido resultados en el último año (tasa de falsos positivos frente a positivos).
- ¿Cuáles son las prioridades empresariales que afectan a la migración de casos de uso? ¿Cuáles son los mayores riesgos para su empresa? ¿Qué tipo de problemas ponen más en riesgo su negocio?
- Priorice por las características del caso de uso.
- Considere la posibilidad de establecer prioridades más bajas y superiores. Se recomienda centrarse en las detecciones que aplicarían un 90 % de verdadero positivo en las fuentes de alertas. Los casos de uso que provocan una tasa alta de falsos positivos podrían ser una prioridad menor para su empresa.
- Seleccione los casos de uso que justifiquen la migración de reglas en términos de prioridad empresarial y eficacia:
- Revise las reglas que no han desencadenado ninguna alerta en los últimos 6 a 12 meses.
- Elimine las amenazas o alertas de bajo nivel que omite de forma rutinaria.
- Preparar un proceso de validación. Defina escenarios de prueba y cree un script de prueba.
- ¿Puede aplicar una metodología para priorizar los casos de uso? Puede seguir una metodología como MoSCoW para priorizar un conjunto más eficiente de casos de uso para la migración.
Paso siguiente
En este artículo, ha aprendido a planear y preparar la migración.