Vid Grosek

Kako se pripraviti na penetracijski test

Praktičen vodnik za organizacije, ki želijo maksimalno izkoristiti varnostno testiranje

Dober penetracijski test vključuje tudi avtomatizirano skeniranje, vendar se z njim ne konča. Skeniranje hitro pokaže znane izpostavljenosti in usmeri nadaljnje delo; tester nato v dogovorjenem obsegu ročno preverja dejansko izkoristljivost ranljivosti in napačnih konfiguracij, njihove povezave ter učinek, ki bi ga lahko dosegel napadalec.

Dober pentest gre od ugotovitve do nadzorovanega dokaza vpliva. Pri internem testu to lahko pomeni preverjanje, ali začetni dostop omogoča višanje privilegijev, lateralno gibanje, zlorabo Active Directoryja, dostop do občutljivih podatkov, varnostnih kopij ali upravljavskih vmesnikov infrastrukture. Cilj ni brez razloga pridobiti »Domain Admin« ali povzročiti motnje, temveč z najmanjšim potrebnim dokazom pokazati realno napadalno pot in prednostno odpraviti njen vzrok.

Skeniranje je del pentesta, ni pa pentest. Avtomatiziran pregled znanih ranljivosti je hiter in koristen prvi korak: široko pregleda sredstva, odkrije očitne izpostavljenosti ter prepreči, da bi tester rutinske preveritve ponavljal ročno. Sam po sebi pa ne pokaže, ali je ugotovitev izkoristljiva, kako se povezuje z drugimi pomanjkljivostmi in kakšen je njen dejanski vpliv. Poročilo skenerja zato ni poročilo o penetracijskem testu.

Najresnejše poti do prevzema domene, dostopa do varnostnih kopij ali upravljanja požarnih pregrad pogosto niso posledica enega nepopravljenega strežnika. Nastanejo iz kombinacije preširokih pravic, zastarelih servisnih računov, napačnih delegacij v Active Directoryju, šibke segmentacije, pozabljenih dostopov, nezavarovanih upravljavskih poti in tehničnega dolga. Naloga pentesta je te povezave odkriti ter jih varno dokazati v jasno odobrenem obsegu. Red-team angažma je širša, vnaprej dogovorjena simulacija nasprotnika, usmerjena predvsem v zaznavo in odziv organizacije.

Za kakovosten test določite obseg in varnostne meje, zagotovite pisno pooblastilo, pripravite dokumentacijo in testne račune, obvestite ustrezne deležnike ter načrtujte odpravo ugotovitev in ponovni test. Ta vodič pripravlja Vid Grosek, prvi OSCE3 in OSCP+ certificirani penetracijski tester v Sloveniji s sedežem v Ljubljani, ki penetracijske teste izvaja prek podjetja Telprom d.o.o. za organizacije v Sloveniji in EU.

Hiter pregled pred naročilom

Pred podpisom ponudbe naj bodo spodnje odločitve zapisane in potrjene. Če katera manjka, je večja verjetnost, da se bo test ustavil, da se bodo porabile ure za usklajevanje ali da ugotovitve ne bodo primerljive z dejanskim tveganjem.

Odločitev	Dokazilo	Odgovorna oseba
Obseg in izključitve	Seznam sredstev, okolij, odvisnosti ter prepovedanih aktivnosti	Lastnik storitve
Pooblastilo	Podpisano pooblastilo in pravila sodelovanja	Pooblaščeni predstavnik naročnika
Varnostni režim	Čas testiranja, stop pogoji, dežurne kontaktne osebe in eskalacijska pot	Vodja IT oziroma varnosti
Dostopi in podatki	Testni računi, način predaje skrivnosti ter dogovor o ravnanju z dokazi	Lastnik aplikacije ali infrastrukture
Zaključek	Lastnik vsake ugotovitve, rok, kriterij preverjanja in retest	Vodja odprave

Praktično pravilo: obseg ni samo seznam IP naslovov. Povejte tudi, kateri poslovni procesi, podatki, integracije in varnostni mehanizmi so pomembni ter kaj tester ne sme storiti brez dodatne potrditve.

1. Vrste penetracijskih testov

