În articolul anterior am arătat cum aș audita două cerințe CyFun: testarea designului controlului (ToD), testarea funcționării în timp (ToE) și legătura lor cu cele două scoruri, documentație și implementare. Acum vin cu întrebarea care contează: ce se întîmplă cînd auditorul se oprește la prima jumătate?
Multe rapoarte de audit „conforme” arată de obicei cam așa: politica există, procedura e semnată, echipa răspunde corect la interviu…. Toate adevărate. Doar că o procedură aprobată nu dovedește că procedura se aplică, iar atacatorii….. nu citesc proceduri. Caută exact locurile unde practica s-a îndepărtat de hîrtie.
Fac și de data asta un exercițiu, tot fără pretenții de completitudine. Scenariul este inventat, dar construit din situații pe care le întîlnim sau le-am citit prin media….scopul este doar explicativ.
Un gateway VPN tăcea
August. O entitate esențială în sensul OUG nr. 155/2024 trece printr-un audit. La cerința PR.PS-04.1 („Jurnalele trebuie menținute, documentate și monitorizate.”), auditorul primește politica de jurnalizare, schema arhitecturii SIEM și o captură de ecran a consolei: 1.240 de surse active. Echipa SOC confirmă că „toate sistemele critice trimit jurnale”. Concluzia: implementat, scor 3 din 5. Bifat.
Octombrie. Un atacator intră prin gateway-ul VPN, folosind o vulnerabilitate publicată cu cîteva săptămîni înainte. Timp de 3 zile se mișcă lateral pînă la un controler de domeniu, apoi lansează ransomware.
Investigația descoperă trei lucruri:
- Jurnalele gateway-ului VPN nu mai erau indexate în sursa logică asociată echipamentului încă din februarie. Actualizarea de firmware modificase formatul mesajelor syslog. Gateway-ul continua să transmită evenimente, iar acestea ajungeau în colectorul central, dar parserul SIEM nu le mai recunoștea și le respingea înainte de indexare. Nici o alertă nu semnalase dispariția evenimentelor utilizabile pentru monitorizarea gateway-ului.
- Jurnalele locale ale gateway-ului se păstrau doar 7 zile. Deși răspunsul la incident a început imediat după atac, analiza criminalistică detaliată a gateway-ului a fost efectuată ulterior, cînd evenimentele primului acces fuseseră deja suprascrise. Acestea nu existau nici în arhivă.
- Ceasul controlerului de domeniu era decalat cu 7 minute. Reconstituirea cronologiei a durat zile în loc de ore.
Lipsa jurnalelor relevante limitează semnificativ capacitatea organizației de a determina dacă au fost exfiltrate date, și în ce interval. Iar raportul de audit din august spunea că totul e în regulă…..
Ce ar fi făcut un auditor care testează
Cifra de 1.240 de surse active este un număr…. nu o probă. Nu spune cîte sisteme critice lipsesc. Pentru cerințele de jurnalizare, trebuiau făcute cel puțin 4 verificări, de cîteva ore fiecare:
- Acoperirea (PR.PS-04.1 și PR.PS-04.3). Inventarul activelor critice (180 de sisteme) comparat cu exportul surselor din SIEM, inclusiv data ultimului eveniment primit. Rezultat: 23 de sisteme critice (13%) fără niciun eveniment în ultimele 24 de ore, printre ele gateway-ul VPN, în silenzio stampa din februarie. Verificările suplimentare au confirmat că pentru toate cele 23 de sisteme colectarea sau prelucrarea jurnalelor obligatorii era nefuncțională. Pentru un eșantion de sisteme critice, verificăm și istoricul întreruperilor de colectare, incidentele asociate și modul în care acestea au fost detectate și remediate în perioada auditată.
- Ora (PR.PS-04.2). Marcajele de timp de pe un eșantion de 10 sisteme, comparate cu sursa NTP de referință. Rezultat: 3 sisteme decalate cu peste un minut, inclusiv controlerul de domeniu.
- Alerta la eșec (PR.PS-04.4). Cu acordul echipei IT/SOC, simulăm două defecțiuni: întreruperea transmiterii jurnalelor de la un server de test și respingerea controlată a unor evenimente de către parser. Verificăm dacă mecanismele de monitorizare detectează defecțiunile și declanșează alertele și răspunsurile definite. Rezultat: niciuna dintre defecțiuni nu a generat o alertă în intervalul de 24 de ore.
- Păstrarea (DE.AE-03.1, tot o Măsură cheie). Cel mai vechi eveniment disponibil pentru fiecare sursă din eșantion, față de cele 12 luni cerute de politică. Rezultat: gateway-ul VPN păstra doar 7 zile.
Ce nu acoperă testul de jurnalizare
Jurnalele ar fi putut face atacul vizibil, dar nu l-ar fi oprit. Incidentul a trecut prin mai multe controale: intrarea prin VPN, mișcarea laterală, controlerul de domeniu, ransomware-ul. Un audit complet al unei organizații la acest nivel de risc ar fi inclus și următoarele teste, fiecare legat de un pas al atacului.
| Nr.crt | Test | Cerința CyFun | Ce ar fi arătat în scenariu |
| 5 | Validarea inventarului: lista sistemelor critice comparată cu o scanare a rețelei | ID.AM-01.1 | Dacă cele 180 de sisteme sînt într-adevăr toate. Testul de acoperire e doar atît de bun pe cît de bună este lista de la care pornește. |
| 6 | Vulnerabilitățile echipamentelor expuse la internet: scanare externă și data patch-ului față de data publicării | ID.RA-08.1 (Măsură cheie), ID.RA-01.6, PR.PS-02.1 | Vulnerabilitatea gateway-ului VPN, publică de cîteva săptămîni și nereparată: calea de intrare a atacatorului. |
| 7 | Gestionarea modificărilor: pe un eșantion de schimbări, inclusiv actualizări de firmware, verific dacă jurnalizarea a fost confirmată după modificare | PR.PS-01.5 | Actualizarea din februarie, după care nimeni nu a observat că jurnalele ajung la colector dar nu mai sînt indexate de SIEM. |
| 8 | Accesul VPN: conectare de test fără MFA și verificarea alertelor pentru sesiuni neobișnuite | PR.AA-03.2 (Măsură cheie), PR.AA-03.4 | Testul MFA ar fi verificat o cale alternativă de compromitere, prin utilizarea unor credențiale furate sau compromise. Nu ar fi demonstrat, însă, protecția împotriva exploatării vulnerabilității gateway-ului VPN |
| 9 | Segmentarea: din zona de rețea sau contextul de acces obținut prin compromiterea gateway-ului VPN, verific accesibilitatea serviciilor administrative ale controlerului de domeniu (RDP, SMB, WinRM sau RPC). | PR.IR-01.2 (Măsură cheie), PR.IR-01.4 | Dacă segmentarea rețelei ar fi limitat mișcarea laterală de la gateway-ul VPN compromis către controlerul de domeniu. |
| 10 | Analiza evenimentelor: reguli de detecție pentru mișcare laterală și autentificări administrative neobișnuite, plus cîteva alerte reale urmărite pînă la închidere | DE.AE-02.1, DE.CM-01.4, PR.AA-05.9 | De ce cele 3 zile de mișcare laterală nu au generat nici o alertă, deși controlerul de domeniu trimitea jurnale. |
| 11 | Restaurarea: un sistem critic restaurat complet din backup, cronometrat, și verificarea că backup-ul e izolat de credențialele de domeniu | PR.DS-11.1 (Măsură cheie), PR.DS-11.4, RC.RP-01 | În cît timp ar fi revenit organizația după ransomware și dacă backup-urile rezistă unui atacator cu drepturi de administrator. |
Remediate în august, constatările de jurnalizare ar fi făcut atacul vizibil doar dacă existau și reguli care să-l semnaleze (testul 10). Incidentul a traversat mai multe niveluri de apărare. Testele propuse ar fi permis identificarea unor deficiențe la aceste niveluri, dar nu toate controalele enumerate pot fi considerate eșuate doar pe baza scenariului. Identificarea și remedierea deficiențelor ar fi putut întrerupe lanțul. Despre testul 11 am scris mai pe larg în „Backup: SUCCES. Restore: surpriză.”
Cum se schimbă scorul CyFun
Același control, evaluat în două feluri, poate produce concluzii diferite: conformitate aparentă pe baza documentației și neconformitate demonstrată prin probe operaționale. PR.PS-04.1 este Măsură cheie. La nivelul de asigurare Esențial, CyFun cere minimum 3 pentru fiecare Măsură cheie, minimum 3 pentru fiecare categorie și un scor general al entității de minimum 3,5. Fiecare control primește separat un scor pentru documentație și unul pentru implementare..
| Auditor care doar citește | Auditor care testează | |
| Probe | Politica, schema SIEM, captura consolei, interviul SOC | Inventar, export SIEM, verificări ale fluxului jurnalelor. |
| Scor documentație | 3 | 3 |
| Scor implementare | 3 („1.240 de surse active”), insuficient probat | 2 (23 din cele 180 de sisteme critice (12,8%) nu au transmis evenimente în ultimele 24 de ore. Pragul de sub 10% al stadiului 3 nu este îndeplinit. Scorul de implementare 3 nu poate fi susținut pe baza probelor analizate; probele suplimentare au confirmat un proces ad-hoc de verificare a funcționării colectării și procesării jurnalelor. |
| Măsura cheie (minimum 3) | Trece, prag aparent atins | Nu trece, scorul necesar nu este atins |
| Rezultat ESENȚIAL | Conformitate declarată fără probe suficiente | Neconformitate documentată, cu necesitatea remedierii |
Pragul nu este arbitrar. CyFun definește nivelul 3 la implementare ca „proces formal, aplicat, cu excepții sub 10%”. Fără numitor (cîte sisteme critice există), procentul de excepții e necunoscut, deci scorul nu se poate justifica.
Efectul nu se oprește aici. Testul alertei atinge și PR.PS-04.4, de nivel Esențial: „eșecurile de procesare a auditului generează alerte și declanșează răspunsuri definite”. Absența alertei demonstrează că mecanismul nu a funcționat în condițiile testate și pune sub semnul întrebării scorul declarat. Un scor de implementare 1 poate fi justificat dacă probele suplimentare confirmă că nu existăun proces standard operațional pentru detectarea și tratarea acestor eșecuri. Testul 4 și testele 5–11 ating încă cinci Măsuri cheie (DE.AE-03.1, ID.RA-08.1, PR.AA-03.2, PR.IR-01.2, PR.DS-11.1). Oricare dintre ele, sub 3, ar fi fost suficientă singură pentru un rezultat neconform.
Mai există o capcană. La nivelul Esențial, CyFun permite marcarea „N/A” pentru cel mult cinci controale, cu excepția Măsurilor-cheie și a controalelor aferente Aspectelor de management. Fiecare control exclus intră în calculul scorurilor cu valoarea 3. Dacă este folosit nejustificat pentru un control care în realitate nu atinge acest nivel, marcajul poate ridica artificial media. De aceea, fiecare „N/A” trebuie justificat în scris și evidențiat în declarația de aplicabilitate..
Ce face diferit un auditor care testează
- Cere probe, nu declarații (”management assertion”). Interviul arată ce cred oamenii că se întîmplă. Exportul din sistem arată ce s-a întîmplat. Un „implementat” are nevoie de cel puțin o probă generată de sistem.
- Verifică dacă lista e completă. Un test pe o listă incompletă iese mereu curat. Consola SIEM număra doar sursele care trimiteau ceva; sistemele ”tăcute” nu apăreau nicăieri. Datele le extrage auditorul sau asistă la extragere.
- Acoperă toată perioada. Un control care merge în ziua vizitei poate să nu fi mers în celelalte 300 de zile.
- Reface testul. Nu întreabă „primiți alerte dacă un sistem nu mai trimite jurnale?”. Oprește controlat o sursă de test și cronometrează alerta.
- Documentează fiecare scor. Proba, eșantionul, excepțiile, motivul scorului. Alt auditor, pe aceleași probe, trebuie să ajungă la aceeași concluzie.
Nici așa nu există garanții absolute. Eșantionul poate rata un caz izolat, iar ce merge azi poate ceda mîine. Dar este o asigurare rezonabilă care se poate verifica, ceea ce o lectură a procedurilor nu poate oferi. Un raport „conform” obținut fără teste nu protejează pe nimeni: nici conducerea, nici auditorul, nici pe cei care depind de serviciile organizației. Întrebarea nu este „aveți o procedură?”, ci „funcționează procedura și cît de bine?”.
În audit, a testa nu înseamnă să reproduci fiecare control pe fiecare sistem. Înseamnă să selectezi probe și proceduri adecvate riscului, astfel încât scorul atribuit să poată fi susținut. Nu numărul testelor sau paginilor raportului dă valoare auditului, ci capacitatea de a identifica deficiențe relevante și de a susține concluziile.
”A fi conform” # ”a rezista unui atac”.
