Grįžti į sąrašą

Saugumo operacijų centro (SOC) paslaugų pirkimas

Išanalizuota

Akcinė bendrovė Klaipėdos valstybinio jūrų uosto direkcija (PV)

Rinkos konsultacijaCPV: 72700000 - Kompiuterių tinklo paslaugos
ID: 66918212026-02-25 15:25
Atidaryti CVP IS

Aprašymas

Perkamos Saugumo operacijų centro (SOC) paslaugos Klaipėdos valstybinio jūrų uosto direkcijai. Jos apima IBM Qradar SIEM įrankio priežiūrą, kibernetinio saugumo analitiką bei incidentų tyrimą, taip pat tinklų ir informacinių sistemų pažeidžiamumų valdymą. Paslaugomis siekiama užtikrinti aukštą kibernetinio saugumo lygį ir efektyvų reagavimą į grėsmes.

Kvalifikaciniai reikalavimai

  • 1Teikėjo informacijos saugos valdymo sistema turi atitikti ISO/IEC 27001 tarptautinio standarto arba kitų lygiaverčių informacijos saugos valdymo sistemų reikalavimus.

Techniniai reikalavimai

IBM Qradar SIEM priežiūra

  • 1Nuolat stebima SIEM būklė, taikomos proaktyvios problemų prevencijos priemonės, reaguojama į pastebėtus sutrikimus ir problemas, atkuriamas SIEM veikimas.
  • 2Įdiegiami SIEM programiniai atnaujinimai ne vėliau nei per 22 darbo dienas po gamintojo atnaujinimo išleidimo, nebent gamintojas rekomenduoja kitaip arba nustatoma rizika sistemos stabilumui.
  • 3Tvarkomi standartiniai ir specifiniai įrašų šaltiniai: pridedama į SIEM, modifikuojama, pašalinama.
  • 4Perimamos esamos SIEM sistemoje jau sukonfigūruotos koreliacijos taisyklės (šiuo metu veikiančių – apie 200 vnt.), analizuojama ir užtikrinamas nepertraukiamas veikimas, optimizavimas ir aktualumas (MITRE ATT&CK taktikų padengimas).
  • 5Tvarkomi išoriniai kibernetinių grėsmių indikatorių (cyber threat intelligence) duomenų šaltiniai (kenksmingų IP adresų, domenų ir pan.): pridedama, modifikuojama, pašalinama.
  • 6Konfigūruojamos SIEM koreliacijos taisyklės pagal saugumo analitikų pateiktas rekomendacijas ir pastabas (modifikuojama, pašalinama).
  • 7Nufiltruojami pertekliniai sisteminiai įrašai ir pateikiamos filtravimo rekomendacijos.
  • 8Teikiamos rekomendacijos dėl reikalingų sisteminių įrašų rinkimo.
  • 9Pridedami nauji sistemos naudotojai, pašalinami seni sistemos naudotojai.
  • 10Kuriamos ataskaitos pagal saugumo analitikų siūlymus ir perkančiosios organizacijos poreikį.
  • 11Teikiami siūlymai dėl SIEM įrankio veikimo optimizavimo ir įgyvendinimo.
  • 12Užtikrinamas SIEM įrankio konfigūracijos rezervinių kopijų darymas prieš kiekvieną reikšmingą pakeitimą ar programinį atnaujinimą.

