Site compromis și malware distribuit vizitatorilor: când devine incidentul o încălcare GDPR?

„Am identificat scriptul, l-am șters, am schimbat parolele și am instalat măsuri suplimentare de securitate.”

Din punct de vedere tehnic, acestea sunt măsuri firești și necesare după compromiterea unui website. Din perspectiva protecției datelor însă, mai există o întrebare:

Ce s-a întâmplat înainte ca scriptul să fie eliminat?

Un website compromis reprezintă, fără îndoială, un incident de securitate. Dar un incident de securitate IT nu reprezintă automat o încălcare a securității datelor cu caracter personal în sensul GDPR. Tocmai această diferență trebuie analizată rapid și documentat.

Pentru explicația tehnică a atacului, vezi și: „Fake Cloudflare: verificarea care te poate face să instalezi singur malware pe calculator.”

Ce înseamnă „personal data breach”?

GDPR privește drept încălcare a securității datelor un incident care conduce accidental sau ilegal la distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesarea neautorizată a datelor cu caracter personal.

Prin urmare: Website compromis = incident de securitate.

Dar pentru a ajunge la: Website compromis = personal data breach trebuie analizat dacă au fost compromise și date cu caracter personal. Este o distincție esențială.

Un exemplu real: website legitim transformat în vector de atac

Într-un incident analizat recent de echipa noastră, un website legitim fusese compromis prin introducerea unui script neautorizat. Vizitatorului îi era prezentată o falsă verificare Cloudflare. În realitate, mecanismul îl determina să execute o comandă PowerShell, iar analiza tehnică a unui endpoint afectat a confirmat că ulterior au fost descărcate și executate mai multe componente malware. Soluția antivirus a intervenit în cursul lanțului și a blocat una dintre componente.

Cazul este interesant din perspectiva GDPR deoarece prezintă două direcții diferite de investigație.

1. Ce a putut vedea atacatorul în infrastructura companiei?

Prima întrebare privește website-ul și datele deținute de operator. Trebuie stabilit nivelul accesului obținut de atacator. Există o diferență majoră între:

Scenariul A: a fost modificat un singur fișier sau injectat un JavaScript, fără acces la baza de date; și:

Scenariul B: atacatorul a obținut acces la WordPress administrator, hosting, cPanel, FTP/SFTP/SSH sau baza de date.

În al doilea scenariu, trebuie investigat imediat dacă atacatorul putea accesa:

• date introduse prin formulare;
• nume și adrese de email;
• conturi de utilizatori;
• date ale clienților;
• newslettere;
• date ale administratorilor;
• comenzi;
• loguri;
• alte informații stocate în website.

Nu este suficient să întrebăm dacă există dovada că datele au fost „furate”.

Întrebarea tehnică relevantă este și:

Ce nivel de acces a avut atacatorul și ce putea accesa cu acel nivel de privilegii?

2. Ce s-a întâmplat cu vizitatorii?

A doua direcție este diferită. Un website compromis poate deveni o platformă de distribuire de malware către propriii vizitatori. În cazul analizat de noi, exista dovada că mecanismul afișat pe website putea declanșa efectiv un lanț malware pe calculatorul utilizatorului. Aceasta nu înseamnă automat că toate persoanele care au vizitat website-ul au fost infectate.

Atacul poate fi condiționat de:

• tipul browserului;
• adresa IP;
• țară;
• referer;
• cookie-uri;
• dispozitiv;
• faptul că utilizatorul a mai accesat sau nu pagina;
• interacțiunea efectivă cu falsa verificare.

De aceea una dintre cele mai importante întrebări ale investigației devine: Câți utilizatori au fost expuși și în ce perioadă?

T0 și T1: două momente pe care trebuie să le cunoaștem

Într-un asemenea incident încercăm să stabilim două repere: T0 – prima apariție a compromiterii și T1 – momentul în care codul malițios a fost dezactivat sau website-ul a fost oprit/remediat.

