Convalida della configurazione del registro di sicurezza (rsyslog e syslog-ng) per PCI DSS 10.5

Mi sembra che tu stia analizzando eccessivamente il problema: PCI DSS non ti richiede di garantire che il sistema sia impossibile da abusare, richiede che tu esegua la dovuta diligenza lungo alcuni dei vettori di abuso di base.

Le citazioni qui sono da DSS 3.1 "Procedure di test":

10.5.1 Only individuals who have a job-related need can view audit trail files.

Assicurarsi che i registri del tipo auth * siano leggibili solo da root. Questo può essere piuttosto semplice:

$ grep authpriv /etc/rsyslog.conf
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure
$ ls -l /var/log/secure
-rw------- 1 root root 1085793 Nov 10 13:43 /var/log/secure
$

E hai finito. È possibile che un amministratore malintenzionato faccia il possibile per registrare authpriv da qualche altra parte e sia oscuro vedere dove e che sia anche leggibile? È possibile , ma non è quello che sta cercando QSA, ma stanno cercando di assicurarti di non configurare erroneamente i tuoi log in modo che tutti possano leggere authpriv.

(modifica) la situazione che descrivi nel commento:

The issue with checksumming was that applications had valid needs to alter the configuration (in places that do not affect security logs) and that broke the checksum.

dovrebbe effettivamente essere più facile da indirizzare con rsyslog:

• i log di sistema sono specificati in /etc/rsyslog.conf, standardizzati e auto-gestiti su tutti i sistemi da cfengine.
• rsyslog.conf include /etc/rsyslog.d / *. conf
• le configurazioni del registro delle applicazioni vanno in /etc/rsyslog.d/application.conf

In questo modo, è possibile dimostrare facilmente che la configurazione del sistema per la registrazione (ad esempio) di authpriv è corretta e che la configurazione è comune tra i sistemi. Le personalizzazioni per applicazione sono isolate nei file /etc/rsyslog.d/*.conf, che non hai bisogno di checksum o prova per il tuo QSA - può guardare uno o due, ma in generale, si fiderà di te come amministratore per non nascondere una configurazione di sistema ridondante non valida nei file di configurazione a livello di applicazione.

Ancora: PCI DSS ti chiede di documentare che stai facendo le cose di base giuste. Non stanno cercando di costringerti a dimostrare, al di là di ogni ombra di dubbio, che non c'è modo per te di fare qualcosa di sbagliato.

10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

Mostra che i tuoi file di log non sono scrivibili per gruppi inappropriati o "altro":

# find /var/log -type f -a \( -perm -g+w -or -perm -o+w \) -ls
131282 2220 -rw-rw-r--   1 root     utmp      2265216 Oct 30 09:51 /var/log/wtmp-20151101
133888  192 -rw-rw-r--   1 root     utmp       192000 Nov  9 16:12 /var/log/wtmp
# 

wtmp è scrivibile in gruppo per utmp per consentirne l'aggiornamento da parte di terminali non root, quindi è normale. Nessun altro risultato. Insieme ai controlli di base per mostrare che i tuoi registri sono in / var / log, tutto è pronto.

10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.

10.5.4 Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal log server or media.

Per prima cosa, mostra la configurazione che indica che i log sono inviati al tuo SIEM centrale. Quindi mostra una query che dimostra che i registri della tua macchina possono essere trovati sul tuo SIEM. Ripeti l'operazione per qualsiasi dimensione del campione richiesta da QSA.

Non è necessario eseguire una riconciliazione completa per cui ogni riga trovata localmente viene trovata sul server remoto. Devi solo dimostrare di averlo configurato per accedere a un server remoto e che funziona apparentemente correttamente.

10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.

Conferma che / etc / rsyslog * e / var / log / * sono monitorati dal tuo FIM (ad esempio, Tripwire). Questo è tutto.

Questi passaggi sono sufficienti per proteggere il tuo ambiente? No! Il PCI DSS è un pavimento, non un soffitto. È una lista di controllo di due diligence di base per iniziare e cercare di assicurarsi che tutti si allacciano le cinture di sicurezza. In questo modo puoi continuare a cercare modi per migliorare la tua sicurezza, ma probabilmente passerai l'audit PCI sul tuo percorso.

Ora, detto questo, sto rilevando un altro problema nella tua domanda, che è che ti manca il controllo centralizzato della configurazione. Ciò renderà i vostri audit più difficili - quando dite "ecco il file di configurazione, ed ecco la configurazione di Puppet che mostra che è usata dal 95% dei nostri server" rendete più semplice per il QSA firmare su un campione del vostro ambiente. Se hai "configurazioni valide [che] tendono a proliferare" hai un problema che non sta solo influenzando la tua conformità PCI, avrà un impatto sulla tua sicurezza generale. Dovresti esaminare la gestione centralizzata (ecco un confronto di quattro di tali strumenti ).

Le persone molto intelligenti e creative tendono a pensare a tutte le eventualità che potrebbero rompere un sistema e renderle conto. È un buon istinto per creare un buon sistema affidabile. Ma ora è quello che stai facendo qui. Non confondere il superamento del controllo PCI con la creazione di un sistema di sicurezza infrangibile o persino un sistema di sicurezza davvero eccezionale. I due sono molto diversi. Come menziona gowenfawr, tutto ciò che devi davvero fare è mantenere la dovuta diligenza, e non fare cose veramente stupide come avere il file di registro modificabile da chiunque abbia accesso al sistema.

Non è possibile creare il sistema perfetto come quello che stai descrivendo è inalterabile. Per lo meno un abile attaccante potrebbe semplicemente sostituire il tuo syslog con la sua versione che filtra alcuni record. Con un accesso di basso livello a un sistema ci sono innumerevoli modi per coprire le tue tracce. Ci sono modi per scoprirlo, ma ci sarà sempre un modo per aggirarlo. Niente è "inalterabile" nel modo in cui stai pensando alla parola inalterabile.