Cum pregatesti un test de penetrare si ce faci cu raportul
Scopul se decide inainte, nu in prima zi de testare. Cum alegi intre staging si productie, de ce ai nevoie de doua conturi per rol si ce transforma un raport intr-o dovada de conformitate.
Pregatirea decide cat valoreaza testul
Un test de penetrare are un buget de timp fix. Fiecare ora pierduta pe acces care nu functioneaza, conturi care nu au fost create sau un mediu care cade este o ora in care nimeni nu iti cauta vulnerabilitati.
Cea mai frecventa risipa nu este tehnica. Este ca scopul se negociaza in prima zi de testare, in loc sa fie decis inainte.
Scopul: ce intra si ce nu
Scrie scopul ca lista de adrese, nu ca descriere. "Aplicatia principala" inseamna lucruri diferite pentru tine si pentru tester.
Pentru fiecare sistem din scop noteaza: URL sau interval IP, mediul (productie sau staging), si ce roluri de utilizator exista.
Decide explicit si ce ramane in afara. Integrarile terte sunt cazul obisnuit: nu ai dreptul sa autorizezi testarea unui sistem care nu este al tau, iar furnizorul acela poate avea propria politica. Daca procesatorul de plati este in afara scopului, spune asta in contract si noteaza-l in dosarul de conformitate, ca sa nu arate mai tarziu ca o omisiune.
Mediul: staging daca seamana, productie daca nu
Intrebarea nu este care este mai sigur, ci care produce un rezultat adevarat.
Testarea pe staging este alegerea implicita rezonabila, cu o conditie: sa fie o copie fidela a productiei. Un staging cu date golite, cu jumatate din integrari dezactivate si cu alt nivel de configurare produce un raport despre un sistem care nu exista.
Testarea pe productie da raspunsul real, dar cere reguli scrise: ferestre de timp agreate, fara denial of service, un contact de escaladare disponibil pe durata testarii, si backup verificat inainte de start.
Daca alegi staging, verifica explicit ce difera de productie si consemneaza diferentele. Acelea sunt zonele despre care testul nu spune nimic.
Conturile: pregatite inainte, nu in prima zi
Pentru un test autentificat ai nevoie de cate doua conturi pentru fiecare rol, nu unul. Doua conturi de acelasi tip sunt singurul mod de a testa daca utilizatorul A poate vedea datele utilizatorului B, si acesta este cel mai des intalnit defect real in aplicatiile de business.
Pregateste-le cu cel putin o zi inainte, verifica-le tu, si trimite-le pe un canal pe care il folosesti si pentru alte secrete. Include: date de autentificare, orice pas de MFA si cum se ocoleste pentru conturile de test, si ce date sunt sigure de modificat.
Daca aplicatia are inregistrare deschisa, spune daca testerul poate crea conturi singur.
Ce inseamna "am remediat"
Aici se pierde cea mai mare parte din valoarea testarii. Raportul ajunge, echipa repara ce e usor, si dosarul ramane cu un document care listeaza probleme fara nicio urmare.
Pentru fiecare constatare ai nevoie de o decizie scrisa, si sunt doar trei posibile:
Remediat. Schimbarea este in productie, si testerul a confirmat prin retest. Fara retest nu ai remediere, ai o intentie.
Acceptat ca risc. Decizie legitima. Cere un motiv, un proprietar cu autoritate sa o ia, si o data de reevaluare. O constatare acceptata si documentata este in regula la audit. Una ignorata in tacere nu este.
Compensat. Cauza nu s-a schimbat, dar alt control reduce riscul. Noteaza care este acel control si cine verifica ca ramane activ.
Constatarile care nu intra in niciuna dintre cele trei sunt cele care apar din nou la testul de anul viitor, cu aceeasi severitate.
Ce pui in dosarul de conformitate
Nu raportul singur. Pentru auditorul acreditat DNSC:
- scopul convenit, datat, semnat de ambele parti
- raportul cu severitati si pasi de reproducere
- tabelul de decizii, cu una din cele trei de mai sus pentru fiecare constatare
- dovada de retest pentru tot ce este marcat remediat
- data urmatoarei testari planificate
Ultimul punct este cel care arata ca testarea este un proces si nu un eveniment, ceea ce este exact ce cere formularea din OUG 155/2024 despre evaluarea periodica a eficacitatii masurilor.
Pe scurt
Scopul se decide inainte, nu in prima zi. Mediul se alege dupa cat de fidel este, nu dupa cat de sigur pare. Conturile se pregatesc in pereche. Iar un raport fara tabel de decizii si fara retest nu este dovada de conformitate, este o lista de probleme pe care le stiai.
Daca vrei testarea facuta de o parte independenta, BetterQA lucreaza din Cluj-Napoca si este certificata ISO 27001, ISO 9001, ISO 14001 si ISO 13485.
