Ponovni varnostni pregled: od ugotovitev do preverjene odprave

Poročilo o penetracijskem testu je uporabno, ko lahko odgovorna oseba ugotovitev pretvori v spremembo in pokaže njen učinek. Zaključena naloga še ne potrjuje spremembe na preverjenem sistemu. Popravek je lahko samo v razvojni veji, zajame eno pot dostopa ali zahteva nastavitev, ki še ni uvedena v produkcijo.

Načrt odprave in ponovnega varnostnega pregleda povezuje prvotne dokaze, nameščeno spremembo in opaženi rezultat. Prispevek predlaga postopek za vodje varnosti, razvijalce in odgovorne za odpravo. Ciljno preverjanje posameznih ugotovitev pri tem ostaja ločeno od novega celovitega pregleda sistema.

Ohranite izvirno ugotovitev

Vsaki ugotovitvi dodelite stalno oznako ter ohranite prvotni obseg, dokazila in datum pregleda. Ob prenosu v sistem nalog dodajte prizadeto okolje, komponento, vlogo računa in predpogoje. Skrajšan naslov naloge ne sme postati edina razlaga, ki je na voljo razvijalcu.

Navodila OWASP za poročanje priporočajo podatke, s katerimi tehnične skupine ugotovitev razumejo in odpravijo. Pri ponovnem pregledu predvidevajo povezavo prejšnjih ugotovitev s posodobljenim stanjem. Navodila OWASP WSTG za poročanje.

Občutljiva dokazila hranite na odobrenem mestu z omejenim dostopom. Naloga naj vsebuje dovolj konteksta za odgovorno osebo in povezavo do dokazov. Veljavnih poverilnic ali dejanskih podatkov uporabnikov ne razširjajte samo zato, ker so bili vključeni v izvirno gradivo pregleda.

Oceno ugotovitve ločite od vrstnega reda odprave

Resnost ugotovitve pomaga opisati tehnično stanje, na časovni načrt pa vplivajo tudi izpostavljenost, prizadeta storitev, odvisnosti in začasne omejitve. Napaka avtorizacije na javni aplikaciji lahko zahteva drugačen odziv od podobnega stanja na ločeni komponenti, ki je bila umaknjena iz uporabe. Navedite dejstva, na katerih temelji prednostna obravnava. Splošnega roka brez podlage ne dodajajte.

Ugotovitve z istim vzrokom povežite. Več končnih točk brez istega preverjanja pravic lahko zahteva skupen popravek in več preizkusov. Posamezne oznake naj ostanejo sledljive, da združitev ne prikrije poti, na kateri odprava še ni potrjena.

NIST SP 800-115 obravnava načrtovanje tehničnih pregledov, analizo ugotovitev in pripravo ukrepov. Gre za temeljno publikacijo iz leta 2008, ne za nov standard testiranja. NIST SP 800-115. Predlagani register je praktičen pripomoček in ni prikazan kot oblika, ki jo NIST izrecno zahteva.

Določite odgovorno osebo in pričakovani rezultat

Odgovorna oseba za odpravo mora biti sposobna uskladiti spremembo tudi, če sodeluje več skupin. Navedite odvisnosti od razvoja, infrastrukture ali dobavitelja ter osebo, ki lahko odobri namestitev. Oznaka »IT« ni dovolj natančna, če nihče ne more pojasniti stanja naloge.

Pričakovano vedenje opišite pred izbiro tehnične rešitve. Pri napaki avtorizacije objektov je lahko cilj, da uporabnik dostopa do dovoljenih zapisov, zahteve za zapise druge organizacije pa so zavrnjene. Tak opis dopušča rešitev, primerno arhitekturi aplikacije, in hkrati določa mejo za ponovni preizkus.

Odgovorna oseba naj opredeli vzrok, povezano kodo ali nastavitve ter druge poti, ki uporabljajo isto logiko. Posamezen simptom lahko izgine, skupni vzrok pa ostane. Načrt naj pojasni, zakaj predlagana sprememba zajame relevantno preverjanje dostopa.

Ločite dokaz o kodi od dokaza o namestitvi

Pregledana sprememba kode pokaže poseg v izvorno kodo. Oznaka gradnje določi programski paket. Zapis namestitve ta paket poveže z okoljem. Poročilo ponovnega pregleda mora jasno navesti, katero od teh stanj je bilo dejansko preverjeno.

Če je popravek na voljo samo v testnem okolju, poročajte o rezultatu tega okolja. Preverjanje produkcije naj ostane ločeno. Kadar je preizkus produkcije omejen, določite, katera dokazila o različici in nastavitvah podpirajo trditev o namestitvi ter kaj ostaja nepreverjeno. Rezultata testnega okolja brez podlage ne razširite na vse namestitve.

