Retenția logurilor pentru incidente trebuie să ofere organizației suficient istoric pentru detectare, triere, investigație și raportare. Perioada trebuie stabilită în funcție de risc, criticitatea sistemului și valoarea investigativă a sursei, iar configurația reală trebuie verificată periodic.
01. Retenție loguri pentru incidente: ce problemă rezolvă
Un incident este adesea detectat după ce primele indicii au dispărut. Un cont compromis poate fi folosit discret săptămâni întregi, o regulă de forwarding din Microsoft 365 poate rămâne activă luni, iar exfiltrarea poate arăta inițial ca trafic legitim.
Din acest motiv, retenția logurilor nu este o simplă decizie de stocare. Este o decizie despre cât de bine poate organizația să reconstruiască faptele, să limiteze impactul și să demonstreze ce măsuri au fost luate.
Retenția corectă permite corelarea unui incident cu activități anterioare și ulterioare: autentificări, schimbări de privilegii, acces la date, modificări de configurare, execuții de procese, conexiuni externe și acțiuni administrative.
Fără această cronologie, investigația începe să se bazeze pe presupuneri. Echipa trebuie să poată determina când a început compromiterea, ce identități au fost utilizate, ce sisteme au fost afectate, ce informații au fost accesate și ce mecanism de persistență a fost creat.
Pentru organizațiile vizate de NIS2, problema are și o dimensiune de guvernanță. Managementul trebuie să poată demonstra existența unor măsuri adecvate și proporționale pentru gestionarea riscurilor și incidentelor.
02. Nu există o perioadă universală de păstrare
O perioadă fixă aplicată tuturor logurilor este ușor de administrat, dar rareori este justificată. Retenția depinde de criticitatea serviciului, timpul estimat de detectare, obligațiile contractuale și de reglementare, valoarea datelor, tipurile de amenințări și capacitatea reală de investigare.
Logurile de autentificare și activitate privilegiată pentru un tenant Microsoft 365 care procesează informații sensibile au o valoare investigativă diferită față de logurile foarte detaliate produse de un sistem intern de monitorizare.
În primul caz, lipsa istoricului poate împiedica stabilirea accesului neautorizat la conturi, mailbox-uri sau documente. În al doilea caz, păstrarea integrală pe termen lung poate fi disproporționată dacă informația relevantă este deja agregată sau corelată într-o altă platformă.
Ca principiu operațional, organizația are nevoie de o fereastră suficientă pentru detectare, triere, investigație și raportare, plus o marjă pentru incidentele descoperite târziu.
| Categorie | Întrebarea de control | Valoarea principală |
|---|---|---|
| Identity | Putem reconstrui autentificările și schimbările de privilegii? | Compromise investigation |
| Cloud activity | Putem determina ce date și configurații au fost accesate? | Impact assessment |
| Endpoint | Putem determina execuția, persistența și mișcarea laterală? | Technical investigation |
| Network | Putem identifica destinațiile și conexiunile relevante? | Traffic reconstruction |
| Administrative activity | Putem demonstra cine a modificat un control și când? | Accountability |
03. Retenție activă, arhivă și conservarea cazurilor deschise
Retenția activă reprezintă perioada în care logurile sunt disponibile imediat pentru interogare, corelare și analiză. Această zonă este critică pentru SOC, IT și echipele de incident response.
Arhiva poate păstra date mai vechi cu un cost mai redus, acces controlat și un timp de recuperare acceptabil pentru investigații retrospective, audit sau litigii.
Cele două niveluri nu trebuie confundate. Păstrarea tuturor evenimentelor în storage rapid pentru mai mulți ani poate deveni foarte costisitoare. Eliminarea istoricului după câteva săptămâni poate face imposibilă o investigație descoperită târziu.
Separat, orice incident confirmat sau suspiciune credibilă trebuie să permită conservarea dovezilor relevante. Politica standard de ștergere nu trebuie să elimine loguri, exporturi, configurații sau alte artefacte aferente unui caz încă deschis.
În Microsoft Purview, de exemplu, durata efectivă a audit logurilor depinde de serviciu, licențiere și politicile de retenție configurate. Organizația trebuie să valideze tehnic aceste limite, nu să presupună că durata menționată într-o politică internă este aplicată automat.
04. Stabiliți sursele care contează înainte de a calcula terabiți
Retenția începe cu un inventar de surse, nu cu alegerea unei perioade. Organizația trebuie să identifice evenimentele care permit detectarea și reconstrucția unui incident material.
Pentru majoritatea organizațiilor, acestea includ identitatea, activitatea privilegiată, endpoint-urile, rețeaua, emailul, serviciile cloud, infrastructura critică și sistemele care găzduiesc date sau procese sensibile.
Logging scope
Sursele care merită evaluate primele.
Microsoft Entra ID: sign-ins, risk events, roluri și modificări administrative.
Microsoft 365: Exchange, SharePoint, OneDrive, Teams și administrative audit.
Endpoint și EDR: procese, execuții, persistence și evenimente de securitate.
Firewall, VPN, proxy și DNS: conectivitate și acces extern.
Servere și infrastructură: autentificare, administrare și configurări.
Backup și recovery: acces administrativ, ștergeri și modificări.
SaaS și aplicații critice: activitate de utilizator și schimbări de acces.
Platforme administrative: cine a modificat controalele și configurațiile.
În Microsoft 365 sunt relevante autentificările, modificările de roluri și politici, activitatea pentru Exchange, SharePoint, OneDrive și Teams, regulile de forwarding, consimțământul acordat aplicațiilor și modificările de configurare de securitate.
O investigație a unui cont compromis este incompletă dacă există doar alarma de autentificare, dar nu există istoric pentru acțiunile executate după acces.
05. Calitatea logurilor contează la fel de mult ca durata
Un log păstrat doi ani, dar fără timestamp sincronizat, identificator de utilizator, adresă sursă sau informația despre acțiunea executată poate avea o valoare investigativă foarte mică.
Retenția trebuie evaluată împreună cu completitudinea, integritatea și posibilitatea de corelare.
Sincronizarea timpului și identitatea
Dacă firewall-ul, endpoint-ul, identitatea cloud și serverul de aplicație folosesc timestamp-uri diferite, cronologia incidentului devine dificil de reconstruit și de susținut.
Aceeași persoană poate apărea prin UPN, cont local, adresă de email, device ID sau cont privilegiat separat. Fără corelare, analiza consumă timp și poate pierde relația dintre evenimente.
Protecția logurilor
Accesul la loguri trebuie limitat și monitorizat. Administratorii care pot modifica infrastructura nu ar trebui să poată elimina fără urmă dovezile aceleiași infrastructuri.
Controalele relevante includ segregarea rolurilor, acces privilegiat temporar prin PIM sau JIT, jurnalizarea activității administrative, alerte pentru modificarea politicilor de retenție și mecanisme de imutabilitate acolo unde riscul justifică măsura.
06. Cum transformați retenția logurilor într-un control demonstrabil
O politică eficientă nu enumeră doar termene. Ea leagă fiecare categorie de log de un scop, o sursă, un responsabil, o locație de stocare, o perioadă de acces activ, o perioadă de arhivare și o regulă de conservare pentru incidente.
În plus, politica trebuie să stabilească cine aprobă excepțiile și când este revizuită decizia.
Un cadru practic începe cu evaluarea contextului. Identificați serviciile critice, informațiile sensibile, dependențele de furnizori, expunerile externe și scenariile plauzibile de incident.
Apoi prioritizați sursele care pot confirma sau infirma aceste scenarii. Abia după aceea calculați volumul, costul, capacitatea de căutare și opțiunile de arhivare.
| Element | Ce trebuie documentat |
|---|---|
| Source | Sistemul și evenimentele colectate. |
| Purpose | Scenariile de investigație susținute. |
| Owner | Responsabilitatea pentru colectare și revizuire. |
| Active retention | Durata disponibilității imediate pentru analiză. |
| Archive | Durata și modul de recuperare a datelor istorice. |
| Integrity | Protecția împotriva modificării sau ștergerii neautorizate. |
| Evidence test | Dovada că un eveniment vechi poate fi găsit și interpretat. |
Implementarea trebuie verificată prin teste. Selectați un eveniment istoric, precum o modificare de rol, o autentificare suspectă sau schimbarea unei reguli de email, și verificați dacă poate fi găsit, interpretat și corelat cu alte surse.
Testul trebuie să măsoare și timpul necesar pentru recuperare. Dacă datele există în arhivă, dar obținerea lor durează zile, această limitare trebuie să fie compatibilă cu procesul de incident response și cu obligațiile de raportare.
Dovezile pentru audit nu se limitează la politica aprobată. Sunt relevante configurațiile efective, inventarul surselor, rezultatele testelor, rapoartele privind eșecurile de colectare, aprobările pentru excepții și revizuirile periodice.
07. Echilibrul dintre securitate, cost și protecția datelor
Logurile pot conține adrese IP, identificatori de utilizator, nume de dispozitive, acțiuni ale angajaților și alte informații care necesită o analiză atentă din perspectiva protecției datelor.
Minimizarea nu înseamnă eliminarea logurilor utile. Înseamnă colectarea și păstrarea informației necesare pentru un scop legitim, cu acces proporțional și termene justificate.
Decizia trebuie aliniată între cybersecurity, IT, DPO, juridic, risc și proprietarii serviciilor.
Dacă aceste funcții lucrează separat, rezultatul este previzibil: securitatea cere mai mult istoric, costurile reduc stocarea, iar conformitatea produce o regulă generală care nu corespunde platformelor reale.
Un model matur tratează aceste tensiuni ca decizii de risc documentate și aprobate.
08. Întrebarea utilă pentru management
Managementul nu trebuie să întrebe doar dacă organizația deține un SIEM sau dacă logging-ul este activ.
Întrebarea utilă este: dacă descoperim mâine un incident început în urmă cu câteva luni, putem reconstrui cine a avut acces, ce a făcut, ce sisteme au fost afectate și ce dovezi susțin concluzia?
Rizea Networks tratează retenția ca parte din capacitatea de incident response și assurance: sursele relevante, perioada justificată, ownership-ul, configurația validată și dovezile disponibile pentru management sau auditor.
Dacă organizația nu poate arăta astăzi ce loguri păstrează, pentru cât timp și cum ar investiga un incident descoperit peste câteva luni, problema nu este arhivarea. Problema este lipsa unui control demonstrabil.