Audit de securitate cibernetică: ce verifică, cât durează, cât costă

„Avem antivirus și firewall, deci suntem în regulă." E fraza pe care o auzim cel mai des înainte de un audit — și aproape întotdeauna se dovedește falsă. Un audit de securitate cibernetică nu confirmă că ești protejat; îți arată exact pe unde ar intra un atacator înainte să o facă el.

Dar termenul „audit de securitate" e aruncat în piață cu sensuri foarte diferite. Unii vând un simplu scan automat de 30 de minute drept „audit complet". Alții livrează 200 de pagini de raport pe care nimeni nu le citește. În acest ghid îți explic, ca inginer care a condus zeci de astfel de proiecte pentru IMM-uri din România și UK, ce verifică un audit serios, cât durează realist, cât costă și — cel mai important — ce primești la final.

1. Ce este, de fapt, un audit de securitate cibernetică

Un audit de securitate este o evaluare structurată a posturii tale de securitate — adică a tuturor punctelor prin care confidențialitatea, integritatea sau disponibilitatea datelor tale ar putea fi compromise. Spre deosebire de un control IT obișnuit, care verifică „funcționează totul?", auditul răspunde la o întrebare incomodă: „cât de greu i-ar fi cuiva rău intenționat să ne facă rău?"

Un audit complet acoperă trei planuri pe care le tratăm întotdeauna împreună, pentru că un atacator nu se oprește la granița dintre ele:

• Planul tehnic — servere, rețea, aplicații web, configurări cloud, stații de lucru, dispozitive mobile, conturi și permisiuni.
• Planul procedural — politici de parole, gestionarea backup-urilor, proceduri de onboarding/offboarding, plan de răspuns la incidente.
• Planul uman — gradul în care angajații pot fi păcăliți prin phishing, vishing sau pretexting. Statistic, factorul uman rămâne cea mai exploatată „vulnerabilitate" din orice organizație.

Un audit care se uită doar la tehnic și ignoră oamenii și procesele îți dă o falsă liniște. De aceea, în pachetele noastre de securitate cibernetică tratăm cele trei planuri ca un tot — pentru că în realitate breșele apar exact la îmbinarea dintre ele (un cont fără MFA + un angajat care dă click + un backup netestat).

2. Pentest vs scanare de vulnerabilități — nu sunt același lucru

Aceasta este cea mai importantă distincție din tot ghidul, pentru că aici se pierd cei mai mulți bani și se nasc cele mai multe iluzii. Mulți furnizori vând o scanare automată la prețul unui audit manual.

Scanarea de vulnerabilități (vulnerability scan)

Este automată. Un tool precum Nessus, OpenVAS sau Qualys parcurge sistemele tale și le compară cu o bază de date de vulnerabilități cunoscute (CVE-uri). E rapidă, ieftină, repetabilă — și ar trebui rulată periodic. Dezavantajul: produce fals-pozitive, nu înțelege contextul de business și nu poate înlănțui mai multe probleme mici într-un atac real.

Testul de penetrare (penetration test / pentest)

