FBI atribuie breșa din PeopleSoft unui patch neaplicat de un contractor. Întrebarea de pus furnizorului tău: cine ține „butonul de patch”?

• Incidentul a expus informații personale ale a mii de angajați ai FBI, potrivit relatărilor. FBI nu a precizat public numărul sau categoriile de date.
• Cauza descrisă oficial: o platformă administrată de o organizație terță și un patch emis explicit pentru ea, neaplicat de un contractor.
• FBI a îndepărtat contractorul și spune că a luat „toate măsurile necesare” pentru a reduce riscul și a-și proteja personalul.

• Platforma afectată ar fi sistemul de resurse umane Oracle PeopleSoft.
• Contractorul ar fi Accenture, responsabil, potrivit relatărilor, de gestionarea patch-urilor și de codul personalizat. Oracle ar fi emis patch-urile neaplicate.
• Accenture nu a răspuns la întrebări concrete despre contractor sau despre patch. Declarația ei: „suntem mândri să susținem misiunea FBI și vom continua să o facem”.
• Reuters își citează sursele fără nume. FBI nu a confirmat public numele contractorului. Tratează numele ca pe o relatare, nu ca pe o concluzie oficială.

Pe 25 septembrie, Google Threat Intelligence Group și Mandiant au publicat o analiză despre exploatarea în masă a Oracle PeopleSoft prin CVE-2026-35273, o vulnerabilitate pentru care Oracle emisese o corecție încă din iunie. Google nu menționa niciun zero-day nou. ShinyHunters susținea însă că a folosit o vulnerabilitate necunoscută la FBI.

Descrierea FBI, un patch emis și neaplicat, este în concordanță cu o vulnerabilitate cunoscută și corectată, nu cu un zero-day. Aceasta este o inferență a noastră: declarația oficială nu numește vulnerabilitatea, deci nu putem spune că este CVE-2026-35273. Rămâne neconfirmat și dacă toate afirmațiile grupului despre volumul datelor corespund realității.

• De ce nu a fost aplicat patch-ul și de când. Nu avem cronologia dintre emiterea corecției și compromitere.
• Cum monitoriza FBI conformitatea contractorului. Relatările nu spun dacă existau verificări independente.
• Numărul exact al angajaților afectați și categoriile de date.
• Dacă datele furate au fost șterse. Grupul a spus că nu le va publica, dar o declarație a atacatorilor nu este o garanție.

Cazul este american, dar situația este banală: un sistem important, administrat de un terț, cu un patch emis de producător care nu ajunge pe server. Majoritatea organizațiilor din România care folosesc un integrator pentru ERP, HR, salarizare sau site au aceeași structură. Responsabilitatea pe hârtie și cea reală pot fi diferite.

Nu trage concluzia că vina este doar a contractorului. FBI este cel care a ales, a supravegheat și, potrivit propriei declarații, a îndepărtat contractorul abia după incident. Întrebarea de conducere este dublă: cine aplică patch-ul și cine verifică?

• Cine, nominal, aplică patch-urile pentru fiecare sistem, și unde scrie asta? Contractul care spune „întreținere” nu este același cu unul care spune „aplicarea patch-urilor critice în X zile de la emitere”.
• Care este termenul pentru vulnerabilitățile exploatate activ? Un termen în zile, legat de anunțurile producătorului sau de catalogul KEV al CISA, nu unul lunar.
• Ce dovadă primești? O dovadă cu versiunea exactă și data aplicării, de la un instrument pe care îl controlezi sau pe care îl poți verifica, nu o confirmare verbală.
• Cine verifică independent? Un scan extern sau o verificare periodică făcută de altcineva decât cel care aplică patch-ul.
• Ce se întâmplă când un patch se amână? Cine decide, cine semnează excepția, pentru cât timp și cu ce măsuri compensatorii.
• Când trebuie să te anunțe furnizorul despre un incident? Un termen în ore, către un contact nominal, cu jurnalele disponibile la cerere.

NIS2 include securitatea lanțului de aprovizionare, inclusiv aspectele legate de furnizorii direcți, printre măsurile de gestionare a riscurilor pentru entitățile esențiale și importante, alături de gestionarea vulnerabilităților. În România, directiva a fost transpusă prin OUG 155/2024, aprobată prin Legea 124/2025, cu DNSC drept autoritate. Un contract care nu spune cine aplică patch-ul este un punct slab pe care un audit îl poate găsi.

Dacă un furnizor te anunță despre un incident într-un serviciu esențial, termenele de 24 de ore pentru avertizarea timpurie și de 72 de ore pentru raportul inițial curg de la momentul în care ai luat tu cunoștință, nu de la cel în care s-a produs incidentul.

Awarely Learning poate transforma întrebările de mai sus într-un exercițiu pentru conducere și achiziții: un furnizor îți spune, vineri seara, că un patch emis acum trei luni nu a fost aplicat. Ce faci în primele 24 de ore? Deciziile rămân ale organizației.