Trei incidente care au implicat terți, trei tipuri diferite de dependențe și un plan de acțiune în opt pași pentru gestionarea incidentelor aflate în afara controlului tău direct.
Un furnizor te informează că sistemele sale au fost compromise.
Centrul tău de operațiuni de securitate (SOC) nu detectează niciun indicator de compromitere în mediul tău. Aplicațiile tale sunt disponibile. Activitatea comercială se desfășoară în mod normal.
Însă furnizorul prelucrează datele clienților tăi, deține date de autentificare pentru o integrare sau operează un serviciu de care depinzi. Ce poți stabili în mod independent și ce trebuie să decizi în timp ce furnizorul încă investighează?
Merită să răspunzi la trei întrebări înainte de a continua lectura:
- Ce date de-ale tale deține fiecare furnizor critic, inclusiv copiile realizate pentru testare, migrare sau integrare inițială?
- Ce date de autentificare și integrări ale furnizorilor pot accesa sistemele tale și cine le poate revoca în decurs de o oră?
- Ce dovezi vei solicita unui furnizor înainte de a restabili o conexiune pe care ai întrerupt-o?
Trei incidente raportate în Europa în ultimele luni arată de ce fiecare dintre aceste întrebări contează.
Trei incidente, trei tipuri diferite de dependențe
1. PUBLICA / PK Softech — Elveția
La sfârșitul lunii septembrie 2026, PK Softech, un furnizor de software pentru administrarea fondurilor de pensii, a detectat un atac cibernetic. În propria declarație, compania a afirmat că persoane necunoscute au folosit programe malware pentru a accesa o parte a infrastructurii sale IT. Aceasta a izolat mediul afectat, a implicat specialiști externi, a informat autoritățile și a depus o plângere penală. Compania a raportat că serviciile sale erau din nou complet disponibile pentru clienți începând cu 2 octombrie.
La 8 octombrie, guvernul federal elvețian a confirmat că datele fuseseră exfiltrate și că Parchetul General al Confederației deschisese o anchetă. PUBLICA, fondul federal de pensii, a avertizat că informațiile expuse ar putea include nume, adrese, numere de asigurări sociale (AHV), salarii, economii pentru pensie și detalii despre soți sau parteneri. Instituția a subliniat că activele și plățile aferente pensiilor nu au fost afectate.
Ulterior, cazul s-a extins. PK Softech deservește mai multe fonduri de pensii elvețiene, iar fondul de pensii Migros a declarat că investighează dacă datele membrilor săi au fost implicate.
Cel mai instructiv detaliu privește Pensionskasse Stadt Zürich (PKZH). PKZH nu utilizează încă PK Softech în producție; migrarea sa este planificată pentru începutul anului 2027. Pentru a pregăti această migrare, instituția transferase datele membrilor către PK Softech. La 15 octombrie, PKZH a declarat că, pe baza informațiilor disponibile în acel moment, datele cu caracter personal ale membrilor săi fuseseră sustrase. Sistemul său de producție nu a fost afectat. Datele exacte și numărul persoanelor implicate erau încă în curs de investigare.
O relație cu un furnizor poate expune date înainte ca serviciul să fie pus vreodată în funcțiune.
Întrebarea operațională: Știi ce date din mediul de producție ai partajat cu furnizorii pentru dezvoltare, testare, migrare sau integrare inițială — și dacă era cu adevărat necesar ca acestea să fie date reale?
2. Master of Malt / Ribon — Regatul Unit
În perioada 13–17 septembrie 2026, atacatorii au folosit o cheie de aplicație BigCommerce compromisă, deținută de Ribon, o aplicație terță, pentru a accesa datele clienților comercianților care utilizau BigCommerce. Master of Malt a raportat că au fost expuse numele, adresele de e-mail, numerele de telefon și adresele poștale ale clienților săi. Compania și-a notificat clienții la 18 septembrie și a raportat incidentul către Biroul Comisarului pentru Informații din Regatul Unit (ICO).
BigCommerce a declarat că datele de autentificare Ribon și Ribon 1.5 fuseseră compromise în urma unui atac asupra Fastr, compania din spatele Ribon, și că propria platformă nu fusese compromisă. BigCommerce a eliminat aplicațiile afectate la 17 septembrie.
Cele două relatări publice diferă. BigCommerce a descris utilizarea datelor de autentificare pentru a injecta scripturi malițioase în câteva magazine online. Master of Malt a descris citirea în masă a înregistrărilor existente ale clienților prin intermediul API-ului. Aceste relatări nu se contrazic, dar nici nu descriu același scenariu al incidentului, iar informațiile publicate nu demonstrează că injectarea de scripturi a avut loc la Master of Malt.
Master of Malt a tras propria concluzie: compania a afirmat că nicio aplicație terță nu ar fi trebuit să poată accesa datele clienților în acest mod și că va insista pe lângă BigCommerce pentru implementarea unor controale mai granulare ale accesului prin API.
Întrebarea operațională: Poți identifica și revoca rapid permisiunile unei aplicații aparținând unui furnizor? Sunt aceste permisiuni limitate la ceea ce aplicația are efectiv nevoie? Și păstrezi propriile jurnale de activitate, astfel încât să nu depinzi de versiunea evenimentelor prezentată de furnizor?
3. Ace & Tate / CEVA Logistics — Țările de Jos
La 1 august 2026, CEVA Logistics și-a informat clienții că o intruziune afecta o parte a operațiunilor sale europene de logistică contractuală. În aceeași zi, Ace & Tate, un comerciant de produse optice, a fost informat că o parte neautorizată accesase o parte a sistemelor utilizate pentru procesarea comenzilor sale.
Ace & Tate a oprit imediat partajarea datelor cu CEVA. Analiza proprie a companiei a constatat că sistemele sale interne nu fuseseră afectate. Aceasta a notificat autoritatea olandeză pentru protecția datelor și ICO din Regatul Unit, a avertizat clienții că livrările comenzilor și retururile ar putea fi întârziate și a declarat că prescripțiile optice, datele de plată, numele de utilizator și parolele nu fuseseră implicate.
Ace & Tate nu a fost singura companie afectată. Bol, De Bijenkorf, Ajax, ING și magazinul de hardware al platformei Steam, deținută de Valve, s-au numărat printre clienții CEVA care au raportat un impact. În septembrie, comunicările ulterioare ale comercianților afectați au confirmat că datele clienților din sistemele CEVA fuseseră, într-adevăr, accesate.
Incidentul a avut două consecințe distincte: expunerea datelor cu caracter personal și perturbarea livrărilor fizice.
Întrebarea operațională: Poți izola un furnizor compromis menținând în același timp funcționarea serviciilor critice? Și ce dovezi vei solicita înainte de a restabili conexiunea?
Un singur furnizor, mulți clienți
Aceste incidente nu au aceeași cauză tehnică fundamentală. Unul a implicat programe malware la un furnizor de software, altul o cheie de aplicație furată, iar al treilea o intruziune la un furnizor de servicii logistice.
Totuși, au o structură comună. În fiecare caz, un singur furnizor s-a aflat între un atacator și numeroase organizații, simultan:
- PK Softech deservește mai multe fonduri de pensii elvețiene, inclusiv PUBLICA, fondul de pensii Migros și, înainte de migrare, PKZH.
- Ribon era instalată în magazinele comercianților care utilizau BigCommerce; Master of Malt a raportat că aplicația rula pe sute de astfel de magazine.
- CEVA gestiona comenzile pentru Bol, De Bijenkorf, Ajax, ING, Ace & Tate, Valve și alte companii.
Acesta este riscul de concentrare. Pentru atacator, o singură compromitere generează numeroase victime. Pentru fiecare client, incidentul se află în afara controlului său, însă consecințele — obligațiile de notificare, încrederea clienților și perturbarea operațiunilor — îi revin.
Cazul Ribon adaugă un nivel suplimentar. Datele de autentificare compromise aparțineau unei aplicații, iar acestea fuseseră expuse în urma unei compromiteri a companiei-mamă, Fastr. Majoritatea inventarelor de furnizori se opresc la primul nivel. Expunerea nu s-a oprit acolo.
Un incident la un furnizor nu înseamnă că infrastructura clientului a fost compromisă. Înseamnă însă că acel client trebuie să stabilească, pe baza propriilor dovezi, dacă datele, căile de acces sau operațiunile sale au fost afectate.
Înainte de incident: ce face posibilă intervenția
Cea mai mare parte a planului de acțiune de mai jos depinde de activitățile desfășurate înainte ca vreun furnizor să sune. Patru măsuri pregătitoare sunt esențiale:
- Un inventar al datelor partajate cu furnizorii, inclusiv al copiilor din mediile care nu sunt de producție: seturi de date pentru testare, extrase pentru migrare și exporturi pentru asistență tehnică. Atunci când datele reale cu caracter personal nu sunt necesare pentru testare, acestea trebuie reduse la minimum sau pseudonimizate. Cazul PKZH arată ce informații poate expune un set de date utilizat pentru migrare.
- Date de autentificare ale furnizorilor cu responsabili desemnați și domeniu de acces definit. Fiecare cheie API, cont de serviciu și permisiune de aplicație trebuie să aibă un responsabil clar, un scop documentat și cel mai restrâns nivel de acces necesar pentru acel scop. Revocarea trebuie să fie o acțiune exersată, nu o operațiune de căutare.
- Propriile jurnale de activitate ale furnizorilor. Autentificările, apelurile API și transferurile de date efectuate de furnizori în mediul tău trebuie înregistrate și păstrate, astfel încât investigația să nu depindă exclusiv de relatarea furnizorului.
- Un set de dovezi convenit contractual. Definește în avans ce trebuie să furnizeze furnizorul după un incident: cronologii, sisteme afectate, categorii de date, înregistrări ale accesului, dovezi ale măsurilor de remediere și, atunci când este justificat, validare independentă.
Un plan de răspuns la incidentele terților în opt pași
Fluxul de lucru de mai jos reprezintă un set de recomandări operaționale, bazate pe practici consacrate de răspuns la incidente, precum NIST SP 800-61 Rev. 3. Nu este o reconstituire a acțiunilor întreprinse efectiv de organizațiile menționate mai sus.
Pasul 1 — Stabilește responsabilitatea și clasifică evenimentul
Responsabil: Comandantul incidentului / Managerul de securitate
Înregistrează notificarea furnizorului ca eveniment de securitate și decide dacă aceasta activează procesul tău de răspuns la incidente. Notează furnizorul, serviciile de afaceri afectate, faptele cunoscute și întrebările la care încă nu există răspuns. Stabilește un canal de comunicare verificat cu echipa de răspuns la incidente a furnizorului și desemnează persoana responsabilă pentru colectarea actualizărilor.
Dovezi: înregistrarea incidentului, responsabil desemnat, marcaj temporal al notificării, clasificare inițială, jurnalul deciziilor.
Escaladează atunci când: ar putea fi afectat un furnizor critic, un set de date sensibile, o integrare cu privilegii ridicate sau un serviciu esențial.
Pasul 2 — Cartografiază dependența și expunerea potențială
Responsabil: Arhitectura de securitate / IT / Managerul furnizorilor
Identifică sistemele, identitățile, datele și serviciile de afaceri legate de furnizor, utilizând CMDB-ul (baza de date pentru gestionarea configurațiilor), evidențele activităților de prelucrare, documentația integrărilor și înregistrările de acces. Include mediile de producție și cele care nu sunt de producție; conturile de serviciu și accesul privilegiat; cheile API, tokenurile și permisiunile aplicațiilor; exporturile de date, seturile de date pentru migrare și copiile pentru testare; copiile de rezervă și datele de asistență tehnică păstrate în exterior; precum și subcontractanții critici ai furnizorului, în măsura în care sunt cunoscuți.
O evaluare limitată la integrările active din mediul de producție nu ar fi identificat expunerea PKZH.
Dovezi: o hartă a dependențelor care corelează accesul furnizorului cu sistemele, datele și serviciile de afaceri.
Escaladează atunci când: nu poate fi stabilită amploarea datelor partajate, există posibilitatea expunerii unor date sensibile sau o funcție critică depinde de furnizor.
Pasul 3 — Ia o decizie privind limitarea incidentului
Responsabil: Comandantul incidentului / Operațiuni IT / Responsabilul de business
Decide dacă menținerea conectivității reprezintă un risc acceptabil. Opțiunile includ restricționarea accesului, dezactivarea integrărilor, revocarea datelor de autentificare sau suspendarea transferurilor de date, așa cum a procedat Ace & Tate în ziua în care a fost informată. Păstrează jurnalele și dovezile criminalistice înainte de a face modificări, ori de câte ori acest lucru este fezabil.
Scopul nu este deconectarea automată a fiecărui furnizor. Scopul este luarea unei decizii documentate și proporționale, împreună cu responsabilul de business.
Dovezi: decizia de limitare a incidentului, acțiunile întreprinse, activele afectate, evaluarea riscului rezidual.
Escaladează atunci când: există suspiciuni privind compromiterea datelor de autentificare, este identificată activitate malițioasă sau furnizorul nu poate oferi garanții rezonabile că menținerea accesului este sigură.
Pasul 4 — Investighează mediul pe care îl controlezi
Responsabil: SOC / DFIR
De regulă, SOC-ul nu are acces la telemetria furnizorului. Poate însă investiga interacțiunile furnizorului cu mediul tău: înregistrările de autentificare, sesiunile privilegiate, activitatea API, conexiunile de rețea, jurnalele aplicațiilor și transferurile de date. Caută solicitări neobișnuite, volume neașteptate, comportamente anormale ale conturilor de serviciu și abateri de la valorile de referință stabilite, apoi corelează-le cu orice indicatori furnizați de furnizor.
Absența alertelor nu constituie o dovadă că nu a avut loc o compromitere, în special atunci când activitatea relevantă se află în afara ariei de monitorizare.
Dovezi: cronologia investigației, interogările și rezultatele acestora, artefacte criminalistice, constatări, lacune de vizibilitate documentate.
Escaladează atunci când: sunt identificate acces neautorizat, extragere suspectă de date, utilizare abuzivă a privilegiilor sau deplasare laterală în rețea.
Pasul 5 — Stabilește expunerea datelor și impactul asupra activității
Responsabil: Comandantul incidentului / Responsabilul datelor / Responsabilul cu protecția datelor (DPO) / Responsabilul de business
Stabilește ce date deținea furnizorul, cum erau stocate și dacă există dovezi privind accesarea sau exfiltrarea acestora. Solicită furnizorului constatări validate: marcaje temporale, sisteme afectate, înregistrări ale accesului și categorii de date. Împarte constatările în trei categorii: expunere confirmată, expunere suspectată și expunere care nu poate fi încă determinată.
În cazul Ace & Tate, notificările inițiale precizau că nu putea fi exclusă implicarea datelor cu caracter personal; confirmarea accesării acestora a venit câteva săptămâni mai târziu. Planifică intervenția ținând cont de această perioadă de incertitudine. Absența unei exfiltrări confirmate nu dovedește că datele nu au fost accesate.
Dovezi: evaluarea impactului asupra datelor, serviciile afectate, constatările justificative, solicitările de dovezi încă nesoluționate.
Escaladează atunci când: sunt identificate date sensibile, perturbări semnificative sau consecințe care ar putea impune raportarea incidentului.
Pasul 6 — Evaluează obligațiile de raportare către autoritățile de reglementare
Responsabil: Juridic / Conformitate / DPO / Managementul securității
Stabilește ce notificări sunt necesare din punct de vedere legal și contractual. Pentru entitățile care intră sub incidența Directivei NIS2 sau a actului național de transpunere a acesteia, evaluează dacă incidentul îndeplinește criteriile pentru un incident semnificativ. Evaluează separat obligațiile prevăzute de GDPR în cazul încălcării securității datelor cu caracter personal. Înregistrează momentul în care ai luat cunoștință de faptele relevante, pragurile aplicabile și motivele care au stat la baza deciziei.
Investigația aflată încă în desfășurare la furnizor nu suspendă termenul propriu de raportare.
Dovezi: evaluarea documentată a obligațiilor de reglementare, termenele aplicabile, evidențele notificărilor.
Escaladează atunci când: este posibil să fie îndeplinit un prag de raportare, se apropie un termen-limită sau incertitudinea împiedică o evaluare justificabilă.
Pasul 7 — Validează remedierea înainte de restabilirea conexiunii
Responsabil: Securitate / Operațiuni IT / Responsabilul de business
Anunțul unui furnizor că serviciile sale funcționează din nou nu demonstrează, de unul singur, că riscul de securitate a fost eliminat. Solicită dovezi privind limitarea incidentului, remedierea, rotația datelor de autentificare și validarea măsurilor, proporționale cu incidentul; atunci când riscul o justifică, solicită o evaluare independentă. Restabilește conexiunea în etape, cu monitorizare intensificată.
Dovezi: documentația remedierii, rezultatele validării, evaluarea riscului rezidual, decizia autorizată de restabilire a conexiunii.
Escaladează atunci când: calea de atac nu a fost eliminată, lipsesc dovezi esențiale sau riscul rezidual depășește nivelul de toleranță aprobat.
Pasul 8 — Analizează incidentul și îmbunătățește controalele
Responsabil: Managementul securității / Gestionarea riscurilor furnizorilor / Responsabilul de business
Evaluează atât relația cu furnizorul, cât și propriul răspuns la incident. Ai putut identifica dependențele, obține dovezile, aplica măsurile de limitare și menține operațiunile esențiale? Actualizează cerințele contractuale, domeniile de acces, acoperirea jurnalizării, mecanismele de notificare și procedurile de recuperare. Desemnează un responsabil și un criteriu de verificare pentru fiecare acțiune corectivă.
Dovezi: raport post-incident, plan de remediere, evaluare actualizată a riscului asociat furnizorului, dovezi privind închiderea acțiunilor.
Escaladează atunci când: rămân riscuri semnificative nerezolvate sau furnizorul nu poate îndeplini cerințele tale de securitate și de asigurare a conformității.
Unde schimbă NIS2 nivelul așteptărilor
Securitatea lanțului de aprovizionare este o componentă explicită a gestionării riscurilor de securitate cibernetică în temeiul articolului 21 din Directiva NIS2 (UE 2022/2555). Transpunerea directivei de către fiecare stat membru transformă aceste cerințe în obligații concrete. Legislația din România este un exemplu util pentru a vedea cât de specifice devin aceste obligații.
În România, NIS2 este transpusă prin Ordonanța de urgență (OUG) nr. 155/2024, aprobată cu modificări prin Legea nr. 124/2025. Pentru entitățile esențiale și importante care intră în domeniul de aplicare:
- Articolul 13 reglementează măsurile de gestionare a riscurilor, inclusiv securitatea lanțului de aprovizionare și securitatea relațiilor cu furnizorii direcți și prestatorii de servicii.
- Articolul 14 stabilește responsabilitatea organelor de conducere pentru aprobarea și supravegherea acestor măsuri.
- Articolul 15 stabilește cerințele de raportare pentru incidentele semnificative: o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință a incidentului, o notificare a incidentului în termen de 72 de ore și un raport final, în general, în termen de o lună. Acesta stabilește, de asemenea, un termen separat de șase ore pentru transmiterea informațiilor care permit echipei naționale CSIRT să determine impactul transfrontalier.
Aceste obligații nu sunt declanșate automat atunci când un furnizor raportează un incident. Organizația trebuie să își evalueze propriul statut, impactul incidentului și criteriile de raportare aplicabile. Obligațiile de raportare prevăzute de GDPR în cazul încălcării securității datelor sunt evaluate separat.
Cele trei cazuri prezentate mai sus s-au produs în alte jurisdicții; legislația română nu li s-a aplicat. Aceasta este utilizată aici doar pentru a ilustra ce ar presupune același scenariu pentru o organizație care intră în domeniul de aplicare al directivei, în cadrul unei transpuneri naționale.
Ce poate și ce nu poate face un SOC
Un SOC nu poate accesa infrastructura unui furnizor, nu poate reproduce investigația sa criminalistică și nu poate verifica fiecare afirmație din raportul său de incident. Poate observa activitatea furnizorului în mediul monitorizat, poate investiga căile de acces, poate corela dovezile, poate sprijini deciziile de limitare a incidentului și poate documenta aspectele care rămân necunoscute.
Capacitatea de a face toate acestea se stabilește înainte de incident: dacă dependențele sunt cartografiate, dacă integrările furnizorilor sunt înregistrate în jurnale, dacă permisiunile au responsabili desemnați și dacă procesul de escaladare implică funcțiile de business potrivite. Gestionarea furnizorilor, departamentul juridic, responsabilitatea pentru protecția datelor, operațiunile IT și conducerea contribuie fiecare la răspuns. SOC-ul are un rol central, dar nu este singurul responsabil.
Lecția operațională
Relațiile cu furnizorii extind dependențele dincolo de infrastructura pe care o deții: date de autentificare pentru aplicații, sisteme logistice, date cu caracter personal și date de producție furnizate pentru proiecte care nu au fost încă puse în funcțiune. Atunci când un singur furnizor deservește numeroși clienți, o singură compromitere se transformă simultan în incidente multiple.
Niciun program de securitate nu poate garanta vizibilitatea asupra sistemelor unei terțe părți. Poate însă stabili ce dependențe există, ce poate fi observat, ce acces poate fi controlat și ce dovezi trebuie să furnizeze furnizorii.
Măsura pregătirii nu este capacitatea de a preveni fiecare compromitere a unui furnizor. Este capacitatea de a ști ce trebuie investigat, cine poate autoriza măsurile de limitare a incidentului, ce trebuie raportat și de ce dovezi este nevoie înainte ca încrederea să fie restabilită.
Surse
Informații publice consultate până la 22 octombrie 2026. Planul de acțiune reprezintă practici propuse, nu o reconstituire a procedurilor organizațiilor afectate.
Dezvăluiri privind incidentele
- Swiss Federal Council — Cyberattack on Publica software supplier: data outflow confirmed (8 Oct 2026)
- PK Softech — Cyberattack statement
- inside-it.ch — Data outflow at the federal pension fund
- SRF — Publica: data categories potentially affected
- PKZH — Cyberattack on PK Softech
- Nau.ch — PKZH statement of 15 Oct 2026
- Migros-Pensionskasse — Cyberattack on software supplier
- BleepingComputer — BigCommerce alerts merchants of breach linked to Ribon apps
- teiss — Ribon attack and Master of Malt
- TechCrunch — CEVA Logistics breach ripples across banks, retailers and Steam (10 Aug 2026)
- Dutch IT Channel — Ace & Tate reports possible data breach after CEVA intrusion
- RetailDetail — De Bijenkorf: customer data was indeed accessed (10 Sep 2026)