Preden naročite pentest, morate razumeti, kaj točno potrebujete:

Po količini informacij

Black box - Tester ne dobi nobenih informacij. Simulira zunanjega napadalca. Časovno potraten, toda realisten.
Grey box - Tester dobi osnovne informacije (IP naslove, uporabniške račune). Najpogostejši pristop.
White box - Tester dobi popoln dostop do dokumentacije, izvorne kode, arhitekture. Najtemeljitejši, toda najmanj realisten.

Po cilju

Mrežni pentest - Testiranje infrastrukture, strežnikov, omrežnih naprav
Aplikacijski pentest - Testiranje spletnih, mobilnih ali namiznih aplikacij
API pentest - Testiranje programskih vmesnikov
Social engineering - Testiranje zaposlenih (phishing, vishing, fizični dostop)
Red team - Scenarijska simulacija nasprotnika za preverjanje zaznave in odziva; tudi ta ima vnaprej dogovorjene meje, varnostne pogoje in eskalacijo.

2. Določitev obsega

Jasen obseg ne pomeni ozkega testa ene aplikacije, enega URL-ja ali ene vnaprej izbrane tehnike. Če želite razumeti dejansko odpornost organizacije, naj penetracijski test zajame celotno dogovorjeno napadalno površino in testerju omogoči, da ugotovitve poveže v napadalno pot.

Obseg določa, kaj je dovoljeno, kdo je lastnik sistemov in kateri varnostni pogoji veljajo; ne sme pa testerja voditi po vnaprej napisanem seznamu posameznih preverjanj. Preozek obseg pogosto prepreči ravno tisti prehod med sistemi, ki pokaže dejanski vpliv ranljivosti.

Kaj mora biti v obsegu

Celotna dogovorjena napadalna površina - zunanja izpostavljenost, notranje omrežje, Active Directory in identitete, strežniki, delovne postaje, brezžična omrežja, aplikacije, API-ji, VPN, oblak ter upravljavski vmesniki, kadar so v lasti naročnika.
Vsi pomembni uporabniški in administrativni nivoji ter realne povezave med okolji, ne le en testni račun ali izoliran strežnik.
Tipi testiranja (mrežno, aplikacijsko, API, brezžično, fizično ali socialni inženiring), če so primerni za cilj testa.
Časovni okvir testiranja in način eskalacije pri ugotovitvi, ki lahko vpliva na poslovanje.
Ali so obremenitveni, DoS/DDoS, phishing ali fizični postopki izrecno dovoljeni oziroma prepovedani.
Lastnik sredstva, poslovna kritičnost, odvisnosti od tretjih ponudnikov in kontakt za vsako okolje.
Izvorni IP-naslovi testerja in ali se jih sme dodati na allowlist; tega ne storite, kadar preverjate delovanje WAF, IPS ali detekcije.

Kaj je lahko izven obsega

Sistemi, integracije, podizvajalci in oblačne storitve, za katere nimate pisnega pooblastila lastnika.
Dejavnosti, ki bi lahko povzročile nedopustno motnjo produkcije, razen kadar so izrecno odobrene in usklajene.
Specifična sredstva brez odobritve ali občutljivi podatki oziroma funkcije, za katere veljajo posebna pravila ravnanja.

Opozorilo: »Testirajte vse, kar je naše« je lahko prava poslovna usmeritev, vendar jo je treba pretvoriti v celovit seznam sredstev, lastnikov, integracij in varnostnih pogojev. To ni mikroupravljanje testerja: po določitvi teh meja mora imeti svobodo, da sam izbere varne in smiselne poti preverjanja.

3. Pravna priprava

Testiranje se sme začeti šele, ko je jasno, kdo ima pravico odobriti vsak sistem v obsegu in pod katerimi pogoji. Ustni dogovor ali domneva, da je sistem »naš«, nista dovolj.

Obvezni dokumenti

