Kas yra įsilaužimo testavimas ir kada įmonei jo reikia

Skenavimas, auditas ir įsilaužimo testavimas yra trys skirtingi darbai su trimis skirtingomis kainomis. Kuris iš jų atsako į Jūsų klausimą, ir ko Lietuvos teisės aktai iš tikrųjų reikalauja.

Jūs prašote pasiūlymo svetainės saugumui ir gaunate tris, kurie skiriasi dešimt kartų, ir viename parašyta „saugumo skenavimas“, antrame „saugumo auditas“, trečiame „įsilaužimo testas“, bet visuose trijuose stovi tas pats žodis „saugumas“, kuris nieko iš to, kas skiriasi, nepasako. Tai nėra vienas darbas trimis pakopomis ir nėra trys kainos už tą patį, o trys skirtingi darbai, kurie atsako į tris skirtingus klausimus, todėl pirmasis žingsnis nėra kainų palyginimas, o supratimas, į kurį iš tų trijų klausimų Jūs iš tikrųjų norite atsakymo.

Šis straipsnis atsako į du: kas yra įsilaužimo testavimas ir ar jis reikalingas būtent Jūsų įmonei. Antrasis klausimas svarbesnis, nes didžiajai daliai Lietuvos mažųjų ir vidutinių įmonių joks teisės aktas įsilaužimo testavimo tiesiogiai nereikalauja, o pasiūlymas, kuris tai nutyli, parduoda Jums tinkamą paslaugą netinkamu metu.

Mes tai rašome parduodami saugumo auditą, ir čia nėra prieštaravimo, nes auditas, kuriame yra vietos rankinei patikrai, ir įsilaužimo testas, kurio reikalauja konkretus teisės aktas, nėra tas pats darbas, o įmonė, kuri nuperka antrąjį tada, kai jai reikėjo pirmojo, sumoka daugiau ir sužino mažiau.

Trys darbai, parduodami panašiais pavadinimais

Srities terminologija čia paini, bet po ja yra aiški riba, kurią geriausiai įvardija standartų institucija: NIST SP 800-115 įsilaužimo testavimą apibrėžia kaip saugumo testavimą, kuriame vertintojai imituoja tikras atakas, kad rastų kelius apeinant sistemos apsaugą, ir nurodo, kad ieškoma pažeidžiamumų derinių, o ne atskirų radinių. Ta pati publikacija pažeidžiamumų skenavimą aprašo kaip būdą, kuriuo identifikuojami ištekliai ir jiems atitinkantys žinomi pažeidžiamumai.

Praktikoje tai reiškia keturis skirtingus darbus, kuriuos verta įvardyti kiekvieną atskirai. Skenavimas yra automatinis, ir jame įrankis palygina Jūsų sistemą su žinomų pažeidžiamumų duomenų baze ir grąžina sąrašą. Pažeidžiamumų vertinimas yra tas pats sąrašas, kurį žmogus patikrino ir surikiavo, paprastai neišnaudodamas nė vieno iš rastų pažeidžiamumų. Įsilaužimo testavimas yra žmogaus vedamas darbas, kuriame rastos silpnosios vietos išnaudojamos ir sujungiamos į grandinę, kad paaiškėtų, kaip toli užpuolikas iš tikrųjų nueina. Atitikties auditas atsako į visai kitą klausimą: ar sistema atitinka įvardytą standartą ar teisės normą.

Ribą tarp pirmųjų trijų aiškiausiai nubrėžia mokėjimo kortelių standartas, ir jis tai daro ne apibrėžtimi, o tikslu: PCI saugumo standartų tarybos gairės įsilaužimo testą nuo skenavimo skiria pagal tikslą: skenavimas identifikuoja, surikiuoja ir praneša apie pažeidžiamumus; testas ieško būdų juos išnaudoti, kad apeitų sistemos apsaugą. Ta pati taryba savo standarte priduria abi puses: skenavimas pats savaime nėra įsilaužimo testas, ir testas, kuris tik bando išnaudoti skenerio radinius, taip pat nėra pakankamas.

Todėl klausimas „ar Jums reikia įsilaužimo testavimo“ nėra klausimas apie biudžetą, o apie tai, į ką Jūs norite atsakymo: ar Jūsų sistemoje yra žinomų silpnųjų vietų, ar kas nors su jomis iš tikrųjų gali ką nors padaryti.

