IT specialistamsVerslui

Saugumo Operacijų Centras – samdyti iš išorės, ar kurti savo?

Podcast’ai Spotify platformoje

Šiuo metu, vis dažniau linksniuojant NIS2 reglamentą, ne viena organizacija susimąsto ne tik apie reglamento reikalavimų įgyvendinimą, bet ir apskritai apie įmonės pažeidžiamumą bei ieško būdų, kaip patikimai apsisaugoti. Kartais galvojama apie atskirus saugiklius, tačiau taip pat susimąstoma apie Saugumo Operacijų Centrą.

Apie Saugumo operacijų centrą (toliau – SOC), jo keliamus iššūkius bei ar išties lengva suburti kokybišką SOC komandą pasakoja ,,Blue Bridge“ Saugumo operacijų centro vadovas Povilas Kaminskas.

Kodėl SOC?

 

Saugumo Operacijų Centrai – bene sparčiausiai pasaulyje auganti IT sritis. Priežastis paprasta – kiek bebūtų sudiegta automatizuotų užkardymo priemonių (angl. preventions), jos vis tiek nesaugo organizacijos nuo visų grėsmių scenarijų. Be to, jas visas susidiegti yra brangu. Todėl organizacijos nutaria eiti kitu keliu – steigti arba pirkti iš išorės Saugumo Operacijų Centrų (toliau – SOC) paslaugas. Tokių paslaugų esmė – realiu laiku stebėti ir matyti saugumo situaciją organizacijos infrastruktūroje. Neturint SOC, organizacija gali matyti tam tikras atskiras infrastruktūros detales, kas vyksta pavienėse sistemose. Tačiau pilno, viską apimančio organizacijos saugumo vaizdo nėra.  

SOC leidžia aptikti įvairiausius grėsmių scenarijus, ar tai būtų rimtas bandymas įsilaužti, ar nedidelė saugumo spraga, kuria bet kada gali pasinaudoti piktavalis. Pasileidus SOC paaiškėja, kad organizacija patiria po kelis ar net keliolika saugumo incidentų kas mėnesį, nors anksčiau buvo manoma, kad jo nėra nė vieno. Žinoma, kuomet kalbama apie saugumo incidentus, reikia susitarti, šis terminas automatiškai nereiškia patirtos žalos. Absoliuti dauguma saugumo incidentų yra bandymai įsilaužti. Juos laiku aptikus ir užkardžius, tikimybė patirti žalą priartinama nuliui. Bėda ta, kad, neturint SOC, organizacijos nemato saugumo įvykių ir incidentų ir galvoja, kad viskas yra ramu. Tada vieną dieną paaiškėja, kad jos yra nulaužtos, duomenys pavogti arba serveriai užkriptuoti. Gamintojo IBM statistika sako, kad organizacijos, neturinčios SOC, saugumo incidentą vidutiniškai aptinka per 200 dienų. Toks ilgas laikas iš esmės reiškia, kad organizacijos aptinka saugumo incidentą dažniausiai tada, kai patiria žalą. Puikus to pavyzdys – šių metų kovo 30d., kuomet ,,AT&T” – didžiausia JAV telekomunikacijų bendrovė – paskelbė, kad tamsiajame internete nutekėjo milžiniškas klientų asmeninės informacijos duomenų rinkinys. Tai palietė net 73 milijonus individų. Manoma, kad šie duomenys buvo pavogti dar 2021 metais, kuomet įsilaužėliai grasino, jog pavogė žmonių duomenis, tačiau to iki galo nebuvo išsiaiškinta (šaltinis: ,,TrendMicro” blog, AT&T Data Leak Affects 73 Million Past and Present Customers | Trend Micro News ). Vadinasi, jeigu organizacija būtų laiku užkardžiusi vien bandymą įsilaužti, šio skandalo, kurio atgarsiai siekia net 2021 metus, galėjo ir nebūti – organizacijos, turinčios SOC, saugumo incidentus aptinka per dieną, valandą ar net keliolika minučių. 

Tačiau svarbu suprasti, kaip SOC suteikia tokią didžiulę vertę organizacijai. Visų pirma, nėra taip, kad tik pasirašius sutartį su SOC tiekėju ir pradėjus teikti SOC paslaugas, organizacija tampa iš karto saugi. Saugumo lygio padidinimas organizacijoje yra gana ilgas tęstinis darbas, kuomet SOC komanda ir IT priežiūros komanda tampa vienu bendru dariniu, kurio pagrindinis tikslas – apsaugoti organizaciją nuo kibernetinių atakų. Pasirašius SOC sutartį arba sukūrus savo SOC, pirmas pusmetis ar metai pareikalauja daug intensyvaus darbo tiek iš SOC komandos, tiek iš priežiūros komandos. Visiems atsiranda darbo siekiant sustyguoti SOC veiklą, aprašyti ir paleisti grėsmių scenarijus, atlikti organizacijos saugumo higieną. Pradėjus SOC vystymą organizacijoje, svarbu ne tik techninė, tačiau ir komunikacinė dalis.  Priežiūros komanda iš SOC komandas pradeda gauti nemažą kiekį informacijos, kas dažnai gali kelti nepatogumą nepasitenkinimą. Toks situacijos pasikeitimas veda prie priežiūros proceso peržiūros, naujų darbo tvarkų. Iš savo SOC klientų matome, kad pereinamasis laikotarpis, kuomet SOC integruojasi į organizaciją, trunka 3-12 mėnesių. O SOC vystymas vyksta nepertraukiamai ir, maždaug po 1-2 metų, tiek mes, tiek klientai gali pasakyti, kad jų organizacijos saugumas pakilo į juntamai aukštesnį lygį. 

