DESAmedia ·

Trumpas atsakymas

Jei jūsų organizacija įtraukta į Kibernetinio saugumo subjektų registrą, NIS2 (lietuviškai TIS2) reikalavimai neapsiriboja jūsų organizacija: juos reikia perkelti ir į sutartis su tiekėjais, kurie kuria, prižiūri ar talpina jūsų sistemas. Atsakomybė lieka jums: Kibernetinio saugumo įstatymas ir Vyriausybės patvirtintas Kibernetinio saugumo reikalavimų aprašas (toliau KSRA) reikalauja, kad sutartyse su tiekėjais būtų numatyta jų atitiktis reikalavimams, pareiga pranešti apie incidentus, jūsų teisė atlikti auditą, spragų valdymas, SLA, prieigų lygiai ir dar keli dalykai (KSRA 34 punktas). Organizaciniai reikalavimai, įskaitant tiekimo grandinę, turi būti įgyvendinti per 12 mėnesių nuo įregistravimo, techniniai per 24 mėnesius. Organizacijoms, kurias NKSC į registrą įtraukė pirmojo identifikavimo metu (pranešimai išsiųsti iki 2025 m. balandžio 17 d.), tai reiškia, kad sutartys jau turėjo būti sutvarkytos, o techninius reikalavimus reikia įgyvendinti ne vėliau kaip iki 2027 m. balandžio 17 d. Didžiąją dalį tų techninių reikalavimų jūsų sistemoje realiai įgyvendins programavimo partneris, todėl žemiau rasite, ką įrašyti į sutartį, ko reikalauti techniškai ir kaip patikrinti esamus tiekėjus.

Kam tai taikoma ir kokie terminai

Atnaujintas Kibernetinio saugumo įstatymas, kuriuo į Lietuvos teisę perkelta NIS2 direktyva (ES) 2022/2555, įsigaliojo 2024 m. spalio 18 d. Jis taikomas įstatymo 1 ir 2 prieduose nurodytuose sektoriuose veikiančioms vidutinėms ir didelėms įmonėms bei viešojo sektoriaus institucijoms. Kai kurie subjektai, pavyzdžiui, centrinės ir regioninės valdžios viešojo administravimo subjektai, priskiriami esminiams nepriklausomai nuo dydžio. Mažoms ir labai mažoms įmonėms įstatymas paprastai netaikomas, išskyrus įstatyme numatytas išimtis.

Subjektai skirstomi į esminius ir svarbius. Esminiams taikoma griežtesnė NKSC priežiūra, o dalis techninių reikalavimų taikoma tik jiems. Pareigos atsiranda nuo įregistravimo Kibernetinio saugumo informacinėje sistemoje (KSIS). KAM duomenimis, registre yra 1443 organizacijos iš 11 ypatingos svarbos ir 7 kitų itin svarbių sektorių, o registras peržiūrimas ne rečiau kaip kartą per metus, todėl naujų subjektų atsiranda ir dabar.

Terminai nustatyti KSRA 71 ir 72 punktuose:

Reikalavimai Terminas nuo įregistravimo KSIS Pirmojo identifikavimo subjektams
Organizaciniai (politika, rizikų vertinimas, incidentų valdymas, tiekimo grandinė, sutartys, spragų valdymo tvarka) 12 mėnesių NKSC nurodo 2026 m. balandžio 17 d.
Techniniai (KSRA 1-7 lentelės: žurnalai, kopijos, tinklo ir sistemų apsauga, šifravimas, prieigos) 24 mėnesiai Ne vėliau kaip 2027 m. balandžio 17 d.

Jei jūsų organizacija įregistruota vėliau, terminai skaičiuojami nuo jūsų įregistravimo dienos, kurią rasite NKSC pranešime ir KSIS.

Svarbi detalė: reikalavimai taikomi ne visoms organizacijos sistemoms, o toms tinklų ir informacinėms sistemoms, kurios susijusios su veikla, pagal kurią organizacija pateko į registrą. Todėl pirmas žingsnis yra ne tiekėjų sutartys, o sistemų sąrašas ir jų priskyrimas tai veiklai.

Kodėl tai liečia jūsų programavimo partnerį