Ką kiekvienas iš jų atsako ir ko nepasako

Skenavimas atsako greitai ir pigiai, o jo silpnybė yra kontekstas, nes įrankis nežino, kuri iš šimto pažymėtų eilučių yra Jūsų mokėjimo formoje, o kuri — testinėje aplinkoje, kurios niekas nepasiekia iš interneto, ir jis taip pat nežino, kad dvi atskirai nekenksmingos klaidos kartu duoda prieigą prie duomenų bazės — todėl sąrašas yra darbo pradžia, o ne darbo rezultatas.

Įsilaužimo testavimas atsako lėčiau ir brangiau, o jo vertė yra būtent grandinėje, nes testuotojas ieško ne „ar čia yra pažeidžiamumas“, o „ką aš su juo galiu padaryti“ — ar iš viešos formos galima nueiti iki administratoriaus teisių, ar iš vieno kliento paskyros galima matyti kito kliento duomenis, ar iš testinės aplinkos galima pasiekti produkcinę duomenų bazę. Atsakymas į šį klausimą yra tas, kurį vadovas supranta be vertimo.

Atitikties auditas nedaro nė vieno, nė kito, nes tikrina, ar sistema atitinka normą, ir jo rezultatas yra sprendimas dėl atitikties, o ne sąrašas techninių silpnybių; būtent todėl įmonė gali išlaikyti atitikties auditą ir tą pačią savaitę būti nulaužta, ir čia nėra jokio prieštaravimo, nes du dokumentai atsako į du skirtingus klausimus.

Nė vienas iš šių darbų nepakeičia kitų ir nė vienas iš jų nėra „geresnis“ už kitus, todėl vienintelis prasmingas klausimas yra tas, kuris iš jų dabar atsako į tai, ką Jums iš tikrųjų reikia žinoti.

Pavadinimų painiava nėra tik vienos rinkos problema, ir tai matyti lyginant rinkas: Suomijoje, Švedijoje ir Norvegijoje rinka parduoda du darbus — skenavimą ir įsilaužimo testavimą — ir viduriniam variantui pavadinimo nėra; jis laikomas skenavimo rezultatu, o ne atskira paslauga. Vokietijoje yra atvirkščiai, nes ten vienas žodis neretai žymi visus tris darbus, įskaitant patį testą, ir būtent todėl lyginant pasiūlymus pavadinimas yra silpniausias įmanomas orientyras, o vienintelis saugus klausimas lieka tas, ar rasti pažeidžiamumai bus išnaudojami.

Ar įstatymas to reikalauja būtent iš Jūsų

Čia verta būti tiksliems, nes čia pasiūlymai dažniausiai perdeda: Lietuvoje įsilaužimo testavimo pagal pavadinimą nereikalauja joks teisės aktas iš kiekvienos įmonės, kuri turi svetainę.

Kibernetinio saugumo įstatymas, kuris nauja redakcija įsigaliojo 2024 m. spalio 18 d. ir perkelia Europos Sąjungos direktyvą (ES) 2022/2555, nustato pareigas subjektams: įsivertinti savo statusą, atsakingą asmenį, rizikos valdymą ir pranešimą apie incidentus. Įsilaužimo testavimas pačiame įstatyme pagal pavadinimą nėra paminėtas nė viename straipsnyje.

Testavimą ir vertinimą įvardija Kibernetinio saugumo reikalavimų aprašas, patvirtintas Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 nauja 2024 m. lapkričio 6 d. nutarimo Nr. 945 redakcija. Jo 48.1 punktas reikalauja ne rečiau kaip kartą per metus atlikti atitikties vertinimą, o 48.3 punktas — kibernetinio saugumo auditą ne rečiau kaip kartą per trejus metus, bet tik tada, jei Jūs esate įstatymo subjektas. Tie patys dokumentai numato, kad Nacionalinis kibernetinio saugumo centras gali tikrinti subjektus ir pareikalauti dokumentų.

Tai dvi sąlygos kartu, ne viena: įmonė, kuri nėra įstatymo subjektas, iš šio punkto pareigos negauna, ir subjektas, kurio konkreti sistema nenaudojama reguliuojamai paslaugai teikti, taip pat negauna, todėl pirmasis žingsnis nėra pasiūlymo prašymas, o įsivertinimas, ar Jūs apskritai esate subjektas.

