Kiteworks po visuotinio išjungimo: spraga rasta, įsilaužimo požymių nėra

Rugsėjo 28 d. „Kiteworks“ pranešime nurodyta, kad po prevencinio klientų sistemų išjungimo pataisyta anksčiau nežinoma kritinė spraga mažiau nei 1 % klientų įjungtoje funkcijoje, sistemas galima atkurti, o įsilaužimo ir spragos išnaudojimo požymių nenustatyta. Ši išvada remiasi tiekėjo stebėsena; atskiros organizacijos dar turi įsitikinti, kad jų pačių valdoma aplinka parengta darbui.

Rugsėjo 25 d. pirminiame „Kiteworks“ perspėjime klientų prašyta laikinai išjungti sistemas gavus federalinių institucijų informaciją apie galimą artėjančią ataką; saugumo vadovas Frankas Balonis perspėjo, kad „a threat actor may attempt to target some Kiteworks systems“. Prašymas buvo prevencinis: tuo metu duomenų apie įsilaužimą nebuvo. Klientams dabar svarbu patvirtinti pataisos būklę ir patikrinti veiklą po paleidimo.

Nuo perspėjimo iki leidimo atkurti sistemas

Pirmas sprendimas buvo sumažinti galimos atakos poveikį, kol jos būdas dar nebuvo nustatytas. Savarankiškai valdomas sistemas, įrengtas organizacijos patalpose arba AWS ir Azure aplinkose, turėjo išjungti patys klientai; tiekėjo prižiūrimas aplinkas stabdė „Kiteworks“. Šis skirtumas svarbus ir atkuriant darbą: vieni klientai patys valdo sustabdymo bei paleidimo eigą, o kiti laukia tiekėjo valdomos paslaugos grąžinimo.

Atnaujintame pirminiame perspėjime sekmadienį jau buvo leista sistemas paleisti, o tiekėjo prižiūrimos aplinkos vėl veikė. Vėlesniame viešame pranešime paaiškinta, ką komandos nuveikė per pauzę: kartu su federalinėmis institucijomis tyrė grėsmę, rado iki tol nežinomą pažeidžiamumą, parengė ir įdiegė pataisą. Visose aplinkose dar pritaikytas papildomas apsaugos sluoksnis.

Visuotinis nurodymas nereiškė, kad pažeidžiama buvo kiekviena „Kiteworks“ įdiegta sistema. Perspėjimo metu galimos atakos kelias nebuvo aiškus, todėl tiekėjas ragino laikinai sustabdyti platesnį sistemų ratą. Tik tyrimo metu paaiškėjo, kad rasta spraga susijusi su retai įjungta galimybe. Dėl šios įvykių sekos plačiai taikyta apsaugos priemonė ir siaura galutinė pažeidžiamumo apimtis viena kitai neprieštarauja.

Kur rasta spraga ir ką reiškia stebėsenos išvada

„SecurityWeek“ aprašytame klientams siųstame pranešime pažeidžiamumas siejamas su „Advanced Forms“ duomenų surinkimo produktu. Oficialus viešas atkūrimo pranešimas funkcijos neįvardijo, tačiau nurodė, kad kiti „Kiteworks“ produktai nepaveikti. Todėl vien naudojimasis failų perdavimo paslauga dar nepasako, ar konkrečioje aplinkoje buvo įjungta paveikta galimybė.

Neigiama stebėsenos išvada apima laikotarpį, dėl kurio buvo paskelbtas perspėjimas: neįprastos veiklos, spragos išnaudojimo ar sistemų kompromitavimo požymių nenustatyta. Tai svarbu vertinant įvykio baigtį, bet neatsako į kiekvieno savarankiškai valdomo diegimo klausimus: ar pataisa iš tiesų pritaikyta, ar paslauga paleista teisinga konfigūracija ir ar vietiniai žurnalai rodo tą patį.