Bendrieji paslaugų reikalavimai

  • 1Teikiant paslaugas turi būti vadovaujamasi Valstybės informacinių išteklių valdymo įstatymu, Kibernetinio saugumo įstatymu, Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“ patvirtintu Kibernetinio saugumo reikalavimų aprašu, kitais Europos Sąjungos ir Lietuvos Respublikos teisės aktais, Lietuvos Respublikos ir tarptautiniais standartais, reglamentuojančiais informacijos saugą, kibernetinį saugumą, asmens duomenų apsaugą (aktualiomis redakcijomis).
  • 2Tiekėjo specialistai privalo mokėti lietuvių kalbą arba turi būti užtikrintos kokybiškos vertimo paslaugos Tiekėjo sąskaita.
  • 3Tiekėjo parengti dokumentai (analizės, projektavimo ir diegimo dokumentacija) turi būti pateikiami lietuvių kalba.
  • 4Tiekėjas sutarties vykdymui turi turėti 24 valandas per parą 7 dienas per savaitę nenutrūkstamai veikiančią pagalbos tarnybą, kuri turi turėti aprašytą ir veikiantį kreipinių ir incidentų sprendimo procesą, atitinkantį ITIL (atitiktis turi būti pagrįsta tiekėjo pateikiamais metodikos aprašais, procesų dokumentacija ir (ar) specialistų sertifikatais) geriausių praktikų rekomendacijas.
  • 5Tiekėjo pagalbos tarnyba privalo turėti interneto portalą, atitinkantį ITIL (ar lygiavertės metodikos) IT paslaugų valdymo geriausių praktikų metodiką, kuriame Perkančiosios organizacijos atsakingi asmenys turėtų galimybę registruoti gedimų kreipinius, stebėti darbų vykdymo eigą, generuoti ataskaitas.
  • 6Tiekėjo pagalbos tarnyboje turi būti komunikuojama lietuvių kalba.
  • 7Tiekėjo pagalbos tarnyba turi suteikti galimybes registruoti kreipinius tiek elektroniniu paštu, tiek telefonu, tiek per Web portalą.
  • 8Paslaugų įgyvendinimo planas: paslaugų suderinimo ir veikimo pradžios planas.
  • 9Pradinis SIEM\SOC sukonfigūravimas – iki 45 kalendorinių dienų.
  • 10Pirmoji SOC paslaugų analizės ataskaita – per 2 mėn.
  • 11Visas SOC funkcionalumas – per 3 mėn.

Paslaugų lygio susitarimai (SLA)

  • 1Saugumo įvykio reakcijos laikas: vidutiniškai 2 val. nuo visų saugumo įvykių per mėnesį.
  • 2Užklausos (suteikti informaciją, konsultuoti, atlikti konfigūravimo veiksmus ir pan.) reakcijos laikas 8 val.
  • 3Užklausos sprendimo laikas 72 val.
  • 4Pažeidžiamumai prioritetizuojami pagal CVSS bazinį balą (Common Vulnerability Scoring System).
  • 5Kritiškumo lygiai nustatomi taip: CVSS balas 9.0–10.0 – Kritinis; 7.0–8.9 – Aukštas; 4.0–6.9 – Vidutinis; 0.1–3.9 – Žemas.
  • 6Jei pažeidžiamumui nėra priskirto CVSS balo, kritiškumą nustato Tiekėjas, suderinęs su Perkančiąja organizacija, atsižvelgdamas į poveikį paslaugų tęstinumui, duomenų konfidencialumui ir infrastruktūros kritiškumą.
  • 7Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus kritinius KDV pažeidžiamumus per 4 val. nuo nustatymo.
  • 8Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus aukštus KDV pažeidžiamumus per 1 darbo dieną.
  • 9Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus vidutinius ir žemus KDV pažeidžiamumus periodinėje ataskaitoje.
  • 10Kritiniai KDV pažeidžiamumai turi būti pašalinami per 72 val.
  • 11Aukšti KDV pažeidžiamumai turi būti pašalinami per 5 darbo dienas.
  • 12Vidutiniai KDV pažeidžiamumai turi būti pašalinami per 30 kalendorinių dienų.
  • 13Žemi KDV pažeidžiamumai turi būti pašalinami pagal suderintą planą.
  • 14Kritinių pažeidžiamumų atveju testavimo laikotarpis negali viršyti 8 darbo valandų nuo pataisos gavimo, nebent su Perkančiąja organizacija suderinama kitaip.
  • 15Terminai gali būti netaikomi, jei nėra gamintojo pataisos, įrenginys nepasiekiamas (offline/VPN), trūksta resursų ar atnaujinimas sukelia kritinę verslo riziką (tokiais atvejais taikomos suderintos išimtys / kompensacinės priemonės).
  • 16Jei dėl techninių ar veiklos apribojimų pažeidžiamumo pašalinti per nustatytą terminą neįmanoma, Tiekėjas privalo pateikti rizikos įvertinimą, pasiūlyti laikinas rizikos mažinimo priemones (workaround) ir suderinti naują terminą su Perkančiąja organizacija.
  • 17Jei įdiegus atnaujinimą KDV veikia netinkamai, sistemos veikimas turi būti atkurtas per 8 val. nuo sutrikimo nustatymo (rollback arba kita priemonė).
  • 18Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus kritinius serverių pažeidžiamumus per 2 val. nuo nustatymo.
  • 19Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus aukštus serverių pažeidžiamumus per 1 darbo dieną.
  • 20Tiekėjas privalo informuoti Perkančiąją organizaciją apie nustatytus vidutinius ir žemus serverių pažeidžiamumus periodinėje ataskaitoje.
  • 21Rizikos analizė ir rekomendacijos kritiniams serverių pažeidžiamumams pateikiamos per 8 val.
  • 22Rizikos analizė ir rekomendacijos aukštiems serverių pažeidžiamumams pateikiamos per 2 darbo dienas.
  • 23Rizikos analizė ir rekomendacijos vidutiniams ir žemiems serverių pažeidžiamumams pateikiamos periodinėje ataskaitoje.
  • 24Serverių pažeidžiamumus faktiškai šalina (atnaujinimus diegia, keičia konfigūraciją) Perkančioji organizacija.
  • 25Tiekėjas privalo konsultuoti dėl serverių pažeidžiamumų šalinimo prioritetų nustatymo.
  • 26Tiekėjas privalo įvertinti Perkančiosios organizacijos įgyvendintų priemonių efektyvumą pakartotinio skenavimo metu.
  • 27Tiekėjas privalo atnaujinti pažeidžiamumų būseną ataskaitose.
  • 28SLA vykdymo atitiktis vertinama kas mėnesį.
  • 29SLA vykdymo atitikties ataskaitose turi būti nurodyta: nustatymo data, informavimo data, šalinimo data (KDV atveju), rekomendacijos pateikimo data (serverių atveju), faktinis įvykdymo terminas.
  • 30SLA pažeidimai laikomi esminiais sutarties pažeidimais, jei kritinių KDV pažeidžiamumų šalinimo terminas viršijamas daugiau nei 2 kartus per ketvirtį.
  • 31SLA pažeidimai laikomi esminiais sutarties pažeidimais, jei kritinių serverių pažeidžiamumų analizės terminas pažeidžiamas daugiau nei 2 kartus per ketvirtį.

