DORA, anul doi: SOC-ul tău vede cu adevărat atacul?
Când Digital Operational Resilience Act (DORA) a devenit aplicabil în toată UE, în ianuarie 2025, instituțiile financiare și-au petrecut primul an cu documentația: registre de risc, contracte actualizate cu furnizorii, fluxuri de escaladare a incidentelor. Etapa aceasta s-a încheiat. În anul doi, autoritățile de reglementare pun o întrebare mai directă — nu dacă documentația există, ci dacă o echipă de securitate poate chiar să vadă un atac în desfășurare, la timp pentru a interveni.
Ce testează, de fapt, anul doi al DORA
Cerințele tehnice ale DORA depășesc cu mult documentația. Articolul 9 obligă entitățile financiare să monitorizeze și să gestioneze continuu securitatea sistemelor ICT. Articolul 10 le cere să detecteze rapid activitățile anormale, cu praguri clare pentru declanșarea răspunsului la incident. Articolul 19 impune un termen strict de raportare: notificare inițială cât mai devreme posibil și nu mai târziu de patru ore de la clasificarea unui incident ca major, cu un raport complet în 24 de ore de la momentul constatării. Articolele 28-30 extind același nivel de rigoare la furnizorii terți ICT — procesatori, platforme cloud și alți furnizori de care depinde o instituție financiară.
Autoritățile verifică acum dacă instituțiile pot îndeplini aceste obligații în practică, nu doar să le descrie într-un document de politică.
De ce contează acest decalaj
Majoritatea organizațiilor au deja un inventar de active, înregistrări de configurare și jurnale de la nivelul endpoint-urilor. Niciuna dintre acestea, luată separat, nu arată cum comunică sistemele între ele — mai ales în infrastructura veche, pe dispozitivele nemanagementuite sau în integrările cu terți, acolo unde telemetria standard este limitată. Exact acesta este punctul orb exploatat de atacatori: trafic intern neobișnuit, beaconing de tip command-and-control și mișcare laterală apar adesea în rețea cu mult înainte ca un agent endpoint sau o regulă de corelare să le semnaleze.
Acest decalaj face și termenul DORA mai greu de respectat. Un termen de patru ore pentru notificare lasă puțin spațiu pentru a reconstitui manual ce sisteme au fost afectate, dacă tiparul de acces al unui furnizor s-a schimbat cu adevărat sau cât de departe s-a extins un incident. Răspunsurile depind de existența unor dovezi de trafic pregătite dinainte, nu reconstruite sub presiune ulterior — motiv pentru care articolele despre riscul asociat terților contează în practică: un contract definește ce are voie să facă un furnizor, dar doar traficul observat arată ce face de fapt.
Ce este de făcut
- Cartografiați cum arată comunicarea "normală" între sistemele critice, inclusiv conexiunile cu furnizorii, înainte ca un incident să vă oblige să o reconstituiți sub termenul de patru ore.
- Extindeți monitorizarea și la segmentele neacoperite de agenții endpoint: echipamente vechi, dispozitive nemanagementuite, OT/IoT și integrările cu terți vizate de evaluările conform articolelor 28-30.
- Tratați monitorizarea la nivel de rețea ca pe un complement al jurnalelor endpoint și de identitate, nu ca pe un înlocuitor — valoarea apare atunci când cele trei surse sunt corelate în momentul în care se declanșează o alertă.
- Simulați printr-un exercițiu de tip tabletop întregul traseu de raportare DORA, de la "anomalie detectată" la "notificare de patru ore redactată", pentru a identifica unde se blochează astăzi colectarea dovezilor.
- Tratați evaluările de risc ale furnizorilor ca documente vii: verificați periodic dacă tiparul real de trafic al unui furnizor mai corespunde cu ce descrie contractul, nu doar la reînnoire.
Primul an de DORA a demonstrat că instituțiile pot construi guvernanța necesară. Al doilea an testează dacă acea guvernanță rezistă în fața unui incident real — iar totul se reduce la vizibilitate, nu la documentație.