Įstatymo 14 straipsnio 5 dalyje tarp privalomų kibernetinio saugumo elementų įvardytas tiekimo grandinės saugumas, įskaitant santykius su tiesioginiais tiekėjais ir paslaugų teikėjais, bei tinklų ir informacinių sistemų įsigijimo, plėtojimo ir priežiūros saugumas, įskaitant spragų valdymą. NIS2 direktyvos 21 straipsnio 3 dalis eina dar toliau: vertinant tiekimo grandinės priemones reikia atsižvelgti į kiekvieno tiesioginio tiekėjo pažeidžiamumus, jo produktų kokybę ir kibernetinio saugumo praktiką, įskaitant saugaus programavimo procedūras.

Pats tiekėjas, jei nėra įtrauktas į registrą, įstatymo pareigų tiesiogiai neturi. NKSC tai vadina netiesioginiu poveikiu: reikalavimai jį pasiekia per jūsų sutartį ir jūsų kontrolę. KAM formuluotė aiški: subjektai privalo reikalauti ir įsitikinti, kad tiekėjai atitinka kibernetinio saugumo reikalavimus, turi incidentų valdymo planus, atitinkamus sertifikatus ir bendradarbiaus įvykus incidentui. Atsakomybė už tiekėjo pasirinkimą ir priežiūrą lieka organizacijai, kiek tiekėjų ji bebūtų pasitelkusi.

Yra ir išimtis, kurią verta žinoti: valdomų paslaugų teikėjai, debesijos ir duomenų centrų paslaugų teikėjai gali patys būti kibernetinio saugumo subjektai, kuriems taikomas Komisijos įgyvendinimo reglamentas (ES) 2024/2690. Jei jūsų talpinimo ar IT priežiūros partneris yra toks subjektas, paklauskite, kokius reikalavimus jis jau įgyvendina pats.

Ką KSRA reikalauja numatyti sutartyje

KSRA šeštasis skirsnis skirtas tiekimo grandinei. Jame reikalaujama patvirtinti tiekimo grandinės saugumo valdymo tvarką (32 punktas), nustatyti tiekėjų atrankos kriterijus (33 punktas), sutartyse numatyti konkrečius dalykus (34 punktas), vertinti tiekėjų riziką (35 punktas), kontroliuoti sutartyje nurodytų reikalavimų vykdymą (38 punktas) ir tvarkyti tiekėjų sąrašą (39 punktas).

Pirkėjui svarbiausias yra 34 punktas. Jame išvardyta, ką sutartis su tiekėju ir subtiekėju turi numatyti, kiek tai susiję su teikiamomis paslaugomis. Žemiau kiekvienas papunktis išverstas į tai, ką tai reiškia programinės įrangos kūrimo, priežiūros ar talpinimo sutartyje.

KSRA 34 p. Ką reikalauja Kaip tai atrodo IT sistemos sutartyje
34.1 Tiekėjo atitiktis Aprašui Priedas su konkrečiais KSRA reikalavimais, kuriuos tiekėjas įgyvendina jūsų sistemoje ar infrastruktūroje, ir atsakomybės pasiskirstymas (ką darote jūs, ką daro tiekėjas)
34.2 Personalo įgūdžiai, mokymai, sertifikatai, kvalifikacija Kas turės administratoriaus prieigą, kokią kvalifikaciją ar sertifikatus turi komanda, kaip keičiami žmonės
34.3 Pareiga pranešti apie visus incidentus, kai tik apie juos sužinoma, ir pateikti tyrimo ataskaitą Kontaktai abiem kryptimis, kanalas, pranešimo terminas valandomis, tyrimo ataskaitos turinys ir terminas
34.4 Jūsų teisė atlikti auditą, įskaitant neplaninį, ir tiekėjo pareiga sudaryti tam sąlygas Audito teisė sutarties galiojimo metu ir po didelio incidento, prieiga prie dokumentų, žurnalų ir aplinkų
34.5 Pareiga valdyti spragas, keliančias riziką jūsų sistemoms Priklausomybių ir bibliotekų stebėsena, pataisų terminai pagal kritiškumą, pranešimas apie rastą spragą
34.6 Konfidencialumas ir duomenų neatskleidimas Konfidencialumas galioja ir pasibaigus sutarčiai; duomenų grąžinimas ar sunaikinimas su įrodymu
34.7 Paslaugų lygis (SLA) Reakcijos ir sprendimo laikas pagal klaidos kritiškumą, prieinamumo įsipareigojimas, darbo ir ne darbo valandos
34.8 Loginės ir fizinės prieigos lygiai ir sąlygos Kas, prie ko, kokiu būdu (VPN, kelių veiksnių autentifikacija), kiek laiko ir kas tvirtina prieigą
34.9 Reikalavimai tiekėjo patalpoms, įrangai, priežiūrai, informacijos perdavimui Kur talpinami duomenys ir kopijos, kaip saugomi kūrėjų kompiuteriai, kaip perduodami duomenys
34.10 Šalių teisės ir pareigos Kas atsako už kurį reikalavimą, ką tiekėjas daro gavęs jūsų nurodymą, kaip sprendžiami neatitikimai

