Planeamiento de la migración a Microsoft Sentinel
Los equipos del centro de operaciones de seguridad (SOC) usan soluciones centralizadas de administración de eventos e información de seguridad (SIEM) y de orquestación de seguridad, automatización y respuesta (SOAR) para proteger el patrimonio digital, cada vez más descentralizado. Aunque los SIEM heredados pueden mantener una buena cobertura de 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 su parte, Microsoft Sentinel puede ingerir datos de recursos locales y en la nube, lo que garantiza la cobertura de todo el patrimonio.
En este artículo se comentan las razones para migrar desde un SIEM heredado y se describe cómo planear las distintas fases de la migración.
Pasos de migración
En esta guía, aprenderá a migrar su 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 distintos pasos en el proceso.
Nota
Para obtener 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 obtener más información, póngase en contacto con el equipo de su cuenta.
¿Qué es Microsoft Sentinel?
Microsoft Sentinel es una solución de administración de eventos e información de seguridad (SIEM) y respuesta automatizada de orquestación de seguridad (SOAR) escalable y nativa de la nube. Use Microsoft Sentinel para proporcionar análisis de seguridad inteligentes e inteligencia sobre amenazas a 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 contra amenazas. Obtenga 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 las amenazas. Los SIEM 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 numerosos componentes de seguridad diferentes y volúmenes de registros cada vez más altos. El análisis de estos datos ralentiza los equipos de SOC en sus esfuerzos para 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 un desafío con el escalado de 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 restringidos por los límites de almacenamiento o consulta.
- Análisis manual y respuesta. 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 ineficiente. Normalmente, los equipos de SOC supervisan la orquestación y la infraestructura, administran las conexiones entre el SIEM y varios orígenes de datos, y realizan actualizaciones y revisiones. Estas tareas suelen realizarse a costa de una evaluación y un análisis críticos.
Un SIEM nativo de nube aborda estos desafíos. Microsoft Sentinel recopila datos automáticamente y a escala, detecta amenazas desconocidas, investiga amenazas con inteligencia artificial y responde a incidentes rápidamente con automatización integrada.
Planeamiento de la migración
Durante la fase de planeación, se identifican los componentes de SIEM existentes, los procesos de SOC existentes y se diseñan y planean nuevos casos de uso. El planeamiento exhaustivo le permite mantener la protección de los recursos basados en nube (Microsoft Azure, AWS o GCP) y las 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 entregas 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 de Microsoft Sentinel.
Consideraciones
Revise estas consideraciones clave para cada fase.
| Fase | Consideración |
|---|---|
| Descubra | 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 competentes 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 contenido preconfigurado de Microsoft Sentinel 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 de usuario (UAT) para validar los casos de uso. |
| Operacionalización | Migre el contenido y los procesos de SOC para asegurarse de que la experiencia de analista existente no se interrumpa. |
Identificación de 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 negocio?
- ¿Quiénes son las partes interesadas en la migración? Es probable que la migración de SIEM toque muchas áreas de su negocio.
- ¿Qué impulsa sus prioridades? Por ejemplo, mayor riesgo empresarial, requisitos de cumplimiento, prioridades empresariales, etc.
- ¿Qué es la escala de migración y la escala de tiempo? ¿Qué factores afectan a las fechas y plazos de entrega? ¿Va a migrar un sistema heredado completo?
- ¿Tiene las habilidades que necesitas? ¿El personal de seguridad está entrenado y listo para la migración?
- ¿Hay algún bloqueador específico en la organización? ¿Algún problema afecta al planeamiento y la programación de la migración? Por ejemplo, problemas como los requisitos de personal y entrenamiento, las fechas de licencia, las paradas difíciles, las necesidades empresariales específicas, etc.
Antes de comenzar la migración, identifique casos de uso clave, reglas de detección, datos y automatización en su SIEM actual. Enfoque la migración como un proceso gradual. Realice las acciones con determinación y de forma razonada sobre lo que va a migrar primero, lo que no desea que tenga prioridad y lo que en realidad no necesita migrarse. 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 activamente útiles para su negocio.
Identificación de casos de uso
Al planear la fase de detección, use las instrucciones siguientes 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 efectivos? Un buen punto de partida es ver 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 negocio? ¿Qué tipo de incidencias ponen en riesgo su negocio?
- Priorice por características de casos de uso.
- Considere la posibilidad de establecer prioridades más bajas y más altas. Se recomienda centrarse en las detecciones que aplicarían un verdadero positivo del 90 % en las fuentes de alerta. Los casos de uso que provocan una alta tasa de falsos positivos podrían ser una prioridad más baja para su negocio.
- Seleccione los casos de uso que justifican 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.
- Prepare 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 ajustado de casos de uso para la migración.
Paso siguiente
En este artículo, ha aprendido a planear y preparar la migración.