Atacurile informatice pot deveni o problemă de continuitate a companiei sau instituției, iar organizațiile trebuie să știe dinainte de incident care sunt pașii și termenele de revenire.
Atacul asupra Agenției Naționale de Cadastru și Publicitate Imobiliară (ANCPI) din 14 iulie 2026 este exemplul recent relevant. Guvernul a confirmat un atac de tip ransomware: atacatorii au criptat și au șters o parte din infrastructura de virtualizare care găzduia aplicațiile Agenției. Dar, conform informațiilor oficiale, baza de date centrală nu a fost afectată.
Cu alte cuvinte, disponibilitatea serviciilor și integritatea datelor sunt două probleme diferite. Aplicația e-Terra ANCPI a fost repornită etapizat abia începând cu 11 august, după 28 de zile de la confirmarea incidentului.
Această lună de nefuncționare confirmă un principiu fundamental în serviciile de cybersecurity: Backup ≠ Continuitate.
De ce reziliență cibernetică? Dacă mâine avem un incident major, ce activități continuă, cine este responsabil și în cât timp revenim la funcționare normală pe sisteme curate?
Organizația poate avea datele, chiar mai multe copii ale lor (ex: principiul 3-2-1). Dar, fără planificare prealabilă, pot trece săptămâni pentru reconstrucția aplicațiilor, identităților, integrărilor și fluxurilor de lucru, ca în cazurile publice recente. Programul de reziliență cibernetică definește ordinea pașilor și duratele acceptabile și le testează.
În acest articol ilustrăm un program de reziliență, structurat pentru claritate în șase faze desfășurate pe aproximativ 12 săptămâni. Folosim în analiză principii din cadrele de risc și reglementările aplicabile folosite de OPTI (prescurtat: NIST, CIS Controls, ISO 27001, ISO 22301 și ISO/IEC 27031, GDPR și NIS2 - unde este cazul). Implementarea concretă variază de la caz la caz.
Care sunt cele șase faze propuse?
| Fază | Săptămâni |
|---|---|
| 0. Stabilizare + Responsabilități | primele 2-3 zile |
| 1. Inventar + Business Impact Analysis | săptămânile 1-2 |
| 2. Reducerea suprafeței de atac (Hardening) | săptămânile 2-6 |
| 3. Restore + Continuitate | săptămânile 3-8 |
| 4. Incident Response + Training | săptămânile 6-10 |
| 5. Operare recurentă | săptămânile 10-12 |
Fazele se suprapun parțial, pentru a menține ritmul echipei de implementare și pentru economie de timp. De exemplu, corectarea conturilor evident vulnerabile (parte din hardening) poate începe până la finalizarea inventarului complet.
Faza 0. Stabilizare și responsabilități
În primele 2-3 zile, obiectivul este evitarea haosului organizațional în cazul în care incidentul grav ar apărea "mâine dimineață". Toate celelalte faze se construiesc pe baza responsabilităților fundamentale în organizație, înainte de orice audit, unelte și tehnologii.
Mai întâi stabiliți echipa de urgență: management, IT, juridic (inclusiv DPO), responsabil de comunicare și toți furnizorii tehnici care vor fi implicați într-un eventual atac. Pentru rolurile critice se definesc și înlocuitorii (cine preia responsabilitatea în caz de indisponibilitate temporară).
Se verifică:
- accesibilitatea copiilor de siguranță (backup), inclusiv a unei copii în exteriorul infrastructurii IT curente.
- accesele esențiale administrative
- existența conturilor de tip break-glass (acces administrativ urgent)
- existența unui canal de comunicare alternativ față de infrastructura organizației (ex: nu depindem de funcționarea e-mailului oficial pentru a ne coordona).
NIST CSF 2.0 formulează principiul:
"Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced." (GV.RR-02)
Un livrabil util este o fișă fizică de o pagină: "Primele 60 de minute în caz de atac".
Într-o variantă simplificată:
| 0-15 minute | 15-30 minute | 30-60 minute |
|---|---|---|
| Izolăm sistemul afectat Nu ștergem și nu reinstalăm fără instrucțiuni de la echipa tehnică Notăm ora și simptomele, creăm dovezi (ex: poză) Activăm responsabilul de incident | Stabilim severitatea Identificăm sistemele și identitățile suspecte Protejăm backup-urile Deschidem jurnalul incidentului | Separăm sistemele curate de cele compromise Păstrăm logurile IT Evaluăm impactul asupra datelor Stabilim punctul de recuperare înainte de orice restore. |
Acțiunile exacte depind de tipul incidentului. Ceea ce este important este ca acțiunile să fie decise și diseminate în organizație înainte de incident, nu inventate sub presiune.
Rezultatul Fazei 0: Organizația știe cine decide și ce responsabilități are în primele minute ale incidentului.
Faza 1. Inventar și dependențe (Business Impact Analysis)
În săptămânile 1-2, organizația trebuie să înțeleagă arhitectura de procese și infrastructura IT proprie.
Inventarul trebuie să includă minim endpointurile, serverele, aplicațiile cloud, rețelele, echipamentele speciale, conturile privilegiate, cheile, furnizorii, API-urile și integrările externe.
Un inventar pur tehnic nu este suficient. Un server poate fi critic dacă de el depinde un proces important al organizației, indiferent ce specificații și cost a avut.
Business Impact Analysis (BIA) este definită de ISO 22301 ca:
"process of analysing the impact over time of a disruption on the organization." (3.5)
Pentru fiecare proces critic trebuie stabilite cel puțin patru elemente:
- RTO: în cât timp trebuie să revină serviciul
- RPO: câtă informație ne permitem să pierdem
- Workaround: cum continuăm temporar activitatea
- Ordinea de restaurare: ce sistem trebuie pornit înaintea altuia.
Managementul va răspunde la întrebările care nu sunt, de fapt, întrebări IT: Ce poate lipsi patru ore? Ce poate lipsi o zi? Ce nu poate lipsi deloc?
Aici apar de obicei și surprize: se detectează puncte unice de eșec pe care nu le-ai fi bănuit: un program scris acum 30 de ani care este necesar pentru închiderea contabilă a zilei, un laptop folosit ca server, un serviciu extern de care organizația depinde.
Rezultatul Fazei 1: Organizația are un inventar, plus harta fluxurilor între procese, tehnologie și angajați, plus intervalele acceptabile de indisponibilitate.
Responsabilitatea este partajată în cloud.
O eroare frecventă în fazele de inventar și hardening este senzația de siguranță dată de cloud. Fie că folosești aplicații SaaS sau ai date în arhitecturi serverless, se aplică regula de bază: Shared Responsibility Model.
Responsabilitatea este partajată, de exemplu furnizorul securizează infrastructura (data center-ul, rețeaua fizică), dar tu ești responsabil de securitatea datelor, a identităților și de configurările client. Granița diferă în funcție de serviciul folosit (ex: IaaS vs SaaS), în Google Cloud această colaborare fiind numită și modelul shared fate (destin comun).
Un scenariu banal: un angajat deschide un atașament malware. Ransomware-ul criptează fișierele locale, iar clientul de cloud sincronizează automat fișierele criptate sau modificate, unde ele pot afecta întreaga echipă, inclusiv posibilitatea restaurării.
Dacă organizația folosește ecosistemul Google, instrumentele de securitate native trebuie activate și configurate:
- Pentru documente și identitate (Workspace): Implementează politici de Context-Aware Access. Poți condiționa accesul la Google Drive sau e-mail de securitatea endpointului folosit.
- Pentru infrastructura serverless/cloud: Google Cloud Security Command Center (SCC) oferă vizibilitate centralizată, detectând configurările greșite și vulnerabilitățile înainte ca ele să fie exploatate.
OPTI implementează soluții Google Cloud la cheie sau extinde echipa ta
Faza 2. Reducerea suprafeței de atac (hardening)
În săptămânile 2-6, putem lua măsurile tehnice necesare în urma inventarului și BIA.
În majoritatea organizațiilor, progresul real vine din executarea consecventă a controalelor de bază:
- conturi nominale
- acces minim necesar
- MFA
- administrarea separată a conturilor privilegiate
- patching centralizat și EDR
- criptarea endpointurilor și segmentarea rețelelor
CIS Controls v8.1 recomandă:
"Establish and maintain a documented secure configuration process for enterprise assets … and software." (Safeguard 4.1)
Se adaugă verificarea expunerii web: API-uri, tokenuri de acces la resurse informatice, înregistrările DNS ale domeniilor și e-mailului (ex: SPF, DKIM și DMARC) dar și inventarierea componentelor software ajunse la end-of-life sau cunoscute cu vulnerabilități (ex: pluginuri WordPress, încă prezente în site-urile instituțiilor).
Pentru stațiile Windows, un nucleu rezonabil de protecție include: Windows aflat în perioada de suport, inventar de software local, instrument de patching cu SLA pentru vulnerabilitățile critice, EDR cu posibilitate de izolare, criptare discuri, separare cont standard pentru activitatea curentă vs. cont administrativ pe stație.
Detecția și monitorizarea se fac continuu prin EDR. Livrabilele concrete ale departamentului IT vor include: sursele critice de log și indicatorii de compromitere, responsabilul de triaj cu SLA-ul asociat, regulile de retenție, fluxurile de escaladare și procedurile de izolare a endpoint-urilor compromise. După aceste etape se declanșează procesul de Incident Response.
Segmentarea rețelelor adaugă protecție: O stație compromisă nu ar trebui să poată comunica liber cu serverele, dispozitivele speciale, imprimantele și toate celelalte endpointuri.
Un SIEM (Security Information and Event Management) poate aduce vizibilitate, fără a compensa existența unor endpointuri neadministrate, accese privilegiate uitate și puncte de restaurare care nu au fost testate (vezi mai jos).
O ordine pragmatică de hardening (care poate varia conform metodologiei):
inventar ▷ patching ▷ EDR ▷ segmentare ▷ scanare recurentă ▷ SIEM
Rezultatul Fazei 2: Suprafața de atac a organizației a scăzut, iar departamentul IT are un proces repetabil de control și remediere pentru resurse similare.
Faza 3. Restore și continuitate testate end-to-end
În săptămânile 3-8 se face diferența între un program de reziliență pe hârtie și un program eficient și demonstrabil. Ce trebuie demonstrat e faptul că sistemele pot fi restaurate conform timpilor (RTO / RPO) definiți de management în Faza 1.
GDPR cere testarea periodică a eficacității măsurilor tehnice și organizatorice, împreună cu:
"the ability to restore the availability and access to personal data in a timely manner." (art. 32)
Exercițiile de restaurare pot urma traseul:
Traseul unui exercițiu de restaurare
Ultima copie curată (backup)
│
▼
Amplasare în mediu izolat (clean room)
│
▼
Repornire servicii tehnice (DB, storage, DNS, certificate)
│
▼
Repornire integrări (API, e-mail, identitate, servicii externe)
│
▼
Validare business (teste fluxuri operaționale)
│
▼
Documentare (pentru repetabilitate) 
Un exemplu de test documentat
Start restore: 09:00 Serviciu funcțional: 13:20 RTO realizat: 4h20 RPO realizat: 6h Validare de business: reușită / nereușită Probleme descoperite: LISTĂ
Pasul de validare business este esențial, un utilizator normal al organizației trebuie să poată executa procesul pentru care sistemul respectiv există (ex: să facă o factură sau să răspundă clienților). Nu este suficient ca serverul să pornească și baza de date să răspundă, pentru a avea continuitate organizațională.
Rezultatul Fazei 3: Organizația poate demonstra că serviciile pot fi reconstruite și cunoaște timpul real de recuperare.
Faza 4. Incident response și training (exerciții tabletop)
În săptămânile 6-10, măsurile se concentrează asupra factorilor umani. Un atac major afectează toate departamentele:
- Managementul stabilește severitatea și ia decizii de risc
- Echipa tehnică izolează, investighează și restaurează
- Juridicul și DPO-ul evaluează implicațiile legale / asupra datelor personale
- Comunicarea pregătește mesajele interne și externe
- Furnizorii critici sunt incluși în procedura de escaladare
NIS2 include explicit între măsurile de gestionare a riscului cibernetic:
"incident handling" și "business continuity, such as backup management and disaster recovery, and crisis management" (Art. 21(2)(b)–(c))
În această fază se pregătesc playbook-uri per tip de atac: ransomware, compromiterea unui cont de e-mail, furtul unui laptop, indisponibilitatea unui serviciu critic sau compromiterea unui cont privilegiat și se face trainingul personalului, urmat de exerciții tabletop.
Cum se organizează un tabletop exercise?
Într-un tabletop, sistemele IT nu trebuie de regulă oprite. Echipa primește scenariul în etape: "La 08:35, două stații nu mai pot accesa share-ul de fișiere." "La 08:50, apare o notă ransomware." … Se discută deschis: Cine declară incidentul, cine izolează rețeaua? Putem vorbi între noi dacă e-mailul este compromis? Cine sună furnizorul? Ce informații trebuie să păstrăm pentru investigație?
Din training și tabletop exercise se descoperă problemele pe care un audit documentar le poate ignora. De exemplu un număr de telefon care lipsește sau un acces cunoscut de o singură persoană din organizație.
Rezultatul Fazei 4: Personalul organizației știe ce trebuie să facă în diferite scenarii, reducând riscul de haos.
Faza 5. Reziliența devine proces permanent
În săptămânile 10-12, se realizează dosarul de reziliență, dar mai ales, se definește disciplina operațională pe termen lung, printr-un calendar de activități recurente executate de organizație.
ISO/IEC 27031:2025 afirmă rolul serviciilor TIC de a susține continuitatea activității și se leagă de ISO/IEC 27001 și ISO 22301:
"… information and communication technology (ICT) is prepared to support business continuity. It outlines a framework for ICT readiness that aligns with broader business continuity objectives …" (ISO/IEC 27031:2025)
Un calendar permanent poate arăta astfel, simplificat pentru o organizație medie:
| Interval | Sarcini | Responsabil și controale |
|---|---|---|
| Lunar | patching, EDR, backup și alerte | Nume, dată, document |
| Trimestrial | recertificarea acceselor, test de restore, revizuirea parțială BIA | Nume, dată, document |
| Semestrial | tabletop, exercițiu tehnic și actualizarea planului de continuitate | Nume, dată, document |
| Anual | BIA complet, arhitectură, furnizori, buget și priorități de investiție | Nume, dată, document |
O opțiune în această fază devine implicarea unui audit extern sau a unei autorități de certificare care să alinieze procedurile la unul sau mai multe standarde. Mai întâi organizația s-a pregătit timp de 12 săptămâni, apoi este gata să fie verificată în mod transparent.
Rezultatul Fazei 5: Fiecare activitate de reziliență cibernetică are proprietar, frecvență, controale și dovadă de execuție.
Ce ar trebui să existe concret după 12 săptămâni?
La finalul programului ar trebui să existe un set utilizabil de documente și dovezi:
- Raport executiv cu riscurile prioritizate de management
- Registru de active și BIA cu RTO/RPO
- Registru de riscuri cu proprietar, termen și risc rezidual
- Planul de business continuity și disaster recovery
- Playbook-uri pentru tipurile de incidente importante
- Procese-verbale ale testelor de restaurare reale
- Un baseline/checklist pentru endpointuri și rețea
- Raportul exercițiilor de incident response
- Roadmap tehnic și bugetar pentru următoarele 12 luni
Dacă se contractează un audit sau certificare externă, este un plus pentru organizație.
Ce a obținut organizația?
Programul de reziliență al organizației a trecut mult dincolo de ideea de backup. Deși nu este o garanție contra atacurilor, el i-a permis organizației să își cunoască riscurile și metodele de apărare și să reacționeze planificat pe o bază deja testată.
Incidentele din presa recentă au arătat diferența dintre existența informației și disponibilitatea serviciului (Backup ≠ Continuitate). Același lucru este valabil într-o companie cu 30 de angajați, într-un spital, într-o fabrică sau într-un business care depinde de un ERP/CRM și câteva aplicații cloud.
OPTI Software este certificat ISO 27001 și operează de peste 20 de ani sisteme software și infrastructură IT pentru organizații din România și din afara țării.
Surse și standarde
- NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond, Recover
- CIS Critical Security Controls v8.1
- ISO 22301:2019: Business Continuity Management Systems
- ISO/IEC 27031:2025: ICT Readiness for Business Continuity
- Regulamentul (UE) 2016/679: GDPR, art. 32.
- Directiva (UE) 2022/2555 (NIS2)
- OUG 155/2024 privind cadrul național de securitate cibernetică, aprobată prin Legea 124/2025 și completată prin Legea 123/2026.
