Saugumas – viena pamatinių sričių siekiant sklandaus organizacijos veikimo. Dažnai, siekiant stiprinti saugumą, diegiamas Saugumo Operacijų Centras (toliau – SOC, angl. Security Operations Center) arba Saugumo informacijos ir įvykių valdymas (toliau – SIEM, angl. Security information and event management). Tačiau kaip žinoti, jog šie sprendimai veikia tinkamai?

Apie tai, kaip vertinti Saugumo operacijų centro bei darbuotojų, dirbančių su šiuo sprendimu, veiklą, remdamasis 2020m. atlikta klientų apklausa, dalijasi,,Blue Bridge“ Saugumo operacijų centro vadovas Povilas Kaminskas.

 

Kodėl ,,geras” SOC?

Žodį „geras“ pasirinkau ne atsitiktinai. Apibūdinti sėkmingai dirbantį SOC galima įvairiais terminais: efektyvus, greitas, ekonomiškai patrauklus, pažangus ir pan., tačiau dažniausiai, dalinantis savo patirtimi neformalioje aplinkoje, naudojama skalė „Blogai – Puikiai“. Kai sutinkate pažįstamą iš kitos organizacijos ir klausiate jo „kokia tavo patirtis su X tiekėju?“, jo atsakymas greičiausiai bus „gera“, „puiki“ ar „prasta“. Turbūt to žmogaus pirmas atsakymas nebus „dirba efektyviai“. Todėl ir vertinti SOC darbą norisi šitoje skalėje. Taigi, kas yra „gerai“ dirbantis SOC?

Ilgas reakcijos laikas

 

Kuomet prieš 4 metus kūrėme Blue Bridge SOC, atlikome keliasdešimties Lietuvos įmonių apklausą šia tema. Nesiuntėme klausimynų, važiavome į gyvus interviu. Vienas labai aiškus kriterijus, kuris buvo įvardintas kaip probleminis, vertinant tuomet Lietuvoje veikusius SOC centrus ir tiekėjų teikiamas SOC paslaugas, buvo reagavimo greitis. Klientai sakė, kad nors ir gauna paslaugą iš išorinio tiekėjo, reagavimas į saugumo įvykius užtrunka kartais net kelias paras. Šis nusiskundimas skambėjo daugelį kartų ir tapo akivaizdu, kad klientams tai svarbu. Atrodytų, tai yra bendras suvokimas ir nieko naujo mums klientai nepasakė. Ir, visgi, pasakė. Pasakė tai, kad tuo metu rinkoje teikiamos paslaugos neatitiko kokybės kriterijų ir lūkesčių, kuriuos klientai turėjo reagavimui į kibernetines grėsmes. Tapo akivaizdu, kad „geras“ SOC turi greitai reaguoti į saugumo įvykius. Jeigu svarstysite įsigyti paslaugą iš išorės, paklauskite SOC tiekėjo, koks buvo faktinis praeito mėnesio vidutinis reagavimo laikas į visus saugumo įvykius. Gavę atsakymą suprasite, kad ne visi SOC tiekėjai kelia vienodus kokybinius reikalavimus SOC paslaugai. Vieni SOC centrai užtikrina žaibiškus reagavimo laikus į kiekvieną saugumo įvykį, o kiti skirsto saugumo įvykius į svarbius ir nesvarbius pagal tai suteikdami skirtingus reagavimo laikus. Viešuose pirkimuose dažnai matau SLA (paslaugų teikėjo ir kliento susitarimas; angl. service-level agreement) lentelę, kurioje į „svarbius“ įvykius prašoma sureaguoti per 4 valandas, o į „nesvarbius“ – per 16 valandų. Bėda ta, kad saugumo įvykis negali būti „svarbus“ ar „nesvarbus“, nes jis dar nėra saugumo incidentas. Laiku neapdorotas „nesvarbus“ saugumo įvykis gali reikšti dar du ar tris papildomus susijusius „nesvarbius“ laiku neapdorotus saugumo įvykius, o rezultate – didžiulį saugumo incidentą.

SOC darbo matavimas ir apibrėžtis

 

