Pentest anual: ce sa ceri in SOW si cum interpretezi raportul
Pentestul anual a devenit o cerinta de baza in contractele B2B si in standardele ISO 27001, dar calitatea livrabilului poate varia enorm intre furnizori. Un raport prost este o falsa siguranta, in timp ce un pentest serios poate identifica vulnerabilitati critice cu impact direct pe disponibilitate, integritate si reputatie. Diferenta nu sta intr-un brand celebru, ci in modul in care SOW-ul este formulat si in capacitatea ta de a citi raportul fara confuzii.
Echipa Blackbone livreaza pentest pentru clienti din fintech, e-commerce si SaaS, iar majoritatea provocarilor incep inainte de prima zi de testare: scope ambiguu, asteptari nealiniate sau credinta ca un scan automat este suficient. Articolul de fata strange recomandarile pe care le facem cumparatorilor: ce cerinte tehnice trebuie sa apara in contract, ce metodologii sunt standard si cum se citeste corect un raport ca sa generezi remedii prioritizate cu impact real.
Vei gasi modele de scope, explicatii pentru OWASP WSTG si PTES, ghid de citire CVSS, structura unei matrice de prioritizare si reguli pentru retesting. La final, clarificam ce nu este pentest, ca sa nu confunzi un livrabil cu altul. Daca pregatesti achizitia pentru anul urmator, materialul iti ofera o lista de verificare directa.
01Scope-ul SOW: cea mai importanta sectiune
Un SOW solid incepe cu scope-ul: ce active sunt in test, ce metode sunt permise si ce ferestre de timp sunt agreate. Lipsa preciziei aduce frustrare si bug-uri ratate. Daca aplicatia ta principala depinde de un API extern, un scope care lasa API-ul afara nu spune nimic despre riscul real. Daca lasi mediile de staging in test fara aprobare clara, risti incidente neprevazute care opresc echipa de produs.
Recomandam impartirea scope-ului in trei zone: in-scope cu list explicita de domenii, IP-uri si conturi de test, out-of-scope cu motivatie scurta si rules of engagement cu detalii precum interzicerea DoS, restrictii pe testarea endpoint-urilor de productie sau cerinte pentru notificarea preventiva. Documentul include si breakglass-ul: cum oprim testul daca apare un incident colateral si cine este punctul de contact pe ambele parti.
Echipa Blackbone foloseste un template SOW care contureaza scope-ul intr-un workshop dedicat de o ora. Acest pas elimina ambiguitatile si construieste increderea reciproca. Pentru organizatiile cu mai multe produse, recomandam ca scope-ul sa fie revizuit anual: ce era valabil acum doi ani este probabil incomplet astazi, iar perimetrul de atac evolueaza odata cu produsul.
- →Scope-ul in-scope listeaza explicit domenii, IP-uri si conturi de test.
- →Out-of-scope are motivatie scurta si nu lasa zone gri.
- →Rules of engagement clarifica DoS, testare in productie si notificari.
- →Breakglass-ul defineste cum oprim testul cand apare un incident colateral.
02Metodologii: OWASP WSTG, PTES si ce inseamna pentru tine
OWASP Web Security Testing Guide este standardul de referinta pentru pentest pe aplicatii web. Acopera de la enumerarea informatiilor pana la teste pe logica de business si pe configuratii. Cerand explicit OWASP WSTG in SOW, ai garantia ca furnizorul foloseste o lista cunoscuta de verificari, iar gap-urile pot fi argumentate cu trasabilitate. PTES, Penetration Testing Execution Standard, este complementar si descrie procesul end-to-end, de la pre-engagement la raportare.
In practica, un pentest matur combina cele doua: WSTG pentru continutul tehnic, PTES pentru procesul de lucru. Pentru API-uri, adaugam OWASP API Security Top 10, iar pentru aplicatii mobile, OWASP MASVS si MSTG. Pentru infrastructura, NIST SP 800-115 ramane o referinta utila. Solicitand explicit aceste cadre, indepartezi furnizorii care livreaza scanari automate sub eticheta de pentest.
Echipa Blackbone documenteaza in raport ce capitole din WSTG si PTES au fost acoperite si unde nu, cu argumente. Un raport care nu explica ce nu a fost testat nu poate fi un punct de plecare credibil pentru remedii. Dincolo de metodologii, conteaza experienta echipei: cati ani de testare ofensiva, ce certificari OSCP sau CRT detin testerii si daca au exemple anonimizate de raport in prealabil.
OWASP WSTG iti spune ce sa testezi, PTES iti spune cum sa conduci procesul. Cere ambele in SOW si vei selecta din start un furnizor care vorbeste limba ta tehnica.
03Cum citesti CVSS si de ce nu este suficient
Scorul CVSS, in versiunea 3.1 sau 4.0, ofera o estimare standardizata a severitatii unei vulnerabilitati. Vectorul descompune scorul in dimensiuni precum vector de atac, complexitate, privilegii necesare si impact pe confidentialitate, integritate si disponibilitate. Un scor de 9.8 atrage atentia rapid, dar contextul tau poate transforma o vulnerabilitate de 6.5 intr-una mult mai urgenta decat scorul brut.
Pentru prioritizare, recomandam o matrice care combina scorul CVSS cu factori de business: expunere publica, sensibilitatea datelor afectate, costul exploatarii si dificultatea remediilor. O vulnerabilitate critica intr-un microservice nepublicat poate astepta dupa una medie expusa pe internet. Aceasta matrice este construita impreuna de echipa Blackbone si echipa clientului, ca rezultatul sa reflecte realitatea operationala.
Folosim si CISA Known Exploited Vulnerabilities ca filtru suplimentar: daca o vulnerabilitate este pe lista KEV si apare in scope, intra automat in prioritate maxima. Dincolo de scor, raportul trebuie sa contina pasi de reproducere, capturi anonimizate si exemple de payload, ca echipa ta sa poata valida remediul. Un raport fara repro este greu de actionat si genereaza tensiuni intre security si dezvoltare.
- →Vectorul CVSS descompune severitatea pe dimensiuni controlabile.
- →Prioritizarea adauga context: expunere publica, sensibilitate, cost de exploatare.
- →CISA KEV ridica imediat prioritatea vulnerabilitatilor active.
- →Raportul include repro pas cu pas si payload-uri, nu doar descrieri abstracte.
04Prioritizare si plan de remediere
Dupa primirea raportului, urmeaza partea cea mai importanta: planul de remediere. Un raport de 100 de pagini fara o foaie de drum este o investitie semipierduta. Recomandam organizarea remediilor in trei valuri: critical fixes in primele doua saptamani, high si selected medium in primele trei luni si restul in cicluri planificate. Fiecare remediu primeste owner, deadline si criteriu de acceptanta.
Echipa Blackbone livreaza un workshop de prioritizare imediat dupa raport, in care parcurgem fiecare finding cu liderii tehnici si de produs. Iesim cu o lista actionabila, integrata in board-ul de development. Pentru clientii cu Datadog sau alt SIEM, atasam si reguli de detectie pentru pattern-urile observate, ca sa nu ramana doar la corectarea cauzei, ci si la observarea unor incercari similare in viitor.
Un aspect adesea neglijat: comunicarea cu auditorii ISO 27001 sau cu clientii B2B. Plan de remediere clar, cu dovezi de progres, este unul dintre cele mai puternice argumente in fata oricarui due diligence de securitate. Tinem un registru viu cu status, evidence si retesting, accesibil partilor relevante prin canale securizate, nu prin foldere SharePoint nemonitorizate.
Nu accepta planuri de remediere fara owner si fara criteriu de acceptanta. Findings fara responsabil dispar in lunile aglomerate si reapar in urmatorul audit cu acelasi scor.
05Retesting: cand, cum si cu ce buget
Retesting-ul este partea cu cel mai bun ROI. Verifica daca remediile aplicate functioneaza si daca nu au introdus regresii. Un SOW corect include explicit retesting in domeniu, cu un calendar realist: cinci, sapte sau zece zile lucratoare alocate la o luna dupa raportul initial. Furnizorii care nu includ retesting in oferta initiala sunt un semnal de alarma.
Doua reguli simple ghideaza retesting-ul: retestezi fiecare critical si high cu pas cu pas din raportul initial si confirmi remedierea prin reproducere completa, nu doar prin discutie cu echipa. Pentru medium si low, retesting-ul este partial, dar tinut intr-un registru pentru ciclul anual urmator. Daca un remediu este partial, ramane in lista urmatorului pentest, fara sa fie retras din raport.
In firma de IT Blackbone, retesting-ul este inclus in pachetul anual standard, iar pentru remediile complexe oferim suport tehnic in timpul implementarii, ca echipa interna a clientului sa nu blocheze. Un proces matur transforma pentestul dintr-un eveniment punctual intr-un program continuu de imbunatatire, cu trasabilitate pe ani de zile.
- →Retesting-ul valideaza remediile si detecteaza regresiile.
- →SOW include explicit retesting in zile lucratoare si la o data prevazuta.
- →Critical si high se retesteaza prin reproducere completa.
- →Remediile partiale raman in registrul pentru ciclul urmator.
06Ce nu este pentest si cum eviti confuzia
Multi clienti cumpara, fara sa stie, scanari automate care poarta titlul de pentest. Un scan de vulnerabilitati cu Nessus, Qualys sau OpenVAS este util, dar nu este pentest. Lipseste componenta umana: testarea logicii de business, chaining-ul de vulnerabilitati, exploatarea creativa care construieste un atac realist. Cere in SOW dovada de testare manuala, exemple de logic flaws gasite in proiecte anterioare si timpi de executie compatibili cu munca umana.
Pentestul nu este nici red teaming, desi se confunda adesea. Red teaming-ul simuleaza un atacator real cu obiective de business, scope larg, fara avertizare in echipele blue team. Costul si durata sunt mai mari, iar utilitatea apare doar la organizatii cu echipe de detectie deja mature. Confuzia este costisitoare: cumperi red teaming si primesti pentest, sau invers, si ramai cu asteptari nealiniate.
Nu este nici audit de cod, desi unele pentest-uri includ revizuiri tintite. Auditul de cod cere acces la codul sursa si o metodologie SAST plus revizuire manuala. Echipa Blackbone clarifica de la SOW ce livreaza: pentest pe aplicatie, audit de cod, evaluare de configuratie sau combinatii ale acestora. O comunicare directa elimina surprizele la livrare si construieste relatii pe termen lung.
Concluzii
Un pentest anual reusit incepe cu un SOW bine scris, continua cu o metodologie clara si se incheie cu un plan de remediere actionabil. Investitia in claritatea contractuala produce livrabile care imbunatatesc concret postura de securitate, nu doar bifeaza casute de conformitate. Cand toate piesele sunt aliniate, raportul devine ghidul de evolutie pentru anul urmator, nu un document arhivat.
Echipa Blackbone livreaza pentest aliniat OWASP si PTES, cu workshop de scope, raport executiv si tehnic, prioritizare a remediilor si retesting inclus. Daca pregatesti achizitia pentestului pentru ciclul urmator, programeaza o sesiune de o ora si vei pleca cu un draft SOW si o estimare clara, fara timp pierdut in incercari de a defini cerinte vagi cu mai multi furnizori in paralel.
Pregateste-ti pentestul anual cu un SOW solid
Echipa Blackbone te ajuta sa formulezi scope-ul, metodologia si criteriile de acceptanta, plus livrarea raportului si retesting-ul, intr-un pachet predictibil.
Discută cu Blackbone