Controalele de securitate nu sunt un lucru da sau nu. Gândiți-vă critic la cât de extremă puteți lua pentru a vă asigura că nu se pierde niciun eveniment de audit. Fiți creativ în privința controalelor alternative.
Se pare că CIS pune acum liste de verificare a implementării în spatele unui formular de contact. Am găsit o copie veche la CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.2.0.pdf pentru a discuta detaliile de implementare. Terminologia și numerotarea se pot schimba, dar raționamentul este în cea mai mare parte atemporal.
4.1.1.3 Asigurați-vă că jurnalele de audit nu sunt șterse automat (notat) Aplicabilitatea profilului:
- Nivelul 2 - Server
- Nivelul 2 - Stație de lucru
Descriere: setarea max_log_file_action determină modul de tratare
fișierul jurnal de audit atingând dimensiunea maximă a fișierului. O valoare pentru keep_logs
va roti jurnalele, dar nu va șterge niciodată jurnalele vechi.
Motivație: În contexte de înaltă securitate, beneficiile menținerii a
istoricul lung de audit depășește costul stocării istoricului de audit.
Audit: rulați următoarea comandă și verificați potrivirile rezultatelor:
# grep max_log_file_action /etc/audit/auditd.conf
max_log_file_action = păstrați jurnalele
Remediere: Setați următorul parametru în /etc/audit/auditd.conf:
max_log_file_action = păstrați jurnalele
Controale CIS:
6.3 Asigurați-vă că sistemele de înregistrare a auditului nu sunt supuse pierderii (adică rotație/arhivă)
Asigurați-vă că toate sistemele care stochează jurnalele au spațiu de stocare adecvat
pentru jurnalele generate în mod regulat, astfel încât fișierele de jurnal să nu fie
umpleți între intervalele de rotație a buștenilor. Jurnalele trebuie arhivate și
semnat digital periodic.
Rețineți că rațiunea vorbește despre medii de înaltă securitate. Nivelul 2, căruia presupun că este hărți grupa de implementare 2 într-o terminologie mai nouă. Acest lucru este pentru situațiile în care nu vă permiteți să pierdeți niciun eveniment, un impact ridicat din cauza mediului de conformitate sau a altor riscuri.
Un lucru sigur de făcut ar fi să lăsați un proces de arhivare a fișierelor jurnal să ștergă fișierele vechi, numai după ce au fost făcute copii de rezervă. Desigur, puteți șterge fișierele jurnal de pe gazde. Dar aveți grijă ca un eșec în arhivare să nu aibă ca rezultat ștergerea rapidă a fișierelor prin rotația jurnalului.
Pentru stocarea arhivelor, nu lăsați jurnalele de audit să fie modificate sau șterse. Semnează fișierele pentru a le confirma integritatea. Eliminați permisiunile de editare și ștergere din conturile de stocare a obiectelor. Luați în considerare stocarea la rece pe suporturi de bandă.
Această listă de verificare în unele situații recomandă, de asemenea admin_space_left_action = oprire. Da, asta înseamnă că sistemul de audit va închide gazda dacă nu se poate înregistra. Dacă acest lucru vă îngrozește din cauza obiectivelor dvs. de nivel de serviciu, poate fi necesar să reexaminați dacă acest nivel de paranoia este potrivit pentru mediul dvs.
De asemenea, implementați un sistem centralizat de înregistrare a auditului. Redirecționați sau colectați în alt mod evenimente într-un sistem cu o cantitate mare de stocare. Mai ușor de securizat, interogat și reținut.
Care oferă o securitate mai bună: o bază de date centrală cu 6 luni de date gata de a fi interogate și ani pentru copii de rezervă sau o flotă de gazde care rămâne mereu fără spațiu de stocare pentru că cineva a crezut că o listă de verificare interzice ștergerea fișierelor?