Su 34 punktu dažnai persidengia tai, ką sutartyje turėtumėte turėti ir be NIS2: turtinės teisės į kodą, kodo saugojimas jūsų repozitorijoje, duomenų tvarkymo sutartis pagal BDAR, garantija ir išėjimo sąlygos. Juos išsamiai aptarėme straipsnyje Kaip išsirinkti programavimo partnerį: 12 klausimų prieš sutartį. Kibernetinio saugumo požiūriu jie svarbūs dėl veiklos tęstinumo: jei tiekėjas pasitrauks, turite sugebėti sistemą perimti.

Viešajame sektoriuje šie reikalavimai turi atsirasti jau pirkimo dokumentuose. NKSC rekomenduoja pirkimo dokumentuose apibrėžti trečiosios šalies loginės ir fizinės prieigos lygius ir sąlygas, o tiekėjo atitiktį galima vertinti, pavyzdžiui, paprašius užpildyti kibernetinio saugumo reikalavimų lentelę. Kaip saugumo reikalavimus aprašyti specifikacijoje, kad jie būtų patikrinami, rašėme straipsnyje Techninė specifikacija IT projektui.

Techniniai reikalavimai, kuriuos įgyvendins kūrėjas

Techniniai KSRA reikalavimai surašyti septyniose lentelėse. Dalis jų skirta biuro infrastruktūrai (darbo vietoms, belaidžiam tinklui, spausdintuvams), bet nemaža dalis tiesiogiai liečia individualiai sukurtą sistemą, jos serverius ir talpinimą. Būtent juos verta aptarti su programavimo partneriu dabar, kad jie spėtų atsirasti iki 24 mėnesių termino.

Prieigos ir tapatybės valdymas

  • Naudotojai ir administratoriai patvirtina tapatybę slaptažodžiu ir papildoma priemone, t. y. kelių veiksnių autentifikacija (KSRA 7 lentelė, 61 p.).
  • Kiekvienas naudotojas unikaliai atpažįstamas, administratoriaus funkcijos atliekamos atskira paskyra, kuri nenaudojama kasdieniam darbui (58 ir 60 p.).
  • Administratoriaus teisė sustabdoma, jei jis nesinaudoja sistema ilgiau nei 2 mėnesius, naudotojo ilgiau nei 3 mėnesius (62 ir 63 p.).
  • Viešai pasiekiamų svetainių programiniame kode draudžiama laikyti prisijungimo duomenis, API raktus ar ženklus (76.1 p.). Kūrėjui tai reiškia paslapčių saugyklą ir kodo peržiūrą, ar niekas neįrašyta į repozitoriją.
  • Trečiųjų šalių, taigi ir jūsų tiekėjo, prieiga atskiriama nuo kitų resursų, jungiamasi per saugų VPN, kur įmanoma su kelių veiksnių autentifikacija, o prisijungimai registruojami žurnaluose (3 lentelė, 32.2 p.).

Žurnaliniai įrašai

KSRA 1 lentelė nustato, ką būtina fiksuoti (jei sistema tai palaiko): naudotojų ir administratorių autentifikavimo įvykius, paskyrų kūrimą ir prieigų pakeitimus, administratorių veiksmus, žurnalų peržiūrą, trynimą ar keitimą. Žurnaluose turi būti įvykio data ir tikslus laikas, susijęs naudotojas ar įrenginys ir aprašymas. Žurnalai saugomi ne trumpiau kaip 90 kalendorinių dienų, jų negalima trinti ar keisti, kol nesibaigė saugojimo terminas, o duomenys analizuojami ne rečiau kaip kartą per mėnesį.