Kaip suprasti, ar esate subjektas

Kibernetinio saugumo įstatymas įmonių pagal pavadinimą nevardija, o aprašo sektorius ir dydį, ir pareiga įvertinti savo statusą tenka pačiai įmonei, o tai praktikoje reiškia du klausimus: ar Jūsų veikla patenka į kurią nors įstatyme įvardytą sritį, ir ar įmonės dydis pasiekia nustatytą slenkstį. Į abu reikia atsakyti patiems, ir atsakymą reikia dokumentuoti — būtent todėl pirmoji išlaida šioje srityje paprastai yra teisinė konsultacija, o ne techninė paslauga.

Jei atsakymas yra „ne“, tolesni punktai apie esminius ir svarbius subjektus bei sistemas Jums apskritai netaikomi, o jei atsakymas yra „taip“, ateina antrasis klausimas, kuriai rūšiai priklauso konkreti sistema. Testavimo ir vertinimo lūkestis prikabintas prie tų sistemų, kuriomis teikiama reguliuojama paslauga, o ne prie subjekto statuso kaip tokio, ir įmonė gali būti subjektas, kurio nė vienai sistemai šis lūkestis netaikomas.

Yra ir trečiasis kelias, kuris nėra kalendorinė pareiga: priežiūros institucija atskiru atveju gali patikrinti subjektą arba pareikalauti dokumentų, kad įvertintų tinklų ir informacinių sistemų saugumą. Tai nėra planuojama pareiga, bet tai priežastis žinoti, kas Jūsų pusėje į tokį prašymą atsakytų.

Kiti slenksčiai įvardija testavimą, ne įsilaužimo testą

Bendrojo duomenų apsaugos reglamento 32 straipsnis reikalauja reguliariai tikrinti ir vertinti saugumo priemonių veiksmingumą, ir reikalavimo apimtis prikabinta prie rizikos. Tai nėra tas pats, kas pareiga kartą per metus užsakyti įsilaužimo testavimą, o pasiūlymas, kuris 32 straipsnį pateikia kaip tokią pareigą, reglamentą perpasakoja laisviau, nei jis parašytas. Pareiga įrodyti, kad testavimas apskritai vyksta, yra tikra; pareiga rinktis būtent šį testavimo būdą iš 32 straipsnio neišplaukia.

Mokėjimo kortelių standarto PCI DSS 11.4 reikalavimas įsilaužimo testavimą įvardija tiesiogiai, kartą per dvylika mėnesių ir po esminių pakeitimų, bet tai sutartinė pareiga ir taikoma tam, kaip Jūs priimate korteles. El. parduotuvė, kuri mokėjimus visiškai nukreipia mokėjimo paslaugų teikėjui ir pati kortelių duomenų netvarko, ir visi kiti, į kurių aplinką kortelių duomenys patenka, į šį reikalavimą atsako skirtingai. Tai klausimas, į kurį atsako Jūsų korteles priimantis bankas, o ne straipsnis.

Finansų sektoriuje reglamentas (ES) 2022/2554 reikalauja reguliaraus testavimo, o grėsmėmis grindžiamą skverbimosi testavimą (TLPT) numato tik toms įstaigoms, kurias priežiūra yra specialiai nurodžiusi. Standartas ISO/IEC 27001 reikalauja pažeidžiamumų valdymo ir saugumo testavimo, įsilaužimo testavimo pagal pavadinimą nereikalaudamas; teiginys, kad be jo sertifikatas neišduodamas, yra paplitęs ir standarte nerandamas.

Jei nė vienas iš šių slenksčių Jums netaikomas, tada teisės aktų nustatytos pareigos užsakyti įsilaužimo testavimą Jūs neturite, ir tai nereiškia, kad nėra ką daryti, o kad darytina yra kita.

Jei nė vienas slenkstis neperžengtas

Įmonei, kuri nėra subjektas, kortelių duomenų netvarko ir finansų sektoriuje nedirba, prasmingiausias darbas paprastai yra tas, kuris vyksta reguliariai, o ne kartą per trejus metus. Tai atnaujinimai, kuriems yra atsakingasis ir terminas; atsarginės kopijos, kurias kas nors kartą yra atkūręs ir įsitikinęs, kad jos iš tikrųjų atsikuria; kelių veiksnių autentifikacija (MFA) administratorių paskyroms, kurią Kibernetinio saugumo reikalavimų aprašas subjektams įvardija atskirai ir kuri visiems kitiems yra tiek pat naudinga; ir reguliarus skenavimas, kurio rezultatus kas nors iš tikrųjų perskaito.

