Al configurar su SIEM, la ingesta de registros de Active Directory es esencial. Active Directory (AD) sigue siendo la «joya de la corona» para las organizaciones locales o híbridas porque un entorno de AD violado significa que todo el entorno es vulnerable. Por lo tanto, monitorear Active Directory es de suma importancia. Cuando se usa Microsoft Sentinel como SIEM, existen varias formas de ingerir registros de Active Directory. Las dos opciones principales son usar Microsoft Defender for Identity (MDI) o recopilar los registros de seguridad de Windows sin procesar de los controladores de dominio con un agente. Este blog se sumerge en las dos opciones para comparar sus fortalezas y debilidades.
Defensor de la Identidad
Microsoft Defender for Identity es el único producto de Microsoft en la pila de Defender que se enfoca en la seguridad de Active Directory. La instalación de un sensor en todos los controladores de dominio enviará datos a la nube. Luego, los datos están disponibles a través de la búsqueda avanzada dentro del portal de Microsoft Defender y Microsoft los analiza en el backend. Cuando MDI identifica posibles actividades sospechosas (como Pass-The-Ticket, Golden Ticket o Account Enumeration), se crea un incidente para que el equipo de seguridad lo investigue. Estos incidentes se pueden investigar a través del portal de Microsoft Defender.
Si bien el principal beneficio de MDI es su capacidad para detectar problemas potenciales, no siempre está claro cuántos datos sin procesar recopila y le proporciona MDI. Si navegamos a la hoja Advanced Hunting dentro del portal de Microsoft 365, vemos cuatro tablas que contienen información relacionada con AD:
- IdentityInfo: esta tabla contiene información sobre los objetos de usuario de AD y Azure AD, incluidas propiedades como SID, nombres y estado.
- IdentityLogonEvents: contiene todos los eventos de inicio de sesión capturados por AD y Azure AD.
- IdentityDirectoryEvents: eventos que ocurren en los controladores de dominio para objetos de usuario y grupo, incluidos restablecimientos de contraseña y actualizaciones de usuarios y grupos.
- IdentityQueryEvents: esta tabla contiene consultas AD realizadas por usuarios y dispositivos a los controladores de dominio, estas pueden ser consultas LDAP o SAMR que solicitan información. Este tipo de consultas se utilizan a menudo durante el reconocimiento por parte de un adversario.
Al usar el conector de Microsoft 365 Defender dentro de Microsoft Sentinel, podemos ingerir las tablas mencionadas anteriormente. Para ello, abra el entorno de Sentinel, seleccione Conectores de datos y elija Microsoft 365 Defender. Si se desplaza hacia abajo en la página de configuración del conector de datos, puede ver las tablas MDI disponibles. Seleccione las tres tablas que se muestran en la Figura 1 y haga clic en Aplicar cambios para comenzar a sincronizar los datos en Sentinel.
Figura 1: Datos MDI en Sentinel
Los más entusiastas pueden haber notado que falta la tabla IdentityInfo en la Figura 1. Esto se debe a que Sentinel tiene una solución nativa llamada User Entity Behavior Analytics, que extrae automáticamente los datos MDI.
Otra nota importante es el costo de esta solución; ingerir registros de caza avanzados sin procesar en Sentinel no es gratis y tiene un precio. El costo de esta solución es difícil de estimar; un potencial es utilizar las consultas creadas por Microsoft Rod Trent.
Eventos de seguridad de Windows
Cada controlador de dominio recopila eventos de seguridad generados por la actividad en los DC y los guarda en el Visor de eventos. La cantidad de datos recopilados depende de la configuración de auditoría del dominio. Los datos de eventos de seguridad recopilados por los controladores de dominio se pueden transmitir a Microsoft Sentinel. Para hacer esto, se debe instalar un agente en los controladores de dominio. Actualmente hay dos agentes disponibles: Microsoft Monitoring Agent (MMA) y Azure Monitor Agent (AMA). Ambos agentes envían datos de eventos de seguridad a Log Analytics, pero solo se debe considerar el agente AMA. Hay dos razones por las cuales:
- Microsoft considera que MMA es una solución heredada y no la admitirá después de 2022.
- MMA no proporciona un filtrado adecuado para los eventos.
Azure Monitoring Agent solo se puede instalar en servidores hospedados en Azure o integrados en Azure Arc. Una vez instalado, debemos configurar una regla de recopilación de datos que utilice una consulta xPath. Una consulta xPath es un filtro específico del Visor de eventos de Windows, para decirle al agente qué eventos transmitir
Un ejemplo de una consulta xPath es:
‘»¡Seguridad!*[System[EventID=4728]]”’.
Esta consulta recupera el Id. de evento 4278 (miembro agregado al grupo con seguridad habilitada) del registro de eventos de seguridad. Para recopilar varios eventos de los controladores de dominio, debe crear varias consultas xPath (complejas) para recuperar los registros y enviarlos a Microsoft Sentinel.
En la documentación de Microsoft se cubre un manual completo sobre cómo configurar estas reglas e instalar Azure Monitoring Agent.
Nota: esta solución requiere que los controladores de dominio estén conectados a Internet; esto se puede evitar utilizando el reenvío de eventos de Windows.
Comparando ambas opciones
Si bien ambas opciones logran el mismo objetivo, existen diferencias significativas. Los principales son los requisitos de licencia y la complejidad de la configuración.
Defender for Identity es el más fácil de integrar, ya que puede comenzar a sincronizar tablas sin infraestructura adicional, pero MDI solo está disponible con una licencia de Microsoft 365 E5 Security. Esto significa que no es una opción para todas las organizaciones. Si un cliente está comenzando con Sentinel y tiene acceso a una licencia E5, este es el camino que le aconsejo que siga. Les permite obtener el máximo valor sin mucho esfuerzo.
Si bien ingerir los eventos de seguridad sin procesar es más difícil de configurar, este método es mi preferencia. Con eventos de seguridad sin procesar, tiene control total sobre lo que ingiere y, por lo tanto, su costo. Depende de usted si desea ingerir ID de eventos específicos o todos los eventos de seguridad. Esto también significa que este método puede ir mucho más allá en la recopilación de datos y la ingesta de eventos que MDI ni siquiera recopila.