Individualiai sistemai tai reiškia aiškų sprendimą: kurie įvykiai rašomi į programos auditų žurnalą, kur jis siunčiamas (geriausia už pačios sistemos ribų) ir kas turi teisę jį peržiūrėti. Jei sistema to nedaro dabar, tai yra konkretus plėtros darbas, kurį reikia įvertinti ir suplanuoti.

Internetu pasiekiamų sistemų apsauga

3 lentelėje yra keli reikalavimai, kurie yra kasdienė kūrėjo atsakomybė:

  • svetainės saugasienė (WAF) internetu pasiekiamoms sistemoms (36 p.);
  • apsauga nuo pagrindinių atakų pagal OWASP Top 10 gerąsias praktikas (37 p.);
  • naudotojo įvedamų duomenų kontrolė formose (38 p.);
  • klaidų pranešimai neturi atskleisti informacijos apie sistemą, kodą ar serverį (39 p.);
  • leidžiami tik funkcionalumui reikalingi HTTP metodai (40 p.).

Esminiams subjektams 4 lentelė papildomai reikalauja svetainėse naudoti TLS 1.3 ar naujesnę versiją (48.4 p.).

Atnaujinimai, pokyčiai ir spragos

  • Diegiami programinės įrangos gamintojų rekomenduojami atnaujinimai (3 lentelė, 30 p.). Sistemos, kurios dėl objektyvių priežasčių naudoja nepalaikomas versijas, turi veikti atskirame tinklo segmente (31 p.).
  • Saugos pataisos testuojamos prieš diegiant į produkcinę aplinką (44 p.), o pokyčiai, galintys sutrikdyti veiklą, derinami ir išbandomi bandomojoje aplinkoje (43 p.). Praktiškai: be testinės aplinkos šio reikalavimo įvykdyti neįmanoma.
  • Spragų valdymo tvarkoje turi būti reikalavimas nedelsiant šalinti itin reikšmingas spragas ir visą sistemos spragų skenavimą atlikti ne rečiau kaip kas 6 mėnesius (45.7 ir 45.8 p.). NKSC papildomai nurodo gerąją praktiką vertinti naujų sistemų pažeidžiamumus prieš jas įteisinant.

Pataisų, pokyčių ir spragų valdymo tvarka (KSRA 43-45 p.) yra organizaciniai reikalavimai, todėl jiems taikomas 12 mėnesių terminas.

Atsarginės kopijos ir prieinamumas

  • Kopijos daromos nustatytu reguliarumu ir laikomos geografiškai nutolusioje vietoje (2 lentelė, 17 p.).
  • Kopijos reguliariai testuojamos arba naudojama programinė įranga, automatiškai tikrinanti, ar iš jų galima atkurti visiškai veikiančius duomenis (18 p.).
  • Kopijose duomenys šifruojami, o raktai saugomi atskirai nuo kopijų (4 lentelė, 49 p.).
  • Kritinių sistemų prieinamumas turi būti ne mažesnis kaip 99 proc. laiko esminiams subjektams ir 96 proc. svarbiems (16 p.).
  • Veiklos tęstinumo plane nurodomi atkūrimo laikas (RTO) ir leistinas duomenų praradimas (RPO), kurie turi būti išbandomi (27.9 ir 27.10 p.).

Šie skaičiai turi atsispindėti talpinimo ir priežiūros sutartyje. Jei SLA žada 99 proc. prieinamumą, bet niekas nėra išbandęs atkūrimo iš kopijos, reikalavimas įvykdytas tik popieriuje.

Incidentai: ką tiekėjas turi daryti per pirmąsias valandas

Apie didelį kibernetinį incidentą subjektas privalo pateikti NKSC ankstyvąjį perspėjimą ne vėliau kaip per 24 valandas, pranešimą su pradiniu vertinimu ne vėliau kaip per 72 valandas ir galutinę ataskaitą ne vėliau kaip per mėnesį (Kibernetinio saugumo įstatymo 18 straipsnis, NIS2 direktyvos 23 straipsnis). Apie kitus incidentus NKSC informuojama ne vėliau kaip per 72 valandas.