Pažeidžiamumų valdymas (bendrieji)

  • 1Tiekėjas privalo naudoti automatizuotus ir rankinius pažeidžiamumų nustatymo metodus.
  • 2Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys identifikuoti operacinių sistemų pažeidžiamumus.
  • 3Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys identifikuoti taikomųjų programų saugumo spragas.
  • 4Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys identifikuoti konfigūracijos neatitikimus.
  • 5Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys identifikuoti tinklo infrastruktūros pažeidžiamumus.
  • 6Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys identifikuoti pasenusią ar nepalaikomą programinę įrangą.
  • 7Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys naudoti platesnę aprėptį nei vien „Microsoft Defender for Endpoint“ teikiama pažeidžiamumų informacija apie KDV.
  • 8Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, leidžiantys užtikrinti centralizuotą pažeidžiamumų duomenų konsolidavimą.
  • 9Turi būti naudojami pažangūs, rinkoje pripažinti skenavimo įrankiai, turintys galimybę inicijuoti ir valdyti pažeidžiamumų šalinimo procesą.
  • 10Pažeidžiamumų klasifikavimas turi būti atliekamas remiantis tarptautiniais standartais, įskaitant CVE (Common Vulnerabilities and Exposures), administruojamą The MITRE Corporation.
  • 11Pažeidžiamumų klasifikavimas turi būti atliekamas remiantis tarptautiniais standartais, įskaitant MITRE ATT&CK metodologiją (kai taikoma grėsmių konteksto analizei).
  • 12Pažeidžiamumo pavojingumo lygis turi būti nustatomas pagal CVSS (Common Vulnerability Scoring System) metodiką, nurodant bazinį balą ir kritiškumo lygį.
  • 13Skenavimo sprendimas turi palaikyti centralizuotą valdymą, periodinių ir neplaninių skenavimų vykdymą bei ataskaitų generavimą.
  • 14KDV ir serverių pažeidžiamumai turi būti skenuojami ne rečiau kaip kartą per mėnesį.
  • 15Papildomi skenavimai atliekami po reikšmingų infrastruktūros pakeitimų.
  • 16Papildomi skenavimai atliekami po kritinių saugumo pranešimų paskelbimo.
  • 17Papildomi skenavimai atliekami Perkančiosios organizacijos prašymu.
  • 18Papildomi skenavimai atliekami, Perkančiajai organizacijai pranešus apie serverių pažeidžiamumų pašalinimą Tiekėjui.
  • 19Periodinėse ataskaitose turi būti atskirai pateikiama KDV pažeidžiamumų būklė ir šalinimo statusas.
  • 20Periodinėse ataskaitose turi būti atskirai pateikiama serverių pažeidžiamumų sąrašas ir rekomendacijų įgyvendinimo būsena.
  • 21Kritinių pažeidžiamumų atveju informacija turi būti pateikiama nedelsiant.