Tai nėra mažesnis atsakymo variantas, o kitas darbo būdas. Didžioji dalis nulaužimų, su kuriais mes dirbame, prasideda ne nuo įmantrios atakos, o nuo neatnaujinto komponento arba nuo slaptažodžio, kuris tiko ir kitur, ir įsilaužimo testas, kuris vyksta kartą per trejus metus, nuo to neapsaugo. Jei Jūsų svetainė jau nukentėjo, seka yra kita ir ją aprašo atskiras straipsnis apie tai, kaip atkurti nulaužtą svetainę.

Įsilaužimo testavimas tampa pagrįstas tada, kai yra ką prarasti, ir kai praradimo mastas didesnis už testo kainą: sistema, kurioje yra kitų žmonių duomenys, integracija, kuri liečia pinigus, arba užsakovas, kuris reikalauja įrodymo. Iki to momento tai teisingas darbas neteisinga tvarka.

Kas vyksta testo metu

Darbas prasideda apimties nustatymu ir baigiasi ataskaita, o tarp jų yra trys etapai, kuriuos verta suprasti prieš lyginant pasiūlymus, nes būtent jie paaiškina, kodėl vienas testas kainuoja tiek, kiek kainuoja, ir kodėl kitas už tą pačią sistemą kainuoja dešimt kartų mažiau.

Pirmasis etapas yra žvalgyba, kurioje testuotojas surenka viską, ką apie sistemą galima sužinoti iš išorės — kokie adresai vieši, kokios technologijos ir versijos matomos, kur yra prisijungimo formos, kokie failai prieinami be autorizacijos. Šiame etape dar niekas neišnaudojama, bet būtent čia dažniausiai glūdi radiniai, kurių niekas nesitikėjo: pamiršta testinė aplinka, atviras katalogų sąrašas, atsarginė kopija, kuri guli po nuspėjamu adresu.

Antrasis etapas yra pati patikra, kurioje automatiniai įrankiai paleidžiami, kad nebūtų praleista žinoma, bet sprendimus priima žmogus, kuris tikrina, ar radinys tikras, bando jį išnaudoti ir žiūri, ką tuo gauna. Čia atsiranda grandinė — prieiga prie vienos paskyros, iš jos prieiga prie funkcijos, kurios neturėjo būti pasiekiama, iš jos prieiga prie duomenų. Atskirai nė vienas žingsnis nėra dramatiškas; kartu jie yra istorija.

Trečiasis etapas yra įrodymas ir užrašymas, nes prie kiekvieno radinio turi likti įrodymas, kurį galima pakartoti: kokia užklausa buvo išsiųsta, koks buvo atsakymas, kas pasikeitė. Be to ataskaita yra nuomonė, o kūrėjas, kuris ją gauna, praleidžia dieną bandydamas suprasti, ką būtent testuotojas matė.

Todėl ir terminai yra tokie, kokie yra: vienos nedidelės svetainės testas yra kelios dienos, o sistema su keliomis rolėmis, integracijomis ir mokėjimais yra savaitės, ir pasiūlymas, kuris žada visą įsilaužimo testą per vieną dieną, aprašo ne testą, o skenavimą.

Kodėl pasiūlymai skiriasi dešimt kartų

Kai du pasiūlymai už tą pačią svetainę skiriasi dešimt kartų, skirtumas beveik niekada nėra pelno maržoje, ir jis beveik visada yra apimtyje ir metode: vienas siūlo automatinį skenavimą su įrankiu, kurį paleidžia per valandą ir kurio ataskaitą sugeneruoja tas pats įrankis, o kitas siūlo savaitę trunkantį žmogaus darbą, kuriame įrankiai tėra pradžia, ir būtent šį skirtumą pavadinimas „saugumo patikra“ abiem atvejais paslepia.

Antrasis kainą formuojantis veiksnys yra sistemos sudėtingumas, ir jį galima įvertinti dar prieš pokalbį: viena vieša svetainė be naudotojų paskyrų yra vienas darbas, o sistema su keliomis rolėmis, mokėjimais, išorine integracija ir duomenimis, kurie priklauso klientams, yra visai kitas, nes kiekviena rolė yra atskira tikrintina riba ir kiekviena integracija yra vieta, kurioje dvi sistemos viena kita pasitiki labiau, nei turėtų.

