De ce lipsa incidentelor nu înseamnă că infrastructura este sigură

„Nu am avut niciodată un incident de securitate.”

Este un răspuns pe care îl aud frecvent atunci când discut despre securitate cibernetică.

Lipsa incidentelor nu înseamnă automat că o companie este protejată. De cele mai multe ori, înseamnă doar că vulnerabilitățile existente nu au fost încă exploatate.

Pentru a ilustra acest lucru, îți propun un studiu de caz bazat pe un scenariu de audit de securitate cibernetică pentru o companie fictivă, furnizor de servicii cloud pentru sectorul medical și încadrată ca entitate importantă în contextul NIS2.

Compania procesează fișe medicale, rezultate de analize și date personale ale pacienților. O infrastructură activă, cu clienți și date sensibile în mișcare permanentă.

Prima neconformitate: aplicația publică comunica direct cu infrastructura internă

În timpul auditului a fost analizată arhitectura de securitate.

Portalul utilizat de pacienți pentru accesarea rezultatelor medicale era publicat direct în Internet și comunica direct cu infrastructura internă.

Diagrama de arhitectură pusă la dispoziție confirma exact acest lucru. Verificarea configurației firewall-ului a confirmat-o din nou. Analiza fluxurilor de comunicație, a treia oară.

Nu existau mecanisme adecvate de segmentare și izolare între zona expusă Internetului și sistemele care procesau date medicale.

În plus, nu au fost identificate controale compensatorii care să reducă riscul acestei expuneri.

De ce firewall-ul nu era suficient

Problema este că un firewall nu înlocuiește o arhitectură de securitate bine proiectată.

Dacă o aplicație expusă public este compromisă, atacatorul poate încerca să avanseze către infrastructura internă. Segmentarea rețelei și izolarea serviciilor publice reduc semnificativ această posibilitate.

Din acest motiv, neconformitatea a fost încadrată ca majoră.

De ce absența unui incident nu înseamnă absența riscului

Un atacator care reușește să compromită portalul web ajunge direct în rețeaua internă.

Fără niciun obstacol suplimentar.

Fără niciun mecanism care să detecteze că ceva nu este în regulă.

Fără niciun strat care să încetinească sau să blocheze accesul la bazele de date cu fișe medicale.

Faptul că nu s-a întâmplat până acum nu este o dovadă că arhitectura este sigură.

Poate însemna că nimeni nu a încercat suficient de insistent.

Sau că cineva a încercat, dar compania nu a știut.

Ambele variante sunt îngrijorătoare.

A doua neconformitate: date medicale stocate fără criptare

A doua constatare a vizat configurarea infrastructurii.

Bazele de date care conțineau informațiile medicale ale pacienților erau stocate în format necriptat. Text simplu, lizibil direct, fără nicio cheie criptografică necesară.

Auditul a arătat că problema nu se limita la bazele de date.

Nici copiile de rezervă nu erau criptate, iar comunicațiile dintre aplicație și baza de date nu utilizau TLS.

Practic, datele erau expuse atât în stocare, cât și în tranzit.

De ce controlul accesului nu înlocuiește criptarea

Mulți administratori IT consideră că accesul restricționat și soluțiile antivirus sunt suficiente.

Nu sunt.

Dacă un atacator reușește să depășească măsurile perimetrale sau dacă un suport de stocare ajunge în posesia unei persoane neautorizate, datele necriptate pot fi citite imediat.

Criptarea nu împiedică accesul neautorizat, dar împiedică utilizarea informațiilor obținute.

Această neconformitate a fost clasificată ca majoră, deoarece afecta direct confidențialitatea datelor medicale.

Ce spune legea

OUG nr. 155/2024, care transpune Directiva NIS2 în România, impune explicit politici și proceduri privind utilizarea criptografiei, ca cerință minimă obligatorie pentru entitățile importante.

Impune, de asemenea, măsuri privind securitatea arhitecturii rețelelor și sistemelor informatice.

Ambele cerințe erau încălcate.

Ambele neconformități au fost clasificate ca majore.

Pentru că efectul asupra datelor era direct și activ în momentul auditului, nu ipotetic.

Ce rămâne după un audit

Cele două neconformități au un element comun.

Compania avea deja măsuri de securitate implementate:

• firewall;
• control al accesului;
• soluții antivirus.

Auditul a identificat, totuși, două deficiențe majore.

Acesta este rolul unui audit de securitate cibernetică: să le identifice înainte ca ele să devină incidente.

Un audit nu verifică doar dacă există tehnologii implementate.

Verifică dacă arhitectura, configurațiile și măsurile de securitate reduc efectiv riscurile la un nivel acceptabil.

Lipsa incidentelor nu este o dovadă a securității

Firewall-ul și antivirusul sunt necesare.

Nu sunt suficiente.

Diferența dintre o infrastructură aparent sigură și una rezilientă este, de multe ori, vizibilă doar în timpul unui audit.

Nu este un caz izolat: creșterea atacurilor raportată în 2025 arată că tot mai multe organizații descoperă acest gol abia în timpul unui audit.

Dacă mâine ai afla că cineva a avut acces la rețeaua ta timp de trei luni, ce ar fi putut citi?