Pisanje ucinkovitih porocil penetracijskih testov

Poročilo je glavni rezultat vsakega penetracijskega testa. V osemnajstih letih in na stotinah projektov sem ugotovil, da odličen test s slabim poročilom ne zagotavlja vrednosti. Videl sem briljantno tehnično delo, zakopano v poročilih, ki so bila tako gosta in neorganizirana, da stranka ni ukrepala glede niti ene ugotovitve. Nasprotno pa sem videl skromne ocene, ki so povzročile transformativne spremembe, ker je bilo poročilo jasno, strukturirano in napisano z bralcem v mislih. Poročilo zahteva čas že med pregledom. To je izdelek, za katerega stranka plača.

Struktura poročila

Vsako poročilo, ki ga dostavim, sledi dosledni strukturi. Doslednost je pomembna, ker vračajočim se strankam omogoča primerjavo rezultatov iz leta v leto in hitro iskanje potrebnih informacij.

• Vodstveni povzetek - To je verjetno najpomembnejši del. Ne sme biti daljši od dveh strani in mora sporočati poslovni vpliv, ključna tveganja ter strateška priporočila v jeziku, ki ga razume vsak član uprave. Ta del napisem zadnjega, ko so vse ugotovitve dokumentirane, da lahko natančno povzamem celotno varnostno stanje varnosti.
• Metodologija - Kaj je bilo testirano, katera orodja so bila uporabljena, kaj je bilo izrecno izven obsega. Vključim časovnico testiranja in porabljene ure, ker si stranke zaslužijo preglednost.
• Ugotovitve - Podrobni opisi ranljivosti, organizirani po resnosti. Vsaka ugotovitev sledi dosledni predlogi. Ugotovitve številčim zaporedno in se nanje sklicujem v celotnem poročilu.
• Odprava - Kako odpraviti vsako težavo s specifičnimi, izvedljivimi navodili. Nikoli ne napisem "odpravite ranljivost" kot korak za odpravo. Namesto tega zagotovim natančne konfiguracijske spremembe, popravke kode ali arhitekturna priporočila.

Pisanje za različne bralce

Eno poročilo mora služiti več bralcem z zelo različnimi potrebami. Na začetku kariere sem delal napako, da sem poročila pisal izključno za tehnično občinstvo. Rezultat je bil, da vodstvo poročil nikoli ni prebralo, odprava pa nikoli ni bila financirana.

• Vodstvo – Poslovno tveganje, finančni vpliv in strošek neukrepanja. Povežite potrjeni tehnični dostop z dejansko funkcijo sistema: »Ranljivost bi lahko omogočila dostop do osebnih podatkov strank. Morebitna kršitev zahteva ločeno presojo obveznosti po GDPR.« Številke in posledice navedite le, če jih podpirajo dokazi.
• Tehnično osebje - Podrobni koraki reprodukcije, prizadete končne točke, odseki kode in specifična navodila za odpravo. Vedno vključim natančne URL-je, parametre in uporabljene vsebine.
• Skladnost - Preslikava ugotovitev na ustrezne standarde, kot so ISO 27001, PCI DSS ali NIS2. Mnoge moje stranke v Sloveniji in EU potrebujejo to preslikavo, zato kot prilogo vključim krizno referenčno tabelo skladnosti.

Učinkovito pisanje ugotovitev

Vsaka ugotovitev mora slediti strukturirani predlogi. Svojo sem izpilil skozi na stotine poročil in doslednost je tu pomembnejša od ustvarjalnosti.

1. Jasen naslov, ki opisuje težavo - ne "SQL-vrivanje", ampak "SQL-vrivanje v parametru iskanja uporabnikov omogoča pridobitev celotne vsebine baze podatkov"
2. Ocena tveganja z utemeljitvijo - CVSS uporabljam kot izhodišče, vendar vedno dodam kontekstualno oceno tveganja, specifično za okolje stranke
3. Tehnični opis - kaj je ranljivost in zakaj obstaja
4. Dokazi - posnetki z opombami zaslona, pari HTTP zahteva/odgovor in odseki kode z zakritimi občutljivimi podatki
5. Poslovni vpliv - kaj bi napadalec lahko dosegel in kakšne bi bile posledice za organizacijo
6. Koraki za odpravo - specifični, prioritizirani in izvedljivi, vključno z idealno resitvijo in morebitnimi hitrimi ublažitvami

Pogoste napake pri pisanju poročil

Po pregledu poročil več deset drugih podjetij vedno znova vidim iste napake. Nejasni naslovi ugotovitev, ki ne sporočajo dejanske težave. Manjkajoči dokazi, ki bralca silijo, da zaupa besedi testerja. Navodila za odpravo, ki preprosto pravijo "uporabite popravke proizvajalca." Nedosledne ocene resnosti, kjer podobne ranljivosti prejmejo zelo različne ocene, odvisno od tega, kateri tester jih je našel. Vsaka od teh napak spodkopava zaupanje strank in zmanjšuje verjetnost, da bodo ugotovitve odpravljene.

Orodja in delovni tok

Ugotovitve dokumentiram sproti med testiranjem, ne na koncu. Čakanje do zaključka projekta in pisanje ugotovitev iz spomina povzroči manjkajoče podrobnosti in netočne korake reprodukcije. V svojem orodju za beleženje vzdržujem predlogo ugotovitev in jo izpolnjujem v realnem času, vključno s posnetki zaslona, zajetimi med izkoriščanjem. Za poročanje običajno porabim približno 30 odstotkov celotnega časa projekta in ta čas štejem za dobro naložbo.

Dostava poročila

Kako dostavite poročilo, je skoraj tako pomembno kot to, kaj je v njem. Vedno načrtam sestanek za pregled, kjer ugotovitve predstavim osebno. To stranki daje priložnost za postavljanje vprašanj, izpodbijanje predpostavk in razpravo o prioritetah odprave. Ugotovil sem, da stranke, ki prejmejo predstavitev, tri- do štirikrat pogosteje odpravijo kritične ugotovitve v priporočenem časovnem okviru v primerjavi s tistimi, ki poročilo preprosto prejmejo po elektronski pošti.

Viri za navedene postopke in zahteve: OWASP WSTG: Reporting; FIRST CVSS v4.0.

Za načrtovanje nadaljnjih ukrepov sta povezana članka Komuniciranje varnostnega tveganja vodstvu in Ponovni varnostni pregled: od ugotovitev do preverjene odprave.