PII în jurnalele de securitate: ghid operațional pentru GDPR, NIS2 și DORA

Un analist de securitate deschide SIEM la 02:17. Alerta pare inițial de rutină: mai multe autentificări eșuate, o sesiune reușită de la o adresă IP neobișnuită, apoi un val de apeluri API către un endpoint de export pentru clienți. În câteva minute, canalul de incident este aglomerat. CISO vrea să știe dacă este vorba despre o compromitere de cont. Departamentul juridic întreabă dacă jurnalele conțin date cu caracter personal. Responsabilul cu protecția datelor (DPO) întreabă dacă ID-ul de utilizator, adresa IP, identificatorul dispozitivului și URL-urile solicitărilor din SIEM sunt acoperite de informarea privind confidențialitatea și de evidențele activităților de prelucrare. Managerul de conformitate întreabă dacă jurnalele trebuie păstrate pentru raportarea către autoritățile de reglementare. Echipa responsabilă de succesul clienților întreabă dacă un client poate solicita mâine ștergerea acelorași intrări de jurnal.
Acesta este momentul în care multe organizații descoperă că jurnalizarea de securitate și guvernanța confidențialității au fost construite ca lumi separate.
Echipele de securitate doresc jurnale detaliate, retenție îndelungată, stocare imuabilă și acces rapid. Echipele de confidențialitate doresc reducerea la minimum a datelor, limitarea scopului, acces bazat pe roluri, disciplină privind retenția și ștergere atunci când datele nu mai sunt necesare. Echipele de răspuns la incidente doresc ca dovezile să fie păstrate exact așa cum au fost. Responsabilitatea impusă de GDPR cere organizației să poată explica de ce se află acolo date cu caracter personal, cine le-a accesat și cât timp sunt păstrate. NIS2 și DORA adaugă urgență, deoarece entitățile esențiale, entitățile importante și organizațiile financiare au nevoie de dovezi suficiente pentru a clasifica incidentele, a le raporta la timp și a demonstra un management eficace al riscurilor TIC.
Adevărul incomod este simplu: jurnalele de securitate sunt adesea depozite de date cu caracter personal. Jurnalele de autentificare pot conține nume de utilizator, adrese de e-mail, adrese IP, amprente ale dispozitivelor și geolocalizare. Jurnalele aplicațiilor pot expune URL-uri, șiruri de căutare, fragmente de payload, numere de caz și conținut de mesaje. Jurnalele EDR și din cloud pot include nume de gazde asociate angajaților, căi de fișiere care conțin nume, identificatori de sesiune și acțiuni ale administratorilor. Jurnalele IAM pot dezvălui modificări de privilegii, apartenența la grupuri și tentative eșuate de acces la sisteme sensibile.
Dacă jurnalele conțin PII, ele nu mai reprezintă doar o problemă de jurnalizare ISO 27001. Ele devin o problemă de confidențialitate, retenție, dovezi, raportare a incidentelor și guvernanță a furnizorilor. Clarysec tratează guvernanța PII în jurnalele de securitate ca pe o problemă de mapare a cerințelor de conformitate între cadre, nu ca pe o simplă problemă de configurare a instrumentelor.
Dilema reală a CISO: dovezi pentru detecție versus reducerea la minimum a datelor
CISO din scenariul de la 02:17 se confruntă cu un conflict operațional real. Dacă jurnalele sunt prea sărace, SOC nu poate detecta compromiterea, nu poate reconstrui cronologiile și nu poate susține raportarea NIS2 și DORA. Dacă jurnalele sunt prea bogate, organizația poate colecta mai multe date cu caracter personal decât este necesar, le poate păstra prea mult timp, le poate expune unui număr prea mare de administratori sau poate eșua în susținerea drepturilor GDPR și a obligațiilor de transparență.
GDPR definește datele cu caracter personal în sens larg, ca informații referitoare la o persoană identificată sau identificabilă. Prelucrarea include colectarea, stocarea, utilizarea, divulgarea, ștergerea și distrugerea. În practică, jurnalele care conțin adrese IP, ID-uri de utilizator, identificatori de dispozitiv sau înregistrări de activitate pot reprezenta date cu caracter personal, în funcție de context. Principiile GDPR impun prelucrare legală, echitabilă și transparentă, limitarea scopului, reducerea la minimum a datelor, limitarea stocării, integritate și confidențialitate, precum și responsabilitate.
Întrebarea de guvernanță nu este: „Putem jurnaliza vreodată date cu caracter personal?” Întrebarea corectă este: „Ce PII trebuie să jurnalizăm pentru securitate, răspuns la incidente și conformitate, ce temei juridic susține această prelucrare, ce măsuri de protecție se aplică și când trebuie datele șterse, anonimizate sau plasate sub o blocare aprobată?”
Biblioteca de politici de confidențialitate pentru întreprinderi Clarysec abordează direct această tensiune. Politica de protecție a datelor și confidențialitate, Cerințe de implementare a politicii, clauza 6.2.1, prevede:
Pot fi colectate și prelucrate numai datele necesare pentru un scop specific și legitim al organizației.
Pentru IMM-uri, același principiu este formulat în Politica de protecție a datelor și confidențialitate pentru IMM-uri, Cerințe de implementare a politicii, clauza 6.2.1:
Trebuie colectate și păstrate numai datele cu caracter personal minime necesare.
Această propoziție trebuie să ghideze fiecare decizie de proiectare a jurnalizării. Este necesar fiecare câmp din fiecare sursă de jurnal pentru un scop de securitate, operațional, legal sau contractual definit?
De ce ISO 27701 schimbă discuția despre jurnalizare
ISO/IEC 27001:2022 oferă sistemul de management: domeniu de aplicare, părți interesate, evaluarea riscurilor, tratarea riscurilor, control operațional, monitorizare, audit intern și îmbunătățire continuă. ISO/IEC 27002:2022 oferă îndrumări practice de control pentru jurnalizare, monitorizare, protecția confidențialității PII, colectarea dovezilor, protecția înregistrărilor, ștergere, controlul accesului și managementul furnizorilor. ISO/IEC 27701 extinde modelul de guvernanță către managementul informațiilor privind confidențialitatea, concentrându-se pe operatorii și persoanele împuternicite care prelucrează PII, rolurile de confidențialitate, înregistrările privind prelucrarea PII, protecția datelor încă din faza de proiectare, soluționarea cererilor de exercitare a drepturilor și obligațiile persoanelor împuternicite.
Pentru jurnalele de securitate, ISO 27701 contează deoarece impune întrebări specifice confidențialității pe care echipele de securitate le omit uneori:
- Sursa de jurnal prelucrează PII în calitate de operator, persoană împuternicită, operator asociat sau persoană subîmputernicită?
- Datele din jurnale sunt incluse în inventarul activităților de prelucrare?
- Organizația știe ce câmpuri de jurnal conțin PII?
- PII din jurnale este corelată cu regulile de retenție și ștergere?
- Clienții persoanei împuternicite sunt informați despre jurnalizarea accesului la PII atunci când contractul impune acest lucru?
- Jurnalele sunt luate în considerare la răspunsul la cereri de acces, ștergere sau restricționare?
- Incidentele care implică PII sunt evaluate în raport cu criteriile de raportare privind confidențialitatea, securitatea cibernetică și sectorul financiar?
Politica de securitate și control al accesului pentru PII a Clarysec transformă acest model în cerințe operaționale. Din secțiunea Jurnalizare și monitorizare, clauza 4.6.1:
[Ambele] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să definească în REG12 domeniul de jurnalizare a PII pentru evenimente de autentificare, evenimente de acces, acțiuni privilegiate, activități de export PII și modificări semnificative de configurare, înainte de utilizarea în producție sau de o modificare semnificativă.
Clauza 4.6.2 închide apoi bucla dintre jurnalizare, controlul accesului și retenție:
[Ambele] Responsabilul cu securitatea informațiilor TREBUIE să se asigure că jurnalele care conțin PII au acces restricționat și sunt corelate cu o regulă aprobată de retenție sau ștergere în REG02 sau REG12 înainte de începerea monitorizării jurnalelor.
Astfel, guvernanța PIMS devine practică. REG12 definește ce jurnalizare a PII este permisă și necesară. REG02 identifică unde există PII, inclusiv în jurnale. Regulile de retenție și ștergere nu sunt documente adăugate ulterior. Ele devin condiții prealabile pentru jurnalizarea în producție.
Jurnalele de securitate sunt înregistrări, dovezi și activitate de prelucrare PII
O organizație matură nu trebuie să trateze jurnalele ca pe un reziduu tehnic dispensabil. Jurnalele sunt înregistrări. În timpul unui incident, ele pot deveni probe juridice. Atunci când conțin PII, ele sunt și date prelucrate guvernate din perspectiva confidențialității.
Politica de jurnalizare și monitorizare a Clarysec definește cerințele privind normalizarea jurnalelor. Din Cerințe de guvernanță, clauza 5.1.4:
Cerințe privind formatul și normalizarea jurnalelor (de exemplu, marcaj temporal, ID de utilizator, tip de eveniment, IP sursă)
Acestea sunt exact câmpurile care fac jurnalele utile pentru răspunsul la incidente. Tot ele sunt câmpurile care transformă adesea jurnalele în date cu caracter personal. Aceeași politică pentru întreprinderi indică ce nu trebuie să se întâmple niciodată, în Cerințe de guvernanță, clauza 5.3.3:
Stocarea datelor sensibile în clar (de exemplu, parole, secrete criptografice)
Ideea nu este că jurnalele trebuie să evite toți identificatorii. Ideea este că identificatorii trebuie să fie intenționați, protejați și justificați. Parolele, secretele, token-urile complete și payload-urile inutile nu trebuie jurnalizate. ID-urile de utilizator, adresele IP și metadatele evenimentelor pot fi necesare, dar cer controale.
Pentru IMM-uri, Politica de jurnalizare și monitorizare pentru IMM-uri a Clarysec include revizuirea din perspectiva confidențialității în structura rolurilor. Din Roluri și responsabilități, clauza 4.3.1, aceasta impune organizației să:
Verifice că datele de jurnal referitoare la informații personale sau sensibile sunt gestionate în conformitate cu GDPR și cu alte legi privind protecția datelor.
Versiunea pentru IMM-uri stabilește și o cerință de bază clară pentru retenție. Din Cerințe de guvernanță, clauza 5.2.1:
Jurnalele trebuie păstrate cel puțin 12 luni, cu excepția cazului în care legea sau contractul impune o perioadă de retenție mai lungă ori aceasta este justificată ca parte a unui incident activ sau a unui litigiu.
Și stabilește cerința de protecție, în Cerințe de guvernanță, clauza 5.3.1:
Jurnalele trebuie stocate în locații protejate la scriere, iar accesul trebuie restricționat exclusiv la personalul autorizat.
Pentru răspunsul la incidente la nivel de întreprindere, Politica privind colectarea dovezilor și activitățile criminalistice, Cerințe de implementare a politicii, clauza 6.3.1, impune:
Jurnalele din firewall-uri, SIEM, agenți pentru puncte terminale, platforme de management al identității și al accesului (IAM) și platforme cloud trebuie exportate și stocate în formate imuabile.
Versiunea pentru IMM-uri adaugă un principiu de proporționalitate. Politica privind colectarea dovezilor și activitățile criminalistice pentru IMM-uri, Tratarea riscurilor și excepții, clauza 7.2.1, prevede:
Reduceți la minimum sfera colectării; colectați numai ceea ce este necesar.
Acesta este nucleul jurnalizării care respectă confidențialitatea: păstrați ceea ce este necesar, demonstrați de ce este necesar, restricționați cine îl poate vedea și ștergeți-l atunci când scopul aprobat expiră.
Modelul de control Clarysec pentru dovezi care respectă confidențialitatea
În Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, Clarysec plasează jurnalizarea în faza Controale în acțiune, Pasul 19: Controale tehnologice I. Ghidul explică așteptarea de control din ISO/IEC 27002:2022:
A.8.15 – Jurnalizare: „Jurnalele care înregistrează activități, excepții, defecțiuni și alte evenimente relevante trebuie produse, stocate, protejate și analizate.”
Același pas indică organizațiilor să genereze jurnale pentru evenimente-cheie, să le stocheze securizat astfel încât să nu poată fi modificate, să le păstreze pentru o perioadă definită și să le analizeze printr-un SIEM sau printr-un proces de revizuire. De asemenea, conectează jurnalizarea la notificarea încălcării conform GDPR, înregistrările de incident DORA, managementul riscurilor NIS2 și analiza jurnalelor de securitate COBIT.
Dar jurnalizarea singură nu este suficientă. În aceeași fază Controale în acțiune, Pasul 19, Zenith Blueprint abordează ștergerea. Acesta avertizează că datele păstrate peste valoarea lor operațională cresc expunerea și riscul de reglementare și menționează explicit backup-urile, instantaneele și arhivele. Acest lucru contează deoarece o regulă de retenție din SIEM este lipsită de valoare dacă arhivele replicate ale jurnalelor sau bucketurile de stocare obiect din cloud păstrează aceeași PII pe termen nedeterminat.
În Pasul 23: Controale organizaționale, Zenith Blueprint acoperă colectarea dovezilor. Ghidul precizează că dovezile incidentului trebuie identificate, colectate și păstrate într-un mod admisibil juridic, fiabil și aliniat nevoilor de investigare. De asemenea, subliniază o realitate operațională: dovezile sunt adesea pierdute în primele minute ale răspunsului, atunci când jurnalele se rotesc, sistemele sunt repornite sau administratorii modifică conturile compromise înainte de preluarea instantaneelor.
Pasul 23 abordează și confidențialitatea și protecția PII. Ghidul tratează PII ca pe o problemă de ciclu de viață care necesită conștientizarea datelor, clasificare, controlul accesului, mascarea datelor, ștergere, criptare și obligații ale furnizorilor. Pentru jurnale, aceasta înseamnă că SIEM, EDR, platforma de jurnalizare din cloud și sistemul de ticketing trebuie să facă parte din inventarul PII.
Maparea cerințelor de conformitate între cadre pentru PII în jurnale
Zenith Controls: ghidul de mapare a cerințelor de conformitate între cadre mapează controlul ISO/IEC 27002:2022 8.15, Jurnalizare, la controale conexe esențiale pentru guvernanța PII. Aceste relații arată de ce jurnalizarea nu este doar o preocupare SOC.
| Relație ISO/IEC 27002:2022 | De ce contează pentru PII în jurnale |
|---|---|
| 8.16 Activități de monitorizare | Monitorizarea depinde de datele din jurnale, dar controalele privind confidențialitatea trebuie să guverneze ce PII este monitorizată și cine poate vedea alertele. |
| 5.25 Evaluarea și decizia privind evenimentele de securitate a informațiilor | Jurnalele susțin clasificarea evenimentelor, inclusiv dacă expunerea PII generează un incident raportabil. |
| 5.26 Răspunsul la incidente de securitate a informațiilor | Echipele de răspuns au nevoie de jurnale pentru conținere și eradicare, dar accesul trebuie să rămână conform principiului necesității de a cunoaște. |
| 5.27 Învățarea din incidente | Jurnalele istorice susțin analiza cauzei principale și îmbunătățirea controalelor, cu respectarea limitelor de retenție. |
| 8.17 Sincronizarea ceasului | Marcajele temporale exacte sunt esențiale pentru cronologia încălcărilor securității datelor, evaluarea DSAR și reconstrucția criminalistică. |
| 5.34 Confidențialitatea și protecția PII | Jurnalizarea accesului la PII susține trasabilitatea și responsabilitatea privind confidențialitatea. |
| 5.28 Colectarea dovezilor | Jurnalele protejate împotriva alterării susțin criminalistica digitală și admisibilitatea legală. |
| 5.15 Controlul accesului | Tentativele de acces și jurnalele de acces la PII validează eficacitatea restricțiilor de acces. |
| 5.33 Protecția înregistrărilor | Jurnalele sunt înregistrări care trebuie protejate împotriva alterării, pierderii și divulgării neautorizate. |
Zenith Controls mapează, de asemenea, Jurnalizarea la clauza ISO/IEC 27002:2022 8.15, ISO/IEC 27035-1 și ISO/IEC 27035-2 pentru gestionarea incidentelor, ISO/IEC 27701 pentru jurnalizarea activităților de prelucrare PII, ISO/IEC 27017 pentru jurnale de audit cloud, ISO/IEC 27018 pentru jurnalizarea accesului la PII în cloud, ISO/IEC 27005 pentru riscurile generate de jurnalizarea insuficientă, ISO/IEC 27033 pentru jurnalizarea activității de rețea și ISO/IEC 15408-2 pentru funcționalitatea de audit în produsele evaluate.
Pentru confidențialitate în mod specific, Zenith Controls mapează controlul ISO/IEC 27002:2022 5.34, Confidențialitatea și protecția PII, la inventarul activelor, mascarea datelor, serviciile cloud, clasificare, transferul de informații, controlul accesului, managementul identității și revizuirea de securitate a proiectelor și schimbărilor. Pentru un program de guvernanță a jurnalelor, aceste legături devin cerințe practice de proiectare:
- Inventariați depozitele de jurnale ca locații PII.
- Mascați sau tokenizați PII atunci când identificatorii compleți nu sunt necesari.
- Revizuiți serviciile de jurnalizare din cloud și furnizorii SIEM în cadrul controalelor cloud și al controalelor privind furnizorii.
- Clasificați jurnalele care conțin PII ca înregistrări sensibile.
- Guvernați exporturile și transferurile de jurnale ca transferuri de PII.
- Restricționați accesul la jurnale prin controale de identitate și de acces privilegiat.
- Revizuiți modificările aduse jurnalizării aplicațiilor înainte de lansarea în producție.
GDPR, NIS2 și DORA: un jurnal, trei perspective de reglementare
Aceeași intrare de jurnal poate fi privită diferit conform GDPR, NIS2 și DORA.
Conform GDPR, organizația întreabă dacă intrarea de jurnal conține date cu caracter personal, ce temei juridic susține prelucrarea, dacă datele sunt necesare, cât timp sunt păstrate, cine le poate accesa, dacă sunt divulgate către persoane împuternicite sau clienți și dacă trebuie luate în considerare într-o cerere de exercitare a drepturilor sau într-o evaluare a încălcării securității datelor.
Conform NIS2, organizația întreabă dacă jurnalele susțin managementul riscurilor de securitate cibernetică, gestionarea incidentelor, continuitatea activității, controlul accesului, securitatea lanțului de aprovizionare și evaluarea eficacității controalelor. NIS2 Article 20 stabilește responsabilitatea organelor de conducere pentru aprobarea și supravegherea măsurilor de management al riscurilor de securitate cibernetică. Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltare securizată, gestionarea vulnerabilităților, evaluarea eficacității, igienă cibernetică, controlul accesului și managementul activelor. Article 23 creează raportarea etapizată pentru incidente semnificative, inclusiv avertizare timpurie în 24 de ore, notificare în 72 de ore și raport final în termen de o lună.
Conform DORA, entitățile financiare trebuie să opereze un cadru documentat de management al riscurilor TIC. DORA Article 5 atribuie responsabilitatea organului de conducere. Article 10 abordează detectarea. Article 17 impune un proces de gestionare a incidentelor legate de TIC. Article 18 acoperă clasificarea incidentelor legate de TIC și a amenințărilor cibernetice. Article 19 abordează raportarea incidentelor majore legate de TIC. Jurnalele susțin detectarea, clasificarea, analiza cauzei principale, evaluarea impactului, răspunsul, recuperarea și dovezile privind remedierea.
| Perspectivă de conformitate | Întrebarea-cheie pentru PII în jurnale | Dovezi așteptate de Clarysec |
|---|---|---|
| GDPR | PII din jurnale este legală, necesară, transparentă, protejată și păstrată numai cât este necesar? | Inventar PII, temei juridic, regulă de retenție, controale de acces, aliniere cu informarea privind confidențialitatea, înregistrări privind evaluarea încălcării securității datelor. |
| ISO 27701 | Jurnalele de prelucrare PII sunt guvernate prin rolurile PIMS și obligațiile operatorului sau ale persoanei împuternicite? | Inventar REG02, domeniu de jurnalizare PII în REG12, proceduri de soluționare a cererilor de exercitare a drepturilor, reguli de divulgare pentru persoanele împuternicite, dovezi privind monitorizarea PIMS. |
| NIS2 | Jurnalele susțin detectarea, răspunsul, continuitatea activității și raportarea incidentelor semnificative? | Cronologii ale incidentelor, IOC-uri, dovezi privind retenția jurnalelor, supraveghere din partea managementului, obligații de jurnalizare ale furnizorilor. |
| DORA | Jurnalele susțin clasificarea incidentelor TIC, reziliența, cauza principală și raportarea? | Înregistrări ale incidentelor TIC, dovezi imuabile, acoperirea jurnalizării pentru funcțiile critice, acces la jurnalele terților și drepturi de audit. |
| NIST CSF 2.0 | Riscurile de securitate cibernetică, confidențialitate și lanț de aprovizionare sunt integrate în guvernanța riscului la nivel de întreprindere? | Profil curent și Profil țintă, registru de riscuri, roluri ale furnizorilor, rezultate ale monitorizării, dovezi de răspuns și recuperare. |
| COBIT 2019 | Controalele privind jurnalizarea, confidențialitatea și înregistrările sunt guvernate, monitorizate și îmbunătățite? | Revizuire de management, monitorizarea conformității, urmărirea problemelor, raportare privind performanța controalelor. |
Un tabel de corelare mai detaliat al controalelor ajută CISO să justifice jurnalizarea fără a se baza pe afirmații vagi precum „avem nevoie de ea pentru securitate”.
| Cadru | Clauze sau articole relevante | Cum susține jurnalizarea cerința |
|---|---|---|
| GDPR | Articles 5(2), 30, 32, Recital 49 | Jurnalele susțin responsabilitatea, evidențele activităților de prelucrare, securitatea prelucrării și scopurile de securitate a rețelelor și a informațiilor atunci când sunt guvernate și reduse la minimum. |
| Directiva NIS2 | Articles 20, 21, 23 | Jurnalele susțin supravegherea de către management, gestionarea incidentelor, eficacitatea controalelor și termenele de raportare a incidentelor semnificative. |
| DORA | Articles 5, 10, 17, 18, 19 | Jurnalele susțin managementul riscurilor TIC, detectarea, gestionarea incidentelor, clasificarea și raportarea incidentelor majore. |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Jurnalele susțin monitorizarea sistemelor și analiza evenimentelor potențial adverse. |
| COBIT 2019 | DSS05.07, DSS05.09, MEA03 | Jurnalele susțin monitorizarea vulnerabilităților, monitorizarea de securitate și jurnalizarea, monitorizarea conformității și asigurarea. |
Construiți un domeniu de jurnalizare PII în REG12
Un client Clarysec ar gestiona incidentul SIEM de la 02:17 înainte ca acesta să aibă loc. Organizația pornește de la o aplicație destinată clienților care prelucrează date de cont. Înainte de producție, proprietarul aplicației utilizează REG12 pentru a defini domeniul de jurnalizare a PII. Obiectivul este captarea unui număr suficient de evenimente pentru securitate și dovezi de reglementare, fără jurnalizarea inutilă a datelor cu caracter personal sau a conținutului payload-urilor.
| Sursă de jurnal | Evenimente de jurnalizat | Câmpuri PII permise | Câmpuri PII interzise | Regulă de retenție | Rol de acces |
|---|---|---|---|---|---|
| Platformă IAM | Autentificare reușită, autentificare eșuată, eșec MFA, schimbare de privilegii | ID utilizator, IP sursă, ID dispozitiv, marcaj temporal | Parole, coduri de recuperare, răspunsuri complete la întrebări de securitate | 12 luni, extinsă sub blocare pentru incident activ | Operațiuni de securitate, proprietar IAM |
| API aplicație | Acces la endpoint de export PII, autorizare eșuată, volum ridicat de interogări cu risc mare | ID cont, ID utilizator, endpoint, IP sursă | Corpul solicitării, conținutul mesajului, detalii complete de plată | 12 luni, 24 de luni pentru contracte reglementate cu clienți | Operațiuni de securitate, proprietar de aplicație |
| Plan de control cloud | Autentificare administrator, modificare de politică, modificare a accesului la bucket de stocare, activitate asupra cheilor | ID administrator, IP sursă, ID resursă | Secrete, token-uri, chei private | 12 luni, blocare legală dacă incidentul este declarat | Securitate cloud, comandant de incident |
| EDR | Alertă malware, proces suspect, acces la fișier într-o locație protejată | Nume gazdă, ID utilizator, metadate proces | Conținutul fișierului, cu excepția cazului în care colectarea criminalistică este aprobată | 12 luni, retenție de caz criminalistic dacă este escaladat | SOC, responsabil criminalistică |
| Note de caz SIEM | Cronologia incidentului, decizii, referințe la dovezi | Nume ale personalului, ID-uri ale utilizatorilor afectați, atunci când este necesar | Payload-uri ale clienților nemascate, capturi de ecran inutile | Calendar de retenție pentru înregistrările incidentelor | Echipa de răspuns la incidente, juridic, responsabil confidențialitate |
Apoi, responsabilul cu confidențialitatea confirmă dacă organizația acționează ca operator, persoană împuternicită sau ambele pentru fiecare sursă de jurnal. Dacă organizația este persoană împuternicită, instrucțiunile contractuale ale clienților și divulgările privind persoanele subîmputernicite pot limita accesul la jurnale și partajarea acestora. Dacă este operator, trebuie abordate informările privind confidențialitatea, temeiul juridic și soluționarea cererilor de exercitare a drepturilor.
Proprietarul de date actualizează apoi REG02 pentru a include depozitele active de jurnale, indecșii SIEM, arhivele, backup-urile și exporturile criminalistice temporare. Aceasta se aliniază cu Politica de retenție, ștergere și eliminare a PII, Backup-uri, arhive, replici, jurnale și fișiere temporare, clauza 4.4.1:
[Ambele] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să identifice în REG02 depozitele active, arhivele, copiile de backup, replicile, jurnalele, zonele de staging și fișierele temporare care conțin PII înainte de intrarea în producție și în timpul fiecărei revizuiri anuale a retenției.
Politica de păstrare și eliminare a datelor trebuie apoi să alinieze regulile de retenție ale organizației cu cerințele legale, contractuale și de păstrare a dovezilor.
În final, echipa de securitate configurează SIEM astfel încât parolele, secretele și corpurile de payload să fie eliminate sau mascate înainte de ingestie. Jurnalele care conțin PII sunt alocate unor indecși restricționați. Retenția este aplicată automat, cu excepția cazului în care este aprobat un incident sau o blocare legală. Acțiunile de ștergere sunt jurnalizate. Exporturile criminalistice necesită aprobare și urmărirea lanțului de custodie. Tablourile de bord afișează identificatori pseudonimizați atunci când identitatea completă nu este necesară. Recuperarea jurnalelor istorice este testată în cadrul auditurilor interne.
Aceasta este diferența dintre a spune „jurnalizăm pentru securitate” și a demonstra „jurnalizăm numai ceea ce este necesar, protejăm datele, le păstrăm conform unor reguli aprobate și le putem utiliza ca dovezi fără a încălca obligațiile de confidențialitate”.
DSAR, ștergere și jurnale: decideți înainte de sosirea cererii
Una dintre cele mai dificile întrebări este dacă jurnalele trebuie căutate, divulgate sau șterse ca răspuns la cereri de acces ale persoanei vizate sau la cereri de ștergere. Răspunsul depinde de rol, scop, temei juridic, fezabilitate, excepții și obligații de retenție. Însă procesul de guvernanță nu poate fi inventat de la o cerere la alta.
Politica de gestionare a drepturilor persoanei vizate privind PII, Verificarea identității, domeniu de aplicare și evaluare, clauza 4.2.3, prevede:
[Operator] Proprietarul de proces / Proprietarul afacerii TREBUIE să identifice din REG02 sistemele, înregistrările, scopurile, categoriile PII, destinatarii și constrângerile de retenție relevante înainte de evaluarea soluționării.
Aceasta înseamnă că jurnalele trebuie să fie în REG02 cu metadate clare: ce categorii PII conțin, ce scop deservesc, ce constrângere de retenție se aplică și dacă o cerere poate fi soluționată prin divulgare directă, acces rezumat, restricționare, ștergere la expirare sau refuz pe baza unui motiv juridic documentat.
Clarysec recomandă o abordare pe trei niveluri:
- Jurnalele operaționale cu impact redus asupra confidențialității, cum ar fi jurnalele de evenimente de sistem care utilizează ID-uri de utilizator pseudonime, pot fi căutate și divulgate atunci când este adecvat.
- Jurnalele de securitate cu sensibilitate ridicată, cum ar fi datele de corelare SIEM sau contextul de informații privind amenințările, pot necesita filtrare, divulgare rezumată sau restricționare pentru a evita expunerea logicii de detecție sau a datelor terților.
- Dovezile criminalistice aflate sub incident activ sau blocare legală nu trebuie modificate fără analiză. Ștergerea poate fi amânată sau restricționată atunci când există justificare juridică, cu documentarea deciziei de către părțile interesate din confidențialitate și juridic.
Dacă DPO și SOC dezbat fiecare DSAR de la zero, organizația va fi inconsecventă și lentă. Dacă REG02 și REG12 sunt menținute, soluționarea cererilor de exercitare a drepturilor devine bazată pe dovezi.
Raportarea încălcărilor securității datelor și a incidentelor: un eveniment, mai multe cronometre
Alerta de la 02:17 poate declanșa mai multe termene. Evaluarea încălcării securității datelor cu caracter personal conform GDPR poate impune notificarea unei autorități de supraveghere atunci când sunt îndeplinite pragurile de risc. Raportarea incidentelor semnificative conform NIS2 poate impune o avertizare timpurie în 24 de ore, o notificare în 72 de ore și un raport final. DORA poate impune raportarea incidentelor majore legate de TIC în etape inițiale, intermediare și finale. Contractele cu clienții pot avea ferestre de notificare chiar mai scurte.
Politica de gestionare a incidentelor PII și a încălcărilor securității datelor a Clarysec abordează direct această problemă a declanșatorilor multipli. Din Clasificare și evaluarea încălcării securității datelor, clauza 4.2.6:
[Condițional] Responsabilul cu confidențialitatea / Managerul PIMS TREBUIE să evalueze criteriile aplicabile de raportare juridice, sectoriale, din sectorul financiar, de securitate cibernetică, contractuale, ale clienților și ale destinatarilor serviciului pentru fiecare incident PII cu impact ridicat și să înregistreze rezultatul aplicabilității în REG01, REG08 și REG10.
În timpul triajului, organizația trebuie să întrebe:
- Atacatorul a accesat date cu caracter personal sau doar metadate?
- Jurnalele au expus PII suplimentare către utilizatori neautorizați?
- Sunt necesare jurnalele pentru a determina persoanele, sistemele și intervalul de timp afectate?
- Jurnalele sunt stocate imuabil și au acces restricționat?
- O blocare pentru incident a suspendat ștergerea jurnalelor relevante?
- Sunt afectați clienți ai persoanei împuternicite, clienți din sectorul financiar sau destinatari ai serviciului?
- Ce termene de raportare se aplică și cine deține fiecare notificare?
Jurnalele bine guvernate accelerează raportarea, deoarece oferă factorilor de decizie fapte fiabile. Jurnalizarea insuficientă produce întârzieri. Jurnalizarea excesivă creează risc pentru confidențialitate. Răspunsul corect este jurnalizarea țintită, protejată și mapată.
Jurnalizarea la furnizori și în cloud: problema persoanei împuternicite ascunsă în SIEM
Majoritatea organizațiilor nu stochează toate jurnalele pe infrastructură pe care o controlează integral. Jurnalele ajung în platforme SIEM, portaluri EDR, servicii de jurnalizare native cloud, instrumente de observabilitate, sisteme de ticketing și furnizori de servicii de detectare și răspuns gestionate. Conform GDPR, acești furnizori pot fi persoane împuternicite sau persoane subîmputernicite. Conform NIS2 și DORA, ei pot fi și furnizori direcți, furnizori terți de servicii TIC, furnizori de servicii administrate sau furnizori de servicii de securitate gestionate (MSSP).
NIS2 Article 21 include explicit securitatea lanțului de aprovizionare, vulnerabilitățile furnizorilor și practicile generale de securitate cibernetică ale furnizorilor. DORA adaugă cerințe detaliate privind riscul asociat terților TIC pentru entitățile financiare, inclusiv verificare prealabilă înainte de contractare, registre de informații, drepturi de audit și acces, asistență în caz de incident, localizarea datelor, clauze de protecție a datelor, strategii de ieșire și prevederi contractuale pentru funcții critice sau importante.
Pentru PII în jurnalele de securitate, revizuirile furnizorilor trebuie să includă aceste întrebări:
| Întrebare pentru furnizor | De ce contează |
|---|---|
| Ce câmpuri PII sunt ingerate, indexate, îmbogățite sau afișate? | Determină domeniul GDPR, cerințele de reducere la minimum și transparență. |
| Unde sunt stocate, replicate și salvate în backup jurnalele? | Susține evaluarea transferului, localizarea datelor, retenția și ștergerea. |
| Cine poate accesa datele de jurnal ale clientului la furnizor? | Susține controlul accesului, guvernanța persoanei împuternicite și drepturile de audit DORA. |
| Poate furnizorul să susțină stocarea imuabilă și blocarea legală? | Susține păstrarea dovezilor și investigațiile de incident. |
| Poate furnizorul să șteargă sau să returneze jurnalele la încetarea contractului? | Susține limitarea stocării conform GDPR și planificarea ieșirii DORA. |
| Sunt disponibile clientului jurnalele de acces ale furnizorului? | Susține responsabilitatea ISO 27701 și așteptările privind jurnalizarea accesului la PII în cloud. |
| Cum asistă furnizorul în incidente și în raportarea către autoritățile de reglementare? | Susține termenele NIS2 și DORA. |
Un contract SIEM nu este doar un abonament software. Este o dependență de prelucrare PII și de dovezi pentru incidente.
Perspectiva de audit: cum testează evaluatorii PII în jurnalele de securitate
Un auditor bun nu va accepta afirmația că „jurnalele sunt protejate”. Va testa lanțul de la politică la configurare, la dovezi și la revizuire.
| Profilul auditorului | Abordare probabilă de audit | Cerere tipică de dovezi |
|---|---|---|
| Auditor al sistemului de management ISO | Urmărește politica, tratarea riscurilor, includerea în SoA, controlul operațional și îmbunătățirea continuă. | Politică de jurnalizare, inventar PII, domeniu REG12, calendar de retenție, capturi de ecran SIEM, înregistrări ale revizuirilor accesului, constatări de audit intern. |
| Auditor de confidențialitate ISO 27701 | Testează maparea rolurilor PIMS, înregistrările de prelucrare PII, soluționarea cererilor de exercitare a drepturilor, obligațiile persoanelor împuternicite și dovezile privind incidentele de confidențialitate. | Intrări REG02 pentru jurnale, temei juridic, maparea ca operator sau persoană împuternicită, înregistrări de evaluare DSAR, evaluări ale încălcărilor securității PII. |
| Evaluator NIST | Testează acoperirea evenimentelor de audit, revizuirea jurnalelor, acuratețea marcajelor temporale, protecția înregistrărilor de audit și legătura cu răspunsul la incidente. | Configurație de audit, tichete de alertă, teste de protecție de tip AU-9, recuperare de jurnale istorice, permisiuni de acces. |
| Auditor COBIT 2019 | Evaluează guvernanța, monitorizarea, raportarea conformității și responsabilitatea managementului. | Procese-verbale ale revizuirii de management, rapoarte KPI, registre de probleme, tablouri de bord privind performanța controalelor, urmărirea remedierii. |
| Auditor ISACA ITAF | Validează caracterul complet, continuitatea și fiabilitatea dovezilor, precum și testarea controalelor. | Înregistrări ale lanțului de custodie, exporturi imuabile, analiză a lacunelor, eșantioane de jurnale de incident și acțiuni de urmărire. |
| Auditor axat pe DORA | Evaluează procesul de incident TIC, acoperirea funcțiilor critice, riscul asociat terților și testarea rezilienței. | Registru al incidentelor TIC, rapoarte privind cauza principală, contracte cu furnizorii, rezultate ale testelor, dovezi privind fluxul de raportare. |
| Revizor axat pe NIS2 | Evaluează măsurile de management al riscurilor, gestionarea incidentelor, continuitatea și pregătirea pentru raportarea incidentelor semnificative. | Criterii de clasificare a incidentelor, playbook-uri de escaladare, flux de raportare la 24 de ore și 72 de ore, obligații de jurnalizare ale furnizorilor. |
Un test practic de audit este simplu, dar revelator: solicitați SOC să recupereze o intrare de jurnal de acum zece luni care arată o modificare de acces privilegiat într-o platformă cloud, să demonstreze cine a accesat acel jurnal, să demonstreze că nu a fost modificat, să arate regula de retenție care a permis existența lui, să arate câmpurile PII pe care le conține și să explice cum ar fi gestionat într-un DSAR sau într-un raport de incident. Dacă echipa nu poate răspunde integrat pe securitate, confidențialitate și conformitate, guvernanța este incompletă.
Constatări frecvente în auditurile jurnalelor care conțin PII
Clarysec observă adesea aceleași tipare:
- Echipele de aplicații jurnalizează payload-uri complete ale solicitărilor pentru depanare, inclusiv nume, e-mailuri, numere de cont sau conținut de mesaje.
- Indecșii SIEM sunt deschiși grupurilor largi de administratori IT, în loc să fie restricționați la roluri SOC.
- Retenția jurnalelor este setată global, fără a ține cont de sensibilitatea PII, contractele cu clienții sau regulile de blocare pentru incident.
- Jurnalele furnizorului cloud sunt activate, dar accesul administratorilor furnizorului la datele de jurnal ale clientului nu este revizuit.
- Procedurile DSAR nu menționează jurnalele, cazurile SIEM sau exporturile criminalistice.
- Playbook-urile de răspuns la incidente păstrează dovezile, dar echipele de confidențialitate nu sunt implicate în clasificare.
- Backup-urile și arhivele păstrează PII din jurnale mai mult decât SIEM.
- Dezvoltatorii pot modifica nivelurile de jurnalizare în producție fără revizuire de confidențialitate sau securitate.
- Mediile de testare primesc jurnale de producție cu date cu caracter personal.
- Organizația are obligații de raportare NIS2 sau DORA, dar nu poate recupera rapid dovezi fiabile.
Aceste constatări apar rar din rea-credință. Ele apar din responsabilități fragmentate. Jurnalele de securitate se află între SOC, ingineria platformelor, confidențialitate, juridic, conformitate, audit și furnizori. Dacă nimeni nu deține întregul ciclu de viață, apar lacune.
Listă de verificare Clarysec pentru guvernanța jurnalelor pregătită pentru audit
Utilizați această listă de verificare ca punct de lucru pentru următoarea revizuire de guvernanță:
- Definiți ce surse de jurnal pot conține PII: IAM, aplicație, gateway API, SIEM, EDR, cloud, bază de date, rețea, acces fizic și ticketing.
- Înregistrați fiecare depozit de jurnale în REG02, inclusiv depozite active, arhive, backup-uri, replici și exporturi criminalistice temporare.
- Definiți domeniul de jurnalizare a PII în REG12 înainte de utilizarea în producție sau de modificări semnificative.
- Identificați scopul și temeiul juridic pentru prelucrarea jurnalelor de securitate.
- Interziceți parolele, secretele, token-urile complete și payload-urile inutile în jurnale.
- Utilizați mascarea datelor, hashingul sau pseudonimizarea atunci când identificatorii compleți nu sunt necesari.
- Restricționați accesul la jurnalele care conțin PII pe bază de roluri, cu revizuirea accesului privilegiat.
- Stocați jurnalele cu valoare ridicată în formate imuabile sau protejate la scriere.
- Definiți retenția pe tip de jurnal, obligație legală, contract, nevoie de incident și risc privind confidențialitatea.
- Implementați blocări pentru incidente cu aprobare, domeniu de aplicare și expirare.
- Includeți jurnalele în logica de evaluare a DSAR și a cererilor de ștergere.
- Revizuiți furnizorii SIEM, EDR, cloud și MDR ca persoane împuternicite sau terți TIC.
- Testați recuperarea istorică și integritatea dovezilor.
- Mapați jurnalizarea la nevoile de raportare GDPR, ISO 27701, NIS2, DORA, NIST CSF și COBIT.
- Instruiți echipele SOC, de confidențialitate și de aplicații cu privire la ce poate și ce nu poate fi jurnalizat.
Această listă de verificare transformă jurnalizarea care respectă confidențialitatea într-un proces de control repetabil.
De la dilemă la încredere la nivelul organului de conducere
NIS2 transformă securitatea cibernetică într-o responsabilitate de management. DORA face organul de conducere responsabil pentru managementul riscurilor TIC, strategia de reziliență operațională digitală, confidențialitatea datelor, comunicarea incidentelor și politicile privind serviciile TIC furnizate de terți. ISO/IEC 27001:2022 impune conducerii de vârf să alinieze SMSI cu obiectivele organizației, să aloce responsabilități, să asigure resurse și să susțină îmbunătățirea continuă.
Prin urmare, PII în jurnalele de securitate nu este un detaliu tehnic îngust. Este o problemă de încredere la nivelul organului de conducere. Capacitatea organizației de a detecta incidente, de a proteja datele cu caracter personal, de a păstra dovezi, de a răspunde clienților, de a satisface autoritățile de reglementare și de a recupera activitățile depinde de deciziile de jurnalizare luate cu mult înainte de incident.
Cele mai bune programe de guvernanță nu aleg între confidențialitate și securitate. Ele definesc jurnalizarea minimă necesară pentru o securitate robustă, protejează această jurnalizare ca PII sensibilă atunci când este cazul și o conectează la retenție, dovezi, soluționarea cererilor de exercitare a drepturilor și obligațiile furnizorilor.
Pașii următori cu Clarysec
Dacă SIEM, IAM, EDR sau jurnalele cloud conțin date cu caracter personal, acum este momentul să le guvernați deliberat.
Clarysec vă poate ajuta să:
- Construiți un domeniu de jurnalizare PII folosind REG12 și să îl aliniați cu Politica de securitate și control al accesului pentru PII.
- Inventariați depozitele de jurnale, arhivele, backup-urile și exporturile criminalistice folosind REG02 și Politica de retenție, ștergere și eliminare a PII.
- Aliniați controalele de jurnalizare, monitorizare, dovezi și confidențialitate cu Zenith Blueprint.
- Mapați controalele dvs. în GDPR, ISO 27701, NIS2, DORA, NIST CSF și COBIT folosind Zenith Controls.
- Pregătiți dovezi pentru audit pentru revizuiri de asigurare ISO, confidențialitate, NIST, COBIT, NIS2 și DORA.
Începeți cu un sistem cu risc ridicat: platforma IAM, SIEM sau aplicația destinată clienților. Identificați ce PII intră în jurnale, de ce este necesară, cine o poate accesa, cât timp este păstrată și cum ar fi utilizată în timpul unui incident sau al unei cereri de exercitare a drepturilor. Acest exercițiu unic va arăta dacă programul dvs. actual de jurnalizare este doar operațional sau este cu adevărat pregătit pentru audit.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