Kita viešųjų pirkimų realija tokia, kad SOC SLA vis dar dažnai aprašomas pagal priežiūros SLA principus. T.y., reagavimo laikai nustatomi pagal Incidento įtaką organizacijos veiklai. Matau didžiausias lenteles, kuriose aprašomi įvairūs scenarijai, tokie kaip „visos organizacijos veikla sutrikusi ilgiau nei valandai“ arba „neveikia kritinės sistemos ir tai liečia daugiau nei pusę organizacijos darbuotojų“. Tokie SLA parametrai visiškai netinkami SOC veiklai. Mano įvardinti pavyzdžiai rodo, kad saugumo incidentas jau įvykęs ir patiriama milžiniška žala. Tačiau jeigu SOC dirba gerai, jis aptinka jau pačius pirmuosius bandymus „laužtis“ į organizaciją ir, kartu su priežiūros komanda, juos užkardo. Tam, kad įsilaužėlis pasiektų savo tikslus ir organizacija patirtų žalą, reikia atlikti visą eilę veiksmų, t.y., įgyvendinti atakos grandinėlę. O jei SOC dirba tinkamai ir aptinka jau pačius pirmuosius įsilaužėlio veiksmus, jo galimybės įgyvendinti visą atakos grandinėlę priartinamos nuliui ir realybėje žalos niekada nepatiriama. Taigi, netikslinga ruošti didžiules lenteles, aprašančias saugumo incidento įtaką organizacijos veiklai ir pagal tai matuoti SOC darbą, nes, greičiausiai, per metus laiko nei vieno tose lentelėse aprašomo scenarijaus nebus. SOC darbą reikia matuoti pagal reagavimo greitį ir jį taikyti vienodą visiems saugumo įvykiams organizacijoje. Tai ne tik paprastas būdas aprašyti SLA, bet ir efektyvus būdas užtikrinti tinkamą organizacijos grėsmių aptikimą.

Netinkamas žmogiškųjų išteklių paskirstymas

 

Bandymas sutaupyti prie gero nepriveda

Antrasis nusiskundimas 2020 metais atliktoje apklausoje buvo toks, kad tiekėjai neskiria pakankamai žmogiškųjų išteklių apdorojamam klientų kiekiui. Pasak apklaustųjų, tai jausdavosi ne tik per labai ilgą reagavimo laiką, tačiau ir per skiriamą dėmesį organizacijai bei su jomis dirbančių tiekėjo atstovų galimybes gilintis į aptarnaujamos įmonės specifiką.

Pirmiausia, labai svarbu atskirti du dalykus – komandos dydis ir komandos efektyvumas. Abu šie parametrai nusako, kaip gerai yra organizuotas SOC darbas. Jau rašiau anksčiau, kokių kompetencijų reikia, kad SOC dirbtų kokybiškai. Komandos dydis su tuo turi tiesioginį ryšį. Visų pirma, komandoje turi būti aiškiai atskirtos rolės: architektai, naudojamų platformų diegimo ir priežiūros specialistai, grėsmių, saugumo analitikai. Tie, kas perėjo per SOC sukūrimą ir vystymą, aiškiai žino, kad bandymas sukrauti visas roles vienam žmogui lemia neefektyvų darbą. Pirmas dalykas – reikia labai daug ir plačiai mokytis: projektų valdymo, įrankių (dažnai ne vieno, o kelių) diegimo, įrankių priežiūros, įrankių vystymo, saugumo analitikos, grėsmių analitikos ir kitų kompetencijų. Tas nėra fiziškai įmanoma, o toks žmogus spėja paliesti tik patį žinių paviršių ir darbai atliekami sunkiai judant į priekį, susiduriant su daug nežinomųjų, darant daug klaidų. Neturint dedikuotų žmonių specifinėms rolėms, SOC vystymo progresas yra lėtas, nes bandoma susitvarkyti su užduočių kiekiu, sudėtingumu, kylančiomis problemomis ir nelieka laiko SOC vystymui.

