Problema

Muchas pequeñas empresas gestionan sus equipos Windows de forma aislada, sin Active Directory ni políticas de dominio. Los auditores suelen exigir pruebas de que los usuarios estándar no pueden abrir, exportar o borrar los registros del sistema. En un entorno sin AD, ¿cómo se garantiza y documenta esa restricción usando solo configuraciones locales?

Causa

En Windows, la capacidad de leer los registros de seguridad y de sistema está ligada a los privilegios SeSecurityPrivilege y SeBackupPrivilege. Por defecto, los miembros del grupo Administrators poseen ambos, mientras que los usuarios estándar no los tienen. Sin embargo, la interfaz de Event Viewer permite al usuario abrir los logs de Aplicación y Sistema en modo de solo‑lectura, lo que a veces se interpreta como “acceso permitido”. La verdadera barrera debe aplicarse a los logs críticos (Security, Setup, Forwarded Events) y a la operación de exportar o borrar.

Los problemas habituales son:

  1. Política de auditoría desactivada – sin auditoría, el auditor no tiene evidencia de que los intentos fallidos fueron registrados.
  2. Permisos de archivo de registro heredados – si se modifican manualmente los ACL del archivo .evtx, se pueden crear excepciones no deseadas.
  3. Falta de export‑deny – aunque el usuario no pueda abrir el log, Windows permite intentar exportar y obtener “Access is denied” solo si los privilegios faltan.

Solución

La estrategia se divide en tres pasos:

  1. Configurar la política local de auditoría para que registre los intentos de acceso a los logs.
  2. Aplicar una Directiva de Grupo Local (Local GPO) que niegue los privilegios de respaldo y de seguridad a los usuarios estándar.
  3. Capturar evidencia reproducible en cada endpoint.

1. Habilitar auditoría de acceso a los logs

Utiliza auditpol para activar la subcategoría Audit Policy Change y Logon/Logoff y, crucialmente, Audit Policy Subcategory: “Audit Security System Extension” y “Audit Other System Events”. El comando:

auditpol /set /subcategory:"Security System Extension" /failure:enable
auditpol /set /subcategory:"Other System Events" /failure:enable

Esto garantiza que cualquier intento fallido de abrir o exportar un registro quede en el Security Log.

2. Negar privilegios críticos a usuarios estándar

Abre gpedit.msc → Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Asignación de derechos de usuario.

  • Denegar “Back up files and directories” a Usuarios.
  • Denegar “Manage auditing and security log” a Usuarios.

En la práctica, crea dos entradas:

Derecho Usuarios a negar
Back up files and directories Usuarios
Manage auditing and security log Usuarios

Al negar estos derechos, el intento de abrir el Security Log o de exportar cualquier log genera automáticamente “Access is denied”.

3. Documentar la configuración

Para cada equipo, exporta la política local y el estado de auditoría:

secedit /export /cfg C:\Temp\LocalPolicy.inf
auditpol /get /category:* > C:\Temp\AuditPolicy.txt

Guarda los archivos y toma capturas de pantalla de:

  • La ventana de Event Viewer mostrando el mensaje de error al intentar abrir Security como usuario estándar.
  • El cuadro de diálogo de Guardar como… que muestra “Access is denied”.
  • La sección de Asignación de derechos de usuario con los dos derechos negados.
  • La salida de auditpol que confirma que los fallos están auditados.

Cuándo aplicar esta solución

  • Entornos sin dominio donde cada equipo se administra de forma independiente.
  • Auditorías ISO 27001, SOC 2 o NIST que exijan evidencia de control de acceso a los logs.
  • Equipos con usuarios locales que no necesitan privilegios de respaldo ni gestión de auditoría.

No es necesario aplicar esta configuración si:

  • El entorno ya está bajo un controlador de dominio y la política de auditoría se gestiona vía GPO.
  • Los usuarios necesitan exportar logs para tareas de soporte legítimas; en ese caso, crea un grupo de seguridad dedicado y asigna los derechos solo a ese grupo.

Código

# 1. Habilitar auditoría de fallos en eventos críticos
auditpol /set /subcategory:"Security System Extension" /failure:enable
auditpol /set /subcategory:"Other System Events" /failure:enable

# 2. Exportar política local para evidencia
secedit /export /cfg C:\Temp\LocalPolicy.inf

# 3. Guardar configuración de auditoría
auditpol /get /category:* > C:\Temp\AuditPolicy.txt

Verificación

  1. Inicia sesión con una cuenta que pertenezca al grupo Usuarios.
  2. Ejecuta eventvwr.msc. Intenta abrir Security → debe aparecer “Access is denied”.
  3. Desde la misma sesión, intenta Guardar eventos como… → mensaje de error idéntico.
  4. Revisa el Security Log con una cuenta administrativa y busca eventos con ID 4625 (logon failure) y sub‑código que indique “Access is denied” para la operación de lectura del log.
  5. Confirma que los archivos LocalPolicy.inf y AuditPolicy.txt contienen las entradas de denegación y auditoría.

Notas adicionales

  • La denegación de “Back up files and directories” afecta a cualquier operación que requiera el privilegio de respaldo, incluido el uso de wevtutil. Si algún proceso legítimo necesita respaldar archivos, crea un grupo de servicio y otórgale el derecho explícitamente.
  • En Windows 11, la UI de Event Viewer muestra el mensaje de error en un cuadro de diálogo modal; en Windows 10 el mensaje aparece en la barra de estado. Captura ambos estilos si los equipos son mixtos.
  • Mantén los archivos de evidencia en una ubicación protegida (por ejemplo, C:\Evidence\) y registra su hash SHA‑256 para demostrar que no fueron alterados después de la auditoría.