Laikrodis pradeda eiti nuo sužinojimo, o apie incidentą jūsų sistemoje dažnai pirmas sužino tiekėjas. Todėl sutartyje verta aprašyti:

  • per kiek valandų ir kokiu kanalu tiekėjas praneša apie incidentą (KSRA 34.3 reikalauja pranešti, kai tik sužinoma);
  • kas iš abiejų pusių budi ne darbo valandomis;
  • kokią informaciją tiekėjas pateikia per pirmąsias valandas, kad suspėtumėte su 24 ir 72 valandų pranešimais;
  • įrodymų ir žurnalų išsaugojimą (KSRA 24.6 p. reikalauja, kad incidentų valdymo plane būtų įrodymų rinkimo ir išsaugojimo nuostatos);
  • tyrimo ataskaitos turinį ir terminą.

Jei tiekėjas jums teikia su incidentų valdymu susijusias paslaugas, jūsų incidentų valdymo planas turi būti su juo suderintas (KSRA 23 p.).

Esamos sistemos ir esamos sutartys

Daugumai organizacijų didžiausias darbas yra ne nauji pirkimai, o jau veikiančios sistemos ir prieš kelerius metus pasirašytos sutartys. Praktiška eilė tokia:

  1. Sistemų sąrašas. Turto sąrašas yra KSRA reikalavimas. Prie kiekvienos sistemos pažymėkite, ar ji susijusi su veikla, pagal kurią esate registre, kas ją sukūrė, kas prižiūri ir kur ji talpinama.
  2. Tiekėjų sąrašas. KSRA 39 punktas reikalauja tvarkyti tiekėjų sąrašą ir jį peržiūrėti, kai keičiasi sutartys ar įvyksta reikšmingi incidentai.
  3. Sutarčių patikra pagal 34 punktą. Kiekvienai sutarčiai pažymėkite, kurių papunkčių trūksta. Dažniausiai trūksta audito teisės, pranešimo apie incidentus termino ir spragų valdymo pareigos. Trūkstamus dalykus galima įforminti priedu ar susitarimu. Viešajame sektoriuje sutarties keitimą reikia įvertinti pagal Viešųjų pirkimų įstatymo 89 straipsnį.
  4. Techninė spragų analizė. Palyginkite sistemą su techniniais reikalavimais: kelių veiksnių autentifikacija, žurnalai, WAF, kopijos, testinė aplinka. Gausite darbų sąrašą su įvertinimu, kurį galima suplanuoti iki 24 mėnesių termino.
  5. Senos sistemos. Jei sistema veikia nepalaikoma operacine sistema ar karkaso versija ir atnaujinti greitai neįmanoma, ją reikia atskirti tinklo segmente (3 lentelė, 31 p.) ir planuoti modernizavimą.

KAM paaiškina ir dažną klausimą dėl gatavų produktų: jei programinė įranga nupirkta kaip produktas ir daugiau ryšių su teikėju nėra, pakanka įvertinti teikėją ir produktą įsigijimo metu. Jei perkamas palaikymas, palaikymą teikianti organizacija laikoma trečiąja šalimi ir jos rizika vertinama nuolat. Taip pat, pasikeitus kritines priežiūros ar vystymo paslaugas teikiančiam tiekėjui, KAM nurodo tai kaip pagrindą neeiliniam rizikos vertinimui.

Nutraukiant sutartį NKSC rekomenduoja užtikrinti, kad duomenys būtų saugiai grąžinti arba sunaikinti su sunaikinimo įrodymu, panaikintos visos tiekėjui suteiktos prieigos, peržiūrėti paskutiniai jo veiksmų žurnalai ir kad konfidencialumo įsipareigojimai galiotų ir po sutarties.

Tiekėjo vertinimo kontrolinis sąrašas

Šiuos klausimus galite nusiųsti esamam ar būsimam tiekėjui ir paprašyti atsakyti raštu. Atsakymai tiks ir tiekėjo rizikos vertinimui (KSRA 35 p.).

  • Kas turi administratoriaus prieigą prie mūsų sistemos, serverių ir duomenų bazės? Ar prieiga asmeninė, su kelių veiksnių autentifikacija ir terminuota?
  • Ar kodas saugomas mūsų repozitorijoje ir ar kode nėra slaptažodžių ar API raktų?
  • Kaip sekate naudojamų bibliotekų ir priklausomybių spragas? Per kiek laiko diegiate kritinės spragos pataisą?
  • Ar yra testinė aplinka, kurioje išbandomi pakeitimai ir pataisos prieš produkciją?
  • Kokius veiksmus sistema rašo į žurnalą, kur žurnalai saugomi ir kiek laiko?
  • Kur ir kaip dažnai daromos kopijos, ar jos šifruojamos ir kada paskutinį kartą bandytas atkūrimas?
  • Ar internetu pasiekiama sistema yra už WAF ir ar buvo testuota pagal OWASP Top 10?
  • Kada paskutinį kartą atliktas spragų skenavimas ar įsiskverbimo testas ir ką jis rado?
  • Per kiek valandų ir kam pranešate apie incidentą? Ar galite tai įrašyti į sutartį?
  • Ar sutiksite su mūsų ar mūsų paskirto auditoriaus atliekamu auditu?
  • Ar pasitelkiate subtiekėjus ar debesijos paslaugas, kurie turi prieigą prie mūsų duomenų?
  • Ar turite incidentų valdymo planą ir saugumo sertifikatų ar nepriklausomo audito ataskaitą?
  • Ką gausime nutraukus sutartį: kodą, dokumentaciją, prieigas, duomenų kopiją? Kaip patvirtinsite duomenų sunaikinimą?