Uneori T0 poate fi determinat din:

• backup-uri;
• timestamp-urile fișierelor;
• audit logs;
• access logs;
• logurile pluginurilor;
• logurile WAF/CDN;
• istoricul conturilor administrative.

Odată stabilit intervalul, poate fi estimat și numărul vizitatorilor.

Este foarte diferită o situație în care codul a fost activ 30 de minute și pagina a avut zece accesări față de una în care compromiterea a rămas nedetectată timp de două săptămâni.

„Am șters scriptul.” Este incidentul închis?

Nu. Înseamnă că a fost realizată o măsură importantă de containment/remediation. Pentru închiderea incidentului ar trebui însă să putem răspunde rezonabil la întrebările:

• Cum a intrat atacatorul?
• Ce acces a obținut?
• De când era activă compromiterea?
• Ce date erau accesibile?
• Există indicii de acces sau exfiltrare a datelor?
• Câte persoane puteau fi afectate?
• A rămas vreun mecanism de persistență?

Aceste informații sunt relevante atât pentru securitate, cât și pentru DPO.

De ce îl interesează pe DPO vulnerabilitatea tehnică?

Responsabilul cu protecția datelor nu trebuie să devină analist malware. Dar pentru evaluarea GDPR trebuie să înțeleagă consecința tehnică a vulnerabilității.

De exemplu: „Plugin WordPress compromis” spune relativ puțin. În schimb: „Vulnerabilitatea a permis unui atacator neautentificat să execute cod pe server și să citească baza de date” reprezintă o informație esențială pentru evaluarea riscului.

La fel: „A fost compromis contul administratorului WordPress, dar nu existau privilegii de hosting sau acces direct la baza de date” conduce către o evaluare diferită.

Rolul DPO este să transforme constatările tehnice într-o evaluare privind confidențialitatea, integritatea și disponibilitatea datelor personale.

Trebuie notificată automat ANSPDCP?

Nu. Compromiterea unui website nu declanșează automat obligația de notificare. GDPR prevede notificarea autorității atunci când există o încălcare a securității datelor cu caracter personal, cu excepția situației în care aceasta este improbabil să genereze un risc pentru drepturile și libertățile persoanelor.

CEPD precizează că notificarea trebuie făcută, atunci când este necesară, fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la momentul în care operatorul a luat cunoștință de încălcare. Prin urmare, concluzia corectă după identificarea unui script malițios nu este nici: „Trebuie să notificăm imediat.” nici: „L-am șters, deci GDPR nu mai este relevant.”

Concluzia corectă este:

„Trebuie să investigăm rapid dacă incidentul de securitate a compromis date cu caracter personal și ce risc rezultă.”

Când începe termenul de 72 de ore?

Aceasta este una dintre cele mai frecvente întrebări. CEPD consideră că operatorul devine „aware” atunci când există un grad rezonabil de certitudine că a avut loc un incident care a compromis date cu caracter personal. Asta permite efectuarea unei investigații inițiale. Dar investigația nu poate fi folosită pentru amânarea artificială a notificării. Dacă devine clar că date personale au fost compromise și incidentul este notificabil, organizația trebuie să acționeze. Iar dacă în primele 72 de ore nu sunt disponibile toate informațiile, acestea pot fi transmise în etape, pe măsură ce investigația avansează.

Ce trebuie păstrat după incident?

Una dintre cele mai frecvente greșeli este curățarea rapidă a serverului fără conservarea probelor. Organizația vrea, firesc, să readucă website-ul online cât mai repede. Dar înainte de eliminarea tuturor artefactelor este recomandabil, în funcție de gravitatea incidentului, să fie conservate:

• logurile web serverului;
• access/error logs;
• logurile WordPress;
• logurile WAF/CDN;
• logurile de autentificare;
• logurile FTP/SFTP/SSH;
• o copie a fișierelor compromise;
• o copie a bazei de date;
• backup-urile relevante;
• lista pluginurilor și versiunile lor;
• lista conturilor administrative;
• scriptul identificat;
• timestamp-urile fișierelor modificate.

