Pisanje ucinkovitih porocil penetracijskih testov

Porocilo je glavni rezultat vsakega penetracijskega testa. V osemnajstih letih in na stotinah projektov sem ugotovil, da odlicen test s slabim porocilom ne zagotavlja vrednosti. Videl sem briljantno tehnicno delo, zakopano v porocilih, ki so bila tako gosta in neorganizirana, da stranka ni ukrepala glede niti ene ugotovitve. Nasprotno pa sem videl skromne ocene, ki so povzrocile transformativne spremembe, ker je bilo porocilo jasno, strukturirano in napisano z bralcem v mislih. Porocilo ni naknadna misel. To je izdelek, za katerega stranka placa.

Struktura porocila

Vsako porocilo, ki ga dostavim, sledi dosledni strukturi. Doslednost je pomembna, ker vracajocim se strankam omogoca primerjavo rezultatov iz leta v leto in hitro iskanje potrebnih informacij.

• Izvrsni povzetek - To je verjetno najpomembnejsi del. Ne sme biti daljsi od dveh strani in mora sporocati poslovni vpliv, kljucna tveganja ter strateska priporocila v jeziku, ki ga razume vsak clan uprave. Ta del napisem zadnjega, ko so vse ugotovitve dokumentirane, da lahko natancno povzamem celotno varnostno drzto.
• Metodologija - Kaj je bilo testirano, katera orodja so bila uporabljena, kaj je bilo izrecno izven obsega. Vkljucim casovnico testiranja in porabljene ure, ker si stranke zasluzijo preglednost.
• Ugotovitve - Podrobni opisi ranljivosti, organizirani po resnosti. Vsaka ugotovitev sledi dosledni predlogi. Ugotovitve stevilcim zaporedno in se nanje sklicujem v celotnem porocilu.
• Odprava - Kako odpraviti vsako tezavo s specificnimi, izvedljivimi navodili. Nikoli ne napisem "odpravite ranljivost" kot korak za odpravo. Namesto tega zagotovim natancne konfiguracijske spremembe, popravke kode ali arhitekturna priporocila.

Pisanje za vec obcinstva

Eno porocilo mora sluziti vec bralcem z zelo razlicnimi potrebami. Na zacetku kariere sem delal napako, da sem porocila pisal izkljucno za tehnicno obcinstvo. Rezultat je bil, da vodstvo porocil nikoli ni prebralo, odprava pa nikoli ni bila financirana.

• Vodstvo - Poslovno tveganje, financni vpliv in strosek neukrepanja. Ena tehnika, ki jo uporabljam, je oblikovanje ugotovitev v smislu poslovnih scenarijev: "Ce bi bila izkoriscena, bi ta ranljivost lahko razkrila osebne podatke priblizno 50.000 strank, kar bi sprozilo zahteve za obvescanje po GDPR."
• Tehnicno osebje - Podrobni koraki reprodukcije, prizadete koncne tocke, odseki kode in specificna navodila za odpravo. Vedno vkljucim natancne 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 vkljucim krizno referencno tabelo skladnosti.

Ucinkovito pisanje ugotovitev

Vsaka ugotovitev mora slediti strukturirani predlogi. Svojo sem izpilil skozi na stotine porocil in doslednost je tu pomembnejsa od ustvarjalnosti.

1. Jasen naslov, ki opisuje tezavo - ne "SQL Injection", ampak "SQL Injection v parametru iskanja uporabnikov omogoca celotno ekstrakcijo baze podatkov"
2. Ocena tveganja z utemeljitvijo - CVSS uporabljam kot izhodisce, vendar vedno dodam kontekstualno oceno tveganja, specificno za okolje stranke
3. Tehnicni opis - kaj je ranljivost in zakaj obstaja
4. Dokazi - anotirani posnetki zaslona, pari HTTP zahteva/odgovor in odseki kode z urejenimi obcutljivimi podatki
5. Poslovni vpliv - kaj bi napadalec lahko dosegel in kaksne bi bile posledice za organizacijo
6. Koraki za odpravo - specificni, prioritizirani in izvedljivi, vkljucno z idealno resitvijo in morebitnimi hitrimi ublazitvami

Pogoste napake pri pisanju porocil

Po pregledu porocil vec deset drugih podjetij vedno znova vidim iste napake. Nejasni naslovi ugotovitev, ki ne sporocajo dejanske tezave. Manjkajoci 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 razlicne ocene, odvisno od tega, kateri tester jih je nasel. Vsaka od teh napak spodkopava zaupanje strank in zmanjsuje verjetnost, da bodo ugotovitve odpravljene.

Orodja in delovni tok

Ugotovitve dokumentiram sproti med testiranjem, ne na koncu. Cakanje do po zakljucku projekta in pisanje ugotovitev iz spomina povzroci manjkajoce podrobnosti in netocne korake reprodukcije. V svojem orodju za belezenje vzdrzujem predlogo ugotovitev in jo izpolnjujem v realnem casu, vkljucno s posnetki zaslona, zajetimi med izkoriscanjem. Za porocanje obicajno porabim priblizno 30 odstotkov celotnega casa projekta in ta cas stejem za dobro nalozbo.

Dostava porocila

Kako dostavite porocilo, je skoraj tako pomembno kot to, kaj je v njem. Vedno nacrtam sestanek za pregled, kjer ugotovitve predstavim osebno. To stranki daje priloznost za postavljanje vprasanj, izpodbijanje predpostavk in razpravo o prioritetah odprave. Ugotovil sem, da stranke, ki prejmejo predstavitev, tri- do stirikrat pogosteje odpravijo kriticne ugotovitve v priporocenem casovnem okviru v primerjavi s tistimi, ki porocilo preprosto prejmejo po elektronski posti.