Trečiasis yra tai, ką po testo Jūs gaunate ir kiek ilgai vykdytojas lieka šalia: ataskaita be prioritetų, be įrodymų ir be pakartotinės patikros kainuoja mažiau todėl, kad tai mažesnis darbas, o įmonei, kuriai paskui reikia taisyti radinius, būtent šie trys dalykai nulemia, ar dokumentas tampa užduočių sąrašu, ar aplanku, kurio niekas daugiau neatidaro.

Todėl lyginti pasiūlymus pagal kainą įmanoma tik tada, kai apimtis parašyta vienodai, ir paprasčiausias būdas tai pasiekti yra parašyti apimtį patiems ir paprašyti visų siūlyti pagal ją, o ne leisti kiekvienam vykdytojui apibrėžti savąją.

Kada testas pasensta

Įsilaužimo testavimo rezultatas aprašo konkrečią sistemą konkrečią datą, ir tai akivaizdu, vis dėlto būtent čia kyla didžioji dalis nesusikalbėjimo tarp vykdytojo ir užsakovo, nes ataskaita, kuriai yra metai, aprašo kodą, kuris nuo to laiko pasikeitė dešimtis kartų.

Rašytiniai intervalai tai pripažįsta patys: Kibernetinio saugumo reikalavimų apraše šalia trejų metų audito intervalo stovi kasmetinis atitikties vertinimas, o mokėjimo kortelių standarte šalia metinio intervalo stovi „po esminių pakeitimų“, taigi abiem atvejais kalendorius tėra minimumas, o tikroji priežastis testuoti yra pakeitimas.

Praktikoje tai reiškia, kad nauja testo priežastis yra pakeitimas, kuris keičia atakos paviršių: nauja vieša funkcija, nauja integracija su išorine sistema, autentifikacijos keitimas, perkėlimas į kitą prieglobą, nauja naudotojo rolė su platesnėmis teisėmis. Spalvų keitimas ar teksto pataisa tokia priežastimi netampa, kad ir kokia matoma ji būtų.

Antroji priežastis yra ta, kad pasikeitė aplinka, o ne Jūsų kodas: pažeidžiamumas karkase, kurį Jūs naudojate, paaiškėja po testo, ir testas, kuris jo neminėjo, neapsiriko, nes tuo metu jo dar nebuvo. Todėl reguliarus skenavimas ir atnaujinimų procesas yra tai, kas vyksta tarp testų, ir testas jų nepakeičia.

Be savininko leidimo tie patys veiksmai yra neteisėti

Įsilaužimo testavimas nuo atakos techniškai nesiskiria, ir vienintelis dalykas, kuris juos skiria, yra dokumentas: savininko leidimas, kuriame įvardyta apimtis, laikas ir ribos, ir kurį verta įforminti raštu net tada, kai įstatymas šios formos tiesiogiai nereikalauja. Be jo tie patys veiksmai yra tie patys veiksmai, ir tam yra teisinės pasekmės — Lietuvoje neteisėtas prisijungimas prie informacinės sistemos pažeidžiant apsaugos priemones yra nusikalstama veika pagal Baudžiamojo kodekso 198¹ straipsnį.

Praktiškai tai reiškia, kad leidimą duoda tas, kam sistema priklauso, o ne tas, kas ją prižiūri. Jei Jūsų svetainė veikia prieglobos paslaugoje, ir paslaugos teikėjas turi žinoti, kad testas vyks, nes priešingu atveju jo apsaugos sistemos jį sustabdys arba Jūsų paskyrą užblokuos. Jei sistemoje yra trečiosios šalies komponentas, kurio Jūs nekontroliuojate, jis į apimtį neįeina.

Apimties ribas reikia parašyti prieš, o ne po, ir tame sąraše yra tai, kurie adresai yra apimtyje ir kurie nėra, ar testuojame produkcinę aplinką, ar kopiją, kas nutinka, jei testas nutraukia paslaugą, ir kas iš Jūsų pusės pasiekiamas naktį; šis pokalbis užima vieną valandą ir išsprendžia didžiąją dalį ginčų, kurie kitaip kyla testo viduryje.

