Ielaušanās tests (penetrācijas tests jeb pentests) pārbauda, vai konkrētā sistēmā ir ievainojamības, kuras noteiktajos apstākļos iespējams praktiski izmantot, un kāda var būt to ietekme. Ar Jūsu rakstisku atļauju definējam testa robežas un drošības noteikumus, kombinējam automatizētu izpēti ar manuālu pārbaudi un dokumentējam pierādījumus, kas palīdz komandai risku novērst.
Pentesta mērķis nav saražot pēc iespējas garāku ievainojamību sarakstu. Tas ir ierobežotā laikā un apjomā pārbaudīt noteiktu uzbrukuma virsmu, validēt būtiskus atradumus un parādīt, kādu ietekmi tie var radīt. Testa veidu un sākuma punktu izvēlamies pēc sistēmas un riska, kuru Jūs vēlaties pārbaudīt.
Pārbaudām autentifikāciju, sesiju un piekļuves kontroli, biznesa loģiku, ievaddatu apstrādi, API objektu un funkciju autorizāciju, servera konfigurāciju un citas šai lietotnei būtiskas uzbrukuma iespējas. Pārbaude neaprobežojas ar automatizēta skenera rezultātu.
Atkarībā no apjoma pārbaudām publiski pieejamus vai iekšējus servisus, konfigurāciju, zināmas ievainojamības, autentifikācijas un privilēģiju riskus un citus ceļus, kas var dot neatļautu piekļuvi vai ļaut palielināt sākotnēji iegūtās tiesības.
Testam var būt atšķirīgs sākotnējās informācijas un piekļuves līmenis. Ārēja uzbrucēja perspektīva atbild uz vienu jautājumu, savukārt testa konti, dokumentācija vai cita klienta sniegta informācija ļauj dziļāk pārbaudīt autorizāciju, biznesa loģiku un funkcijas, kas nav publiski pieejamas. Pieeju izvēlamies pēc testa mērķa, nevis pēc principa, ka mazāk informācijas vienmēr nozīmē labāku testu.
Pirms aktīvas pārbaudes rakstiski nosakām mērķus un robežas, atļautās un aizliegtās darbības, laika logus, testēšanas avotus, kontaktpersonas, incidenta eskalāciju un testa apturēšanas nosacījumus. Ražošanas sistēmu var testēt tikai ar apzināti izvēlētu riska līmeni. Pentests nav darbība “bez sekām”, tāpēc riskantākas metodes saskaņojam atsevišķi vai izslēdzam.
Definējam testa mērķus, sistēmas, kontus un citus aktīvus, kas ir iekļauti vai izslēgti, atļautās metodes, laika logus, kontaktpersonas, eskalāciju un apturēšanas nosacījumus. Pirms testēšanas ir noformēta nepieciešamā autorizācija.
Izpēti un automatizētus rīkus kombinējam ar manuālu pārbaudi. Būtiskus atradumus validējam tikai tik tālu, cik nepieciešams ietekmes pierādīšanai un cik atļauj saskaņotie noteikumi. Pierādījumus dokumentējam reproducējamā un izstrādātājiem izmantojamā formā.
Saņemat atradumus ar tehniskajiem pierādījumiem, ietekmes skaidrojumu, riska prioritāti un novēršanas ieteikumiem. Vērtējumā ņemam vērā ne tikai tehnisko smagumu, bet arī izmantojamību, sasniedzamību un skartā aktīva nozīmi Jūsu vidē.
Pēc labojumiem atkārtoti pārbaudām saskaņotos atradumus un dokumentējam to statusu. Retests apliecina konkrētā atraduma stāvokli atkārtotās pārbaudes brīdī; tas nav jauns pilna apjoma pentests un neapliecina, ka sistēmā nav citu ievainojamību.
Noskaidrojiet, kur ir vājās vietas
Atsūtiet īsu informāciju par sistēmu un to, ko vēlaties pārbaudīt. Atbildēsim vienas darba dienas laikā un precizēsim informāciju, kas nepieciešama testa apjoma un piedāvājuma sagatavošanai.
Automatizēta skenēšana ir noderīga uzbrukuma virsmas un zināmu problēmu meklēšanai, taču tā pati par sevi neparāda visu lietotnes biznesa loģiku, autorizācijas kļūdas vai to, kā vairāki šķietami nelieli trūkumi savienojas vienā uzbrukuma ķēdē. Pentestā skenera atradumi ir tikai viena no ievades daļām. Tos pārbaudām manuāli, meklējam papildu uzbrukuma ceļus un dokumentējam ietekmi, ko var pierādīt praksē.
Pentests ir sistēmas novērtējums noteiktā laika periodā, un tas negarantē, ka pēc testa ievainojamību nav. To ir vērts apsvērt pirms būtiska laidiena, pēc nozīmīgām arhitektūras vai infrastruktūras izmaiņām, pēc būtiska incidenta vai periodiski atbilstoši sistēmas riskam un organizācijas drošības programmai.
Black box testā testētājs sāk bez iekšējas informācijas, kā ārējs uzbrucējs. Grey box testā viņam ir daļēja informācija, piemēram, lietotāja konts, un white box testā pieejama arī dokumentācija vai pirmkods. Jo vairāk informācijas, jo vairāk sistēmas var pārbaudīt tajā pašā laikā, tāpēc pieeju izvēlamies pēc testa mērķa. Ja jāpārbauda, ko uzbrucējs var paveikt, kad jau ir iekļuvis, piemērotāks ir Assumed Breach tests.