Penetracijsko testiranje za SOC 2: odaberite test koji informira sigurnost

Penetracijski test pruža dokaze o iskoristivim slabostima u definiranom sustavu. Njegova vrijednost ovisi o tome što testeri ispituju, kako to istražuju i što inženjerski tim radi s nalazima. Izvješće koje izostavlja važne granice povjerenja proizvoda može zadovoljiti interni rok, a pritom vam malo reći o sigurnosti.

Za CTO-a korisno pitanje nije samo je li test proveden. Pitanje je preispituje li angažman kontrole koje štite podatke klijenata i daje li nalaze koje tim može reproducirati, ispraviti i provjeriti.

Što SOC 2 zahtijeva, a što ne

SOC 2 je atestacijsko izvješće, a ne certifikacija. Njegovi su kriteriji utemeljeni na načelima; ne nameću jedan univerzalni zahtjev za penetracijskim testiranjem ni godišnju učestalost za svaku organizaciju. Rizik, kontrole koje opisujete, očekivanja revizora i ugovori s klijentima određuju koje je testiranje primjereno.

Prije naručivanja angažmana razgovarajte s revizorom o cilju i očekivanim dokazima. Ako vaša dokumentirana kontrola obećava određenu učestalost ili opseg testiranja, planirajte dokazati tu obvezu.

Jamstvo klijentima zasebno je pitanje. Kupac može zahtijevati neovisni test aplikacije čak i kada ga vaš revizijski pristup ne propisuje. Ta očekivanja utvrdite rano, ali ne dopustite da kontrolni popis nabave zamijeni tehničko određivanje opsega. Ni SOC 2 izvješće ni penetracijski test ne dokazuju da sustav nema ranjivosti.

Odredite opseg površine napada, a ne samo web-stranice

Počnite s arhitekturom, tokovima osjetljivih podataka i granicama povjerenja. OWASP-ove smjernice za modeliranje prijetnji nude korisnu osnovu za utvrđivanje onoga što bi moglo poći po zlu i gdje bi se testiranje trebalo usredotočiti.

Za SaaS proizvod s više zakupaca testiranje samo javne početne stranice ostavlja važne granice aplikacije neispitanima. Pružatelju dajte inventar koji uključuje API-je, pozadinsku obradu, administrativne alate i relevantnu infrastrukturu, a ne samo popis domena.

Iznimke i ograničenja navedite izričito. Netestirani mobilni klijent, nedostupna uloga ili nepristupačno okruženje moraju ostati vidljivi u završnom izvješću. Opseg također treba razlikovati sustave u vašem vlasništvu od usluga trećih strana za koje ne možete ovlastiti testere da ih napadaju.

Odaberite metodu koja odgovara na vaša pitanja

Automatizirano skeniranje utvrđuje moguće slabosti i podupire redovitu higijenu. Penetracijski test dodaje stručno istraživanje iskoristivosti i smislenih putova napada unutar odobrenog opsega. Alati su korisni; izvoz iz skenera preimenovan u penetracijski test nije jednakovrijedan takvom istraživanju.

Testiranje crne kutije (black-box) počinje s ograničenim znanjem o sustavu. Testiranje sive kutije (gray-box) pruža odabrane informacije ili pristup, često uključujući račune. Testiranje bijele kutije (white-box) pruža dublji uvid, potencijalno uključujući izvorni kod i arhitekturu. Ti pristupi odgovaraju na različita pitanja, a ne čine jednostavnu ljestvicu kvalitete.

Za testiranje autorizacije u aplikaciji računi u nekoliko uloga i zakupaca mogu istraživanje učiniti djelotvornijim. Samo testiranje vanjske infrastrukture ne može utvrditi mogu li autentificirani korisnici prijeći granice zakupaca.

Procijenite pružatelja i rezultate

Pitajte tko će obavljati posao i jesu li testirali usporedive arhitekture. Relevantne kvalifikacije podupiru dubinsku analizu, ali same vjerodajnice ne dokazuju kompetenciju specifičnu za aplikaciju. Zatražite anonimizirano ogledno izvješće i razgovarajte o tome kako tim istražuje poslovnu logiku, a ne samo poznate softverske ranjivosti.

Prije potpisivanja razjasnite:

• Koji su sustavi, uloge i putovi napada obuhvaćeni te kako je raspodijeljen napor.
• Koje ručno istraživanje nadopunjuje automatizirane alate.
• Kako se hitni nalazi priopćuju prije završnog izvješća.
• Uključuju li nalazi reproducibilne dokaze, pogođene komponente, učinak i smjernice za otklanjanje.
• Je li uključeno ponovno testiranje, u kojem vremenskom okviru i što se događa ako ispravci stignu kasnije.
• Kako se izvješća, vjerodajnice i prikupljeni podaci štite i naposljetku brišu.

Ponude uspoređujte prema pokrivenosti i rezultatima, a ne samo prema cijeni. Niža ponuda može predstavljati uži angažman, a ne jednakovrijedan posao obavljen učinkovitije.

