Planes de retención de registros en Microsoft Sentinel
Hay dos aspectos de la recopilación y retención de registros que compiten entre sí y que son fundamentales para el éxito de un programa de detección de amenazas. Por un lado, querrá maximizar el número de orígenes de registro que recopile, de modo que disponga de la cobertura de seguridad más completa posible. Por otro lado, hay que minimizar los costes derivados de la ingesta de todos esos datos.
Estas necesidades contrapuestas requieren una estrategia de administración de registros que equilibre la accesibilidad de los datos, el rendimiento de las consultas y los costes de almacenamiento.
En este artículo se describen las categorías de datos y los estados de retención usados para almacenar y acceder a los datos. También se describen los planes de registro que Microsoft Sentinel ofrece para crear una estrategia de retención y administración de registros.
Importante
El tipo de registro Registros auxiliares está actualmente en VISTA PREVIA. Consulte Términos de uso complementarios para las Versiones preliminares de Microsoft Azure para conocer los términos legales adicionales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Microsoft Sentinel está disponible con carácter general en la plataforma de operaciones de seguridad unificada de Microsoft en el portal de Microsoft Defender. Para la versión preliminar, Microsoft Sentinel está disponible en el portal de Microsoft Defender sin Microsoft Defender XDR ni una licencia E5. Para obtener más información, consulte Microsoft Sentinel en el portal de Microsoft Defender.
Microsoft recomienda clasificar los datos ingeridos en Microsoft Sentinel en dos categorías generales:
Los datos de seguridad principales son los datos que contienen un valor de seguridad crítico. Estos datos se usan para la supervisión proactiva en tiempo real, las alertas programadas y los análisis para detectar amenazas de seguridad. Los datos deben estar disponibles fácilmente para todas las experiencias de Microsoft Sentinel casi en tiempo real.
Los datos de seguridad secundarios corresponden a datos complementarios, a menudo en registros detallados de gran volumen. Estos datos tienen un valor limitado desde el punto de vista de la seguridad, pero pueden aportar más riqueza y contexto a las detecciones e investigaciones, y ayudar a dibujar el panorama completo de un incidente de seguridad. No es necesario que esté disponible de inmediato, pero debe ser accesible a petición según sea necesario y en dosis adecuadas.
Esta categoría consta de registros que contienen un valor de seguridad crítico para su organización. Los datos de seguridad principales se pueden describir mediante los siguientes casos de uso para las operaciones de seguridad:
Supervisión frecuente. Las reglas de detección de amenazas (análisis) se ejecutan en estos datos a intervalos frecuentes o casi en tiempo real.
Búsqueda a petición. Las consultas complejas se ejecutan en estos datos para ejecutar búsquedas interactivas y de alto rendimiento para amenazas de seguridad.
Correlación. Los datos de estos orígenes se correlacionan con los datos de otros orígenes de datos de seguridad principales para detectar amenazas y crear casos de ataque.
Informes regulares. Los datos procedentes de estos orígenes están disponibles inmediatamente para su compilación en informes periódicos sobre el estado de la seguridad de la organización, tanto para los responsables de la seguridad como para los de la toma de decisiones en general.
Análisis del comportamiento. Los datos de estos orígenes se usan para crear perfiles de comportamiento de base de referencia para sus usuarios y dispositivos, lo que le permite identificar como sospechosos los comportamientos fuera de lo normal.
Algunos ejemplos de orígenes de datos principales incluyen registros de sistemas antivirus o de detección y respuesta empresarial (EDR), registros de autenticación, seguimientos de auditoría de plataformas en la nube, fuentes de inteligencia sobre amenazas y alertas de sistemas externos.
Los registros que contienen datos de seguridad principales deben almacenarse mediante el plan de Registros de análisis descrito más adelante en este artículo.
Esta categoría abarca los registros cuyo valor de seguridad individual es limitado, pero que son esenciales para proporcionar una visión global de un incidente o una vulneración de seguridad. Normalmente, estos registros son de gran volumen y pueden ser muy detallados. Los casos de uso de las operaciones de seguridad para estos datos son los siguientes:
Inteligencia sobre amenazas. Los datos principales se pueden comprobar con listas de indicadores de compromiso (IoC) o indicadores de ataque (IoA) para detectar amenazas de forma rápida y sencilla.
Búsqueda o investigaciones ad hoc. Los datos pueden consultarse de forma interactiva durante 30 días, lo que facilita un análisis crucial para la búsqueda de amenazas y las investigaciones.
Búsquedas a gran escala. Los datos se pueden ingerir y buscar en segundo plano a escala de petabyte, mientras se almacenan de forma eficaz con un procesamiento mínimo.
Resumen mediante reglas de resumen. Resuma los registros de gran volumen en información agregada y almacene los resultados como datos de seguridad principales. Para obtener más información sobre las reglas de resumen, consulte Agregar datos de Microsoft Sentinel con reglas de resumen.
Algunos ejemplos de orígenes de registro de datos secundarios son registros de acceso de almacenamiento en la nube, registros de NetFlow, registros de certificados TLS/SSL, registros de firewall, registros de proxy y registros de IoT. Para obtener más información sobre cómo cada uno de estos orígenes aporta valor a las detecciones de seguridad sin ser necesario todo el tiempo, consulte Orígenes de registro que se usarán para la ingesta de registros auxiliares.
Los registros que contienen datos de seguridad secundarios deben almacenarse mediante el plan de Registros auxiliares (ahora en versión preliminar) que se describe más adelante en este artículo.
Para una opción que no está en versión preliminar, puede usar Registros básicos en su lugar.
Microsoft Sentinel proporciona dos planes de almacenamiento de registros diferentes, o tipos, para dar cabida a estas categorías de datos ingeridos.
El plan de Registros de análisis está diseñado para almacenar datos de seguridad principales y hacerlos accesibles de forma fácil y constante con un alto rendimiento.
El plan de Registros auxiliares está diseñado para almacenar datos de seguridad secundarios a un coste muy bajo durante largos períodos de tiempo, a la vez que permite una accesibilidad limitada.
Un tercer plan, el plan de Registros básicos, es el predecesor del plan de Registros auxiliares y se puede usar como sustituto de él mientras el plan de Registros auxiliares permanece en versión preliminar.
Cada uno de estos planes conserva los datos en dos estados diferentes:
El estado de retención interactiva es el estado inicial en el que se ingieren los datos. Este estado permite distintos niveles de acceso a los datos, en función del plan, y los costes de este estado varían ampliamente, según el plan.
El estado de retención a largo plazo conserva los datos más antiguos en sus tablas originales hasta 12 años, a un coste extremadamente bajo, independientemente del plan.
Para obtener más información sobre los estados de retención, consulte Administración de la retención de datos en un área de trabajo de Log Analytics.
El siguiente diagrama resume y compara estos dos planes de administración de registros.
El plan de Registros de análisis conserva los datos en estado de retención interactiva durante 90 días de forma predeterminada, ampliable hasta dos años. Este estado interactivo, aunque costoso, le permite consultar los datos de forma ilimitada, con un alto rendimiento, sin cargo por consulta.
Cuando finaliza el período de retención interactiva, los datos entran en estado de retención a largo plazo, mientras permanecen en su tabla original. El período de retención a largo plazo no se define de forma predeterminada, pero puede definirlo para que dure hasta 12 años. Este estado de retención conserva los datos a un coste extremadamente bajo, con fines de cumplimiento normativo o de directiva interna. Solo puede tener acceso a los datos de este estado mediante un trabajo de búsqueda o una restauración para extraer conjuntos limitados de datos en una nueva tabla en retención interactiva, donde puede incluir las funcionalidades de consulta completas para que se lleven a cabo.
El plan de Registros auxiliares mantiene los datos en estado de retención interactiva durante 30 días. En el plan Registros auxiliares, este estado tiene costes de retención muy bajos en comparación con el plan de Registros de análisis. Sin embargo, las funcionalidades de consulta son limitadas: las consultas se cobran por gigabyte de datos examinados y se limitan a una sola tabla, y el rendimiento es significativamente menor. Aunque estos datos permanecen en estado de retención interactiva, puede ejecutar reglas de resumen en estos datos para crear tablas de datos agregados y resumidos en el plan de Registros de análisis, de modo que disponga de todas las funcionalidades de consulta en estos datos agregados.
Cuando finaliza el período de retención interactiva, los datos entran en estado de retención a largo plazo, mientras permanecen en su tabla original. La retención a largo plazo en el plan de registros auxiliares es similar a la retención a largo plazo en el plan de registros de análisis, salvo que la única opción para acceder a los datos es con un trabajo de búsqueda. No se admite la restauración para el plan de Registros auxiliares.
Un tercer plan, conocido como plan de Registros básicos, proporciona una funcionalidad similar al plan de Registros auxiliares, pero con un mayor coste de retención interactiva (aunque no tan alto como el plan de Registros de análisis). Mientras que el plan de Registros auxiliares permanece en versión preliminar, el plan de Registros básicos puede ser una opción para la retención a largo plazo y a bajo coste si su organización no usa características en versión preliminar. Para obtener más información sobre el plan de Registros básico, consulte Planes de tabla en la documentación de Azure Monitor.
Para obtener una comparación más detallada de los planes de datos de registro y más información general sobre los tipos de registro, consulte Introducción a los registros de Azure Monitor | Planes de tabla.
Para configurar una tabla en el plan de Registros auxiliares, consulte Configurar una tabla con el plan de Registros auxiliares en el área de trabajo de Log Analytics (versión preliminar).
Para obtener más información sobre los períodos de retención, que existen entre planes, consulte Administrar retención de datos en un área de trabajo de Log Analytics.