SOC paslaugos padeda stebėti organizacijos sistemų saugumo įvykius, įvertinti įspėjimus ir perduoti juos atsakingiems specialistams. Dev4you.lt naudoja Wazuh saugumo analizei ir Zabbix infrastruktūros būklei stebėti; informaciją peržiūrime mūsų biure. Specialistų darbo laikas, reagavimo veiksmai ir žurnalų saugojimas nustatomi paslaugos plane.Aptarti saugumo stebėsenąPeržiūrėti paslaugos informaciją
IŠSAMI PASLAUGOS PATIKRA
Nuosekliai įvertinkite saugumo duomenų aprėptį, analizę, reagavimą ir žurnalų valdymą. Pateikę el. paštą matysite atsakymais pagrįstą sričių apžvalgą, prioritetus ir veiksmus; PDF bus išsiųstas tuo adresu. Tai nėra nepriklausomo audito išvada.
Įmonėms, kurioms reikia nuosekliai vertinti saugumo signalus ir aiškiai perduoti juos atsakingiems žmonėms.
Pateikite svarbių sistemų sąrašą, esamos stebėsenos aprašą ir už IT bei reagavimą atsakingus kontaktus.
Gaunate apibrėžtus stebėsenos šaltinius, signalų vertinimo eigą, eskalavimo tvarką ir atvirų veiksmų apžvalgas.
SOC paslauga sujungia saugumo technologijas, žmonių darbą ir incidentų valdymo procesą. SIEM renka bei analizuoja įvykius, o SOC apibrėžia, kas juos įvertina ir ką daro toliau. Automatinis duomenų rinkimas visą parą savaime nereiškia specialistų budėjimo visą parą.
Saugumo stebėsenos reikia, kai svarbūs įvykiai išsibarstę skirtingose sistemose, įspėjimai neturi aiškaus gavėjo arba vidinė komanda nespėja jų nuosekliai vertinti. Pradedame nuo klausimo, kokius įvykius įmonė turi pastebėti ir kas gali imtis veiksmų. Vien surinkti daugiau žurnalų nepakanka: reikia tikrinamų šaltinių ir sutvarkytos reagavimo tvarkos.
Įvertiname esamą infrastruktūrą, administravimo prieigas ir svarbiausias sistemas. Jei trūksta inventoriaus, atsakingų kontaktų ar bazinės prieigų kontrolės, šiuos pasiruošimo darbus įtraukiame į pradžios planą. Paslauga gali papildyti vidinę IT komandą, išlaikant aiškų pasidalijimą tarp signalų vertinimo ir sistemų administravimo.
Duomenų šaltinių sąrašą sudarome pagal riziką ir technines galimybes. Kiekvienam šaltiniui patikriname, ar reikalingi įvykiai generuojami, ar juos galima perduoti ir ar pranešime užtenka konteksto analizei. Neperduodamas ar nutrūkęs šaltinis turi būti matomas kaip stebėsenos spraga.
Prieš prijungimą aprašome reikalingas teises, renkamus laukus ir administruojantį asmenį. Naują integraciją patvirtiname bandomuoju įvykiu nuo šaltinio iki galutinio pranešimo. Taip įtrauktų sistemų sąrašas remiasi veikiančiu duomenų keliu, o ne vien įdiegtų agentų skaičiumi.
| Šaltinis | Galimi signalai | Įtraukimo sąlyga |
|---|---|---|
| Darbo vietos | Paskyrų, sistemos ir pasirinktų failų įvykiai | Suderinama aplinka, reikalingos teisės ir patikrintas perdavimas |
| Serveriai | Prisijungimai, tarnybų ir sistemų saugumo įvykiai | Įvardyti žurnalai, prieigos ir šaltinio savininkas |
| Tinklo įrenginiai | Pasirinkti ryšio ar saugumo žurnalai | Įrenginio palaikomas formatas ir patikrinta integracija |
| Kitos sistemos | Veiklai aktualūs pasirinktos sistemos įvykiai | Atskirai įvertintos gavimo galimybės ir apimtis |
Wazuh naudojame kaip saugumo duomenų rinkimo ir analizės platformą. Konkrečios funkcijos priklauso nuo prijungtų šaltinių, konfigūracijos ir paslaugos apimties. Diegimo metu pasirenkame, kokius signalus vertinsime, o bandomaisiais įvykiais patikriname jų kelią iki atsakingo asmens. Patikrinta konfigūracija tampa pradine vėlesnių pakeitimų atskaita.
Žurnalų įvykius vertiname pagal šaltinį, laiką ir susijusią veiklą. Taisykles deriname taip, kad įspėjimas turėtų aiškią tyrimo priežastį ir reikalingą kontekstą. Pasikartojantys nereikšmingi signalai peržiūrimi, išsaugant galimybę pastebėti svarbų pokytį.
Failų vientisumo stebėsena padeda pastebėti pasirinktų failų pokyčius. Reikšmingus katalogus ir išimtis parenkame pagal sistemos paskirtį, kad įprastas atnaujinimas būtų atskiriamas nuo netikėto pakeitimo. Signalui reikia konteksto: kas keitė, kada ir ar tuo metu vyko patvirtinti darbai.
Konfigūracijos vertinimo ir pažeidžiamumų matomumo galimybes taikome pasirinktai aplinkai. Gautas signalas padeda nustatyti tikrinimo ar taisymo prioritetą, tačiau jo reikšmę tiksliname pagal komponento naudojimą. Ataskaitoje atskiriame aptiktą būklę, siūlomą veiksmą ir atlikto pakeitimo patikrą.
Wazuh galimybių dokumentacijoje aprašytas įvykių rinkimas ir analizė; platformos funkcijos savaime nenustato specialistų darbo valandų ar reagavimo įsipareigojimų.
Įspėjimą pirmiausia susiejame su šaltiniu ir aplinkybėmis: ar įvykis tikėtinas, kokią sistemą paveikė ir kokių papildomų duomenų trūksta. Toliau nustatome prioritetą ir perduodame informaciją paskirtam kontaktui. Pranešime turi būti aišku, kas pastebėta, kodėl tai svarbu ir kokio sprendimo reikia.
Reagavimo veiksmus aprašome prieš pradedant paslaugą. Paskyros blokavimas, įrenginio izoliavimas ar sistemos sustabdymas gali paveikti veiklą, todėl kiekvienam tokiam veiksmui būtina konkreti leidimo tvarka. Jei sprendimą priima klientas ar jo administratorius, užfiksuojame perdavimo laiką ir tolesnę atsakomybę.
Duomenų rinkimas Taisyklė
Taisyklė Analizė
Analizė Prioritetas
Prioritetas Eskalavimas
Eskalavimas Sutartas veiksmas
Pavyzdinė eiga. Specialistų darbo laikas, perdavimo tvarka ir leidžiami veiksmai apibrėžiami paslaugos apimtyje.
Naudojame bendrą BAN signalų dalijimosi sprendimą, kuris padeda pritaikyti pastebėtus grėsmių požymius kitose įtrauktose aplinkose. Pavyzdžiui, įtartino šaltinio signalas gali būti vertinamas ir perduodamas sutartoms apsaugos priemonėms. Įspėjimas nėra galutinis įrodymas, kad kiekviena to šaltinio užklausa kenksminga, todėl blokavimą deriname su išimtimis, galiojimo trukme ir galimybe ribojimą atšaukti.
Prieš įjungiant dalijimąsi aprašome, kokie techniniai signalai perduodami, kas juos gali naudoti ir kaip tikrinami klaidingi suveikimai. Kliento žurnalų ar kitų privačių duomenų viešinimas nėra šio modelio dalis. Automatinius ribojimo veiksmus taikome tik įtrauktoms sistemoms ir iš anksto suderintoms taisyklėms; jų rezultatą reikia stebėti taip pat, kaip patį saugumo įspėjimą.
Duomenų rinkimo laiką, specialistų darbo valandas ir reakcijos tikslus aprašome atskiromis sąlygomis. Tai padeda suprasti, kada įvykis užregistruojamas, kada jį vertina žmogus ir kokiu keliu pasiekiamas kliento kontaktas. Automatinė stebėsena savaime nenustato žmonių budėjimo visą parą.
Pradžioje patikriname kontaktų pasiekiamumą ir atsarginį eskalavimo kelią. Jei įmonė turi savo reagavimo komandą, aprašome, kokią informaciją jai perduodame ir kas uždaro įvykį. Konkrečius laikus galima nustatyti įvertinus apimtį, sistemų svarbą ir reikalingą darbo organizavimą.
| Sąlyga | Ką užfiksuojame |
|---|---|
| Duomenų rinkimas | Įtraukti šaltiniai, perdavimo veikimas ir spragų nustatymas |
| Specialistų vertinimas | Darbo valandos ir įspėjimų peržiūros apimtis |
| Reakcija | Prioriteto kriterijai ir pirmo veiksmo tikslas |
| Incidento tvarkymas | Leidžiami veiksmai, tvirtinimas ir atsakingi vykdytojai |
| Eskalavimas | Pagrindinis kontaktas, pavaduojantis asmuo ir perdavimo kanalas |
Kiekviename etape apibrėžiame darbus, jūsų indėlį ir patikrinamą rezultatą.
01
Surenkame svarbių sistemų, žurnalų šaltinių ir atsakingų asmenų duomenis. Klientas įvardija aktualius scenarijus, o mes patikriname technines rinkimo galimybes ir spragas.
02
Aprašome specialistų darbo laiką, eskalavimą ir leidžiamus reagavimo veiksmus. Klientas patvirtina sprendimų priėmėjus bei duomenų saugojimo sąlygas. Atskirai suderiname Wazuh ir Zabbix signalų paskirtį, stebėjimo biure darbo langą ir galimus BAN taisyklių veiksmus.
03
Prijungiame pasirinktus šaltinius ir tiksliname taisykles pagal aplinką. Bandomaisiais įvykiais patikriname duomenų perdavimą, pranešimo kontekstą ir kontaktų pasiekiamumą.
04
Signalus vertiname kartu su sistemos ir veiklos kontekstu, tada nustatome prioritetą. Atsakingam kontaktui perduodame reikalingą sprendimą ir fiksuojame tolesnę eigą.
05
Peržiūrime reikšmingus įvykius, šaltinių spragas ir taisyklių naudingumą. Su klientu pasirenkame patobulinimus ir atnaujiname paslaugos apimtį, jei aplinka pasikeitė. Peržiūrime ir klaidingus suveikimus, blokavimo išimtis bei signalų dalijimosi naudą konkrečiai aplinkai.
Wazuh saugumo signalai, Zabbix infrastruktūros rodikliai ir Veeam kopijų informacija atsako į skirtingus klausimus. Vertinant įvykį gali reikėti suprasti ir sistemos veikimą, ir saugumo požymius, ir atkūrimo galimybes. Paslaugų sąsają planuojame pagal konkretų scenarijų bei turimas prieigas.
Pavyzdžiui, saugumo incidento metu vien veikiančios kopijos neužtenka sprendimui, kada ir ką atkurti: reikia įvertinti incidento apimtį bei tinkamą atkūrimo tašką. Atsarginių kopijų administravimą ir atkūrimo bandymus įvardijame jų pačių paslaugos apimtyje, kad atsakomybės būtų suprantamos.
| Priemonė | Pagrindinė paskirtis |
|---|---|
| Wazuh | Saugumo įvykiai ir jų analizė |
| Zabbix | Infrastruktūros būklė ir pasiekiamumas |
| Veeam | Atsarginės kopijos ir atkūrimas |
Dev4you.lt biure stebime Wazuh ir Zabbix pateikiamą informaciją. Bendras vaizdas padeda susieti saugumo įspėjimą su tikra infrastruktūros būsena: ar tuo metu sutriko ryšys, sustojo tarnyba, padidėjo apkrova arba nutrūko įvykių perdavimas. Kiekvienam klientui parenkame aktualius rodiklius ir gavėjus, kad bendroje stebėsenoje būtų aiškios konkrečios sistemos atsakomybės.
Prieš pradėdami rinkti žurnalus nustatome saugojimo vietą, laikotarpį, prieigos teises ir perduodamų duomenų apimtį. Įvertiname, ar įvykiuose gali būti darbuotojų ar klientų duomenų, ir apribojame prieigą pagal darbo poreikį. Taip pat aprašome kliento duomenų atskyrimą nuo kitų klientų aplinkų. Šios sąlygos turi atitikti konkrečią pasirinktą architektūrą.
Peržiūroje rodome prijungtų šaltinių būklę, svarbius įspėjimus, jų vertinimo rezultatus ir atvirus veiksmus. Fiksuojame ir nematomas aplinkos dalis, kad ataskaita nesudarytų klaidingo visos infrastruktūros aprėpties įspūdžio. Saugojimo ar šaltinių pokyčiai turi atsispindėti atnaujintame paslaugos apraše.
Perduodame prijungtų šaltinių sąrašą, stebimų scenarijų aprašą, eskalavimo kontaktus ir leidžiamų reakcijų tvarką. Pradinis patikrinimas parodo, ar bandomas įvykis pasiekia atsakingą asmenį su reikalingu kontekstu. Periodinė peržiūra leidžia pasirinkti, kurias taisykles tikslinti ir kokias spragas šalinti pirmiausia.
Pradžiai reikalingas svarbių sistemų sąrašas, esama stebėsenos situacija ir atsakingi IT kontaktai. Paslaugai baigiantis atskirai perduodami kliento įrašai, panaikinamos nebereikalingos prieigos ir įvykdoma nustatyta duomenų saugojimo ar pašalinimo tvarka.
Įspėjimas rodo administravimo veiksmą neįprastu metu. Pirmiausia sutikriname šaltinį, paskyrą ir patvirtintų pakeitimų informaciją; tai gali būti suplanuotas darbas arba situacija, kurią reikia tirti. Atsakingas asmuo gauna kontekstą ir konkretų prašymą patvirtinti veiklos teisėtumą.
Jei reikalingas ribojantis veiksmas, jis atliekamas pagal iš anksto nustatytas teises. Pavyzdys parodo sprendimo eigą nuo signalo iki patvirtinto veiksmo, nepriskiriant visiems įspėjimams vienodos reikšmės.
| Veiksnys | Kodėl svarbu | Kokios informacijos reikės |
|---|---|---|
| Šaltiniai ir įrenginiai | Jų skaičius bei integracijų sudėtingumas lemia diegimo darbus. | Įrenginių ir žurnalų šaltinių sąrašas. |
| Žurnalų apimtis ir saugojimas | Duomenų kiekis ir laikymo sąlygos lemia infrastruktūros poreikį. | Numatoma apimtis ir pageidaujama saugojimo trukmė. |
| Žmonių darbas ir reagavimas | Analizės valandos ir incidentų šalinimas vertinami pagal atskirą apimtį. | Pageidaujamos valandos ir atsakinga reagavimo komanda. |
Pasirinkite paslaugą pagal konkretaus darbo apimtį.
Įvertinti organizacijos saugumo būklę ir pateikti pagrįstą trūkumų bei prioritetų ataskaitą.
Patikrinti konkrečią svetainę ir pašalinti sutartus patvirtintus pažeidžiamumus.
APTARKIME
Aprašykite svarbiausias sistemas, turimus žurnalų šaltinius ir dabartinę reagavimo tvarką. Įvertinsime duomenų surinkimo galimybes, analizės poreikį ir atsakomybes.