Jei tiekėjas nesutinka pateikti informacijos, kuri leistų jį įvertinti, KAM rekomenduoja prašyti nepriklausomo auditoriaus vertinimo ataskaitos, kurioje būtų aptarti jums rūpimi reikalavimai.

Pavyzdys: kaip tai atrodo praktiškai

Pavyzdys išgalvotas, organizacija ir skaičiai sugalvoti iliustracijai.

UAB „Pavyzdys“ yra vidutinė įmonė, kurią NKSC įtraukė į registrą kaip svarbų subjektą. Ji naudoja prieš ketverius metus sukurtą klientų savitarnos portalą, kurį prižiūri išorinis kūrėjas, o serveriai nuomojami iš talpinimo paslaugų teikėjo. Sutartyje su kūrėju yra SLA ir kodo perdavimas, bet nėra audito teisės, incidento pranešimo termino ir spragų valdymo pareigos.

Patikra parodė, kad portale administratoriai jungiasi tik slaptažodžiu, programos auditų žurnalas fiksuoja tik užsakymus, o kopijos laikomos tame pačiame duomenų centre. Darbų planas atrodė taip: sutarties priedas su KSRA 34 punkto reikalavimais (incidentas praneštas per kelias valandas, audito teisė, spragų pataisos pagal kritiškumą), kelių veiksnių autentifikacija administratoriams, auditų žurnalas su prisijungimais ir teisių pakeitimais, saugomas atskirai bent 90 dienų, kopijos antroje vietoje su šifravimu ir ketvirtiniu atkūrimo testu, WAF prieš portalą ir spragų skenavimas kas pusmetį. Visa tai buvo suplanuota etapais iki 24 mėnesių termino, o sutarties dalis sutvarkyta pirmiausia.

Dažniausios klaidos

  • NIS2 laikoma vien IT skyriaus užduotimi. Įstatymas atsakomybę už reikalavimų laikymąsi priskiria organizacijos vadovui, o tiekėjų reikalavimai turi atsirasti pirkimuose ir sutartyse.
  • Sutartyje parašyta „tiekėjas laikosi teisės aktų“. Tokia frazė nepakeičia konkrečių 34 punkto nuostatų: terminų, audito teisės, prieigų aprašymo.
  • Pamirštami subtiekėjai. 34 punktas taikomas sutartims su tiekėjais, įskaitant subtiekėjus. Jei kūrėjas naudoja kitą įmonę serveriams ar testavimui, tai turi būti žinoma.
  • Kopijos, kurių niekas neatkūrė. KSRA reikalauja kopijas testuoti, o ne tik daryti.
  • Nėra testinės aplinkos. Be jos neįmanoma testuoti pataisų ir pokyčių prieš produkciją.
  • Bendros paskyros. „admin“ paskyra, kuria naudojasi visa tiekėjo komanda, prieštarauja reikalavimui unikaliai atpažinti kiekvieną naudotoją.
  • Techniniai darbai paliekami paskutiniams mėnesiams. Kelių veiksnių autentifikacija ar auditų žurnalas senoje sistemoje yra plėtros projektas, kuriam reikia biudžeto ir laiko. Kaip vertinti tokių darbų kainą, aprašėme straipsnyje Kiek kainuoja individualios sistemos kūrimas.

DUK

Ar Kibernetinio saugumo įstatymas taikomas mano IT tiekėjui?

