Generalmente, la risposta più conservativa arriva sotto forma di qualcosa di facilmente comprensibile e accessibile dal generale popoloso.

Ignorando l'iperbole di quel tipo di risposta, ci sono due cose che devi prendere veramente in considerazione.

1. Quali log dovrebbero conservare
2. Per quanto tempo dovrei conservare detti log

Conservazione del registro

La risposta a 2 è semplice e ben definita dallo standard. I log devono essere conservati per un anno e gli ultimi tre mesi devono essere facilmente accessibili. Quindi traduciamo questa affermazione nella mia raccomandazione

• Implementa un sistema di registrazione centralizzato, ad es. un sistema a singolo scopo che funge da ricevitore syslog
• Se lo spazio di archiviazione è disponibile sul sistema centrale, conservare tutti i registri dai sistemi con ambito PCI per 1 anno
• Altrimenti mantieni tutti i log dai sistemi con scope PCI sul sistema centrale per 3 mesi, ruota tutti i registri più vecchi di 3 mesi nella memoria a lungo termine (come nastro / VTL / papiro). Expunge registra su archivi a lungo termine che sono più vecchi di 1 anno.

Eventi da registrare

La risposta al primo punto è un po 'meno ben definita. Lo standard vuole che tu mantenga eventi e dettagli per tutti i sistemi con scope PCI. Quindi, assumendo che tu abbia determinato ogni sistema che è in ambito, l'unica domanda è quali eventi vuoi registrare. È molto più difficile rispondere, perché dipenderebbe in gran parte dal proprio ambiente e dalle applicazioni in esecuzione. La risposta facile è chiedere al tuo QSA. Per essere prudente, raccomanderei di aggiungere *.* @logserver ai file di configurazione syslog o di eseguire l'equivalente di Windows. Assicurati che ogni applicazione non syslog su quelle macchine trovi anche un modo per ottenere i loro log out. Ciò include il server web, i client grassi, ecc. Almeno assicurati che tutte le autenticazioni, con esito positivo e , non siano state registrate. Se possibile, i registri completi di controllo dell'accesso ai dati sulle applicazioni sarebbero carini. Per le app Web, questo sarebbe standard nei log di httpd, ma i client grassi potrebbero non essere così dettagliati.

Alla fine, dal momento che il tuo QSA decide se sei o meno conforme, sono la soluzione migliore per rispondere a queste domande.

La mia esperienza con questo dipende dal tuo QSA PCI (cioè è parzialmente soggettivo). Prova a sfogliare il diapositiva di Anton Chuvakin per alcuni suggerimenti:

PCI DSS e registrazione: che cosa è necessario sapere:
link

Ci sono 2 cose che stai discutendo, dal mio punto di vista. Uno è quali registri conservare per conformità PCI. L'altro è il numero di registri da conservare in Splunk.

Splunk è uno strumento di reporting che non rientra nei requisiti PCI. È possibile ridurre il numero di registri tracciati con Splunk per mantenere la licenza e conservare i registri come richiesto per PCI. È possibile configurare un server di registrazione separato per acquisire i log necessari per PCI e alimentare solo Splunk con i registri che si desidera analizzare.

Qui è il documento obbligatorio. La sezione 10 è ciò che stai cercando.

Modifica: dici di usare effettivamente Splunk come server di registrazione centrale. In questo caso, PCI non specifica che le autorizzazioni assegnate a un utente devono essere registrate, tranne che gli utenti con accesso root / admin sono monitorati.

Odio rispondere alla mia stessa domanda specialmente dopo questo fatto, tuttavia ho trovato un ottima risorsa che spiega esattamente cosa deve essere registrato dal controllo di Windows per soddisfare i nostri bisogni

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 

Quello che mi ha sorpreso di più in questa lista è il fallimento solo nell'uso dei privilegi. Quando ci penso, l'uso dei privilegi di cui ci preoccupiamo, cambiando le impostazioni di controllo, l'appartenenza ai gruppi, la modifica dei file protetti dall'integrità del sistema operativo, ecc., Abbiamo già le loro categorie.