KDV pažeidžiamumų valdymas (su šalinimu)

  • 1KDV pažeidžiamumų valdymas turi apimti: pažeidžiamumų identifikavimą, rizikos vertinimą, šalinimo veiksmų planavimą, pažeidžiamumų pašalinimą, įdiegtų priemonių kontrolę.
  • 2Tiekėjas privalo užtikrinti nustatytų KDV pažeidžiamumų pašalinimą, įskaitant saugumo atnaujinimų (patch) diegimą.
  • 3Tiekėjas privalo užtikrinti nustatytų KDV pažeidžiamumų pašalinimą, įskaitant programinės įrangos versijų atnaujinimą.
  • 4Tiekėjas privalo užtikrinti nustatytų KDV pažeidžiamumų pašalinimą, įskaitant konfigūracijos pakeitimus.
  • 5Tiekėjas privalo užtikrinti nustatytų KDV pažeidžiamumų pašalinimą, įskaitant papildomų apsaugos priemonių įgyvendinimą.
  • 6Tiekėjas teikia (nuomos pagrindu) nuotolinio stebėjimo ir valdymo įrankį (RMM – Remote Monitoring and Management ar lygiavertį centralizuoto nuotolinio valdymo ir atnaujinimų diegimo įrankį).
  • 7RMM įrankis turi leisti identifikuoti Windows OS ir programinės įrangos pažeidžiamumus ir diegti atnaujinimus.
  • 8RMM įrankis turi leisti stebėti diegimo būseną.
  • 9RMM įrankis turi užtikrinti veiksmų atsekamumą.
  • 10RMM įrankis turi suteikti galimybę atšaukti atnaujinimus (rollback), jei po atnaujinimo KDV neveikia arba veikia netinkamai.
  • 11RMM įrankis turi leisti stebėti KDV sisteminio disko laisvą vietą.
  • 12RMM įrankis turi leisti patikrinti antivirusinės apsaugos aktyvumą ir atsinaujinimo būseną.
  • 13RMM įrankis turi leisti stebėti BitLocker būseną (enabled/disabled).
  • 14RMM įrankis turi leisti palaikyti dviejų faktorių autentifikaciją (MFA).
  • 15Tiekėjas privalo užtikrinti RMM įrankio generuojamų veiklos auditavimo įrašų (audit logs) perdavimą į Perkančiosios organizacijos SIEM realiu laiku.
  • 16Perduodami duomenys privalo apimti informaciją apie prisijungimus prie RMM sistemos (sėkmingus ir nesėkmingus).
  • 17Perduodami duomenys privalo apimti nuotolinio valdymo sesijų pradžios ir pabaigos laikus, nurodant, prie kurio KDV buvo prisijungta.
  • 18Perduodami duomenys privalo apimti informaciją apie vykdomus grupinius skriptus, diegiamus atnaujinimus ar keičiamas konfigūracijas.
  • 19Perduodami duomenys privalo apimti įvykius, susijusius su RMM sistemos teisių keitimu ar naujų administratoriaus paskyrų kūrimu.
  • 20Jei atnaujinimo įdiegti nepavyksta arba po jo KDV veikia netinkamai, Tiekėjas privalo nedelsdamas informuoti Perkančiąją organizaciją.
  • 21Jei atnaujinimo įdiegti nepavyksta arba po jo KDV veikia netinkamai, Tiekėjas privalo atlikti analizę.
  • 22Jei atnaujinimo įdiegti nepavyksta arba po jo KDV veikia netinkamai, Tiekėjas privalo atkurti paskutinę stabilią būseną.
  • 23Jei atnaujinimo įdiegti nepavyksta arba po jo KDV veikia netinkamai, Tiekėjas privalo pateikti korekcinių veiksmų planą.
  • 24Visi šalinimo veiksmai turi būti dokumentuojami.