Pooblastilo za testiranje (Authorization Letter) - Podpisano s strani lastnika ali osebe z dejanskim pooblastilom. Navaja sredstva, obdobje in dovoljena testiranja.
Pravila sodelovanja (Rules of Engagement) - Dovoljene in prepovedane aktivnosti, čas testiranja, stop pogoji, kontaktne osebe ter pot eskalacije.
NDA in dogovor o ravnanju s podatki - Določita zaupnost, prenos dokazov, hrambo, dostop in varno uničenje testnih podatkov.
Pogodba oziroma naročilnica - Obseg, cena, časovnica, odgovornosti, poročilo, retest in odgovornost za odobritve tretjih oseb.

Vprašanja za pravni oddelek

Ali imamo pooblastilo za testiranje vseh sistemov v obsegu?
Ali so kateri sistemi pri zunanjem ponudniku, v oblaku ali odvisni od podizvajalca?
Ali pogoji ponudnika, najemna pogodba ali polica zavarovanja zahtevajo predhodno obvestilo?
Kdo lahko odobri spremembo obsega ali takojšnjo zaustavitev testa?
Kakšen je postopek ob varnostnem incidentu, izpadu ali nepričakovanem dostopu do podatkov?

4. Tehnična priprava

Dobra priprava prihrani čas in denar:

Dokumentacija za testerja

Arhitekturne diagrame omrežja
Seznam aplikacij in njihovih URL naslovov
Testni uporabniški računi (več nivojev dostopa)
API dokumentacija (če je aplikacijski test)
Izvorna koda in postopek za varen dostop (če je white box)
Prejšnja poročila ali odprte izjeme, kadar so pomembne za obseg
Način predaje poverilnic, MFA postopek in datum ukinitve testnih računov

Interna priprava

Obvestite SOC/NOC - Da ne blokirajo testerja ali sprožijo lažnega alarma
Preverite varnostne kopije - Če gre kaj narobe
Dokumentirajte trenutno stanje - Da boste vedeli, kaj se je spremenilo
Pripravite načrt povrnitve - Za vsak primer
Ohranite dnevnike - Dogovorite se o zadržanju relevantnih dnevnikov, da boste lahko preverili zaznavo in čas odziva.
Ustvarite sled odobritev - Zabeležite, kdo je odobril obseg, dostop in morebitne spremembe med testom.

Komunikacijski kanal

Kdo je kontaktna oseba?
Kako hitro mora odgovoriti?
Kateri kanal uporabljamo (email, telefon, Signal)?
Kdo odloča o spremembi ali zaustavitvi testa in kdo ga nadomešča izven delovnega časa?
Kateri varni kanal se uporabi za kritično ugotovitev in kateri za nujni telefonski klic?

5. Med testom

Dnevna komunikacija

Kratki dnevni sestanki (15 min) za status
Takojšnje obveščanje o kritičnih ugotovitvah
Dokumentiranje vsega kar tester najde

Ne popravljajte med testom

Če tester najde ranljivost, ne popravljajte takoj. Zakaj?

Tester mora videti celotno sliko
Ranljivosti so pogosto povezane
Popravek lahko skrije resnejše težave
Izgubljate čas za testiranje

Izjema: ob verjetno kritični ugotovitvi, dejanski motnji ali nevarnosti za podatke naj se dejavnost ustavi oziroma omeji. Naročnik in tester naj najprej zabeležita minimalno potrebno dokazilo, ocenita vpliv ter dokumentirata odločitev o zadržanju, odpravi ali nadaljevanju testa.

Spremljajte svoje sisteme

Pentest je odlična priložnost za testiranje vaše detekcije:

Ali je SIEM zaznal aktivnost?
Ali so alarmi sprožili?
Koliko časa je minilo do detekcije?
Ali bi vaš SOC ustrezno reagiral in komu bi eskaliral?
Ali so časovni žigi in relevantni dnevniki dovolj kakovostni za preiskavo?

Obravnava kritične ugotovitve

Za kritično ugotovitev naj bo postopek vnaprej določen: tester jo po varnem kanalu sporoči dežurni kontaktni osebi, naročnik potrdi prejem, skupaj ocenita poslovni vpliv in določita naslednji korak. Odločitev, čas, udeleženci in morebitna omejitev testa naj ostanejo zabeleženi.

6. Po testu

Pregled poročila

