Hola a todos!
Reproducimos una artículo del blog de seguridad de Microsoft el 18 de agosto.
En la segunda parte de esta serie de tres partes, cubrimos los cinco tipos de configuraciones de administración de eventos e información de seguridad (SIEM) en paralelo que se usan comúnmente durante una migración a largo plazo a Microsoft Azure Sentinel. Para la tercera parte, analizaremos las mejores prácticas para migrar sus datos y detecciones mientras opera en paralelo con su SIEM local, así como formas de maximizar las potentes capacidades de automatización de Azure Sentinel para optimizar las tareas comunes.
La información que se presenta aquí se deriva de las experiencias que hemos acumulado mientras ayudamos a numerosas migraciones de clientes, así como las experiencias adquiridas por el propio centro de operaciones de seguridad (SOC) de Microsoft en la protección de nuestra infraestructura de TI. Por lo general, la migración a Azure Sentinel se lleva a cabo en tres fases: comenzando con los datos, luego con las reglas de detección y, finalmente, con la automatización de los flujos de trabajo.
Migración de datos a Azure Sentinel:
La primera vez que su equipo de operaciones de seguridad (SecOps) inicie sesión en Azure Sentinel, lo encontrarán precargado con conectores de datos integrados que facilitan la ingesta de datos de toda su organización. Aún así, te conviene ser selectivo; la migración brinda la oportunidad de reevaluar sus necesidades de seguridad y dejar atrás el contenido que ya no es útil. Piense de manera integral en sus casos de uso, luego mapee los datos necesarios para respaldarlos. Querrá identificar cualquier brecha persistente en la visibilidad de su SIEM heredado y determinar cómo cerrarla.
La mayoría de los equipos de SecOps comienzan por ingerir sus datos de la nube en Azure Sentinel. Para un primer paso sencillo, los registros de actividad de Microsoft Azure y los registros de auditoría de Microsoft Office 365 son gratuitos y le brindan visibilidad inmediata de la actividad de Azure y Office 365. También puede ingerir alertas de productos de Microsoft Defender, Azure Security Center, Microsoft Cloud App Security y Azure Information Protection, todo de forma gratuita.
Muchos equipos de seguridad eligen ingerir datos enriquecidos de productos de seguridad en toda la organización mientras usan Azure Sentinel para correlacionarlos. Esto elimina la necesidad de ingerir registros sin procesar de las fuentes de datos, lo que puede resultar costoso. A medida que migre sus detecciones y desarrolle casos de uso en Azure Sentinel, asegúrese de verificar el valor de cualquier dato en relación con sus prioridades clave.
Reglas de detección de migración:
Una tarea clave para su migración consiste en traducir las reglas de detección existentes para asignarlas a Azure Sentinel, que emplea Kusto Query Language (KQL) y se puede usar fácilmente en otras soluciones de Microsoft, como Microsoft Defender para Endpoint y Microsoft Application Insights.
Azure Sentinel tiene cuatro tipos de reglas integradas:
- Agrupación de alertas: reduce la fatiga de alertas al agrupar hasta 150 alertas dentro de un período de tiempo determinado, utilizando tres opciones de agrupación de alertas: entidades coincidentes, alertas activadas por la regla programada y coincidencias de entidades específicas.
- Mapeo de entidades: permite a sus ingenieros de SecOps definir entidades para rastrear durante la investigación. El mapeo de entidades también hace posible que los analistas aprovechen el gráfico de investigación intuitivo para reducir el tiempo y el esfuerzo.
- Resumen de evidencia: muestra eventos, alertas y marcadores asociados con un incidente en particular dentro del panel de vista previa. Las entidades y tácticas también aparecen en el panel de incidentes, lo que proporciona una instantánea de los detalles esenciales y permite una clasificación más rápida.
- KQL: la solicitud se envía a una base de datos de Log Analytics y se establece en texto sin formato, mediante un modelo de flujo de datos que hace que la sintaxis sea fácil de leer, crear y automatizar. Debido a que varios otros servicios de Microsoft también almacenan datos en Azure Log Analytics o Azure Data Explorer, esto reduce la curva de aprendizaje necesaria para consultar o correlacionar.
Debido a que Azure Sentinel usa análisis de aprendizaje automático para producir incidentes accionables y de alta fidelidad, es probable que algunas de sus detecciones existentes ya no sean necesarias.
Recordar:
- No migre todas las reglas a ciegas; enfócate en la calidad, no en la cantidad.
- Aprovechar los recursos disponibles. Revise todas las reglas integradas de Azure Sentinel para identificar reglas listas para usar que puedan abordar rápidamente sus casos de uso. Explore los recursos de la comunidad, como SOC Prime Threat Detection Marketplace.
- Confirme las fuentes de datos conectadas y revise sus métodos de conexión de datos. Revise las conversaciones de recopilación de datos para garantizar la profundidad y amplitud de los datos en los casos de uso que planea detectar.
- Seleccione casos de uso que justifiquen la migración de reglas en términos de prioridad y eficacia comercial:
- Revise las reglas que no han activado ninguna alerta en los últimos 6 a 12 meses.
- Elimine amenazas de bajo nivel o alertas que ignora habitualmente.
- Prepare un proceso de validación: defina escenarios de prueba y cree un script de prueba.
Maximizando la automatización:
La automatización de los flujos de trabajo puede optimizar tanto las tareas comunes como las críticas al permitir que su equipo de SecOps agrupe las alertas en un incidente común y luego modifique su prioridad. Además, los libros de jugadas automatizados en Azure Sentinel permiten una fácil integración con soluciones de emisión de boletos de terceros, como ServiceNow.
Pero la automatización no se trata solo de ejecutar tareas en segundo plano. Desde dentro de la investigación, su equipo puede usar un libro de jugadas automatizado para recopilar información adicional o aplicar una acción de remediación; ayudar a un analista a lograr más en menos tiempo. También tiene la libertad de iterar y perfeccionar con el tiempo, pasando a la automatización completa para la respuesta. Explore los libros de jugadas de GitHub para obtener nuevas ideas y conocer los flujos de automatización más comunes.
Descontinuar su SIEM heredado:
Al tener a la vista sus prioridades más altas y los casos de uso definidos, desarrollará una idea de cuándo está listo para retirar su SIEM heredado y pasar por completo a Azure Sentinel. Según nuestra experiencia, los clientes que sienten que están listos para apagar su antiguo SIEM primero deben completar esta lista de verificación básica:
Tecnología:
- Compruebe los datos críticos: asegúrese de que las fuentes y las alertas estén disponibles en Azure Sentinel.
- Archivar todos los registros: guarde registros críticos de incidentes y casos anteriores (datos sin procesar opcionales) para conservar el historial institucional.
Procesos:
- Playbooks: actualice los procesos de búsqueda e investigación para Azure Sentinel.
- Métricas: asegúrese de que todas las métricas clave se puedan obtener completamente de Azure Sentinel. Cree libros de trabajo personalizados o use plantillas de libros de trabajo integradas para obtener información rápidamente tan pronto como se conecte a las fuentes de datos.
- Casos: asegúrese de que todos los casos actuales se transfieran al nuevo sistema (incluidos los datos de origen requeridos).
Gente:
- Analistas de SOC: asegúrese de que todos los miembros de su equipo estén capacitados en Azure Sentinel y se sientan cómodos dejando el SIEM heredado.
Seguiremos revisando las publicaciones de MSB.
Un saludo