Serverių pažeidžiamumų valdymas (be šalinimo)

  • 1Serverių pažeidžiamumų valdymas apima: pažeidžiamumų identifikavimą, rizikos vertinimą, poveikio analizę, prioritetizavimą, rekomendacijų, pritaikytų Perkančiosios organizacijos TIS, teikimą.
  • 2Serverių pažeidžiamumų valdymas neapima saugumo atnaujinimų diegimo.
  • 3Serverių pažeidžiamumų valdymas neapima konfigūracijos pakeitimų įgyvendinimo.
  • 4Serverių pažeidžiamumų valdymas neapima programinės įrangos versijų atnaujinimo.
  • 5Tiekėjas privalo pateikti prioritetizuotas, pritaikytas Perkančiosios organizacijos TIS rekomendacijas serverių pažeidžiamumams pašalinti.
  • 6Serverių pažeidžiamumai turi būti nustatomi realūs, o ne versijų neatitikimai (pvz., jei Apache nėra įdiegtas modulis, šio modulio pažeidžiamumų šalinimo rekomendacijos neturi būti teikiamos).
  • 7Jei nustatyto serverio pažeidžiamumo rizika yra priimtina Perkančiajai organizacijai, kitoje pažeidžiamumų vertinimo ataskaitoje šis pažeidžiamumas neturi būti minimas sąraše (arba žymimas, kad priimtinas).
  • 8Rekomendacijose turi būti nurodyta: CVE identifikatorius (jei taikoma); CVSS balas; galimas poveikis KDV ar TIS; rekomenduojamas šalinimo būdas (jei nėra standartinio būdo, konsultuojant administratorių, nustatomas ir aprašomas būdas); rekomenduojamas įgyvendinimo terminas pagal kritiškumą.
  • 9Tiekėjas turi konsultuoti Perkančiąją organizaciją dėl šalinimo prioritetų, tačiau faktiškai atnaujinimus serveriuose diegia Perkančioji organizacija.