Fără acestea, organizația poate ajunge într-o situație paradoxală: a remediat incidentul tehnic, dar nu mai poate demonstra ce s-a întâmplat.

Și dacă investigația arată că nu au fost afectate date personale?

Este un rezultat perfect valid. Într-un asemenea caz, organizația poate ajunge la concluzia documentată că incidentul de securitate nu constituie o încălcare a securității datelor cu caracter personal. Sau poate constata că a existat o încălcare, dar aceasta este improbabil să genereze un risc și nu necesită notificarea autorității. Important este ca decizia să nu fie doar: „IT spune că acum site-ul este curat.” Ci, de exemplu: „Investigația a arătat că modificarea a fost limitată la componenta X, nu a existat acces la baza de date, logurile nu indică acces neautorizat la date personale, scriptul a fost activ în intervalul Y, iar evaluarea riscului a condus la concluzia Z.”

CEPD subliniază că încălcările trebuie documentate inclusiv atunci când, în urma evaluării, nu sunt notificate autorității.

Ce se întâmplă dacă există risc ridicat pentru persoane?

Notificarea autorității și informarea persoanelor vizate sunt două obligații distincte.

Atunci când încălcarea este susceptibilă să genereze un risc ridicat pentru drepturile și libertățile persoanelor, poate deveni necesară și comunicarea incidentului către persoanele afectate, conform art. 34 GDPR.

Evaluarea trebuie făcută în funcție de context:

• natura datelor;
• sensibilitatea lor;
• volumul;
• numărul persoanelor;
• posibilitatea de fraudă;
• furt de identitate;
• acces la conturi;
• consecințele posibile;
• măsurile care limitează efectele incidentului.

Nu există o regulă conform căreia „site compromis = anunțăm toți utilizatorii”. Este necesară o analiză reală de risc.

O abordare bună: IT și DPO lucrează în paralel

În incidentele cibernetice, o greșeală frecventă este ca investigația tehnică să se desfășoare separat, iar DPO să afle rezultatele câteva zile mai târziu. O abordare mai bună este:

• IT / securitate investighează cauza, accesul și efectele tehnice.
• DPO identifică ce informații sunt necesare pentru evaluarea datelor personale și începe documentarea incidentului.

Cele două activități trebuie să se desfășoare în paralel. DPO nu trebuie să spună echipei tehnice cum să analizeze un webshell, dar trebuie să poată întreba: „Accesul pe care l-a obținut atacatorul îi permitea să citească baza de date?” Aceasta este întrebarea care transformă un detaliu tehnic într-o informație relevantă GDPR.

Concluzie

Atunci când un website este compromis, obiectivul imediat este evident: oprirea atacului și securizarea infrastructurii, dar procesul nu ar trebui să se termine aici. O organizație trebuie să poată reconstrui suficient incidentul pentru a răspunde la patru întrebări:

1. Ce s-a întâmplat?
2. Ce date au putut fi afectate?
3. Ce persoane au putut fi afectate?
4. Ce obligații rezultă din acest lucru?

Uneori concluzia va fi: incident IT, fără personal data breach. 

Alteori: personal data breach documentat, dar fără obligație de notificare din cauza riscului redus.

Iar în alte situații: încălcare notificabilă către ANSPDCP și, în caz de risc ridicat, comunicare către persoanele vizate.

Diferența nu poate fi stabilită doar prin faptul că „scriptul a fost șters”.

Poate fi stabilită printr-o investigație tehnică suficientă, urmată de o evaluare GDPR documentată.

Ați identificat un incident de securitate?

Echipa GDPR Complet poate asista organizațiile în evaluarea incidentelor de securitate din perspectiva GDPR, documentarea încălcării, evaluarea riscului și stabilirea obligațiilor de notificare către ANSPDCP și/sau persoanele vizate.