Best practice pentru audit de securitate

Nu știu câți dintre voi lucrează pe partea cu InfoSec, dar lansez întrebarea pentru că sunteți activi în alte domenii conexe IT-ului și poate aveți mai multă experiență decât mine.

Recent am terminat prima parte a unui proiect personal de pregătire pe partea de audit de securitate, etapă care a constat în realizarea unui audit de securitate pentru 24 de bloguri din Constanța. Documentul de analiză e încă în lucru și la următorul blog-meet aș vrea să prezint proiectul dar am o dilemă de ordin moral.

Cum e mai bine din punct de vedere etic: 1) să fac un rezumat al analizei (în genul unui „Executive Summary”, dacă știe cineva cum stă treaba cu analizele/rapoartele detaliate) și să prezint statisticile (de la situația cu HTTP vs. HTTPS până la cel mai sigur/vulnerabil blog) după care să prezint fiecărei părți interesate exclusiv analiza pentru blogul în cauză, sau 2) să prezint tot documentul detaliat, cu analiza pentru fiecare blog (în care se văd vulnerabilitățile și potențialele vulnerabilități)?

Eu unul aș merge pe prima variantă, să prezint o serie de statistici și să prezint analiza pentru fiecare blogăr în parte, exclusiv și la cerere.

Mulțam anticipat.

4 Likes

Din câte știam, etic este să trimiți întâi în privat bubele și, dacă nu se rezolvă, le faci publice.

2 Likes

Notifica “victimele” intai. Nu e obligatoriu sa le dai detalii exacte pentru ca teoretic ar trebui sa stie ce au de facut.
Da-le un termen rezonabil sa te contacteze pentru mai multe detalii sau sa rezolve situatia si abia apoi poti sa faci publice toate detaliile.
Cam asa se practica de obicei in domeniu in randul celor care sunt cu adevarat profesionisti si respecta minime reguli de etica profesionala.

2 Likes

Grație unor articole cicite recent, am observat cum se practică în mediul profesional, cu anunțat „victimele”, propus soluții, așteptat să le implementeze și pe urmă public disclosure. Cred că o să merg pe un timeline pe care să-l stabilesc și pe urmă să contactez oamenii să-i anunț ce și cum.

Un termen rezonabil pentru rezolvarea problemele ar fi 7-10 zile după ce-i anunț, după care o să public studiul.

Mulțam de răspunsuri, oameni.

1 Like

Ar fi o idee sa ii rogi sa te anunte daca au nevoie de mai mult timp (gen inca o saptamana) si de ce anume au nevoie de mai mult timp. Caz in care 7 zile extra nu cred ca ar fi chiar asa de mult. In cazul in care intre site si devs sunt intermediari, sau devs sunt in vacanta, ori ocupati cu altceva, cred ca ar merita o sansa in plus, atata timp cat motivul pare ok.

Sau sa te plateasca sa nu faci publice informatiile. Ar fi si asta o optiune. Pretul negociabil, dar poti da un exemplu cu site-uri de diferite marimi si cat ai cere/cerut/primit pentru site-urile respective (sa nu publici informatiile explicit despre site-ul respectiv).

La care din astea două crezi că se încadrează?

(1) Constrângerea unei persoane să dea, să facă, să nu facă sau să sufere ceva, în scopul de a dobândi în mod injust un folos nepatrimonial, pentru sine ori pentru altul, se pedepseşte cu închisoarea de la unu la 5 ani.
(2) Cu aceeaşi pedeapsă se sancţionează ameninţarea cu darea în vileag a unei fapte reale sau imaginare, compromiţătoare pentru persoana ameninţată ori pentru un membru de familie al acesteia, în scopul prevăzut în alin.

Detalii: Art. 207 Noul Cod Penal Şantajul Infracţiuni contra libertăţii persoanei | Noul Cod Penal actualizat 2023 - Legea 286/2009

4 Likes

La asta nu m-am gandit. Multumesc pentru corectare!

Unii la care m-am uitat recent, dar poti sa gasesti de la mai multe firme pe site.
https://hackerone.com/cloudflare

La ce vulnerabilități am găsit, cred că și 7-10 zile ar fi mult. Majoritatea sunt chestii de genul teme/plugin-uri outdated, conturi default și chestii de server setup (SSL și encryption-related included, nu 0-Day-uri), rezolvabile în scurt timp de cine știe ce și cum să facă. Cel puțin primele, cu temele/plugin-urile, cred că și un utilizator care abia pune mâna pe WP e în stare să apese pe Update, să fim serioși. Dar am zis să fie 7-10 zile ca să se încadreze în timeline-ul pe care l-am stabilit, pentru că pe 15 martie vreau să public „studiul”.

Cât despre:

How about NO? Nu de alta da’ am un servici stabil și care-mi place foarte mult, țin foarte mult la libertatea mea și n-aș vrea să fac nunta în camera conjugală de la vreun centru de detenție. Se încadrează și la șantaj/amenințare, așa că nu, mersi.

Mulțam de link, nu știam că umblă și Cloudflare cu bug-bounty pentru infrastructura proprie. E de rumegat și vânat pentru cine are timp.

1 Like

In astfel de cazuri, da. Dar in cms-uri non-standard (gen Gogu’ isi face un site cu php si e vulnerabil la sqlinjection).

Am văzut și așa ceva la unul dintre site-uri, nu mai țin minte dacă era blog sau ceva publicație. Parol, e combinație de ambele, gen publicație de presă (lol, jurnalizm) făcută pe WP.

//LE:it is likely to contain security vulnerabilities” my ass, more like „it is more than sure to contain security vulnerabilities” sau direct „it contains security vulnerabilities”.

1 Like

Poate la momentul scrierii acelui text nu continea nici o vulnerabilitate cunoscuta. Sau poate update-urile de dupa scrierea textului nu au introdus alte vulnerabilitati. Deasta e doar likely sa contina vulnerabilitati. Cum se zice, exceptia confirma regula.