Kā sagatavoties ielaušanās testam

Nosaki mērķi

Vispirms atbildi uz jautājumu, kāds lēmums tiks pieņemts, pamatojoties uz testa rezultātiem. Vai jāizlemj, vai jauno lietotni drīkst laist ekspluatācijā? Vai jāsaprot, ko paveiktu uzbrucējs, kas jau ieguvis vienu darbinieka kontu? Vai jāizpilda līguma vai normatīva prasība? Katrs no šiem mērķiem noved pie cita apjoma un citas pieejas.

Ja mērķis paliek neizteikts, tests parasti pārvēršas par vispārīgu pārbaudi, kuras rezultāts ir garš saraksts bez skaidras prioritātes. Viens uzrakstīts teikums par mērķi šo problēmu atrisina.

Ierobežo apjomu – bet ne pārāk

Apjoms ir vienošanās par to, kas tiks pārbaudīts. Pārāk plašs apjoms sadala uzmanību un noved pie virspusējas pārbaudes; pārāk šaurs apjoms izslēdz tieši to ceļu, ko izmantotu uzbrucējs. Praktisks kompromiss ir noteikt šauru testējamo apjomu, bet plašāku izpētes apjomu, lai testētājs drīkst apzināt visu redzamo virsmu un ziņot par atradumiem ārpus galvenā fokusa.

• Uzskaiti sistēmas, domēnus, apakšdomēnus, API un mobilās lietotnes, kas ietilpst apjomā.
• Skaidri norādi, kas neietilpst apjomā, un kāpēc – tas ir tikpat svarīgi.
• Norādi trešo pušu pakalpojumus, kuriem vajadzīga atsevišķa atļauja no to īpašnieka.
• Vienojies par aizliegtajām metodēm: piemēram, pārslodzes uzbrukumi, sociālā inženierija pret konkrētiem darbiniekiem, darbības ražošanas datubāzē.
• Nosaki testa logu – dienas un stundas –, ja darbība ir sezonāla vai kritiska konkrētos periodos.

Vienojies rakstiski

Rakstiskā vienošanās par testa noteikumiem (angļu val. rules of engagement) ir gan juridiskā, gan praktiskā drošības josta. NIST SP 800-115 tai velta atsevišķu pielikumu ar veidnes struktūru; minimums, kam jābūt fiksētam, ir šāds.

Prasības Latvijas regulētajiem subjektiem

Ja organizācija ietilpst Nacionālās kiberdrošības likuma tvērumā, testa plānošanā jāņem vērā Ministru kabineta noteikumi “Minimālās kiberdrošības prasības”. To 131. punkts nosaka, ka A klases informācijas sistēmai ielaušanās testu veic pirms nodošanas ekspluatācijā un vismaz reizi trijos gados ekspluatācijas laikā; jebkurai sistēmai testu var veikt pēc subjekta iniciatīvas vai pēc Nacionālā kiberdrošības centra vai Satversmes aizsardzības biroja pieprasījuma.

Noteikumu 132. punkts izvirza prasības arī testa veicējam. Ja testu veic uzņēmuma paša darbinieks, viņš pēdējo trīs gadu laikā nedrīkst būt bijis iesaistīts testējamās sistēmas izstrādē vai uzturēšanā; ja testu veic ārēja persona, tai papildus jābūt starptautiski atzītam sertifikātam, kas apliecina kvalifikāciju ielaušanās testu jomā (kā piemēri minēti CEH un OSCP), vai vismaz divu gadu pieredzei ielaušanās testu veikšanā, kas iegūta pēdējo piecu gadu laikā. IKT kritiskās infrastruktūras īpašniekam par testa rezultātiem 10 darbdienu laikā jāinformē Satversmes aizsardzības birojs.

Tehniskā sagatavošanās

Lielākā daļa zaudētā testa laika rodas triviālu iemeslu dēļ: konti nedarbojas, testa vide atšķiras no ražošanas, vai aizsardzības risinājums bloķē testētāju pēc pirmajām desmit minūtēm. To visu var novērst iepriekš.