Este manual și condus de un specialist care gândește ca un atacator. Pornește de la rezultatele scanării, dar merge mai departe: exploatează efectiv vulnerabilitățile, le combină, escaladează privilegii și demonstrează impactul real („am ajuns din formularul de contact până la baza de date cu clienți"). Un pentest validează ce e exploatabil cu adevărat și elimină zgomotul.

Black-box, grey-box sau white-box?

Un pentest se mai diferențiază și după câtă informație primește testerul:

• Black-box — testerul nu știe nimic, simulează un atacator extern complet anonim. Realist, dar consumă timp pe recunoaștere.
• Grey-box — testerul are credențiale de utilizator obișnuit. Cel mai bun raport cost/acoperire pentru majoritatea IMM-urilor.
• White-box — acces complet la cod și arhitectură. Cea mai profundă acoperire, ideală pentru aplicații critice.

3. Etapele unui audit: cum decurge concret

Un audit serios nu începe cu un tool, ci cu o discuție. Iată cum decurge un proiect tipic la noi, pas cu pas:

1. Scoping și definirea regulilor — stabilim ce intră în test (IP-uri, domenii, aplicații), ce e interzis, fereastra de timp și persoanele de contact. Aici semnăm și acordul scris care ne dă mandatul legal de a testa — fără el, testarea ar fi ilegală.
2. Recunoaștere (reconnaissance) — cartografiem suprafața de atac: subdomenii, porturi deschise, servicii expuse, adrese de email publice, tehnologii folosite. Mulți clienți descoperă aici servere uitate, expuse la internet, despre care nu mai știau.
3. Scanare și enumerare — scanare automată de vulnerabilități plus enumerarea detaliată a serviciilor identificate.
4. Exploatare — încercăm efectiv să exploatăm ce am găsit, controlat și fără să afectăm producția. Aici separăm teoria de practică.
5. Post-exploatare și escaladare — odată intrați, vedem cât de departe putem ajunge: mișcare laterală, escaladare de privilegii, acces la date sensibile.
6. Raportare — documentăm tot, prioritizăm pe risc real și scriem recomandări concrete, nu generice.
7. Retestare — după ce remediezi, revenim și verificăm că problemele chiar au fost închise. O vulnerabilitate „rezolvată" dar netestată e încă o vulnerabilitate.

4. Vulnerabilitățile pe care le găsim cel mai des

După zeci de audituri la IMM-uri, tiparele se repetă supărător de des. Nu sunt vulnerabilități exotice, ci scăpări de igienă elementară. Iată „suspecții obișnuiți":

La nivel de conturi și acces

• Lipsa autentificării cu doi factori (MFA) pe conturi critice — email, panou de administrare, VPN, cloud. De departe cea mai frecventă și mai periculoasă scăpare.
• Parole reutilizate și slabe, deseori regăsite în breșe publice (credential stuffing).
• Conturi orfane — angajați plecați care încă au acces, useri de test cu parolă implicită.
• Permisiuni excesive — toată lumea e „admin", contrar principiului privilegiului minim.

La nivel de aplicații și infrastructură

• Software neactualizat — CMS-uri, plugin-uri, librării și servere cu patch-uri lipsă, vulnerabile la exploit-uri publice.
• Panouri de administrare expuse public (/wp-admin, phpMyAdmin, RDP deschis la internet).
• Injecții și XSS în aplicații web scrise fără validare corectă a input-ului.
• Configurări cloud greșite — bucket-uri S3 publice, grupuri de securitate prea permisive, chei API în repository-uri.
• Lipsa segmentării rețelei — odată intrat într-o stație, atacatorul ajunge oriunde.

La nivel de procese și oameni

• Backup-uri netestate sau stocate pe aceeași rețea (inutile în caz de ransomware).
• Lipsa unui plan de răspuns la incidente — nimeni nu știe ce face în primele 30 de minute ale unei breșe.
• Susceptibilitate la phishing — un procent semnificativ de angajați dă click pe linkuri simulate.

Vestea bună: marea majoritate a acestor probleme se remediază cu efort moderat odată ce sunt vizibile. Un audit IT bine făcut, de tipul celui inclus în serviciul nostru de audit IT și securitate, exact asta face — scoate la suprafață ce nu se vede.

5. Ce primești în raportul final

Raportul este produsul real al auditului. Un raport bun e citibil atât de directorul general, cât și de inginerul care va face remedierea. Iată ce trebuie să conțină obligatoriu:

• Rezumat executiv (executive summary) — o pagină, fără jargon, care răspunde la „cât de expuși suntem și ce riscăm". Pentru board și management.
• Lista vulnerabilităților prioritizate — fiecare cu un scor de severitate (de regulă pe scala CVSS: Critică / Înaltă / Medie / Scăzută), nu o listă plată.
• Descriere tehnică și dovadă (proof of concept) — exact ce am găsit, cum se reproduce, cu capturi de ecran. Fără asta, raportul nu e verificabil.
• Impactul de business — ce s-ar întâmpla concret dacă vulnerabilitatea ar fi exploatată (scurgere de date clienți, oprire producție, amendă GDPR).
• Recomandări de remediere concrete — pași acționabili, nu „îmbunătățiți securitatea". Idealul: pentru fiecare problemă, soluția exactă.
• Plan de remediere prioritizat — ce rezolvi în primele 48 de ore, ce în prima lună, ce pe termen lung.

6. Cât durează și de ce depinde costul

Întrebarea pe care toți o pun prima. Răspunsul sincer: depinde de scop, și orice furnizor care îți dă un preț fix înainte de scoping fie supraevaluează ca să fie acoperit, fie livrează superficial. Durata și costul sunt în primul rând o funcție a suprafeței de atac.

Factorii care mută acul:

• Dimensiunea suprafeței — câte IP-uri, aplicații, domenii și conturi intră în scop.
• Tipul de test — o scanare automată ia ore; un pentest manual grey-box pe o aplicație web ia, de regulă, câteva zile până la o săptămână sau mai mult.
• Adâncimea — black-box, grey-box sau white-box.
• Cerințe de conformitate — un audit pentru certificare (ISO 27001, PCI DSS) are cerințe de documentare mai stricte.
• Retestarea — inclusă sau facturată separat.

Ca ordin de mărime orientativ: o scanare de vulnerabilități pentru un IMM mic este o investiție modestă și se poate rula recurent; un pentest manual pe o aplicație sau o infrastructură reprezintă o investiție mai consistentă, justificată de timpul de specialist implicat. Pentru o estimare reală pentru cazul tău, consultă pagina de prețuri sau cere o ofertă pe baza scopului concret — e singurul mod onest de a da un număr.

7. Când ai nevoie de un audit (și cât de des)

Nu există un răspuns unic, dar există momente clare în care un audit nu mai e opțional:

• Anual, ca igienă de bază, pentru orice firmă care procesează date de clienți.
• Înainte sau după o schimbare majoră — lansare de aplicație nouă, migrare în cloud, fuziune, deschidere de birou.
• La cerere contractuală — tot mai mulți clienți mari și parteneri UK cer dovada unui audit recent înainte să semneze.
• Pentru conformitate — GDPR, ISO 27001, PCI DSS, Cyber Essentials (UK) presupun evaluări periodice.
• După un incident — pentru a înțelege cum s-a întâmplat și a închide drumul de intrare.

Regula practică pe care o dăm clienților: tratează securitatea ca pe sănătatea dentară. Nu aștepți durerea ca să mergi la control — faci verificări periodice, pentru că o problemă prinsă din timp costă infinit mai puțin decât una ajunsă urgență.

Indiferent de mărimea firmei, primul pas e același: un scoping onest, urmat de un audit care îți arată realitatea, nu o iluzie liniștitoare. De acolo, prioritizezi și remediezi — în ordinea riscului, nu a panicii.