¿Qué es una revisión de retención del registro Security de los DC?
Una revision de retencion Security DC determina qué eventos Security puede seguir leyendo un investigador en cada controlador de dominio, sus archivos y el destino central de registros. El resultado útil es un expediente de evidencias fechado y vinculado a una política aprobada por la organización. Un tamaño máximo de archivo configurado, un evento antiguo o una conexión de reenvío operativa solo constituye una parte de ese expediente.
Tres preguntas necesitan respuestas independientes: ¿se generaron los eventos requeridos, siguen siendo legibles localmente y el sistema central previsto los recibió y conservó? Empiece por las comprobaciones de la política de auditoría efectiva para la generación de eventos. Esa guía utiliza auditpol para examinar la configuración de auditoría; esta revisión aborda el historial legible, el comportamiento del canal, los archivos y la prueba de una copia central.
Este procedimiento abarca los controladores de dominio de Active Directory y sus canales Windows Security. No evalúa la retención de los registros de auditoría de Microsoft Entra. Los comandos siguientes son ejemplos basados en documentación para operadores Windows autorizados; no se ejecutaron en un dominio de cliente para este artículo. La documentación y el comportamiento del recopilador se revisaron el 4 de octubre de 2026.
Cómo funcionan la capacidad del canal y el modo de retención
Microsoft documenta tres comportamientos relevantes mediante wevtutil: con la retención deshabilitada, los nuevos registros sobrescriben los más antiguos al alcanzar la capacidad; con la retención habilitada y la copia de seguridad automática deshabilitada, los registros existentes permanecen y los entrantes se descartan cuando el registro está lleno. La copia de seguridad automática requiere que la retención esté habilitada y respalda el registro al alcanzar el tamaño máximo. El parámetro /ms controla un límite en bytes, no un número garantizado de días. Consulte la referencia del comando wevtutil.
| Configuración que se debe examinar | Pregunta para la revisión |
|---|---|
| Comportamiento de sobrescritura | ¿El historial local legible llega al punto de inicio aprobado con el volumen real de eventos? |
| Retención sin copia de seguridad automática | ¿Puede el equipo demostrar que siguieron capturándose nuevos eventos al aproximarse a la capacidad máxima? |
| Retención con copia de seguridad automática | ¿Puede el equipo localizar, abrir y buscar en los archivos necesarios para el período aprobado? |
Trate cada controlador de dominio por separado. El historial de un servidor poco activo no puede representar a un controlador con más actividad, y una exportación de configuración no sustituye una lectura de eventos satisfactoria. Conserve la configuración efectiva junto con las observaciones, en lugar de cerrar la revisión únicamente a partir de los parámetros.
Defina la política antes de emitir un veredicto. Pida al responsable que especifique los conjuntos de eventos, el período requerido, las responsabilidades locales y centrales, los requisitos de acceso y el comportamiento de recuperación aceptable. Registre la versión de la política y su aprobación. La guía de correspondencia de cumplimiento conecta controles identificados con evidencias de producción; aplique ese enfoque a la política de retención real en lugar de inventar una duración normativa universal.
Detección: recopilar un expediente fechado para cada DC
Paso 1: leer la configuración efectiva del canal Security
Ejecute estos comandos localmente en cada DC identificado con acceso autorizado. Learn documenta su sintaxis; Security es el canal seleccionado para este procedimiento.
wevtutil gl Security
Get-WinEvent -ListLog Security
Get-WinEvent -ListLog Security | Format-List -Property *
La referencia de Get-WinEvent documenta -ListLog, las propiedades de configuración, el orden de los eventos, -MaxEvents, -Oldest y la lectura de registros guardados mediante -Path. Capture LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull y LogFilePath cuando se devuelvan. Conserve la salida sin procesar, la identidad del equipo, la hora de recopilación con zona horaria, el operador y el resultado del comando.
No excluya silenciosamente un DC porque falle una lectura. Conserve el error y clasifique sus evidencias como no disponibles hasta que se investigue. Un error de permisos, un resultado vacío y un registro leído correctamente son resultados distintos. El registro de revisión debe hacer visibles los tres a su responsable.
Paso 2: leer ambos extremos de la secuencia de eventos disponible
Get-WinEvent -LogName Security -MaxEvents 1 -Oldest |
Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
Get-WinEvent -LogName Security -MaxEvents 1 |
Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
El orden predeterminado empieza por los eventos más recientes; -Oldest lo invierte. Conserve las marcas de tiempo y las identidades devueltas sin suponer que prueban una cobertura ininterrumpida. Armonice la presentación de zonas horarias antes de comparar fuentes. Estas lecturas limitadas identifican los extremos de la secuencia disponible, en vez de calcular las marcas de tiempo mínima y máxima de todos los registros.
Para la revisión, anote el tramo observado y sus limitaciones. Si el primer registro legible es posterior al punto de inicio requerido por la política, investigue si un archivo o una copia central aprobada proporciona el historial que falta. Si es anterior a ese punto, siga comprobando los conjuntos de eventos requeridos y las interrupciones conocidas. Una marca de tiempo antigua no basta para demostrar la integridad del historial.
Paso 3: registrar las evidencias y su decisión
Utilice una fila por DC y después filas vinculadas para los archivos y los destinos centrales. Evite una sola celda de aprobado o suspenso para todo el dominio que oculte un servidor inaccesible. La siguiente tabla propone un registro de evidencias; no es una salida medida:
| Campo de evidencia | Qué debe conservar el operador |
|---|---|
| Fuente y observación | Identidad del DC, canal Security, zona horaria, hora de revisión, operador |
| Configuración efectiva | Configuración sin procesar, límite en bytes, tamaño actual, modo, estado de copia de seguridad automática |
| Límites legibles | Detalles del primer y último evento devueltos, dirección de la consulta, errores |
| Evidencias de archivos | Identidad del archivo, ubicación de almacenamiento, lecturas satisfactorias, resultado de búsqueda |
| Evidencias centrales | Destino, identidad de la fuente, consulta, registros coincidentes, hora de búsqueda |
| Decisión | Versión de la política, alcance evaluado, carencias sin resolver, responsable y próxima acción |
Pida al revisor que distinga una insuficiencia demostrada de una pregunta sin responder. Un archivo ilegible es una carencia de evidencia aunque el archivo exista. Una consulta central que omite un DC es una prueba incompleta aunque el destino devuelva muchos registros de otros servidores. Conserve estas distinciones en el ticket de remediación.
Verificar los archivos y la copia central
Un inventario de archivos debe conducir a lecturas reales. Adapte esta sintaxis documentada de -Path a cada ubicación aprobada de archivos Security; la ruta siguiente es un ejemplo, no un archivo descubierto.
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1 -Oldest
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1
Registre los fallos junto con las lecturas satisfactorias. Después busque en los archivos los conjuntos de eventos y los períodos requeridos por la política. Una muestra legible en los límites solo demuestra que esos registros pueden abrirse; la revisión sigue necesitando una búsqueda explícita que cubra las preguntas pertinentes de la investigación.
Para WEC u otro destino de registros, seleccione eventos de origen conocidos y localice sus registros centrales correspondientes. Conserve el equipo de origen, el canal, el proveedor, el identificador de evento, la marca de tiempo y los datos del evento pertinentes para compararlos. Documente cualquier transformación en la cadena de ingesta en lugar de suponer que un número de registro asignado por el destino es el número de registro de origen.
Separe la recepción de la posibilidad de búsqueda. El paquete de evidencias debe mostrar el destino central de ingesta y la consulta utilizada por un investigador, incluidos los filtros, el intervalo de tiempo y el resultado. Un registro visible en un registro de recepción pero no disponible a través de la vía de búsqueda aprobada deja una carencia práctica para la investigación. A la inversa, una muestra central localizada correctamente no certifica todos los registros ni todos los DC.
Remediación: cumplir la política aprobada y probar la recuperación (Remediation)
Paso 1: resolver la carencia específica
Elija el cambio a partir de las evidencias: capacidad local, gestión del registro lleno, acceso a los archivos, alcance de la suscripción, almacenamiento central o cadena de búsqueda. Asigne un responsable y un paso de verificación. Las decisiones de tamaño y modo necesitan el volumen de eventos previsto y el escenario de interrupción de ese entorno; este artículo no prescribe ningún límite universal en bytes ni ningún período universal de retención.
Antes de cambiar un canal, preserve la configuración actual y las evidencias requeridas. Aplique la configuración aprobada mediante el proceso gestionado del equipo y repita después las lecturas de configuración y eventos. Registre tanto el parámetro previsto como el resultado observado. No borre un registro Security para hacer desaparecer una antigua preocupación de retención ni considere una capacidad mayor como prueba de que ha vuelto el historial perdido previamente.
Paso 2: revisar los parámetros documentados de entrega WEF
La guía de Microsoft sobre WEF para la detección de intrusiones explica que WEF lee los eventos existentes de los canales; no habilita su generación ni cambia el tamaño del registro de origen. El registro local almacena los eventos en búfer durante la desconexión. La sobrescritura puede perder eventos sin una notificación de carencia a WEC. La guía también documenta marcadores, señales de actividad, la opción de leer eventos existentes y parámetros de entrega personalizados.
Estos son los parámetros de ejemplo de Microsoft, que deben revisarse desde una consola elevada para una suscripción de prueba aprobada en WEC; no son recomendaciones de dimensionamiento de producción:
Wecutil ss "testSubscription" /cf:Events
Wecutil ss "SubscriptionNameGoesHere" /cm:Custom
Wecutil ss "SubscriptionNameGoesHere" /dmi:1
Wecutil ss "SubscriptionNameGoesHere" /dmlt:10
/cf:Events selecciona el formato de evento; /cm:Custom selecciona la entrega personalizada; /dmi establece el número máximo de eventos por entrega, mientras que /dmlt establece la latencia máxima de entrega en milisegundos. Sustituya los nombres de ejemplo solo después de revisar la suscripción prevista. Leer eventos existentes puede recopilar el historial disponible; no puede recrear eventos sobrescritos o nunca generados.
Paso 3: validar una interrupción aprobada
Planifique una prueba controlada con el responsable de supervisión, un alcance definido, una condición de parada y un procedimiento de recuperación. Elija actividad benigna ya cubierta por la configuración de auditoría y la suscripción requeridas. Registre los eventos de origen correspondientes antes, durante y después de la interrupción. Especifique de antemano qué registros deberán poder buscarse centralmente y cuándo los evaluará el equipo.
Restaure la recopilación y verifique después esos registros mediante la vía central de búsqueda aprobada. Conserve las evidencias de origen, la cronología de la interrupción, los parámetros de suscripción, los resultados centrales y los errores. Investigue las discrepancias aunque se haya recuperado la conectividad. Informe explícitamente de cualquier intervalo que falte e identifique si los archivos restantes u otra copia aprobada pueden proporcionarlo.
Paso 4: cerrar la revisión de evidencias
El cierre debe identificar exactamente qué se evaluó: los DC incluidos, los eventos requeridos, el período de la política, el historial local disponible, los archivos, el destino central y la vía de búsqueda. Adjunte las excepciones sin resolver con responsable y fecha de revisión. Si la prueba solo abarcó un controlador o eventos seleccionados, indique ese alcance y programe las comprobaciones restantes.
Mantenga las evidencias fechadas. Repita la revisión después de cambios que afecten a los DC incluidos, la configuración de registros, los archivos o la recopilación central. La tarea de mantenimiento útil consiste en actualizar las pruebas subyacentes e investigar las discrepancias, en lugar de copiar el veredicto anterior en un informe nuevo.
Cómo detecta EtcSec este problema
En etc-collector, en el commit 9f698083354a1cb7f625df5cb490a515823c3257, AUDIT_LOG_RETENTION_SHORT emite un hallazgo Info con un Count=1 constante. Su Detect() no lee ningún campo de DetectorData y devuelve el recordatorio incluso sin datos de DC. No mide ni la capacidad de los registros ni la retención legible, y no puede distinguir un entorno conforme de uno deficiente ni pasar automáticamente a verde después de la remediación.
La vía de recopilación AD examinada obtiene objetos del directorio y datos GPO mediante LDAP; este detector no invoca ningún proveedor de registros de eventos ni lee ningún canal Security local. Utilice el recordatorio para solicitar las evidencias por DC descritas anteriormente, no como prueba de un déficit de retención.
Registre la revisión manual y la decisión aprobada junto con el recordatorio. Mantenga las pruebas de historial legible y los resultados de búsqueda centrales a disposición del responsable que acepta el cierre.
Explore las páginas de identidad que apoyan este tema