1. Sagatavo kontus visiem lomu līmeņiem, ko vēlies pārbaudīt, un pārliecinies, ka tie tiešām darbojas.
2. Izlem, vai testētāja adreses tiek izslēgtas no bloķēšanas. Ja netiek, tests pārbauda aizsardzības risinājumu, ne lietotni.
3. Nodrošini testa datus, kas atbilst reāliem – tukša sistēma slēpj lielāko daļu loģikas kļūdu.
4. Ja tests notiek ražošanas vidē, iepriekš izveido rezerves kopiju un pārbaudi, ka to var atjaunot.
5. Brīdini uzraudzības komandu, ja tests ir atklāts; pretējā gadījumā brīdini tikai tos, kam jāzina.
6. Iedod testētājam kontaktpersonu, kas atbild tajā pašā dienā – jautājumi rodas visos testos.

Testa laikā

Testa nedēļā uzņēmuma puses uzdevums ir neaizkavēt. Praktiski tas nozīmē trīs lietas: atbildēt uz jautājumiem tajā pašā dienā, nemainīt testējamo vidi bez brīdinājuma un nelabot atradumus, pirms tie ir dokumentēti – citādi tests un labošana notiek paralēli, un neviens vairs nezina, kas ir pārbaudīts.

Ja uzraudzības komanda testa laikā pamana testētāja darbības un ziņo par tām, tā ir laba ziņa, ko vērts pierakstīt: tā ir viena no retajām reizēm, kad var izmērīt reālo pamanīšanas laiku. Pieraksti, kura darbība tika pamanīta, cik ilgā laikā un kas notika pēc tam – šie trīs dati bieži ir vērtīgāki par pusi ziņojuma atradumu.

Kā lasīt ziņojumu un prioritizēt

Smaguma līmenis ziņojumā ir tehnisks novērtējums, ne tavs prioritāšu saraksts. Pareizā secība rodas, sareizinot izmantojamību ar ietekmi tieši tavā vidē: kritisks atradums izolētā testa serverī var būt mazāk steidzams nekā vidēja līmeņa atradums maksājumu plūsmā.

• Vispirms – viss, kas dod piekļuvi bez autentifikācijas no interneta.
• Tad – ceļi, kas ļauj vienam lietotājam piekļūt cita datiem vai paaugstināt tiesības.
• Tad – atradumi, kas paši par sevi nav kritiski, bet ir ķēdes posmi līdz kritiskam rezultātam.
• Beigās – konfigurācijas un higiēnas atradumi, kurus var apvienot vienā darba paketē.

Katram atradumam piešķir atbildīgo un termiņu. Atradums bez īpašnieka pēc gada izskatīsies tieši tāpat. Ja organizācija ietilpst likuma tvērumā, atceries, ka koordinētas ievainojamību atklāšanas gadījumā Nacionālās kiberdrošības likuma 40. pants nosaka ievainojamības novēršanu ne vēlāk kā 90 dienu laikā, ar iespēju pagarināt līdz 180 dienām.

Atkārtotais tests

Labojums, kas nav pārbaudīts, ir hipotēze. Atkārtotajā testā tiek pārbaudīti tieši iepriekšējie atradumi un tas, vai labojums nav radījis jaunu problēmu – piemēram, vai tiesību pārbaude ir pievienota visiem galapunktiem, nevis tikai tam, kas bija ziņojumā. Praktiski atkārtoto testu ir vērts ieplānot jau sākotnējā līgumā, nevis apspriest pēc pusgada.

Vērts saglabāt arī pašu ziņojumu vēsturi. Ja pēc trim testiem atkārtojas viena un tā pati kļūdu klase, problēma nav konkrētā rindiņa kodā, bet izstrādes process – un tieši to ir vērts labot. Kāda pieeja der katram mērķim, salīdzināts ceļvedī par testēšanas veidiem.

Biežākās kļūdas

• Apjoms noteikts pēc tā, kas ir viegli. Vissvarīgākā sistēma paliek ārpus testa tieši tāpēc, ka tā ir kritiska.
• Konti sagatavoti testa pirmajā dienā. Divas dienas gaidīšanas ir divas dienas mazāk pārbaudes.
• Testa vide neatbilst ražošanai. Atradumu trūkums šādā vidē neko nepierāda.
• Ziņojums nonāk tikai pie IT. Lielākā daļa atradumu prasa lēmumu par prioritātēm, ne tikai tehnisku labojumu.
• Nav atkārtotā testa. Bez tā drošības uzlabojums paliek nepierādīts.