Ko testas nėra: raudonoji komanda, bug bounty ir atitikties patikra

Šalia įsilaužimo testavimo yra keli darbai, kuriuos įprasta vadinti tuo pačiu, ir skirtumai tarp jų nėra akademiniai, o praktiniai — jie nulemia, ką Jūs užsakote ir ką gaunate.

Raudonosios komandos užduotis tikrina ne sistemą, o gynybą: ar Jūsų žmonės ir procesai ataką pastebi ir ką daro. Apimtis platesnė, trukmė ilgesnė, ir dalis vertės yra būtent tame, kad ginančioji pusė nežino, kad vyksta pratybos. Įmonei, kuriai nėra ką pastebėti, nes žurnalų niekas neskaito, šis darbas yra per ankstyvas.

Bug bounty yra modelis, ne testas: Jūs paskelbiate taisykles ir mokate už radinius tiems, kurie juos atsiunčia. Tai gali rasti tai, ko vienas testuotojas nepastebėjo, bet neduoda nei apimties garantijos, nei termino, nei ataskaitos, kurią galima pridėti prie pirkimo dokumentų.

Grėsmėmis grindžiamas skverbimosi testavimas (TLPT) yra atskiras, prižiūrimas darbas finansų sektoriuje, ir jis apibrėžtas Europos Sąjungos reglamente. Jei Jūsų įmonė nėra priežiūros nurodyta finansų įstaiga, šio termino Jūsų pasiūlyme neturėtų būti.

Dar viena riba, kurią įprasta ištrinti, yra tarp „juodosios“, „baltosios“ ir „pilkosios dėžės“ — kiek testuotojas apie sistemą žino jau pradžioje. Tai srities susitarimas, ne teisės akto reikalavimas, ir jis turi tiesioginę įtaką kainai ir tam, ką testas ras. Testuotojas be prieigos imituoja svetimą; testuotojas su paskyra ir dokumentacija per tą patį laiką nueina toliau. Nė vienas variantas nėra teisingesnis; klausimas yra, ko Jūs bijote.

Ką Jūs gaunate ir kaip tai skaityti

Testo rezultatas yra ataskaita, o jos vertė yra prioritetuose, ne radinių skaičiuje, nes ataskaita su šimtu eilučių, kuriose nepasakyta, nuo kurios pradėti, yra lygiai taip pat nenaudojama kaip skenerio išklotinė. Gera ataskaita prie kiekvieno radinio pasako, ką užpuolikas su juo gali padaryti, kaip lengvai, ir ką konkrečiai keisti.

Antra, ko reikia prašyti, yra patikra po pataisymų, nes radinys, kuris ištaisytas, ir radinys, apie kurį kas nors mano, kad jis ištaisytas, skiriasi vienas nuo kito, ir vienintelis būdas tai išsiaiškinti yra patikrinti dar kartą. Mes tai darome per trisdešimt dienų po pataisymų, ir šio termino verta prašyti iš kiekvieno vykdytojo.

Trečia yra tai, ką su ataskaita darys Jūsų kūrėjas. Radinys, kuris aprašytas CVE numeriu ir be konteksto, kūrėjui reiškia paiešką; radinys, prie kurio pridėta konkreti užklausa ir vieta kode, reiškia pataisą. Jei kūrimą atlieka viena įmonė, o testą kita, šis skirtumas yra tas, kuris nulemia, ar pataisos bus padarytos per savaitę, ar per ketvirtį.

Ketvirta yra tai, ko ataskaitoje negali būti: teiginys, kad sistema dabar saugi. Testas parodo, ką sutartoje apimtyje sutartą dieną pavyko padaryti. Jis neįrodo, kad nėra nieko kito, o vykdytojas, kuris tai žada, parduoda Jums ramumą.

Yra dar viena priežastis, kodėl šį pokalbį verta pradėti anksčiau, nei atrodo būtina: testas, kuris vyksta savaitę prieš sistemos paleidimą, randa tą patį, ką būtų radęs prieš tris mėnesius, bet radiniams taisyti nebelieka nei laiko, nei biudžeto, ir praktikoje tai baigiasi sąrašu, kuris priimamas kaip rizika, o ne pataisomis, todėl logika testuoti prieš paleidžiant sistemą parašyta būtent taip, kaip parašyta, ir ta pati logika tinka ir tiems, kuriems ši pareiga netaikoma.