Kibernetinio saugumo analitika ir incidentų tyrimas

  • 1Informuojama apie incidentus pagal su Perkančiąja organizacija suderintą komunikacijos planą, kuris turi apimti: Tiekėjo ir Perkančiosios organizacijos atsakingų už kibernetinio saugumo užtikrinimą kontaktus; procesą, aprašantį komunikacijos veiksmus incidento atveju; kanalus, bus informuojama apie incidentus.
  • 2Analizuojami SIEM generuojami aliarmai (patvirtinimas, klasifikavimas, grupavimas, išsprendimo inicijavimas, konsultavimas sprendžiant).
  • 3Užtikrinama, kad „Microsoft Defender for Endpoint“ telemetrija būtų integruota į SOC naudojamą SIEM.
  • 4„Microsoft Defender for Endpoint“ generuojami įspėjimai negali būti vertinami izoliuotai – jie turi būti koreliuojami su kitų TIS teikiamais į SIEM duomenimis.
  • 5Tobulinamos esamos koreliacijos taisyklės ir įvedamos naujos.
  • 6Naudojami išoriniai ir vidiniai kibernetinių grėsmių indikatorių šaltiniai (pvz., MISP, nacionaliniai CERT/NKSC pranešimai, kiti patikimi grėsmių žvalgybos šaltiniai) ir užtikrinama jų integracija į SIEM koreliacijos taisykles.
  • 7IoC (Indicators of Compromise) pagrindu veikiančios analitinės taisyklės turi aptikti žinomų kenksmingų failų maišos (Hash) reikšmes.
  • 8IoC (Indicators of Compromise) pagrindu veikiančios analitinės taisyklės turi identifikuoti komunikaciją su žinomais kenksmingais ar sukčiavimo unikaliais interneto adresais (phishing URL).
  • 9IoC (Indicators of Compromise) pagrindu veikiančios analitinės taisyklės turi identifikuoti komunikaciją su žinomais blogos reputacijos IP adresais.
  • 10IoC (Indicators of Compromise) pagrindu veikiančios analitinės taisyklės turi identifikuoti komunikaciją su anksčiau kompromituotais ar C2 (Command and Control) serveriais.
  • 11IoC (Indicators of Compromise) pagrindu veikiančios analitinės taisyklės turi aptikti kenksmingų domenų ar domenų generavimo algoritmų (DGA) požymius.
  • 12Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent bandymų įsilaužti (brute force, password spraying, scanning) identifikavimą.
  • 13Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent neįprastų autentifikacijos modelių ir autentifikavimo rizikos nustatymą.
  • 14Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent vartotojų elgesio nuokrypių (anomalijų) identifikavimą.
  • 15Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent teisių ar privilegijų pakėlimo (privilege escalation) požymių aptikimą.
  • 16Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent horizontalaus judėjimo (lateral movement) infrastruktūroje identifikavimą.
  • 17Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent kredencialų vagystės požymių identifikavimą.
  • 18Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent kenksmingo programinio kodo vykdymo požymių identifikavimą.
  • 19Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent ilgalaikio įsitvirtinimo (persistence) infrastruktūroje požymių identifikavimą.
  • 20Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent auditavimo išjungimo ar saugumo kontrolės apėjimo požymių identifikavimą.
  • 21Tiekėjas privalo užtikrinti analitinių taisyklių veikimą, paremtų elgsenos analizę ir atakos taktikų, technikų bei procedūrų (TTP) identifikavimu, remiantis MITRE ATT&CK metodologija, bent neįprastos tinklo prieigos ar duomenų iškėlimo (exfiltration) požymių identifikavimą.
  • 22Elgsenos aptikimai negali būti ribojami tik statinėmis taisyklėmis – turi būti taikoma įvykių koreliacija ir kontekstinė analizė.
  • 23Nustatomos incidento pirminės priežastys (root cause).
  • 24Nustatomos incidentų atakos grandinės.
  • 25Tiriamas incidentas, atkuriama jo eiga.
  • 26Surenkami ir išsaugojami SIEM esantys incidento įrodymai.
  • 27Teikiamos saugos ir saugos valdymo procesų gerinimo rekomendacijos, suvaldžius incidentą.
  • 28Valdomas incidento sprendimas.
  • 29Teikiamos ataskaitos 1 kartą per mėnesį: netikrų aliarmų (false-positive) kiekis; tikrų eskaluotų aliarmų kiekis; saugumo stiprinimo pasiūlymai; incidentų priežastys; pasiūlytų saugumo veiksmų vykdymo statusas (derinant su paslaugos gavėju); pasiūlytos naujos koreliacijos taisyklės.
  • 30Teikiami periodiniai (ne rečiau kaip kas 3 mėnesius) pasiūlymai ir konsultacijos dėl paslaugos gerinimo.
  • 31Teikiamos rekomendacijos IT infrastruktūros saugumo spragoms, kuriomis buvo pasinaudota saugumo incidento metu, šalinti.
  • 32Saugumo įvykių stebėsena ir incidentų registravimo laikas: 24/7.
  • 33Konsultavimo, kibernetinių incidentų tyrimo ir papildomų paslaugų teikimo laikas: 9x5.
  • 34Tiekėjas pritaiko kibernetinio saugumo įvykių ir kibernetinių incidentų valdymo TIS taip, kad kibernetiniai incidentai Nacionalinio kibernetinio saugumo centro Kibernetinio saugumo informacinėje sistemoje (KSIS) veikiančioje Nacionalinėje kibernetinių incidentų valdymo platformoje būtų registruojami automatiniu būdu, naudojant automatizuotų pranešimų apie kibernetinius incidentus per API funkcionalumą pagal esminiams kibernetinio saugumo subjektams taikomus reikalavimus.

Dokumentai4

  • 3_KVJUD SOC tech. sąlygos 2025.02.25 ok.docx
  • 1092_6691821.pdf
  • 1_UD KVIETIMAS DALYVAUTI RINKOS KONSULTACIJOJE.docx
  • 2_SOC klausimai dėl tech sąlygų 2026.02.24 ok.docx
tendis.lt · Sukurta recodin.lt