OTP, breșe de securitate și plângeri penale
18 minute • Ana-Maria Udriste • 06 iunie 2022
În data de 03 iunie 2022, Cristian Iosub a publicat pe blogul său un articol prin care aduce la cunoștința publicului faptul că OTP Leasing a avut o breșă de securitate, care a expus toți clienții săi și a indicat pas cu pas modul în care a descoperit această breșă de securitate.
Pe scurt, ce s-a întâmplat?
Iosub și-a făcut cont pe platforma OTP Leasing pentru a gestiona un contract pe care îl are. În momentul în care a intrat în platforma MyLeasing, a constat că poate modifica (fără niciun alt subterfugiu) datele tuturor clienților OPT Leasing din platforma MyLeasing și avea acces la peste 15.000 de contracte.
Aceste contracte conțin, desigur, date personale. Dacă ți-ai făcut un contract de leasing, știi că acolo scrie absolut tot despre tine și despre compania ta.
Iosub a decis să notifice compania despre această breșă de securitate ca să poată lua măsurile necesare. Mesajele au fost ignorate cu succes, deși CEO-ul companiei i-a vizitat inclusiv profilul de LinkedIn, iar ulterior problema a fost transferată departamentului de marketing și comunicare.
Ce ește o breșă de securitate?
Breșă de securitate este în limba engleză ”data breach”. Noi am vrut să adoptăm o definiție mai complexă, respectiv:
„încălcarea securității datelor cu caracter personal” înseamnă o încălcare a securității care duce, în mod accidental sau ilegal, la distrugerea, pierderea, modificarea, sau divulgarea neautorizată a datelor cu caracter personal transmise, stocate sau prelucrate într-un alt mod, sau la accesul neautorizat la acestea;
Sursa: art. 4 pct. 12 din GDPR
Prin urmare, dacă este un accident al unei persoane care duce la divulgarea neautorizată sau accesul neautorizat al unei persoane, atunci avem o breșă de securitate.
Ca să mergem vizual, lucrurile stau fix așa:
Prin urmare, în momentul în care o persoană are acces neautorizat la date (pe românește, are acces la anumite date la care nu ar fi trebuit să aibă acces), asta înseamnă că avem o breșă de securitate.
Am scris o serie lungă de articole pe tema breșelor de securitate, pe care le poți citi mai jos:
- GDPR: prevenirea si abordarea incidentelor (breselor de securitate) – Avocatoo
- GDPR și dreptul de acces: cum îți faci singur o breșă de securitate fără să-ți dai seama – Avocatoo
- Dacă pun destinatarii în e-mail în CC în loc de BCC am o breșă de securitate? – Avocatoo
- S-a strigat bingo! Avem cea mai mare tranzacție pentru o breșă de securitate în SUA: 700 milioane. – Avocatoo
Fix pe problema securității datelor am scris un articol complex când am vorbit despre Vreau Credit SRL și Raiffeisen Bank, dar voi relua și aici.
Ce măsuri ar fi trebuit să ia OTP Leasing pentru ca datele să fie sigure?
Dacă ne uităm pe articolul lui Iosub, o să vedem, chiar dacă nu suntem de specialitate, faptul că măsurile de securitate erau destul de … slabe.
Spre exemplu, ai fi putut să nu oferi drept de admin unei persoane complet străine, fără o verificare prealabilă (sunt un pic ironică, aici, desigur).
Sau ai fi putut să:
- pui 2FA (2 factor authentication)
- verifici manual persoanele care-și fac cont (dacă altă metodă nu ai)
- comunici username și parole de înregistrare în momentul în care devii client OTP Leasing
- să nu salvezi parolele în clear text șamd
Exemplele de mai sus sunt oferite pur informativ și nu au vreo legătură cu situația reală.
De unde știm ce măsuri să luăm? Nu știm exact ce măsuri să implementăm. Dar art. 32 din GDPR ne oferă următoarele îndrumări:
(1) Având în vedere stadiul actual al dezvoltării, costurile implementării și natura, domeniul de aplicare, contextul și scopurile prelucrării, precum și riscul cu diferite grade de probabilitate și gravitate pentru drepturile și libertățile persoanelor fizice, operatorul și persoana împuternicită de acesta implementează măsuri tehnice și organizatorice adecvate în vederea asigurării unui nivel de securitate corespunzător acestui risc, incluzând printre altele, după caz:
(a) pseudonimizarea și criptarea datelor cu caracter personal;
(b) capacitatea de a asigura confidențialitatea, integritatea, disponibilitatea și rezistența continue ale sistemelor și serviciilor de prelucrare;
(c) capacitatea de a restabili disponibilitatea datelor cu caracter personal și accesul la acestea în timp util în cazul în care are loc un incident de natură fizică sau tehnică;
(d) un proces pentru testarea, evaluarea și aprecierea periodice ale eficacității măsurilor tehnice și organizatorice pentru a garanta securitatea prelucrării.
(2) La evaluarea nivelului adecvat de securitate, se ține seama în special de riscurile prezentate de prelucrare, generate în special, în mod accidental sau ilegal, de distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat la datele cu caracter personal transmise, stocate sau prelucrate într-un alt mod.
(3) Aderarea la un cod de conduită aprobat, menționat la articolul 40, sau la un mecanism de certificare aprobat, menționat la articolul 42, poate fi utilizată ca element prin care să se demonstreze îndeplinirea cerințelor prevăzute la alineatul (1) din prezentul articol.
(4) Operatorul și persoana împuternicită de acesta iau măsuri pentru a asigura faptul că orice persoană fizică care acționează sub autoritatea operatorului sau a persoanei împuternicite de operator și care are acces la date cu caracter personal nu le prelucrează decât la cererea operatorului, cu excepția cazului în care această obligație îi revine în temeiul dreptului Uniunii sau al dreptului intern.
Cel mai probabil, la o primă strigare, aș crede că OTP Leasing își putea permite un audit de securitate în urma căruia să stabilească ulterior strategia de implementare a securității.
Care, repet, nu trebuie să însemne că luăm o firmă de IT și securitate și dăm 100K euro. Putem găsi și soluții mai puțin costisitoare.
De ce nu a notificat OTP Leasing autoritatea?
Potrivit articolului publicat în Libertatea, OTP Leasing spune că a notificat autoritățile (dar nu spune și care autorități), dar aparent lucrurile nu stau chiar așa.
Când trebuie să notifici ANSDPCP dacă ai o breșă de securitate?
Exemple clare despre ce înseamnă riscurile, cum se analizează și cum se face o informare a persoanelor vizate afectate găsiți în pachetul avocatoo conceput ca o bază de pornire pentru a implementa o procedură de răspuns în cazul breșelor de securitate și nu intrăm în amănunte.
După cum putem vedea, avem mai multe situații în care trebuie să notificăm fie persoanele vizate, fie autoritatea, fie ambele.
Tot mergând pe vizual, suntem aici:
Așadar, ca să vedem dacă OTP Leasing avea obligația să notifice ANSDPCP despre breșa de securitate, trebuie să analizăm dacă prezenta încălcare poate genera un risc pentru drepturile și libertățile persoanelor fizice sau nu.
Când vom face această analiză, vom avea în vedere următoarele aspecte orientative:
- tipul încălcării
- dacă datele personale au fost criptate
- dacă au fost criptate, puterea criptării
- cât de mult au fost datele pseudonimizate (ie. dacă persoanele fizice pot fi identificate în mod rezonabil din datele existente)
- datele personale incluse sunt sau nu sensibile, (ie. nume, adresă, date personale, date biometrice)
- volumul datelor implicate
- numărul persoanelor vizate afectate
- natura încălcării, (ie. furt, accident etc.)
- orice alți factori ar putea fi relevanți.
Ce date personale au fost implicate?
Nu știu exact, pentru că nu am avut acces la baza de date și încă nu există informații oficiale în acest sens, dar dacă mă uit la contractul meu de leasing și la cele câteva sute de alte contracte de leasing pe care le-am văzut până acum, pot spune sigur că avem următoarele date personale:
- nume, prenume
- CNP
- adresă de domiciliu
- serie și număr de buletin
- data nașterii
- adresă de e-mail
- telefon
Ne putem da seama că din punct de vedere al datelor personale, avem niște date … foarte personale. Sigur, nu la fel de personale ca cele din analizele medicale, dar orișicât.
Luăm lista de mai sus și constatăm că:
- tipul încălcării – breșă internă, făcută de angajați sau colaboratori (asta în funcție de persoanele care au lucrat pe partea de securitate, pentru că e posibil să fie un mixt)
- dacă datele personale au fost criptate – nu
- dacă au fost criptate, puterea criptării – nu avem
- cât de mult au fost datele pseudonimizate (ie. dacă persoanele fizice pot fi identificate în mod rezonabil din datele existente) – persoanele pot fi identificate cu toate detaliile
- datele personale incluse sunt sau nu sensibile, (ie. nume, adresă, date personale, date biometrice) – sunt
- volumul datelor implicate – minim 15490 de elemente de date personale sensibile (respectiv numărul minim de contracte). Sigur, acest număr poate fi mai mic, dacă cumva mergem pe ideea că există o persoană ce are mai multe contracte, dar aceleași date.
- numărul persoanelor vizate afectate – minim 15490 de persoane (cu aceleași observații ca mai sus) – sau, altfel spus, toți clienții OTP Leasing
- natura încălcării, (ie. furt, accident etc.) – accident (prin neimplementarea unor măsuri de securitate adecvate de către companie)
- orice alți factori ar putea fi relevanți. – faptul că orice persoană din exterior putea interveni și să modifice datele oricărui client OTP Leasing este un factor demn de luat în considerare
Prin urmare, DA, autoritatea trebuie să fie notificată în termen de cel mult 72 de ore de la momentul la care i s-a adus la cunoștință acest lucru. Din relatările din articolul lui Iosub, vedem că au trecut cu lejeritate câteva săptămâni timp în care evenimentul a fost complet ignorat.
Mai mult, OTP Leasing avea obligația legală de a informa toate persoanele afectate de această breșă de securitate tot în acest termen de 72 de ore (recomandare – GDPR spune ”fără întârziere nejustificată”). Lucru care nu s-a întâmplat și pe care l-am probat din mai multe surse, având în vedere că am cunoștințe ce au contracte de leasing la OTP Leasing (adică se află prin cei 15490 de contracte) și nu au primit niciun fel de informație că datele lor ar fi fost complet compromise.
Dacă remediezi problema nu mai notifici autoritatea?
Să ne oprim un pic asupra afirmației reprezentanților OPT Leasing pentru Libertatea: ”OTP Leasing recunoaște incidentul cibernetic, dar susține că acesta „nu a afectat și nu va afecta în niciun fel activitatea clienților” și că l-a remediat „în câteva ore”.
Trecând peste faptul că din relatări și print-screen-uri nu reiese faptul că OTP Leasing a remediat în ”câteva ore” – faptul că remediezi o breșă de securitate nu înseamnă că nu mai ai obligația de a notifica autoritatea și persoanele vizate.
Altfel spus, dacă ajungi la concluzia ca respectiva divulgare de date reprezintă un pericol (repet, vorbim de toți clienții OTP Leasing), erai obligat să anunți autoritatea, indiferent că remediezi imediat sau nu. Și acolo povesteai cu lux de amănunte tot ceea ce s-a întâmplat, inclusiv cum ai remediat, ce măsuri ai luat & co.
Apropo, inclusiv persoanelor vizate ar cam trebui să le spui ce măsuri ai luat. Nu o spun eu, ci chiar art. 34 alin. (1) din GDPR:
În cazul în care încălcarea securității datelor cu caracter personal este susceptibilă să genereze un risc ridicat pentru drepturile și libertățile persoanelor fizice, operatorul informează persoana vizată fără întârzieri nejustificate cu privire la această încălcare.
Desigur, mai apoi avem și excepțiile, când nu ar trebui să notifici persoanele:
(a) operatorul a implementat măsuri de protecție tehnice și organizatorice adecvate, iar aceste măsuri au fost aplicate în cazul datelor cu caracter personal afectate de încălcarea securității datelor cu caracter personal, în special măsuri prin care se asigură că datele cu caracter personal devin neinteligibile oricărei persoane care nu este autorizată să le acceseze, cum ar fi criptarea;
(b) operatorul a luat măsuri ulterioare prin care se asigură că riscul ridicat pentru drepturile și libertățile persoanelor vizate menționat la alineatul nu mai este susceptibil să se materializeze;
(c) ar necesita un efort disproporționat. În această situație, se efectuează în loc o informare publică sau se ia o măsură similară prin care persoanele vizate sunt informate într-un mod la fel de eficace.
Sunt curioasă doar care va fi acea ”întârziere nejustificată” de câteva săptămâni. Repet: mă raportez exclusiv la perioada de timp de la momentul la care au luat cunoștință de breșă până când a fost remediată.
Spre exemplu, când am avut breșa de securitate pe Avocatoo prin accesul complet neautorizat din partea unui concurent care a „spart” un plug-in, breșa a fost remediată pe ceas în 4 minute. După aceste 4 minute nu mai avea nimeni acces la aceste date, plug-in-ul fusese înlocuit și totul ok.
Ce trebuie să faci ca să eviți o breșă de securitate?
Din păcate, breșele de securitate nu prea pot fi evitate. Am spus și o voi repeta – dacă vine cineva și-ți spune că sistemul tău este impenetrabil, înseamnă că nu a dat în el cum trebuie.
Uite, compania aeriană low-cost Pegasus a avut o breșă de 6.5TB de date pentru că nu a fost configurat serverul de AWS corect și corespunzător. 💩 happens.
Scopul nu este să pui usturoi și tămâie la fiecare colț de megabit, ci să depui toate eforturile rezonabile ca să eviți cât de mult poți o breșă de securitate.
Iar asta înseamnă:
- să instruiești periodic angajații despre prelucrarea datelor, riscuri și sancțiuni
- să implementezi programe software care să lase cât mai puțin ”loc de joacă”
- să faci un audit periodic de securitate
- să verifici procesele care stau în spate (majoritatea breșelor de securitate intervin și pentru că procesele din spate, care implică oameni, sunt deficitare)
- să te duci la specialiști în securitate care chiar te întreabă de sănătate
- să apelezi la avocați și consultanți care se uită 360 la afacerea ta și nu doar îți iau banii (ăia mulți) și-ți pun niște documente în brațe
- când lucrezi cu colaboratori, să faci contracte țepene, ca să știi împotriva cui te îndrepți
Responsabilizarea vine cu fiecare din noi. Nu există o formulă magică. Și e bine să plecăm de la idee că breșele de securitate nu pot fi evitate. Putem doar să încercăm să le diminuăm.
Plângere penală?
Tot în articolul din Libertatea, OTP Leasing a informat redacția că a depus o plângere penală împotriva lui Iosub.
Dacă am merge pe fraudă informatică, vedem că articolul 249 din Codul Penal ne spune așa:
”Introducerea, transmiterea, modificarea sau ştergerea de date informatice, restricţionarea accesului la aceste date ori împiedicarea în orice mod a funcţionării unui sistem informatic, în scopul de a obţine un beneficiu material pentru sine sau pentru altul, dacă s-a cauzat o pagubă unei persoane, se pedepseşte cu închisoarea de la 2 la 7 ani.”
În acest caz putem vedea că nu sunt întrunite elementele constitutive ale infracțiunii. Nu a introdus, transmis, modificat sau șters deloc date informatice. Nu a fost restricționat accesul la date și nici nu a fost împiedicată funcționarea acestuia.
Mergem și mai departe, pe fals informatic, și vedem că articolul 325 din Codul Penal ne spune așa:
Fapta de a introduce, modifica sau şterge, fără drept, date informatice ori de a restricţiona, fără drept, accesul la aceste date, rezultând date necorespunzătoare adevărului, în scopul de a fi utilizate în vederea producerii unei consecinţe juridice, constituie infracţiune şi se pedepseşte cu închisoarea de la unu la 5 ani.
Dacă Cristian Iosub s-ar fi dat drept altă persoană în cadrul OTP ca să obțină anumite beneficii și ar făcut-o cu obținerea unor consecințe juridice (cum ar fi să șteargă leasingul cuiva de acolo), atunci poate că ne-am fi putut gândi, cumva, incidental, la o asemenea infracțiune. Altfel, nu chiar.
Iar dacă am merge și mai departe, pe Accesul ilegal la un sistem informatic, avem următoarele:
Art. 360 Cod Penal
(1) Accesul, fără drept, la un sistem informatic se pedepseşte cu închisoare de la 3 luni la 3 ani sau cu amendă.
(2) Fapta prevăzută în alin. (1), săvârşită în scopul obţinerii de date informatice, se pedepseşte cu închisoarea de la 6 luni la 5 ani.
(3) Dacă fapta prevăzută în alin. (1) a fost săvârşită cu privire la un sistem informatic la care, prin intermediul unor proceduri, dispozitive sau programe specializate, accesul este restricţionat sau interzis pentru anumite categorii de utilizatori, pedeapsa este închisoarea de la 2 la 7 ani.
Ca să nu ne lungim, voi luat doar următorul exemplu dintr-o speță recentă:
”Într-o astfel de situaţie nu poate fi reţinută infracţiunea de acces ilegal la un sistem informatic, prevăzută de art. 360 alin. (1) şi (3) CP, atâta vreme cât inculpatul s-a folosit în activitatea infracţională de două carduri valabile, emis pe numele său de o unitate financiară, fiind evident, în această ipoteză, că accesarea sistemului informatic al băncii s-a făcut în mod legal: inculpatul, fiind titularul cardurilor, avea dreptul de a retrage de la orice bancomat sumele aflate în contul ataşat cardului respectiv, situaţie în care nu este îndeplinită una dintre condiţiile laturii obiective, şi anume ca accesarea sistemului informatic să se facă “fără drept”.” Juridic vorbind, nu este îndeplinită latura obiectivă a infracțiunii.
”Fără drept” înseamnă că nu avea voie să acceseze acea secțiune prin crearea unui cont simplu și că ar fi trebuit ”să facă ceva”.
Sau, cum s-a spus în literatura de specialitate:
”- fără drept, respectiv în una dintre următoarele situaţii: (a) nu este autorizată, în temeiul legii sau al unui contract; (b) depăşeşte limitele autorizării; (c) nu are permisiunea, din partea persoanei fizice sau juridice competente, potrivit legii, să o acorde, de a folosi, administra sau controla un sistem informatic ori de a desfăşura cercetări ştiinţifice sau de a efectua orice altă operaţiune într-un sistem informatic [în cazul variantei prevăzute de art. 360 alin. (1) C. pen.];”
Aspecte privind infracţiunea de acces ilegal la un sistem informatic de Gheorghe-Iulian Ioniţă, în Revista Română de Drept Penal al Afacerilor nr. 2/2020.
În această situație, pur și simplu … a existat acolo.
Este ca și cum mâine îți faci un cont pe un site de e-commerce, vezi că ai o secțiune unde ți se acordă (fără ca tu să faci ceva), acces peste tot în site-ul respectiv și tu doar îi informezi pe cei cu site-ul, iar altceva nu. Mai mult, mai alertezi și autoritățile competente cu ocazia asta. Și site-ul respectiv.
În loc de concluzie
GDPR are deja 4 ani de zile din momentul în care a început să se aplice la nivel național și european, pentru că este un Regulament al Uniunii Europene și se aplică peste tot. Din păcate, nu am înțeles ce înseamnă pro-activitate și care sunt măsurile de securitate pe care să le implementăm, în mod rezonabil, astfel încât să fie cât de cât ok.
Cazul de față este unul care expune, cel puțin la prima vedere, o bază de date semnificativă a clienților unui jucător important de leasing pe piața din România.
Nu trebuie ca implementarea GDPR să coste 100K euro din prima sau să schimbăm sisteme peste noapte. Ci să depunem, treptat, eforturi pentru ca datele să fie mai protejate și nu la liber.
Implicațiile nu sunt doar despre o eventuală amendă din partea autorității. Ci vorbim de ruperea unei relații de încredere cu clienții și potențialii clienți, precum și un prejudiciu de imagine, care ar fi putut fi evitat.
Se întâmplă să ai o breșă de securitate. Important este ce înveți din ea și cum o abordezi, la nivel 360: juridic, securitate, comunicare.
PS: am intrat pe site și am dat click pe bannerul acela incorect setat pentru cookie. A apărut asta.