Sekite 15min Google
Priežastis nėra vien mada. „Verizon“ kasmetinėje duomenų pažeidimų tyrimo ataskaitoje nurodoma, kad beveik pusė (44 proc.) analizuotų incidentų buvo susiję su išpirkos reikalaujančiomis programomis, o tokios atakos dažniausiai taikosi ne į geriausiai apsaugotus, o į lengviausiai pasiekiamus taikinius. Mažesnės įmonės, turinčios ribotus IT išteklius, į šią kategoriją patenka dažniau, nei norėtų pripažinti.
Tuo pat metu keičiasi ir pati verslo aplinka, kurioje veikia SVV sektorius. Vis daugiau mažesnių įmonių tampa didesnių, reguliuojamų organizacijų tiekėjomis ar partnerėmis, o tai reiškia, kad jų saugumo lygis nebėra vien jų pačių reikalas. Jei nedidelė IT ar paslaugų įmonė turi prieigą prie didesnio kliento sistemų ar duomenų, jos pažeidžiamumas tampa ir kliento rizika. Būtent todėl vis daugiau sutarčių šiandien numato kibernetinio saugumo audito ar įsilaužimų testavimo reikalavimus jau jų pasirašymo etape.
Kas iš tikrųjų vyksta per įsilaužimų testavimą (pentest)
Rinkoje terminas „įsilaužimų testavimas“ arba pentest dažnai vartojamas laisvai, apimant labai skirtingo gilumo paslaugas – nuo automatizuoto, kelias valandas trunkančio skenavimo iki kelias savaites trunkančios rankinės analizės, kurios metu specialistai bando realiai pasiekti sistemą taip, kaip tai darytų užpuolikas.
Profesionalioje praktikoje skiriami keli testavimo tipai, priklausomai nuo to, kiek informacijos apie sistemą testuotojai gauna iš anksto. „Juodosios dėžės“ (angl. black box) testavimas imituoja išorinį užpuoliką, neturintį jokios informacijos apie sistemos vidų – testuotojai turi patys viską atrasti taip, kaip tai darytų realus piktavalis. „Pilkosios dėžės“ (angl. grey box) metodas suteikia dalinę informaciją, pavyzdžiui, vartotojo teises, ir imituoja situaciją, kai užpuolikas jau turi tam tikrą prieigą, tarkime, per pavogtus prisijungimo duomenis. „Baltosios dėžės“ (angl. white box) testavimas atliekamas turint visišką prieigą prie kodo ir architektūros dokumentacijos, todėl leidžia giliausiai išanalizuoti sistemos logiką, tačiau mažiau atspindi realaus išorinio užpuolimo scenarijų.
„Didžiausia klaida, su kuria susiduriame, – įmonė mano, kad kibernetinis saugumas yra vienkartinis projektas, po kurio galima viską pamiršti“, – sako „Baltic Amadeus“ informacijos saugumo vadovas Gabrielius Vinciūnas, dirbantis su įvairaus dydžio įmonėmis Lietuvoje. „Sistema, kuri buvo saugi prieš metus, per tą laiką pasikeitė – atsirado naujų integracijų, naujų darbuotojų, naujų įrankių. Kiekvienas pokytis gali tapti potencialia rizika.“
Pasirinkimas tarp šių metodų priklauso nuo to, ką įmonė nori sužinoti. Jei tikslas yra suprasti, ką realiai galėtų pasiekti pašalinis užpuolikas, racionaliausia rinktis juodosios dėžės testavimą. Jei rūpi, kaip giliai vidinis pažeidimas ar pavogta prieiga galėtų paveikti sistemą, tinkamesnis pilkosios ar baltosios dėžės metodas. Nemaža dalis tiekėjų šiuos skirtumus paaiškina nepakankamai aiškiai arba jų apskritai nemini, todėl užsakovui verta pačiam paklausti, kokiu principu bus vykdomas testavimas.
Kada tai tampa aktualu praktiškai
Pagal „Baltic Amadeus“ eksperto pastebėjimus, dažniausiai testavimo poreikis SVV segmente iškyla trimis momentais:
- prieš paleidžiant naują produktą ar platformą, kuri tvarko mokėjimus ar asmens duomenis,
- po reikšmingo infrastruktūros pokyčio, pavyzdžiui, migravimo į debesiją, naujo tiekėjo prijungimo,
- kai įmonė pradeda dirbti su didesniais, reguliuojamais klientais, kurie patys reikalauja saugumo įrodymų iš savo partnerių.
Pastarasis punktas tampa vis dažnesnis: didelės, reguliuojamos organizacijos savo tiekimo grandinės saugumą vertina vis atidžiau. Tai reiškia, kad net nedidelė įmonė, norinti tapti tiekėja, gali susidurti su reikalavimu parodyti, jog jos sistemos buvo tikrintos. Kai kuriose pramonės šakose, kaip finansų, sveikatos apsaugos, energetikos, tokie reikalavimai jau tapo standartine sutarčių dalimi, o ne išimtimi.
Ketvirtasis, rečiau minimas, bet praktikoje vis svarbesnis momentas – kai įmonė pati pastebi neįprastą aktyvumą savo sistemose, tačiau negali tiksliai nustatyti, ar tai realus incidentas, ar klaidingas pavojaus signalas. Tokiu atveju kryptingas testavimas padeda ne tik atsakyti į konkretų klausimą, bet ir sustiprinti bendrą stebėsenos sistemą ateičiai.
Ką rodo įsilaužimų testavimo praktika: dažniausi radiniai
Nors kiekvienos organizacijos situacija skiriasi, praktikoje pasikartoja tam tikri modeliai. Dažniausiai testavimo metu aptinkamos problemos nėra itin sudėtingos technologiškai. Priešingai, identifikuotos spragos, dažnu atveju, yra paprasti, ilgą laiką nepastebėti dalykai:
- pasenę arba bendrinami prisijungimo duomenys,
- testinės aplinkos komponentai, palikti ir pamiršti po produkto paleidimo,
- seniai peržiūrėtos ir pernelyg plačios prieigos teisės, dažnai suteiktos „dėl patogumo“.
Ilgametę patirtį Lietuvos kibernetinio saugumo rinkoje turinčios „Baltic Amadeus“ komanda, dirbdama su finansų sektoriaus ir kitomis reguliuojamomis organizacijomis, ne kartą fiksavo atvejus, kai atskiros, iš pažiūros nereikšmingos spragos, sujungtos į vieną scenarijų, sudarydavo realų kelią iki jautrių duomenų. Būtent tokių sudėtinių scenarijų atradimas ir yra pagrindinis skirtumas tarp paviršutiniško patikrinimo bei tikro įsilaužimų testavimo – automatizuotas įrankis atskirą spragą pažymės kaip žemos rizikos, tačiau nepamatys, kaip ji susijungia su kitomis.
Kaina, apie kurią retai kalbama iki incidento
IBM duomenų pažeidimų kaštų ataskaitoje vidutinė incidento kaina organizacijai įvertinta maždaug 4,45 mln. JAV dolerių, įskaičiuojant prastovas, klientų netektį ir teisines pasekmes. Dauguma Lietuvos SVV įmonių tokio masto nuostolio nepatirtų, tačiau net ir vidutinio dydžio sutrikimas, pavyzdžiui, sustabdyta internetinė parduotuvė prieš šventes, nutekėję keliasdešimt klientų įrašų ar priverstinė gamybos linijos prastova, praktikoje dažnai kainuoja daugiau, nei būtų kainavęs metinis prevencinis įsilaužimų testavimas.
Netiesioginiai kaštai dažnai lieka nepastebėti planuojant biudžetą iš anksto:
- laikas, kurį komanda praleidžia tvarkydama incidento pasekmes vietoje įprasto darbo,
- klientų ar partnerių pasitikėjimo praradimas,
- galimas sutarčių nutraukimas, jei incidentas paveikė ir kliento duomenis.
- Šie kaštai retai patenka į pradinį svarstymą „ar mums to reikia“, tačiau būtent jie dažniausiai lemia realų finansinį smūgį.
Ko teirautis užsakant įsilaužimų testavimą (pentest)
Įmonei, pirmą kartą svarstančiai apie testavimą, verta iš anksto apsibrėžti kelis dalykus.
- Pirma – kuri sistemos dalis yra svarbiausia ir turėtų būti testuojama pirmiausia: dažniausiai tai klientų prisijungimo, mokėjimų ar asmens duomenų apdorojimo sritys.
- Antra – kokio tipo testavimo reikia šiame etape, atsižvelgiant į tai, kas kelia didžiausią rūpestį: išorinė ataka ar vidinė rizika.
- Trečia – kaip bus vertinama testavimo kokybė, nes vien ataskaitos ilgis ar rastų spragų skaičius nėra geras rodiklis.
Taip pat kalbantis su potencialiu kibernetinių paslaugų tiekėju gali būti pravartūs šie klausimai:
- Ar testavimas bus atliekamas rankiniu būdu, ar tik automatizuotais įrankiais?
- Kokia komandos patirtis dirbant su panašaus dydžio ir sudėtingumo sistemomis?
- Ar ataskaitoje bus paaiškinta, kaip kiekvienas radinys galėtų būti realiai išnaudotas?
- Kas bus atsakingas už radinių ištaisymo patikrinimą po testavimo?
Įsilaužimų testavimo apimtis, pasak Vinciūno, neturi būti „viskas arba nieko“: nedidelei įmonei racionalu pradėti nuo aiškiai apibrėžtos, svarbiausios sistemos dalies ir plėsti apimtį augant verslui. Tokia pakopinė strategija leidžia kontroliuoti biudžetą ir kartu palaipsniui formuoti nuolatinę saugumo kultūrą, o ne vienkartinį, greitai pamirštamą projektą.
Dažniausios klaidos, kurių verta vengti
Renkantis tiekėją, dažna klaida – lyginti vien kainą, neatsižvelgiant į tai, kas už jos slypi. Kainų skirtumas tarp pasiūlymų gali siekti kelis kartus, ir tai nebūtinai reiškia, kad brangesnis variantas yra geresnis vien todėl, kad jis brangesnis. Tačiau tai reiškia, kad be konteksto kaina yra prastas atrankos kriterijus.
Kita praktikoje matoma klaida – pasitenkinti vien sertifikatų sąrašu, nepasidomint konkrečia komandos patirtimi dirbant su panašaus sudėtingumo projektais. Sertifikatai, tokie kaip CEH, OSCP ar CISSP, rodo bazinį žinių lygį, tačiau neatskleidžia, kaip specialistas elgsis susidūręs su nedokumentuota, individualiai sukurta įmonės IT aplinka.
Trečia klaida – nepasitikrinti, ar tiekėjas dirbo su panašaus dydžio ar to paties sektoriaus organizacijomis. Finansų, sveikatos apsaugos ar kitų reguliuojamų sričių projektai reikalauja ne tik techninių žinių, bet ir supratimo apie atitikties reikalavimus bei tai, kaip saugumo procesai veikia sudėtingoje, realiai funkcionuojančioje organizacijoje. Ketvirta ir, ko gero, svarbiausia klaida – nepasitikrinti, kaip aiškiai apibrėžiama testavimo apimtis prieš pasirašant sutartį. Neaiškiai apibrėžta apimtis yra dažniausia priežastis, kodėl projektai vėluoja arba nepasiekia realios vertės.
Ką tai reiškia įmonei per artimiausius metus
SVV segmento įmonėms, kurios iki šiol saugumo testavimą laikė didelių korporacijų reikalu, artimiausi metai greičiausiai atneš pokytį. Dalis jo bus savanoriška, motyvuota noru apsisaugoti nuo realios rizikos, dalis – primesta iš išorės, dėl didesnių partnerių ar klientų reikalavimų.
Įmonėms, kurios pradeda ruoštis iš anksto, o ne tada, kai reikalavimą jau pateikia klientas ar reguliatorius, procesas paprastai kainuoja mažiau, vyksta sklandžiau ir sukelia mažiau sutrikimų kasdienei veiklai.