Tačiau toks modelis, kuomet daug rolių sutelkiama viename žmoguje, yra gana plačiai sutinkama praktika. Kodėl taip yra? Tokiu būdu siekiama sumažinti investicijas. Sukurti ir paleisti SOC (ar vidinį, ar kaip komercinę paslaugą) – didelė investicija. SOC paleidimas yra tam tikras verslo planas. Kuomet paskaičiuojami kaštai ir pajamos, pamatoma, kad lūžio taškas yra po trijų metų, dažnai vadovams tai nėra priimtinas terminas. Tada bandoma optimizuoti, ieškoma būdų sutaupyti, o pagrindinė išlaidų eilutė, kaip ir daugumoje verslų, yra žmogiškieji resursai. 30% sumažinus komandą, lūžio taškas pasislenka dvigubai arčiau. Rezultate visi patenkinti planu, tačiau iš tikrųjų tai – didelė klaida. Nepakankama komanda dirbs neefektyviai, SOC vystymo progresas bus labai lėtas ir, atėjus lūžio taško datai paaiškės, kad rezultatai kardinaliai skiriasi nuo plano.

Kokybė priklauso nuo kiekybės?

Visų rolių sutelkimas viename asmenyje sukelia visą eilę veiklos ir efektyvumo problemų, apie tai būtų galima parašyti atskirą straipsnį. Taigi, rolių atskyrimas yra svarbi komandos efektyvumo dalis ir ji veda prie sekančių svarbių komandos darbo parametrų: standartizavimo ir automatizavimo. Atskirtose rolėse žmonės turi galimybę sutelkti dėmesį į tai, kaip yra teikiama paslauga. Žmogus, kuris rūpinasi paslaugų teikimu, suka galvą, kaip padaryti, kad vienas saugumo analitikas galėtų aptarnauti kuo daugiau įmonių. Nesupraskit neteisingai, tai labai skiriasi nuo to, ką galima rasti neefektyviame SOC, kuomet atėjęs saugumo analitikas gauna tris klientus, vėliau ketvirtą, penktą ir tas skaičius yra didinamas tol, kol atsiranda kokybės problemų, krūvis viršija galimybes, kuomet pradedama gauti klientų skundus ir t.t. Efektyviame SOC dedikuotas žmogus rūpinasi, kaip standartizuoti, optimizuoti saugumo analitikų veiklą, kaip jiems suteikti papildomas priemones atlikti paskirtą darbą greičiau. Taip pat dirbama su klientu – siekiama, kad saugumo analitiko perduodama informacija būtų vertinga klientui, kad būtų dirbama su realiomis grėsmėmis, o ne bandoma susidoroti su klaidingais aliarmais.

Yra visa eilė priemonių, kaip padėti saugumo analitikams nešvaistyti laiko, nedaryti to paties per tą patį, padėti rasti informaciją apie pasikartojančius įvykius, dalintis patirtimi tarpusavyje ir pan. Nuolatinis dėmesys paslaugų teikimo vystymui leidžia SOC komandai dirbti efektyviai ir žmonių skaičiumi augti lėčiau nei ateinančių klientų kiekis. Neefektyviame SOC klientų aptarnavimo greitis ir kiekis pagrinde priklauso nuo kiekvieno saugumo analitiko asmeninių gebėjimų ir greičio, o saugumo analitikų kiekis auga lygiai su augančiu aptarnaujamų klientų kiekiu. O tai daro tiesioginę neigiamą įtaką kaštams. Išeitys yra dvi – branginti paslaugas (tačiau neturint aiškaus kokybinio pranašumo prieš konkurentus to padaryti neįmanoma) arba reikalauti maksimumo iš esamų žmonių ir tokiu būdų nedidinti kaštų. Deja, gaudami nežmonišką krūvį saugumo analitikai neatlaiko, išeina kitur ir toks SOC staiga susiduria su dar didesne problema – darbuotojų trūkumu. Tuomet ir atsiranda klientų nusiskundimai, kad reaguojama lėtai, nesigilinama į organizacijos specifiką, neskiriama pakankamai laiko.

Taigi, siekiant ,,gero“ SOC labai svarbu nuo pat jo starto investuoti į reikiamas roles, atskirti teikimo ir vystymo roles, skirti didelį dėmesį veiklos standartizavimui ir efektyvinimui ir, nors atsipirkimo lūžio taškas pradžioje atrodo labai toli, jį peržengus su tinkama strategija ir tinkamai paruošta komanda rezultatai ,,šauna į dangų”.

Daugiau informacijos apie SOC paslaugas: https://bluebridge.lt/paslaugos/soc/