Ir paskutinis dalykas, kurį verta pasakyti tiesiai: įsilaužimo testavimas nėra paliudijimas, kad sistema saugi, o paliudijimas, kad konkrečią dieną konkretioje apimtyje žinomas įgūdis nerado kelio toliau už ką nors konkretaus, ir todėl vertingiausia ataskaitos dalis dažnai yra ne radinių sąrašas, o aprašymas to, kas buvo bandyta ir nepavyko, nes būtent ši dalis kitam testuotojui po trejų metų pasako, kur neverta pradėti nuo nulio.

Ką paruošti prieš pokalbį

Kad pasiūlymas apskritai būtų palyginamas, vykdytojas turi žinoti apimtį, todėl paruoškite sąrašą adresų ir sistemų, kurios į ją įeina, nurodykite, ar testuojame produkcinę aplinką, ar kopiją, pasakykite, kas sistemoje yra tokio, ko negalima liesti, ir įvardykite žmogų, kuris gali leisti testą sustabdyti.

Produkcinė aplinka ar kopija

Tai klausimas, kuris nulemia ir kainą, ir riziką, nes testas produkcinėje aplinkoje parodo tai, kas iš tikrųjų prieinama, ir būtent todėl jis gali ką nors sulaužyti: perkrauti, užpildyti duomenų bazę testiniais įrašais, išsiųsti klientams tikrus el. laiškus arba įstrigti apsaugos sistemoje, kuri užblokuoja testuotoją, o paskui užblokuoja ir dalį Jūsų naudotojų.

Testas kopijoje saugesnis ir kartu nepilnesnis, nes kopija retai identiška: joje paprastai nebūna tikrųjų integracijų, tikrojo duomenų kiekio ir tikrosios konfigūracijos, o būtent konfigūracijoje dažnai glūdi problema. Jei renkatės kopiją, užrašykite, kuo ji skiriasi nuo produkcinės aplinkos, nes šis sąrašas yra ir sąrašas to, ko testas nepatikrino.

Vidurio kelias, kurį naudojame dažniausiai: skaitymo veiksmai produkcinėje aplinkoje, rašymo ir potencialiai griaunamieji — kopijoje, su iš anksto sutartu langu ir žmogumi, kuris gali sustabdyti. Tai nėra kompromisas dėl kainos, o būdas gauti abiejų variantų atsakymus nenutraukiant darbo.

Tinka ir priešingas sąrašas, būtent tai, kas nėra apimtyje, nes tylomis priimtos ribos yra tos, dėl kurių vėliau ginčijamasi. Trečiųjų šalių paslaugos, kurių Jūs neprižiūrite, į ją neįeina, ir jų testavimas be tų šalių leidimo yra ta pati problema, apie kurią kalba ankstesnis skyrius. Jei Jūsų svetainė naudoja išorinį mokėjimo langą, išorinį pokalbių langą ar išorinę analitiką, tai kitų nuosavybė, ir pasiūlymas, kuris žada juos „taip pat patikrinti“, žada tai, ko negalima.

Galiausiai pasakykite, kas nutiks su radiniais po to: kas juos taisys, per kokį terminą, ir ar vykdytojas po pataisymų tikrins dar kartą. Testas be šio susitarimo dažnai baigiasi dokumentu, kurio niekas neatidaro, ir tai brangiausia įmanoma versija: sumokėta už žinojimą, kurio nenaudojate.

Pasakykite ir tai, kokio atsakymo Jūs ieškote, nes „mums reikia įvykdyti reikalavimą“ ir „norime žinoti, ar kas nors gali prieiti prie klientų duomenų“ yra du skirtingi darbai su dviem skirtingomis kainomis, o vykdytojas, kuris neklausia, kuris iš jų yra Jūsų, pasiūlys tą, kuris jam patogesnis.

Jei nesate tikri, kurioje slenksčio pusėje esate, nuo to verta pradėti. Automatinis auditas paprastai atsako į klausimą apie žinomas silpnąsias vietas pigiau ir greičiau nei rankinis eksperto darbas, ir jo rezultatas pasako ir tai, ar įsilaužimo testavimas yra kitas žingsnis. Pokalbį apie apimtį verta pradėti nuo proceso aprašymo, o ne nuo technologijų sąrašo, nes apimtį nulemia tai, ką Jūs prarandate, jei sistema Jus apvilia.