En general, la respuesta más conservadora se presenta en forma de algo fácilmente comprensible y accesible por la población general.

Ignorando la hipérbole de ese tipo de respuesta, hay dos cosas que realmente debes tener en cuenta.

1. ¿Qué registros debo conservo
2. ¿Cuánto tiempo debo retener dichos registros?

Retención de registros

La respuesta a 2 es simple y bien definida por el estándar. Los registros deben conservarse durante un año y los últimos tres meses deben ser fácilmente accesibles. Así que vamos a traducir esa declaración en mi propia recomendación

• Implemente un sistema de registro centralizado, por ejemplo, un sistema de un solo propósito que actúa como un receptor de syslog
• Si el almacenamiento está disponible en el sistema central, entonces retenga todos los registros de los sistemas con alcance PCI durante 1 año
• De lo contrario, retenga todos los registros de los sistemas de ámbito PCI en el sistema central durante 3 meses, gire todos los registros de más de 3 meses a un almacenamiento a largo plazo (como cinta / VTL / papiro). Se eliminan los registros de almacenamiento a largo plazo que tienen más de 1 año.

Eventos para registrar

La respuesta al primer punto está un poco menos bien definida. El estándar quiere que usted guarde eventos y detalles para todos los sistemas con alcance PCI. Entonces, suponiendo que haya determinado todos los sistemas que tiene en su alcance, la única pregunta es qué eventos desea registrar. Esto es mucho más difícil de responder, ya que dependería en gran medida de su entorno y de las aplicaciones que se estén ejecutando. La respuesta fácil es preguntar a tu QSA. Para ser conservador, recomendaría agregar *.* @logserver a sus archivos de configuración de syslog, o realizar el equivalente de Windows. Asegúrese de que las aplicaciones que no sean de syslog en esas máquinas también encuentren la manera de cerrar sus sesiones. Esto incluiría un servidor web, clientes pesados, etc. Como mínimo, asegúrese de que todas las autenticaciones, y exitosas, se registren. Si es posible, los registros de auditoría completos del acceso a datos en las aplicaciones serían buenos. Para las aplicaciones web, esto sería estándar en sus registros de httpd, pero los clientes pesados pueden no ser tan granulares.

Al final, dado que su QSA decide si usted cumple o no, es su mejor opción para responder estas preguntas.

Mi experiencia con esto es que depende de su PCI QSA (es decir, es parcialmente subjetivo). Intente hojear el slidedeck de Anton Chuvakin para obtener algunos consejos:

PCI DSS y registro: lo que necesita saber:
enlace

Desde mi punto de vista, hay 2 cosas que están discutiendo. Uno es qué registros mantener para el cumplimiento de PCI. La otra es cuántos registros se deben mantener en Splunk.

Splunk es una herramienta de informes que está fuera de los requisitos de PCI. Puede reducir la cantidad de registros que realiza un seguimiento con Splunk para mantener su licencia y seguir manteniendo los registros según lo requerido por PCI. Puede configurar un servidor de registro independiente para capturar los registros que necesita para PCI, y solo alimentar a Splunk con los registros que desea analizar.

Aquí está el documento de requisitos. La sección 10 es lo que estás buscando.

Editar: usted dice que, de hecho, utiliza Splunk como su servidor central de registro. En ese caso, PCI no especifica que se deban registrar los permisos asignados a un usuario, excepto que se haga un seguimiento de los usuarios con acceso de administrador / raíz.

De alguna manera odio responder a mi propia pregunta, especialmente esta tarde después del hecho, sin embargo encontré un gran recurso que explica exactamente lo que se necesita registrar desde la auditoría de Windows para cumplir nuestras necesidades.

Account Management
Audit Application Group Management Success, Failure 
Audit Computer Account Management Success, Failure 
Audit Distribution Group Management Success, Failure 
Audit Security Group Management Success, Failure 
Audit User Account Management Success, Failure 

Detailed Tracking
Audit DPAPI Activity No Auditing 
Audit Process Creation No Auditing 
Audit Process Termination No Auditing 
Audit RPC Events No Auditing 

DS Access
Audit Directory Service Access Failure 

Logon/Logoff
Audit Account Lockout Success, Failure 
Audit IPsec Extended Mode No Auditing 
Audit IPsec Main Mode No Auditing 
Audit IPsec Quick Mode No Auditing 
Audit Logoff Success, Failure 
Audit Logon Success, Failure 
Audit Special Logon Success, Failure 

Object Access
Audit File System Success, Failure 
Audit Registry Success, Failure 

Policy Change
Audit Audit Policy Change Success, Failure 
Audit Authentication Policy Change Success, Failure 
Audit Authorization Policy Change Success, Failure 
Audit Filtering Platform Policy Change Success, Failure 
Audit MPSSVC Rule-Level Policy Change Success, Failure 
Audit Other Policy Change Events Success, Failure 

Privilege Use
Audit Sensitive Privilege Use Failure 

System
Audit Security State Change Success, Failure 
Audit System Integrity Success, Failure 

El que más me sorprendió de esta lista es el error solo en el uso de privilegios. Cuando pienso en ello, el uso de privilegios que nos preocupa (cambiar la configuración de auditoría, pertenencia a grupos, cambiar archivos protegidos de la integridad del sistema operativo, etc.) ya tiene sus propias categorías.