SOC iššūkiai 

 

Su pirmaisiais SOC iššūkiais susiduriama jau pačioje pradžioje, kuomet pradedama galvoti apie SOC įkūrimą ar paslaugos įsigijimą. 

SOC veiklos supratimas

 

SOC – tai visiškai naujo tipo veikla organizacijoje, kuri to neturi. Tai nėra „dar viena“ priežiūros veikla. Tai visiškai naujas konceptas organizacijoje ir dažniausiai nėra žinių, ko reikia, kad toks darinys organizacijoje atsirastų, ką reikia įgyvendinti ir kaip pasiekti normų rezultatų. Dažna mūsų klientų užklausa – ar galite mums aprašyti SOC procesus. Iš tiesų, ko norima paklausti – ar galite mums įkurti SOC? Mes, kaip tiekėjas, irgi esame perėję per šį procesą. Norinčių konsultuoti šia tema rinkoje yra labai nedaug, o ir konsultacijų lygis itin skiriasi. Iš tiesų, siekiant sukurti savo SOC, reikia nuo pat pradžių dedikuoti žmones, kurie turi reikiamus IT paslaugų vystymo gebėjimus. Dalį žinių galima susirinkti iš išorės konsultantų ir viešoje erdvėje esančios medžiagos. Tačiau, mano nuomone, nėra vienos tokios įmonės pasaulyje, kurią pasamdžius būtų suplanuotas ir įgyvendintas pilnas SOC paleidimas organizacijoje. Mano jau minėti SOC procesai – tai tik maža dalis to, ką organizacijos turi pasidaryti. Procesai – tai aprašymas, kaip veikia SOC. Tačiau ką veikia SOC, kokių gebėjimų tam reikia, kokių tikslų siekiama, yra atskiros svarbios temos, kurias reikia apgalvoti. Didelė darbų dalis, kurios iš anksto nesuplanuos joks konsultantas, tai plano realizavimas, iššūkiai, su kuriais susiduriama pradedant tiekti SOC paslaugas.  

Komanda

 

Vienas didžiausių iššūkių, su kuriais susiduria bene visi SOC – surinkti tinkamas kompetencijas turinčius žmones. Ši IT sritis yra bene sparčiausiai auganti tiek pasaulyje, tiek ir Lietuvoje. Iš tiesų, SOC veiklai reikia ne tik saugumo analitikų, bet ir kitų, ne mažiau retų ar net dar retesnių kompetencijų: 

  • IT paslaugų kūrėjas. Tai žmogus, atsakingas už pačios paslaugos sukūrimą ir suformavimą.  
  • SOC architektas. SOC architektas taip pat dalyvauja įrankių diegime (dažnu atveju netgi diegia pats), testavime. Tai yra kertinė rolė viso SOC vystyme. Vystymo darbų kiekis, teikiant SOC paslaugas, yra milžiniškas, todėl labai svarbu atskirti šią rolę nuo kasdieninės rutininės saugumo analitikos.  
  • Saugumo analitikai. Tai žmonės, kurie, dirbdami su SOC įrankiais, atlieką nuolatinę, kasdienę, rutininę kibernetinio saugumo analitiką. Tai yra ta rolė, kuri patenka po paslaugos SLA, turi užtikrinti reagavimo laikus, dirbti su įrankiais nepertraukiamai ir būti pasiruošusi reaguoti į įvykius čia ir dabar. SOC sėkmė priklauso nuo greito reagavimo, todėl nėra tinkama, kad saugumo analitikas „peržiūrės įvykius, kai turės laiko“. Saugumo įvykiai yra aukščiausio prioriteto įvykiai organizacijoje, todėl būtina garantuoti, kad dirbančio su SOC įrankiais saugumo analitiko prioritetas Nr. 1 visuomet yra SOC kibernetinio saugumo analitika.  

O kaip pritraukti ir, svarbiausia, išlaikyti tokius specialistus? Dauguma specialistų nori dirbti tokiame SOC, kuris yra didelis, pažangus, aptarnauja didelį kiekį įvairių įdomių klientų. Ateidami dirbti, žmonės tikisi, kad procesai bus sutvarkyti, darbo bus pakankamai ir įdomaus, komandoje dirbs geri specialistai, bus iš ko mokytis, bus numatytos karjeros galimybės. SOC saugumo analitiko darbas reikalauja disciplinos, atsakomybės prisiėmimo, rūpesčio kliento saugumu, tuo pačiu yra gana pastovus, rutininis ir pasikartojantis.  

