Trei incidente third-party, trei tipuri diferite de dependență și un playbook în opt pași pentru incidentele care se petrec în afara controlului tău direct.
Un furnizor te anunță că sistemele lui au fost compromise.
SOC-ul tău nu vede niciun indicator of compromise (IoC) în mediul vostru. Aplicațiile merg. Business-ul funcționează normal.
Doar că furnizorul procesează datele clienților tăi, deține credențiale pentru o integrare sau operează un serviciu de care depinzi. Ce poți stabili pe cont propriu și ce trebuie să decizi cât timp furnizorul încă investighează?
Înainte de a citi mai departe, merită să răspunzi la trei întrebări:
- Ce date de-ale tale deține fiecare furnizor critic, inclusiv copiile făcute pentru testare, migrare sau onboarding?
- Ce credențiale și integrări ale furnizorilor pot ajunge în sistemele tale și cine le poate revoca în mai puțin de o oră?
- Ce dovezi ceri unui furnizor înainte să refaci o conexiune pe care ai întrerupt-o?
Trei incidente raportate în Europa în ultimele luni arată de ce contează fiecare dintre aceste întrebări.
Trei incidente, trei dependențe diferite
1. PUBLICA / PK Softech — Elveția
La finalul lui septembrie 2026, PK Softech, furnizor de software pentru administrarea fondurilor de pensii, a detectat un atac cibernetic. Potrivit propriei declarații, persoane necunoscute au folosit malware pentru a accesa o parte din infrastructura sa IT. Compania a izolat mediul afectat, a apelat la specialiști externi, a informat autoritățile și a depus plângere penală. A anunțat că serviciile sunt din nou complet disponibile pentru clienți începând cu 2 octombrie.
Pe 8 octombrie, guvernul federal elvețian a confirmat că datele au fost exfiltrate și că Parchetul General al Confederației a deschis o anchetă. PUBLICA, fondul de pensii federal, a avertizat că informațiile expuse ar putea include nume, adrese, coduri de asigurare socială (AHV), salarii, economii de pensie și date despre soți sau parteneri. A subliniat însă că activele și plățile de pensii nu au fost afectate.
Apoi cazul s-a extins. PK Softech deservește mai multe fonduri de pensii elvețiene, iar fondul de pensii Migros a anunțat că verifică dacă sunt implicate și datele membrilor săi.
Cel mai grăitor detaliu ține de Pensionskasse Stadt Zürich (PKZH). PKZH nu folosește încă PK Softech în producție; migrarea e planificată pentru începutul lui 2027. Ca să pregătească migrarea, transferase deja date ale membrilor către PK Softech. Pe 15 octombrie, PKZH a declarat că, potrivit informațiilor de până atunci, datele personale ale membrilor săi au fost sustrase. Sistemul de producție nu a fost afectat. Ce date și câte persoane sunt implicate era încă în investigație.
O relație cu un furnizor îți poate expune datele înainte ca serviciul să fie măcar live.
Întrebarea operațională: Știi ce date de producție ai share-uit cu furnizori pentru dezvoltare, testare, migrare sau onboarding și dacă era într-adevăr nevoie să fie date reale?
2. Master of Malt / Ribon — Regatul Unit
Între 13 și 17 septembrie 2026, atacatorii au folosit un application key BigCommerce compromis, deținut de Ribon (o aplicație third-party), pentru a accesa datele clienților unor comercianți BigCommerce. Master of Malt a raportat că au fost expuse numele, adresele de email, numerele de telefon și adresele poștale ale clienților săi. Și-a notificat clienții pe 18 septembrie și a raportat incidentul către Information Commissioner’s Office (ICO) din Marea Britanie.
BigCommerce a declarat că credențialele Ribon și Ribon 1.5 au fost compromise în urma unui breach la Fastr, compania din spatele Ribon, și că propria platformă nu a fost compromisă. A eliminat aplicațiile afectate pe 17 septembrie.
Cele două versiuni publice diferă. BigCommerce a descris folosirea credențialelor pentru a injecta scripturi malițioase într-un număr mic de storefront-uri. Master of Malt a descris citirea în masă, prin API, a înregistrărilor existente despre clienți. Nu se contrazic, dar nici nu spun aceeași poveste, iar nimic din ce s-a publicat nu confirmă că a existat script injection la Master of Malt.
Master of Malt a tras singură concluzia: nicio aplicație third-party n-ar fi trebuit să poată accesa datele clienților în felul ăsta, iar compania va cere BigCommerce un control mai granular al accesului API.
Întrebarea operațională: Poți identifica și revoca rapid permisiunile aplicației unui furnizor? Au acestea un scop limitat la ce are aplicația cu adevărat nevoie? Și ai propriile log-uri, ca să nu depinzi de versiunea furnizorului despre ce s-a întâmplat?
3. Ace & Tate / CEVA Logistics — Țările de Jos
Pe 1 august 2026, CEVA Logistics și-a informat clienții că o intruziune afectează o parte din operațiunile sale europene de contract logistics. Ace & Tate, retailer de ochelari, a aflat în aceeași zi că o persoană neautorizată a accesat o parte din sistemele folosite pentru procesarea comenzilor sale.
Ace & Tate a oprit imediat transferul de date către CEVA. Analiza proprie a arătat că sistemele interne nu au fost afectate. A notificat autoritatea olandeză pentru protecția datelor și ICO din Marea Britanie, și-a avertizat clienții că livrările și retururile ar putea întârzia și a precizat că rețetele, datele de plată, username-urile și parolele nu au fost implicate.
Ace & Tate nu a fost singura. Bol, De Bijenkorf, Ajax, ING și magazinul de hardware Steam al Valve s-au numărat printre clienții CEVA care au raportat impact. În septembrie, comunicările ulterioare ale retailerilor afectați au confirmat că datele clienților din sistemele CEVA au fost, într-adevăr, accesate.
Incidentul a avut două consecințe distincte: expunerea datelor personale și perturbarea livrărilor fizice.
Întrebarea operațională: Poți izola un furnizor compromis menținând totodată serviciile critice funcționale? Și ce dovezi ceri înainte de reconectare?
Cauze diferite, același tipar: un furnizor, mulți clienți
Incidentele nu au o cauză tehnică comună. Unul a implicat malware la un vendor de software, altul un application key furat, iar al treilea o intruziune la un furnizor de logistică.
Au însă aceeași structură. În fiecare caz, un singur furnizor se afla între atacator și multe organizații deodată:
- PK Softech deservește mai multe fonduri de pensii elvețiene, printre care PUBLICA, fondul de pensii Migros și, în etapa de pre-migrare, PKZH.
- Ribon era instalată în magazinele comercianților BigCommerce; potrivit Master of Malt, rula pe sute de astfel de magazine.
- CEVA gestiona comenzi pentru Bol, De Bijenkorf, Ajax, ING, Ace & Tate, Valve și alții.
Asta înseamnă concentration risk. Pentru atacator, o singură compromitere aduce multe victime. Pentru fiecare client, incidentul e în afara controlului său, dar consecințele îi aparțin în totalitate: obligațiile de notificare, încrederea clienților, perturbarea operațională.
Cazul Ribon mai adaugă un nivel. Credențialele compromise aparțineau unei aplicații, iar acestea au fost expuse în urma unui breach la compania-mamă, Fastr. Majoritatea inventarelor de furnizori se opresc la primul nivel (first tier). Expunerea nu s-a oprit acolo.
Un incident la furnizor nu înseamnă automat că infrastructura clientului a fost compromisă. Înseamnă însă că clientul 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 un răspuns bun
Cea mai mare parte din playbook-ul de mai jos depinde de munca făcută înainte să sune vreun furnizor. Patru pregătiri duc greul:
- Un inventar al datelor partajate cu furnizorii, inclusiv copiile din afara producției: seturi de test, extrase pentru migrare, exporturi pentru suport. Acolo unde datele personale reale nu sunt necesare pentru testare, minimizează-le sau pseudonimizează-le. Cazul PKZH arată ce poate expune un dataset de migrare.
- Credențiale de furnizor cu owner și scope clar. Fiecare API key, service account și permisiune de aplicație ar trebui să aibă un owner, un scop documentat și cel mai restrâns scope de care e nevoie pentru acel obiectiv. Revocarea ar trebui să fie o acțiune exersată, nu o căutare.
- Propriile log-uri despre activitatea furnizorilor. Autentificările, apelurile API și transferurile de date făcute de furnizori în mediul tău ar trebui logate și păstrate, ca investigația ta să nu depindă doar de relatarea furnizorului.
- Un pachet de dovezi stabilit prin contract. Definește din timp ce trebuie să furnizeze furnizorul după un incident: timeline, sisteme afectate, categorii de date, înregistrări de acces, dovezi ale remedierii și, acolo unde se justifică, validare independentă.
Un playbook în opt pași pentru third-party incident response
Fluxul de mai jos este o recomandare operațională, construită pe practicile consacrate de incident response, precum NIST SP 800-61 Rev. 3. Nu reconstituie ce au făcut efectiv organizațiile de mai sus.
Pasul 1 — Stabilește ownership-ul și clasifică evenimentul
Owner: Incident Commander / Security Manager
Înregistrează notificarea furnizorului ca eveniment de securitate și decide dacă activează procesul de incident response. Notează furnizorul, serviciile de business afectate, faptele cunoscute și întrebările deschise. Stabilește un canal verificat cu echipa de incident response a furnizorului și numește persoana care centralizează update-urile.
Dovezi: înregistrarea incidentului, responsabilul desemnat, momentul notificării, clasificarea inițială, jurnalul deciziilor.
Escaladează când: pot fi afectați un furnizor critic, un set de date sensibil, o integrare cu privilegii sau un serviciu esențial.
Pasul 2 — Mapează dependența și expunerea potențială
Owner: Security Architecture / IT / Vendor Manager
Identifică sistemele, identitățile, datele și serviciile de business legate de furnizor, folosind CMDB-ul, registrele de prelucrare, documentația integrărilor și înregistrările de acces. Include: mediile de producție și non-producție, service accounts și accesul privilegiat, API keys, tokens și permisiunile aplicațiilor, exporturile de date, dataset-urile de migrare și copiile de test, backup-urile și datele de suport ținute extern, subcontractorii critici ai furnizorului, acolo unde îi cunoști.
Dacă te-ai fi uitat doar la integrările live din producție, ai fi ratat expunerea PKZH.
Dovezi: o hartă a dependențelor care leagă accesul furnizorului de sisteme, date și servicii de business.
Escaladează când: nu poți stabili ce date au fost partajate, pot fi expuse date sensibile sau o funcție critică depinde de furnizor.
Pasul 3 — Ia o decizie de containment
Owner: Incident Commander / IT Operations / Business Owner
Decide dacă menținerea conectivității e un risc acceptabil. Opțiunile includ restricționarea accesului, dezactivarea integrărilor, revocarea credențialelor sau suspendarea transferurilor de date, așa cum a făcut Ace & Tate chiar în ziua în care a fost informată. Acolo unde se poate, păstrează log-urile și dovezile forensic înainte de a face modificări.
Scopul nu e să deconectezi reflex orice furnizor. E nevoie de o decizie documentată, proporțională, luată împreună cu business owner-ul.
Dovezi: decizia de containment, acțiunile întreprinse, activele afectate, evaluarea riscului rezidual.
Escaladează când: se suspectează compromiterea credențialelor, se descoperă activitate malițioasă sau furnizorul nu poate oferi garanții rezonabile că accesul continuu e sigur.
Pasul 4 — Investighează mediul pe care îl controlezi
Owner: SOC / DFIR
De obicei, SOC-ul nu are acces la telemetria furnizorului. Poate însă investiga interacțiunile furnizorului cu mediul tău: autentificări, sesiuni privilegiate, activitate API, conexiuni de rețea, log-uri de aplicație și transferuri de date. Caută cereri neobișnuite, volume neașteptate, comportament anormal al service accounts și abateri de la baseline-urile stabilite, apoi corelează-le cu indicatorii pe care îi transmite furnizorul.
Lipsa alertelor nu dovedește că nu există compromitere, mai ales când activitatea relevantă iese din aria de monitorizare.
Dovezi: timeline-ul investigației, query-urile și rezultatele lor, artefactele forensic, concluziile, lacunele de vizibilitate documentate.
Escaladează când: identifici acces neautorizat, extragere suspectă de date, abuz de privilegii sau lateral movement.
Pasul 5 — Stabilește expunerea datelor și impactul asupra business-ului
Owner: Incident Commander / Data Owner / DPO / Business Owner
Află ce date deținea furnizorul, cum erau stocate și dacă există dovezi de acces sau exfiltrare. Cere-i furnizorului concluzii validate: timestamps, sisteme afectate, înregistrări de acces și categorii de date. Împarte constatările în trei categorii: expunere confirmată, expunere suspectată și expunere care încă nu poate fi determinată.
În cazul Ace & Tate, primele notificări spuneau că nu se poate exclude implicarea datelor personale, iar confirmarea accesului a venit abia după câteva săptămâni. Planifică pentru acest decalaj. Faptul că exfiltrarea nu e confirmată nu dovedește că datele nu au fost accesate.
Dovezi: evaluarea impactului asupra datelor, serviciile afectate, constatările care o susțin, cererile de dovezi încă nesoluționate.
Escaladează când: identifici date sensibile, perturbări semnificative sau consecințe care ar putea fi raportabile.
Pasul 6 — Evaluează obligațiile de raportare
Owner: Legal / Compliance / DPO / Security Management
Stabilește ce notificări legale și contractuale se aplică. Pentru entitățile care intră sub incidența NIS2 sau a transpunerii naționale, evaluează dacă incidentul îndeplinește criteriile unui incident semnificativ. Evaluează separat obligațiile GDPR privind încălcarea securității datelor cu caracter personal. Notează momentul în care ai luat cunoștință de faptele relevante, ce praguri se aplică și pe ce te-ai bazat în decizie.
Investigația în curs a furnizorului nu îți oprește ceasul pentru raportare.
Dovezi: evaluarea de reglementare documentată, termenele aplicabile, evidența notificărilor.
Escaladează când: un prag ar putea fi atins, un termen se apropie sau incertitudinea nu permite o evaluare pe care să o poți susține.
Pasul 7 — Validează remedierea înainte de reconectare
Owner: Security / IT Operations / Business Owner
Faptul că un furnizor anunță că serviciile funcționează din nou nu demonstrează, în sine, că riscul de securitate a fost rezolvat. Cere dovezi de containment, remediere, credential rotation și validare, proporționale cu incidentul. Acolo unde riscul o cere, solicită independent assurance. Reconectează în etape, cu monitorizare intensificată.
Dovezi: documentația de remediere, rezultatele validării, evaluarea riscului rezidual, decizia autorizată de reconectare.
Escaladează când: vectorul de atac nu a fost adresat, lipsesc dovezi critice sau riscul rezidual depășește toleranța aprobată.
Pasul 8 — Analizează incidentul și îmbunătățește controalele
Owner: Security Management / Vendor Risk / Business Owner
Analizează atât relația cu furnizorul, cât și propriul răspuns. Ai reușit să identifici dependențele, să obții dovezile, să faci containment și să menții operațiunile esențiale? Actualizează cerințele contractuale, scope-ul accesului, acoperirea logării, aranjamentele de notificare și procedurile de recovery. Fiecărei acțiuni corective atribuie-i un owner și un criteriu de verificare.
Dovezi: raportul post-incident, planul de remediere, evaluarea actualizată a riscului de furnizor, dovada închiderii.
Escaladează când: rămân deschise riscuri semnificative sau furnizorul nu îți poate îndeplini cerințele de securitate și assurance.
Cum schimbă NIS2 așteptările
Securitatea lanțului de aprovizionare (supply-chain security) face parte explicit din managementul riscurilor de securitate cibernetică, conform Articolului 21 din Directiva NIS2 (UE 2022/2555). Transpunerea din fiecare stat membru o traduce în obligații concrete, iar cea din România arată bine cât de specifice devin acestea.
În România, NIS2 este transpusă prin OUG 155/2024, aprobată cu modificări prin Legea 124/2025. Pentru entitățile esențiale și importante care intră sub incidența ei:
- Articolul 13 acoperă măsurile de management al riscurilor, inclusiv securitatea lanțului de aprovizionare și securitatea relațiilor cu furnizorii direcți și prestatorii de servicii.
- Articolul 14 face organele de conducere responsabile de aprobarea și supravegherea acestor măsuri.
- Articolul 15 stabilește raportarea incidentelor semnificative: avertizare timpurie (early warning) în 24 de ore de la momentul luării la cunoștință, notificarea incidentului în 72 de ore și un raport final, de regulă în termen de o lună. Prevede totodată un termen separat, de șase ore, pentru informațiile care permit CSIRT-ului național să stabilească impactul transfrontalier.
Aceste obligații nu se declanșează automat când un furnizor raportează un incident. Organizația trebuie să-și evalueze propriul statut, impactul incidentului și criteriile de raportare. Obligațiile GDPR privind încălcarea securității datelor se evaluează separat.
Cele trei cazuri de mai sus au avut loc în alte jurisdicții, iar legislația românească nu li s-a aplicat. O folosim aici doar ca exemplu pentru ce ar cere același scenariu de la o organizație aflată sub incidența unei transpuneri naționale.
Ce poate și ce nu poate face un SOC
Un SOC nu poate accesa infrastructura unui furnizor, nu îi poate reproduce investigația forensic și nu poate verifica fiecare afirmație din raportul lui de incident. Poate vedea activitatea furnizorului în mediul monitorizat, poate investiga căile de acces, corela dovezi, susține deciziile de containment și documenta ce rămâne necunoscut.
Cât din toate acestea poate face se decide înainte de incident: dacă dependențele sunt mapate, dacă integrările cu furnizorii sunt logate, dacă permisiunile au owneri, dacă escaladarea implică funcțiile de business potrivite. Vendor management, legal, privacy, IT operations și conducerea poartă fiecare o parte din răspuns. SOC-ul e central, dar nu îl deține singur.
Lecția operațională
Relațiile cu furnizorii îți extind dependențele dincolo de infrastructura pe care o deții: credențiale de aplicație, sisteme de logistică, date personale, date de producție predate pentru proiecte care încă nu au intrat live. Când un furnizor deservește mulți clienți, o singură compromitere devine dintr-odată multe incidente.
Niciun program de securitate nu poate garanta vizibilitate în sistemele unui terț. Poate însă stabili ce dependențe există, ce e observabil, ce acces poate fi controlat și ce dovezi trebuie să furnizeze furnizorii.
Măsura pregătirii nu e dacă previi orice compromitere la un furnizor. Contează dacă știi ce să investighezi, cine poate autoriza containment-ul, ce trebuie raportat și de ce dovezi ai nevoie înainte ca încrederea să fie restabilită.
Surse: Informații publice revizuite la data de 22 octombrie 2026.
Notă: Ghidul (manualul de acțiune) reprezintă o practică propusă, 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)