Utvrdite pravila sigurnog izvođenja

Prije početka testiranja dokumentirajte ovlaštenje i pravila angažmana. Utvrdite odobrene hostove, račune, okruženja, vremenske okvire testiranja, kontakte za hitne slučajeve i uvjete zaustavljanja. Dogovorite jesu li isključeni testiranje uskraćivanja usluge, socijalni inženjering, uspostava trajnog pristupa ili izvlačenje podataka.

Testiranje u produkciji može otkriti stvarne probleme s konfiguracijom, ali stvara i operativni rizik. Reprezentativno pripremno (staging) okruženje može biti sigurnije, pod uvjetom da su razlike u odnosu na produkciju zabilježene. Gdje je izvedivo, koristite sintetičke podatke zakupaca i dogovorite koji su dokazi dovoljni za dokazivanje učinka bez prikupljanja nepotrebnih informacija o klijentima.

Osigurajte da timovi za nadzor znaju razlikovati ovlaštenu aktivnost od nepovezanog incidenta. Testiranje ne smije postati izgovor za isključivanje zaštitnih kontrola bez dokumentiranja posljedica.

Razrađeni primjer: nalaz o izolaciji zakupaca

Razmotrimo ilustrativni SaaS angažman. Pretpostavimo da proizvod ima dva testna zakupca, obične korisnike, administratore zakupaca i ulogu podrške. Test uključuje autentificirane API-je i tijekove izvoza; infrastruktura identiteta treće strane je isključena.

Tester otkriva da krajnja točka za izvoz provjerava prijavu, ali ne provodi dosljedno vlasništvo zakupca. Koristeći sintetičke zapise, pokazuje da korisnik zakupca A može zatražiti izvoz koji pripada zakupcu B.

Nalaz treba navesti krajnju točku, potrebne privilegije, pogođeni tijek rada, reproducibilne dokaze i poslovni učinak. Inženjerski tim prati problem do pozadinskog procesa koji vjeruje identifikatoru zakupca dostavljenom u zahtjevu.

Ispravak provodi provjeru vlasništva prije planiranja izvoza i ponovno pri njegovu dohvaćanju. Regresijski testovi obuhvaćaju zahtjeve među zakupcima i relevantne uloge. Ponovno testiranje potvrđuje da je izvorni put blokiran i provjerava srodne putove izvoza. Tim čuva izvorni nalaz, dokaze o implementaciji i rezultat ponovnog testa; ne označava jednostavno zadatak kao „gotov“.

Pretvorite nalaze u inženjerski rad s jasnom odgovornošću

Nalaze trijažirajte prema tehničkoj ozbiljnosti i poslovnoj izloženosti. Razmotrite potrebne privilegije, izloženost internetu, pogođene podatke, pouzdanost iskorištavanja i kompenzacijske kontrole. Nominalno umjeren problem može zahtijevati hitno postupanje kada narušava ključnu granicu klijenta.

Svakom nalazu dodijelite vlasnika, ciljni datum i metodu provjere. Gdje je primjereno, uvedite privremenu mjeru ublažavanja dok se priprema trajni ispravak. Neka imenovani vlasnik rizika odobri svaki prihvaćeni preostali rizik, uz obrazloženje i datum pregleda; šutnja inženjerskog tima nije prihvaćanje.

Zabilježite testiranu verziju proizvoda i okruženje. Rezultat od prije velikog redizajna autorizacije ne može opisivati novu implementaciju. Kao praktičnu preporuku, potrebe za testiranjem ponovno procijenite nakon bitnih arhitektonskih promjena, ozbiljnih incidenata ili nove izloženosti, uz vašu ustaljenu učestalost.

Održavajte dokaze korisnima za revizore i kupce

Sačuvajte dogovoreni opseg, pravila angažmana, završno izvješće, zapise o otklanjanju, dokaze o ponovnom testiranju i odluke o riziku. Cjelovito izvješće držite pod ograničenim pristupom jer može sadržavati osjetljive pojedinosti o iskorištavanju.

Pripremite sažetak za klijente koji opisuje datume testiranja, opseg, metodologiju, ograničenja i status otklanjanja, bez nepotrebnog otkrivanja uputa za napad. Za dodatna pitanja pročitajte naš vodič za pregled jamstva.

U Secaniju povežite dokaze o testiranju s relevantnim sustavima, zahtjevima, kontrolama, vlasnicima i odlukama o pregledu. Praznine u dokazima pratite kao zadatke i zadržite ljudsko odobrenje zaključaka. Time odnos između onoga što je testirano i onoga što se promijenilo ostaje dostupan za kasniji pregled.

Prije traženja ponuda izradite jednostraničan opis opsega koji obuhvaća granice povjerenja, testne račune, iznimke, rezultate i očekivanja u pogledu ponovnog testiranja. Taj dokument pružatelju, revizoru i inženjerskom timu daje zajedničku osnovu za test koji informira sigurnost.