Zahtevajte sestanek za pregled ugotovitev
Vprašajte za pojasnila če kaj ni jasno
Preverite ali so vse ugotovitve reproducibilne
Zahtevajte dokaze (posnetki zaslona, dnevniki, minimalni dokaz koncepta) in jasen opis vpliva
Dogovorite se, kdo sme videti poročilo, kje se hrani ter kdaj se dodatni dokazi varno izbrišejo

Prioritizacija

Ne vse ranljivosti so enako pomembne. Upoštevajte:

CVSS ocena - Toda ne slepo, kontekst je pomemben
Izpostavljenost - Ali je ranljivost dosegljiva iz interneta?
Podatki - Kateri podatki so v nevarnosti?
Težavnost izkoriščanja - Ali potrebuje avtentikacijo? Posebno znanje?

Načrt odprave

Za vsako ugotovitev določite:

Kdo je odgovoren za popravek?
Kakšen je rok?
Kako boste preverili, da je popravljeno?
Ali popravek vpliva na druge sisteme in kakšen je načrt povrnitve?
Kateri dokaz bo pokazal, da je popravek učinkovit, in kdaj bo izveden retest?

Ponovno testiranje

Po popravkih vedno naročite retest. Zakaj?

Popravki pogosto ne delujejo pravilno
Nov popravek lahko uvede novo ranljivost
Dokumentacija za revizorje

7. Pogoste napake

"Pentest naročimo enkrat letno za compliance"

Če testirate samo zato, da odkljukate zahtevo, ne boste dobili prave vrednosti. Pentest je priložnost za učenje, ne samo dokument za revizorje.

"Vse je v obsegu"

Brez jasnega obsega tester ne more učinkovito razporediti časa. Rezultat: površno testiranje vsega namesto temeljitega testiranja pomembnega.

"Ne rabimo dokumentacije, naj tester najde sam"

Čas, ki ga tester porabi za odkrivanje osnov, je čas, ki ga ne porabi za iskanje ranljivosti. Black box ima smisel, toda samo če to res želite.

"Popravili smo, tako da je zdaj varno"

Brez ponovnega testiranja ne veste, ali popravek dejansko deluje. Videl sem že "popravke", ki so situacijo še poslabšali.

Potrebujete pentest?

Z več kot 18 leti izkušenj in certifikati OSCE3, OSCP+ vam lahko pomagam identificirati in odpraviti varnostne ranljivosti.

Kontaktirajte me

Pogosta vprašanja

Ali za penetracijski test potrebujem pravno pooblastilo?

Da. Pred začetkom potrebujete pisno pooblastilo lastnika oziroma osebe z dejanskimi pristojnostmi za vsa sredstva v obsegu. Pravila sodelovanja, pogodba ter dogovor o zaupnosti in ravnanju s podatki določijo varne pogoje izvedbe.

Ali naj med testom popravljam ranljivosti?

Ne. Med testom ranljivosti praviloma ne popravljajte, saj mora tester videti celotno sliko in povezane ranljivosti; prehiter popravek lahko skrije resnejše težave. Edina izjema je kritična ranljivost, ki jo napadalci že aktivno izkoriščajo.

Ali je po popravkih potreben ponovni test?

Da. Po odpravi ranljivosti vedno naročite ponovni test (retest), saj popravki pogosto ne delujejo pravilno ali uvedejo nove ranljivosti, retest pa zagotovi dokumentacijo za revizorje. Proračun zanj predvidite že na začetku.

Kakšna je razlika med black, grey in white box testom?

Pri black box testu tester ne dobi nobenih informacij in simulira zunanjega napadalca. Pri grey box testu dobi osnovne informacije, kot so IP naslovi in uporabniški računi; to je najpogostejši pristop. Pri white box testu dobi popoln dostop do dokumentacije, izvorne kode in arhitekture, kar je najtemeljitejše, a najmanj realistično.

Kako se red team razlikuje od penetracijskega testa?

Penetracijski test ima jasno določen obseg in pravila. Red team angažma simulira nasprotnika, da preveri zaznavo in odziv, vendar ima tudi ta vnaprej dogovorjene meje, varnostne pogoje in pot eskalacije.

Preberite več o mojih strokovnih področjih ali si oglejte profil: Spoznajte Vida Groska.