Register naj vsebuje oznako ugotovitve, okolje, odgovorno osebo, vzrok, načrtovani ukrep, povezavo do popravka, datum namestitve, obseg ponovnega pregleda, rezultat in omejitev. Dodajte rok glede na sprejeto odločitev o tveganju ter razlog za ponovno presojo morebitne izjeme.

Pripravite preizkus, ki loči različne izide

Izhajajte iz prvotnih pogojev in jih uskladite z nameščeno različico. Preverite, da vloga računa, ciljni sistem in relevantne nastavitve omogočajo smiseln preizkus. Ukinjena končna točka ali nedosegljiv testni račun lahko prepreči ponovitev, ne da bi s tem potrdili odpravo vzroka.

Pri izmišljenem API za račune uporabite poskusne zapise in dva odobrena testna računa z različnimi pravicami. Vsak račun naj uspešno izvede dovoljeno opravilo. Nato preverite zavrnitev dostopa, ko eden zahteva zaščiteni zapis drugega. Če poti za spremembo ali izvoz uporabljajo isto logiko in so vključene v obseg, preverite tudi te.

Gre za zasnovo meril sprejema, ne za navodilo za dostop do dejanskih tujih podatkov. Pred izvedbo določite cilje, račune, dovoljena dejanja in pogoje prekinitve. Ponovni pregled naj pridobi zadostna dokazila z najmanjšim potrebnim posegom.

Če rezultat ne omogoča zanesljivega sklepa, pojasnite razlog. Časovna omejitev, omrežni filter in napaka aplikacije niso enakovredni zavrnitvi avtorizacije. Če prvotno dejanje ne uspe več, navedite opaženo zaščito in omejitve razlage. Sam neuspeh ni dovolj za sklep o vzroku.

Statusi naj imajo določene pomene

Spodnje oznake so predlog za jasno poročanje. Organizacija lahko uporablja drugačne izraze, če njihov pomen ostane nedvoumen.

Kadar vzrok ni znan, navedbo »ni bilo mogoče ponoviti« ohranite kot pojasnjeno opažanje. Ne pretvorite je samodejno v potrjeno odpravo. Če se sredstvo odstrani iz obsega, to odločitev zabeležite ločeno od tehničnega statusa ugotovitve.

Poročajte o preostalem tveganju in nadaljnjih ukrepih

Poročilo naj poveže prvotno ugotovitev, preverjeno spremembo, datum, okolje, izvedene primere in rezultat. Pojasnite preostalo pot dostopa ali predpostavko. Bralec mora razlikovati med preverjeno odpravo v aplikaciji in začasno omejitvijo, ki zmanjša izpostavljenost, vzrok pa ostaja.

Pri odprti ugotovitvi določite naslednji ukrep in odgovorno osebo. Ob zaključku posodobite tehnični register in vodstveni pregled. Sicer lahko organizacija še naprej poroča o zastarelem tveganju ali delni popravek napačno predstavi kot zaključeno odpravo.

Smiselne regresijske preizkuse vključite v obstoječe preverjanje aplikacije, kadar varujejo popravljeno mejo dostopa. Ugotovitev ponovno preglejte ob spremembi logike pravic, nastavitev nameščanja ali skupnih komponent. Uspešen ponovni pregled podpira omejen sklep v določenem času in ne zagotavlja prihodnje varnosti sistema.

Pogosta vprašanja

Ali za zaključek zadostuje zaslonska slika razvijalca?

Slika lahko podpre zapis spremembe. Sama ni neodvisna potrditev, da je dogovorjeno stanje odpravljeno v ciljnem okolju. Odločitev o zaključku povežite z zahtevanimi dokazili.

Ali ponovni pregled nadomesti nov penetracijski test?

Ciljni ponovni pregled preveri izbrane ugotovitve in dogovorjene povezane primere. Nov pregled ima lasten obseg ter lahko zajame spremembe in področja zunaj ponovnega preverjanja.

Ali sprejeto tveganje lahko označimo kot odpravljeno?

Ne. Navedite pristojno osebo, obrazložitev, rok ponovne presoje in omejitve. Neodpravljeno tehnično stanje mora ostati vidno.

Povezani prispevki: varnostni pregledi API, varnostno poročanje in tveganja ter varnostni kontrolni seznami.

Sources / Viri

• OWASP WSTG v4.2: Reporting.
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.

Za načrtovanje nadaljnjih ukrepov sta povezana članka Prioritizacija ranljivosti: Onkraj ocen CVSS in Pisanje ucinkovitih porocil penetracijskih testov.