Savarankiškai talpinantiems „Advanced Forms“ klientams nurodyta kreiptis į „Kiteworks“ pagalbos komandą. Tai konkretesnis veiksmas už bendrą leidimą grįžti prie darbo: tokiai aplinkai reikia tiesiogiai suderinti pataisos bei atkūrimo būklę. Kitoms organizacijoms pirmiausia reikia nustatyti, ar jos apskritai naudojo paveiktą funkciją, kad bendras perspėjimas nebūtų painiojamas su jų konkrečia rizika.

Ką patikrinti po paslaugos paleidimo

Atkūrimas užbaigia prastovą, tačiau organizacijos įvykio įrašas turėtų apimti ir jos pačios veiksmus. Klientams, kurių duomenų mainai priklauso nuo šios paslaugos, svarbu atskirti tiekėjo atliktą darbą nuo to, ką gali patvirtinti tik jų administratoriai.

1. Kontaktai ir atsakomybė. Patikrinkite, ar saugumo perspėjimas pasiekė techninį budėtoją ir už veiklos tęstinumą atsakingą žmogų. Užfiksuokite, kas turi teisę skubiai sustabdyti paslaugą, kai tiekėjo žinia ateina ne darbo metu. Šio įvykio eiga parodė, kad reagavimo laikas priklauso nuo kontaktų grandinės, o ne vien nuo turimų atsarginių kopijų.
2. Faktinė pauzė. Sulyginkite tiekėjo nurodytą laikotarpį su savo sistemos išjungimo ir paleidimo įrašais. Pažymėkite, kurie failų perdavimai, formų pateikimai arba automatiniai darbai buvo pristabdyti, ir patikrinkite, ar eilėje likusios operacijos atsinaujino. Taip suplanuotos prastovos padariniai nebus supainioti su naujais paslaugos sutrikimais.
3. Pataisa ir funkcijos būsena. Nustatykite, ar jūsų aplinkoje įjungta „Advanced Forms“, ir paprašykite patvirtinimo, kokia pataisa ar papildoma apsauga pritaikyta būtent jūsų diegimui. Savarankiškai talpinant šį produktą, atkūrimo klausimą suderinkite su tiekėjo pagalbos komanda. Viešas leidimas atkurti sistemas savaime nenurodo, kokius pakeitimus atliko kliento administratorius.
4. Stebėsena po atkūrimo. Peržiūrėkite prieigos, administravimo ir duomenų mainų įrašus aplink išjungimą bei po paleidimo. Įvertinkite netikėtus prisijungimus, nesėkmingas operacijas ir paslaugos klaidas pagal savo įprastą veiklą; radę neatitikimų, išsaugokite įrašus tyrimui. Taip vietinė stebėsena papildo bendrą tiekėjo vertinimą.

Ką išjungimas parodė apie veiklos tęstinumą

Retas tiekėjo prašymas sąmoningai nutraukti veikiančią duomenų mainų paslaugą iškėlė sprendimą, kurio įprastas atkūrimo planas gali neaprašyti. Organizacijai reikia žinoti, kurie procesai gali palaukti, kaip apie pauzę sužino nuo jų priklausantys žmonės ir kas leidžia juos paleisti atgal. Čia svarbūs ne vien techniniai atkūrimo veiksmai, bet ir galimybė greitai sustabdyti darbą neprarandant informacijos apie neužbaigtas operacijas.

Tiekėjo pusėje pauzė suteikė laiko grėsmei ištirti ir pataisai parengti. Kliento pusėje ji reiškė paslaugos pertrūkį, po kurio reikia atkurti ir nutrūkusius darbo procesus. Paslauga gali būti vėl pasiekiama, nors eilėje likę perdavimai ar formų pateikimai dar nebaigti; jų būklė paaiškėja tik patikrinus konkrečios organizacijos aplinką.

Taip pat skaitykite:

• DI agentai ieškojo spragų, tačiau Australija įsilaužimo nepatvirtino
• MB ar UAB: 1 000 eurų kapitalas nėra svarbiausias skirtumas