Turėti savo, ar samdyti iš išorės? 

 

Kodėl nėra rezultato?

 

Mes labai aiškiai matome, kad prieš keletą metų savo SOC pasileidę organizacijos keičia strategiją ir ateina pas mus ieškodami SOC paslaugos iš išorės. Lietuvoje liko labai nedaug organizacijų, kurios sugeba turėti savo SOC ir tai, pagrinde, didelės įmonės. Organizacijos įvardina dvi pagrindines priežastis:  

  1. SOC specialistai išeina kitur, o naujų rasti sunku, 
  2. SOC vystymo progresas per mažas. 

Dažnu atveju organizacijos mato, kad, per, tarkime, tris gyvavimo metus, SOC stipriai nepasikeitė ir nepaaugo kokybiškai. Ir tai yra visiškai normalu ir suprantama. Dažnai vidiniuose organizacijų SOC dirba vienas arba du specialistai ir neapima visų kompetencijų, kurias įvardinau anksčiau. Būtent reikiamas kompetencijų plotis dažnai ir yra stabdantis progresą kriterijus. SOC tiekėjai yra visiškai kitokioje situacijoje. Komandoje yra SOC architektai, SOC paslaugų vystytojai, didelis saugumo analitikų kiekis. Visi mokosi vieni iš kitų, kompetencijos greitai auga, kai kurių žmonių tiesioginė ir vienintelė atsakomybė yra SOC vystymas. Ir tuomet tas progresas ir rezultatai yra.  

Didelė komanda leidžia turėti dedikuotus žmones paslaugų, naudojamų technologijų vystymui, teikimo kokybės užtikrinimui ir gerinimui, saugumo analitikai. Visa tai, daugeliu atveju, nėra racionalu turėti organizacijoje, kuri, pavyzdžiui, teikia teisines konsultacijas ar prekiauja elektronikos prekėmis. 

Reikia įsivertinti darbo krūvius

 

Nepriklausomai nuo to, ar tai vidinis, ar išorinis, SOC yra organizacinis darinys, kuris teikia tam tikras paslaugas. Rinkoje matome besikuriančius naujus SOC tiekėjus ar organizacijas svarstančias apie nuosavo SOC įkūrimą ir pastebime, kad didžioji dauguma jų kalba tik apie SIEM paslaugą. Neneigiu ir pritariu – SIEM yra SOC pamatas ir startuoti reikėtų būtent nuo to. Tačiau SOC nelygu SIEM. Palyginkime tai su pardavėjų komanda organizacijoje. Pardavėjai neparduoda vieno produkto ar vienos paslaugos, jie parduoda visą organizacijos produktų ir paslaugų krepšelį. Lygiai taip ir SOC – tai ne SIEM paslauga, o visas saugumo paslaugų paketas. Kalbame apie tokias paslaugas kaip SIEM, EDR, XDR, NDR, pažeidžiamumų valdymas, socialinė inžinerija ir kt. Ir šioje vietoje visi SOC susiduria su iššūkiu, kaip sukurti, paleisti ir teikti visas SOC paslaugas. Vėl gi, organizacijoje, kurioje tam paskiriamas vienas ar du žmonės, tai sunkiai įvykdoma misija. Atsiremiama į kompetencijos plotį ir gylį. Sakysite, bet jeigu organizacija tikrai didelė, tuomet galima skirti daug žmonių SOC komandai ir jie visa tai padengs? Tiesa, tačiau reikia atkreipti dėmesį į efektyvumą ir atsiperkamumą. Vieni įrankiai, kaip, pvz., SIEM, reikalauja nuolatinio dėmesio, tačiau kiti, kaip, tarkime, pažeidžiamumų valdymas, reikalauja dėmesio kartą per mėnesį. Todėl labai realu, kad jūsų suburta didžiulė komanda nebus užpildyta darbu. Priminsiu, kad komandos dydis reikalingas dėl reikalaujamų kompetencijų pločio, tačiau komandos apkrovimas gali būti labai žemas. Štai tokiu būdu išorinis paslaugos tiekėjas gali SOC suteikti už patrauklesnę kainą – savo brangius resursus ir plačią kompetenciją jis dalina per klientus, todėl sugeba ne tik turėti didelę komandą, bet ir ją efektyviai apkrauti darbu. O klientui netenka mokėti už pilną tam tikros kompetencijos etatą, o tik už dalį to etato laiko reikalingo paslaugai suteikti.

 

Su ,,Blue Bridge” siūlomomis Saugumo Operacijų Centro paslaugomis galite susipažinti čia.

 

Straipsnio partneris:

soc

Įvertink šį straipsnį

    Prenumeruokite ir gaukite žinias pirmieji

    Taip pat skaitykite

    Skaityti daugiau
    Skaityti daugiau