Tiesiogiai tik tuo atveju, jei tiekėjas pats įtrauktas į registrą (pavyzdžiui, kaip valdomų paslaugų ar debesijos paslaugų teikėjas). Kitais atvejais reikalavimai jį pasiekia per jūsų sutartį: jūs privalote juos numatyti ir kontroliuoti jų vykdymą (KSRA 34 ir 38 p.).

Ar ISO 27001 sertifikatas reiškia, kad tiekėjas atitinka reikalavimus?

Sertifikatai minimi tarp to, ką galima reikalauti iš tiekėjo personalo ir organizacijos (KSRA 34.2 p.), ir jie palengvina vertinimą. Tačiau NKSC nurodo, kad privalomas kibernetinio saugumo auditas turi būti atliekamas pagal NKSC metodiką, todėl ISO 27001 atitikties vertinimas jo savaime nepakeičia. Sutartyje vis tiek turi būti 34 punkto nuostatos.

Kokios baudos gresia?

Kibernetinio saugumo įstatymo 30 straipsnis nustato maksimalias baudas: esminiam subjektui iki 10 000 000 Eur arba iki 2 proc. pasaulinės metinės apyvartos, svarbiam iki 7 000 000 Eur arba iki 1,4 proc., atsižvelgiant į tai, kuri suma didesnė. Biudžetinėms įstaigoms taikomos mažesnės ribos: esminiam subjektui iki 1 proc. biudžeto ir pajamų, bet ne daugiau kaip 60 000 Eur, svarbiam iki 0,5 proc., bet ne daugiau kaip 30 000 Eur. Konkretus dydis priklauso nuo pažeidimo pavojingumo.

Ar reikia keisti visas sutartis iš karto?

NKSC rekomenduoja 34 punkto reikalavimus įtraukti į naujai sudaromas sutartis, atsižvelgiant į perkamas paslaugas. Esamas sutartis protinga peržiūrėti pagal sistemų kritiškumą: pirmiausia tos, pagal kurias tiekėjas turi prieigą prie sistemų, susijusių su registruota veikla.

Ar galime patys atlikti tiekėjo auditą?

Taip, jei tokia teisė numatyta sutartyje. KSRA 34.4 punktas reikalauja numatyti jūsų ar jūsų įgalioto paslaugų teikėjo teisę atlikti tiekėjo atitikties auditą, įskaitant neplaninį. Tai nėra tas pats, kas įstatymo 14 straipsnio 8 dalyje numatytas kas 3 metus atliekamas kibernetinio saugumo auditas, kurį atlieka nepriklausomi sertifikuoti auditoriai.

Ar reikalavimai taikomi ir mūsų įmonės svetainei?

Reikalavimai taikomi sistemoms, susijusioms su veikla, pagal kurią esate registre. Jei svetainė ar portalas yra tokia sistema (pavyzdžiui, klientų savitarna), jai taikomi ir konkretūs reikalavimai internetu pasiekiamoms sistemoms: WAF, apsauga pagal OWASP Top 10, draudimas laikyti prisijungimo duomenis kode. Informacinei svetainei, kuri su ta veikla nesusijusi, jie privalomai netaikomi, nors kaip geroji praktika praverčia.

Ką daryti toliau

Pradėkite nuo trijų dalykų: sudarykite sistemų ir tiekėjų sąrašą, pažymėkite sistemas, susijusias su registruota veikla, ir kiekvieną sutartį palyginkite su KSRA 34 punktu. Tada su kūrėju aptarkite techninius reikalavimus ir susidėliokite darbų planą iki savo 24 mėnesių termino.

DESAmedia kuria ir prižiūri individualias sistemas, todėl galime padėti iš kūrėjo pusės: įvertinti esamą sistemą pagal techninius reikalavimus, parengti darbų planą su sąmata ir įgyvendinti pakeitimus, nuo kelių veiksnių autentifikacijos iki auditų žurnalo ir kopijų atkūrimo testų. Tam skirta paslauga IT konsultacijos ir sistemų projektavimas, o naujoms sistemoms Web aplikacijų kūrimas. Viešojo sektoriaus organizacijoms aktualus ir puslapis Viešajam sektoriui. Tai nepakeičia įstatyme numatyto kibernetinio saugumo audito, kurį atlieka nepriklausomi sertifikuoti auditoriai. Klausimus galite užduoti per kontaktų puslapį.

Šaltiniai