Įsiskverbimo testavimo užduotis turi apibrėžti, kokį saugumo klausimą reikia patikrinti, į kokias sistemas leidžiama kreiptis ir kaip bus valdomas poveikis paslaugai bei duomenims. Pasiūlymas „patikrinsime jūsų saugumą“ neleidžia palyginti tiekėjų darbo apimties. Naudingas rezultatas yra atkuriamas nustatytų problemų įrodymas ir jų pašalinimo patikra.
Toliau pateiktas modelis skirtas organizacijai, užsakančiai savo valdomos ar tinkamai autorizuotos sistemos patikrą. Jis apima parengimą, darbo taisykles, duomenų apsaugą ir ataskaitos priėmimą. Pavyzdžiai yra hipotetiniai, o apimtis ir leidimai turi būti patvirtinti tikrų sistemų savininkų.
Pasirinkite klausimą, kurį testas turi atsakyti
Pradėkite nuo konkretaus scenarijaus: ar vieno kliento paskyra gali pasiekti kito kliento dokumentą, ar administravimo sąsaja tinkamai apsaugota, ar pakeitus autentifikavimą išliko prieigos ribos. Tokia užduotis padeda pasirinkti metodą, paskyras ir įrodymą. Bendras pažeidžiamumų skaičius ne visada atsako į svarbiausią organizacijos riziką.
BDAR 32 straipsnis apima reguliaraus techninių ir organizacinių saugumo priemonių veiksmingumo tikrinimo, vertinimo ir analizavimo procesą. Jis nenustato vienodo įsiskverbimo testo grafiko ar vienintelio metodo visoms organizacijoms. Konkretų tikrinimą pasirinkite pagal riziką, sistemą ir kitus taikomus reikalavimus.
Saugumo audito užduotis padeda atskirti dokumentų ir organizacinės kontrolės vertinimą nuo techninio įsiskverbimo bandymo. Automatinis pažeidžiamumų skenavimas taip pat nėra identiškas rankiniam logikos bei prieigos scenarijų tyrimui. Pirkimo aprašas turi aiškiai nurodyti, kokio darbo iš tiesų tikimasi.
Apimtį užrašykite tiksliais objektais ir ribomis
Nurodykite domenus, adresų intervalus, programas, API, aplinkas ir leidžiamus paskyrų vaidmenis. Prie kiekvieno objekto pridėkite savininką ir leidimo šaltinį. Sistemų žemėlapis padeda aptikti priklausomybes, kurios gali nepriklausyti jūsų organizacijai: mokėjimo paslaugą, tapatybės teikėją ar bendrą debesijos infrastruktūrą.
Jeigu leidžiama tikrinti programą, tai savaime nesuteikia leidimo bandyti visą jos tiekėjo infrastruktūrą ar kitų klientų sistemas. Trečiosios šalies paslaugai patikrinkite taikomas bandymų sąlygas ir reikalingus leidimus. Neaiškus objektas turi būti patikslintas prieš su juo atliekant veiksmus, o ne vėliau įrašytas į ataskaitą.
| Užduoties dalis | Hipotetinis užpildymas | Priėmimo klausimas |
|---|---|---|
| Sistema | Bandomoji dokumentų portalo versija | Ar ji atitinka tikrinamo pakeitimo funkcijas? |
| Paskyros | Du atskiri klientų vaidmenys ir vienas administratorius | Ar įmanoma palyginti prieigos ribas? |
| Pagrindinis tikslas | Dokumentų atskyrimo ir teisių patikra | Ar išbandyti alternatyvūs prieigos keliai? |
| Duomenys | Dirbtiniai dokumentai su aiškiomis bandymo žymomis | Ar nereikia tikrų klientų turinio? |
| Ribos | Tik patvirtinti galiniai taškai ir metodai | Ar išimtys matomos visai komandai? |
| Pabaiga | Ataskaita, artefaktų pašalinimas ir pakartotinė patikra | Ar liko nepašalintų bandymo prieigų? |
Suderinkite žinomą informaciją ir darbo modelį
Užsakovei verta aiškiai nurodyti, ką testuotojas gaus: architektūros aprašą, šaltinio kodo dalį, įprastas paskyras ar tik viešą adresą. Šie variantai atsako į skirtingus klausimus ir reikalauja skirtingo laiko. Daugiau pradinės informacijos gali leisti geriau patikrinti konkrečias rizikas; mažiau informacijos savaime nereiškia kokybiškesnio testo.
NIST SP 800-115 pateikia techninių saugumo patikrų planavimo, vykdymo ir rezultatų analizės metodinį pagrindą. Tai 2008 m. dokumentas, todėl jo procesinį modelį reikia papildyti aktualia tikrinamos technologijos metodika. OWASP Web Security Testing Guide gali padėti detalizuoti žiniatinklio programos apimtį; užduotyje nurodykite naudojamą versiją ar konkrečius skyrius.
Metodikos pavadinimas nėra visas darbų sąrašas. Prie jo pažymėkite, kurie scenarijai įtraukti ir kurie neaktualūs. Jei tikrinama kelių organizacijų duomenis laikanti paslauga, atskyrimo testai neturi likti neapibrėžti vien todėl, kad pasiūlyme parašyta „OWASP patikra“.
Darbo taisyklėse numatykite leidžiamą poveikį
Prieš pradžią suderinkite laiką, užklausų apimties ribas, leidžiamas technikas ir veiksmus, kuriems reikia atskiro sprendimo. Atskirai aptarkite paslaugos trikdymą, duomenų keitimą, išorinius pranešimus ir socialinės inžinerijos scenarijus, jei jie iš viso planuojami. Jų negalima tyliai įtraukti į bendrą techninio testo leidimą.
Nurodykite stabdymo sąlygas: netikėtai sutrikusi paslauga, aptikti tikri jautrūs duomenys, neapibrėžta trečiosios šalies sistema arba kontaktų nepasiekiamumas. Abi pusės turi žinoti, kas gali pareikalauti sustabdyti veiksmus ir kaip vėl leidžiama juos tęsti. Tikslas — saugiai patikrinti hipotezę, o ne tęsti bandymą bet kokia kaina.
Veiklos tęstinumo planas padeda suderinti testavimo langą su tikros paslaugos priklausomybėmis. Jei naudojama bandomoji aplinka, užrašykite jos skirtumus nuo gamybinės: kita autentifikavimo schema, išjungtos integracijos ar skirtingos tinklo taisyklės gali riboti išvadų taikymą.
Duomenų įrodymui surinkite tik tiek, kiek būtina
Prieš testą paruoškite dirbtinius įrašus, leidžiančius patikrinti prieigos ribas. Pavyzdžiui, du klientai turi aiškiai skirtingus bandomuosius dokumentus; pakanka įrodyti, kad vienas gali pasiekti kito bandymo įrašą. Nereikia kopijuoti didelio tikrų dokumentų rinkinio vien tam, kad ataskaita atrodytų įtikinama.
Jei netikėtai atsiveria tikri duomenys, taikykite suderintą stabdymo ir pranešimo eigą. Užfiksuokite pakankamus techninius faktus, bet neplatinkite turinio nereikalingiems gavėjams. Duomenų kiekio mažinimo metodas padeda suplanuoti įrodymo apimtį, o šifravimo planas — jo saugų perdavimą ir saugojimą.
Sutartyje nustatykite, kas gauna ataskaitą, kur laikomi priedai ir kada pašalinami darbiniai artefaktai. Atskirai įvertinkite paslaugos teikėjo vaidmenį bei taikomas duomenų tvarkymo sąlygas. Konfidencialumo susitarimas pats savaime neatsako į visus BDAR vaidmenų ir saugumo klausimus.
Įtraukite užpildytą prieigos patikros scenarijų
Hipotetinė užduotis: „Patikrinti, ar įprastas kliento A naudotojas gali pasiekti kliento B bandomąjį dokumentą per numatytas programos ir API funkcijas.“ Priėmimo įrodymas turi parodyti naudotą vaidmenį, tikrintą versiją, tikėtiną ribą ir faktinį rezultatą. Testuotojas naudoja tik iš anksto paruoštus objektus ir patvirtintus veiksmus.
Jei nustatoma problema, aprašoma, kokiam duomenų tipui ir kokiomis sąlygomis ji aktuali. Vien ekrano kopija be vaidmens ir aplinkos informacijos gali neleisti komandai pakartoti patikros. Ataskaitoje reikia pakankamai techninių duomenų taisymui, tačiau viešai dalijamai santraukai galima parengti atskirą, mažiau jautrią versiją.
TLS patikros lapas padeda pridėti perdavimo konfigūracijos vertinimą, kai jis patenka į apimtį. Tačiau geras TLS rezultatas nepakeičia prieigos patikros. Paslaugos ryšys gali būti tinkamai šifruotas, nors programos leidimų klaida vis tiek suteikia prieigą netinkamam naudotojui.
Radinius vertinkite pagal tikrą poveikį
Kiekvienam radiniui prašykite aprašo, paveikto objekto, patikros sąlygų, įrodymo, poveikio ir siūlomo taisymo krypties. Techninis sunkumo balas gali padėti palyginti, bet jis neturi pakeisti organizacijos konteksto. Prieiga prie jautraus klientų turinio ir informacinis serverio antraštės radinys neturi vienodos reikšmės vien todėl, kad abu pateikti sąraše.
Pažymėkite, ar radinys patvirtintas, ar tik įtariamas, ir kokie apribojimai liko. Jei metodas dėl saugumo ribų negalėjo būti išbandytas iki galo, tai turi būti matoma. Nereikia iš nepatvirtintos galimybės daryti kategoriškos išvados, bet jos taip pat nereikia tyliai pašalinti iš tolesnio vertinimo.
Prie kiekvieno reikšmingo radinio paskirkite savininką ir sprendimą: taisyti, taikyti laikiną apsaugą arba pagrįstai spręsti dėl likutinės rizikos. Terminas parenkamas pagal poveikį ir aplinkybes; bendras sutarties šablono dienų skaičius nėra visų radinių tinkamo prioriteto įrodymas.
Pakartotinė patikra turi tikrinti rezultatą
Pataisos bilieto uždarymas neįrodo, kad problema pašalinta. Pakartotinėje patikroje naudokite ankstesnį scenarijų ir reikšmingus gretimus atvejus, kad pataisymas nebūtų tik vieno kelio blokavimas. Įraše pažymėkite testuotą versiją ir tai, ar neatsirado naujų prieigos arba veikimo sutrikimų.
Saugumo priemonių priede atnaujinkite tik tas priemones, kurių veikimas iš tiesų pasikeitė. Jei radinys parodė platesnę paskyrų valdymo problemą, susiekite jį su kibernetinės higienos veiksmų planu. Vienkartinis techninis taisymas neturi užgožti pasikartojančios administravimo priežasties.
Užbaikite darbą pašalindami bandymo pėdsakus
Uždarymo sąraše patikrinkite bandomąsias paskyras, laikinus leidimus, įkeltus dokumentus ir sukurtas integracijas. Išsaugokite reikalingą ataskaitą bei įrodymus pagal sutartą tvarką, o nereikalingus darbinius failus pašalinkite. Organizacija turi žinoti, ar po patikros liko kokia nors aktyvi prieiga.
Galutinėje santraukoje nurodykite patikrintą apimtį, svarbiausius radinius, pašalinimo būseną ir likusias ribas. Įsiskverbimo testas yra konkrečiu laiku ir apimtimi atlikta patikra, todėl jo negalima pristatyti kaip garantijos, kad sistema neturi jokių pažeidžiamumų. Nauji reikšmingi pakeitimai turi būti įtraukti į tolesnio saugumo tikrinimo planą.
Lygindami tiekėjų pasiūlymus paprašykite nuasmeninto ataskaitos pavyzdžio ir paaiškinimo, kaip komanda tikrina panašias prieigos funkcijas. Palyginkite įtrauktus vaidmenis, rankinio darbo apimtį, komunikaciją radus kritinę problemą ir pakartotinės patikros sąlygas. Vien žemesnė kaina ar didesnis nurodytų priemonių skaičius neparodo, ar bus atsakyta į jūsų pagrindinį saugumo klausimą. Profesiniai sertifikatai gali papildyti kompetencijos vertinimą, tačiau negali pakeisti konkrečios užduoties supratimo ir aiškios darbų apimties. Galutinį pasirinkimą pagrįskite šiais patikrinamais kriterijais.