IT paslaugų teikėjo sutartis pagal NIS2: saugumo sąlygos, SLA ir pranešimai apie incidentus

IT paslaugų teikėjo sutartyje pagal NIS2 nepakanka atitikties deklaracijos, bendros saugumo nuostatos ir mėnesinio paslaugos prieinamumo rodiklio. Su paslauga susijusi rizika turi būti paversta aiškiu atsakomybės paskirstymu, išmatuojamais paslaugų lygiais, operatyviu informacijos apie incidentus teikimu, prieiga prie įrodymų ir praktiškai įgyvendinamu pasitraukimo planu. Atspirties taškas yra paslaugos kritiškumas ir faktinis kontrolės priemonių pasidalijimas tarp šalių. Tik tuo remiantis galima nustatyti, kokios saugumo priemonės, terminai, tikrinimo teisės ir pranešimo pareigos turi būti įtrauktos į sutartį.

Sutartis kaip rizikos valdymo priemonė

Sutarčių peržiūrą reikėtų pradėti ne nuo parengto saugumo sąlygos šablono, o nuo organizacijos priklausomybių nuo tiekėjų žemėlapio. Kiekvieno tiekėjo atveju būtina nurodyti aptarnaujamas paslaugas, procesus, sistemas, duomenis ir vietas, o tada įvertinti paslaugos neprieinamumo arba saugumo pažeidimo poveikį. Pirmiausia analizuojamos tos priklausomybės, kurių sutrikimas gali sustabdyti veiklą, apriboti įsipareigojimų vykdymą arba apsunkinti incidento valdymą. Todėl ne visoms IT paslaugoms reikalingos vienodos sutartinės saugumo priemonės.

Tiekėjo kritiškumas turi būti klasifikuojamas pagal veiklos sutrikimo poveikio analizę ir rizikos vertinimą, o ne vien pagal sutarties vertę. Ypatingo dėmesio reikia paslaugoms, už kurių tęstinumą ir incidentų valdymą atsako įmonė, nors techninę informaciją, įvykių žurnalus, atsargines kopijas ar paslaugai atkurti būtiną aplinką kontroliuoja tiekėjas. Organizacijoje taip pat turi būti paskirtas su tiekėju susijusios rizikos savininkas. Be šio vaidmens atsakomybė lieka išskaidyta tarp pirkimų, IT, informacijos saugumo ir proceso savininko.

Sutarties turinį reikia rengti pagal galimus sutrikimų scenarijus: paslaugos gedimą, ataką, duomenų praradimą ar sugadinimą, tiekėjo darbuotojų nepasiekiamumą, subtiekėjų grandinės sutrikimą ir bendradarbiavimo nutraukimą. Kiekvienam scenarijui turi būti nustatyti šalių veiksmai, atsakomybės ribos, informacijos srautai ir atkūrimo sąlygos. Iš šių sprendimų nustatomi prieinamumo lygiai, reagavimo ir atkūrimo trukmė, privalomos dokumentacijos apimtis bei tikrinimo teisės.

Pažadas užtikrinti aukštą prieinamumą neatsako į klausimą, kiek laiko gali neveikti gamybos valdymo sistema, nuo kurio momento skaičiuojama prastova ir kas pateiks incidentui įvertinti reikalingus duomenis. Jis taip pat negarantuoja prieigos prie įvykių žurnalų kopijų, informacijos apie subtiekėjus ar duomenų, būtinų saugiai perkelti paslaugą. Tokios spragos paprastai išryškėja gedimo metu, kai atsakomybės pasidalijimas nebegali likti numanomas.

Nuoroda į NIS2 arba atitinkamus KSC reikalavimus turi užbaigti rizikos ir atsakomybės analizę, o ne pakeisti praktinį sutarties turinį. Platesnis valdymo kontekstas pateiktas medžiagoje NIS2 gamybos įmonėms: kam taikoma, kokias pareigas nustato ir kaip pasirengti neapsiribojant vien IT sritimi. Sutarčių pakeitimų apimtį kiekvienu atveju reikia pritaikyti prie organizacijos vaidmens, paslaugos kritiškumo ir faktinio kontrolės priemonių pasidalijimo tarp šalių.

Paslaugos apimtis ir atsakomybė

Pareigų pasidalijimas turi būti aprašytas techniniame priede, o ne paliktas bendroje sutarties dalyko apibrėžtyje. Priede reikėtų nurodyti aptarnaujamus išteklius ir aplinkas, duomenų rūšis, jų tvarkymo ir paslaugų teikimo vietas, sąsajas, pagalbos teikimo laiką ir išimtis. Be šios informacijos neįmanoma vienareikšmiškai nustatyti, kur baigiasi tiekėjo atsakomybė, koks įvykis pradeda SLA rodiklių skaičiavimą ir kas apsaugo sistemų sąsajose esančius elementus.

Saugumo priemones tikslinga aprašyti nurodant laukiamą rezultatą, atsakingą šalį ir įgyvendinimo įrodymą, o technologines detales palikti valdomoje techninėje dokumentacijoje. Taip mažinama rizika, kad sutartis greitai pasens. Standartinį tiekėjo saugumo priemonių katalogą galima priimti tik palyginus jį su konkrečios paslaugos rizika ir pašalinus nustatytas spragas. Atsakomybės matricoje turi būti atskirti kontrolės priemonės savininkas, jos vykdytojas ir išimtis tvirtinantis asmuo ar subjektas.

Jeigu aplinką administruoja tiekėjas, sutartyje papildomai turi būti reglamentuota privilegijuotoji prieiga: pareigų atskyrimas, tapatybės nustatymo būdas, administracinių veiksmų registravimas ir neatidėliotinas teisių panaikinimas pasikeitus vaidmeniui ar pasibaigus bendradarbiavimui. Vien pareiškimo, kad atsarginės kopijos yra daromos, nepakanka, jeigu klientas nežino, kas jas šifruoja, kur jos saugomos, kas gali atkurti duomenis ir koks dokumentas patvirtina atkūrimo bandymo rezultatą.

Tiekėjas turi tvarkyti aktualų paslaugai įtaką darančių subtiekėjų sąrašą, nurodyti jų vaidmenis bei duomenų tvarkymo vietas ir nustatyti jiems ne silpnesnius reikalavimus, nei sutarta su klientu. Sutartyje turi būti aiškiai apibrėžta, kuriems pakeitimams reikia išankstinio sutikimo, o kuriems pakanka pranešimo ir pakartotinio rizikos vertinimo. Vadybos sistemos sertifikatas gali būti naudingas atliekant šį vertinimą, tačiau jis nepakeičia konkrečiai paslaugai nustatytos atsakomybės. Šis ryšys plačiau aptartas medžiagoje NIS2 ir LST EN ISO 27001: ką suteikia sertifikatas ir ko dar trūksta siekiant atitikties KSC.

Patikrinamos saugumo sąlygos

Saugumo sąlyga tampa pamatuojama ir valdoma tik tada, kai joje apibrėžti laukiamas rezultatas, taikymo apimtis, veiksmų periodiškumas, įvykdymo patvirtinimo būdas ir išimčių valdymo tvarka. Formuluotės „pagal geriausią praktiką“ arba „laikantis deramo rūpestingumo“ gali papildyti reikalavimus, tačiau neleidžia įvertinti, ar tiekėjas tinkamai įvykdė savo įsipareigojimą. Kiekvienai saugumo priemonei reikia paskirti reikalavimo savininką, nustatyti įrodymų saugojimo terminą ir nurodyti šalį, turinčią teisę patvirtinti išimtį.

Taip parengti reikalavimai turi apimti bent pažeidžiamumų ir atnaujinimų valdymą, saugios konfigūracijos palaikymą, šifravimą, įvykių žurnalų apsaugą ir saugojimą, atsarginių kopijų kūrimą, atkūrimo bandymus, pakeitimų valdymą bei prieigos kontrolę. Prieigos teisių peržiūrų, atkūrimo bandymų ir ataskaitų teikimo periodiškumas bei pažeidžiamumų šalinimo terminai turi būti nustatomi pagal konkrečios paslaugos riziką. Jie neturėtų būti vienodi visiems tiekėjams.

Kiekviena išimtis turi būti įtraukta į registrą, nurodant pagrindimą, pašalinimo terminą, rizikos savininką ir kompensacines kontrolės priemones. Prieš patvirtinant išimtį būtina įvertinti, ar šios priemonės iš tiesų sumažina riziką iki organizacijai priimtino lygio.

Nuostata dėl reguliaraus atsarginių kopijų kūrimo yra nepakankama, jei joje nenurodyti kopijuojami duomenys ir sistemos, saugojimo terminas, apsauga nuo pakeitimo ar ištrynimo, prieigos taisyklės ir atkūrimo bandymų dažnis. Joje taip pat turi būti apibrėžta, kaip tiekėjas praneša apie nepavykusį kopijavimą ar atkūrimo bandymą, kas tvirtina taisomuosius veiksmus ir kokia ataskaita patvirtina jų užbaigimą. Analogiškai pareigai šalinti pažeidžiamumus reikia nustatyti klasifikavimo metodą, nuo rizikos priklausančius reagavimo terminus, atnaujinimų atidėjimo taisykles ir laikinųjų saugumo priemonių dokumentavimą.

Įrodymai turi būti suskirstyti į periodiškai teikiamus ir pateikiamus pareikalavus. Pirmajai grupei gali priklausyti pažeidžiamumų suvestinės, atnaujinimų ataskaitos, atkūrimo bandymų rezultatai ir prieigos teisių peržiūrų patvirtinimai. Po incidento, reikšmingo pakeitimo ar nustačius neatitiktį gali prireikti išsamių bandymų rezultatų, įvykių žurnalų, pakeitimų istorijos, išimčių registro ir taisomųjų veiksmų plano. Šių dokumentų apimtį, savininkus ir saugojimo terminus verta susieti su medžiagoje NIS2 ir KSC dokumentacija prieš patikrinimą: kokių politikų, registrų ir įrodymų iš tikrųjų reikia aprašytais principais.

Tikrinimo teisės turi būti proporcingos ir praktiškai įgyvendinamos, taip pat ir debesijos paslaugų teikėjų atveju. Pirmasis lygis gali apimti dokumentų peržiūrą ir paaiškinamąjį susitikimą, kitas – nepriklausomas ataskaitas arba suderintus bandymus, o auditą vietoje galima numatyti padidėjusios rizikos, reikšmingo incidento ar patikimų įrodymų trūkumo atvejais. Sutartyje turi būti nustatyti terminai, konfidencialumo taisyklės, techninė apimtis ir nustatytų trūkumų šalinimo tvarka, nesuteikiant klientui teisių, kurių neįmanoma įgyvendinti bendro naudojimo aplinkoje.

SLA atsparumui, o ne vien prieinamumui

SLA turi būti grindžiamas poveikio veiklai analize, o ne standartiniu tiekėjo parametrų katalogu. Proceso savininkas pirmiausia nustato toleruotiną veiklos pertraukos trukmę, leistiną duomenų praradimą ir neprieinamumo poveikį gamybai, klientų aptarnavimui, atsiskaitymams bei teisinėms pareigoms. Tik tada nustatomi atkūrimo laiko tikslai, pakaitinės paslaugos ir avarinio režimo reikalavimai bei pranešimų prioritetai. Mėnesinis prieinamumo rodiklis neparodo, ar vienas gedimas kritiniu momentu nesustabdys proceso ilgiau, nei organizacija gali toleruoti.

Be prieinamumo, sutartyje turi būti nustatyti pranešimo gavimo patvirtinimo, diagnostikos pradžios, funkcijų atkūrimo ir priežasties pašalinimo terminai, taip pat informavimo dažnis, eskalavimo lygiai ir darbo ne įprastomis valandomis tvarka. Reagavimo laikas nėra atkūrimo laikas, o laikinojo sprendimo įdiegimas dar nereiškia, kad problema galutinai pašalinta. Aiškiai atskyrus šias sąvokas, operacinė komanda žino, kada galės atnaujinti darbą, o paslaugos savininkas – kada tiekėjas turi užbaigti priežasčių analizę ir įgyvendinti ilgalaikį taisomąjį veiksmą.

Gamybos procesą valdančios sistemos kritinis incidentas gali pareikalauti neatidėliotino eskalavimo ir nenutrūkstamo informavimo iki avarinio režimo įjungimo. Toks pats gedimas mokymo aplinkoje gali būti priskirtas žemesniam prioritetui. Todėl klasifikacija turi būti grindžiama poveikiu veiklai, o ne tik techniniu klaidos aprašymu. Jei organizacija turi patikimų istorinių duomenų, nustatydama ribines vertes ji turėtų atsižvelgti į faktinę reagavimo ir atkūrimo trukmę, prieinamumo rezultatus bei pasikartojančių gedimų skaičių.

Matavimo mechanizme turi būti nurodytas duomenų šaltinis, laiko juosta, skaitiklio paleidimo ir sustabdymo momentas, sutartos paslaugos teikimo valandos, techninės priežiūros laikotarpiai bei incidento klasės keitimo taisyklės. Matavimo išimtys turi būti pateiktos baigtiniame ir patikrinamame sąraše. Jos negali apimti įvykių, patenkančių į tiekėjo atsakomybės sritį. Šių nuostatų atitiktį faktiniam operaciniam pasirengimui galima įvertinti atliekant NIS2 auditą gamybos įmonėje – kaip patikrinti organizacijos pasirengimą naujoms pareigoms.

Paslaugų kreditai ar simbolinės kompensacijos neatkuria proceso ir nesumažina prastovos poveikio. Didesnę reikšmę turi pareiga pateikti taisomųjų veiksmų planą, eskalavimas vadovybei, papildomi atsparumo bandymai ir teisė nutraukti sutartį, jei sutarti paslaugų lygiai nuolat arba pakartotinai nepasiekiami. Finansinė sankcija gali sustiprinti atsakomybę, tačiau nepakeičia paslaugos atkūrimo, priežasčių šalinimo ir pakartotinių gedimų prevencijos mechanizmo.

Incidentai ir pranešimo pareigos

Sutartyje tiekėjas turi būti įpareigotas nedelsdamas pranešti apie kiekvieną įvykį, galintį paveikti paslaugą, duomenis, veiklos tęstinumą ar kliento saugumą. Pirminis pranešimas negali priklausyti nuo to, ar jau galutinai patvirtinta įvykio priežastis, žalos mastas arba teisinis kvalifikavimas. Sutartinis terminas turi palikti klientui pakankamai laiko atlikti savo vertinimą ir, kai taikoma, laikytis išorinių pranešimo terminų. Jis turi būti nustatomas atsižvelgiant į paslaugos kritiškumą ir visą parą veikiančio kontaktinio punkto prieinamumą, o ne į šalių administracinį patogumą.

Informacijos teikimas turi būti suskirstytas į pirminį įspėjimą, situacijos atnaujinimus, ataskaitą po incidento ir pagrindinės priežasties analizę. Kiekvienam etapui reikia nustatyti duomenų apimtį, leidžiamą kanalą, gavėjus, atnaujinimo dažnį ir eskalavimo taisykles, jei nepavyksta susisiekti. Pirminiame pranešime turi būti nurodytas bent aptikimo laikas, paveikti ištekliai ir paslaugos, numatomas poveikis, atlikti veiksmai, turimi techniniai indikatoriai, tolesnio plitimo rizikos įvertinimas ir kito atnaujinimo laikas. Kontaktų sąraše turi būti nurodyti pavaduojantys asmenys, o jo veiksmingumas periodiškai tikrinamas, taip pat ir ne įprastomis darbo valandomis.

Jeigu tiekėjas pagrindinę taikomąją programą palaikančioje aplinkoje aptinka neįprastą srautą, jis turi įspėti klientą dar prieš nustatydamas, ar įvyko saugumo pažeidimas. Klientas pradeda savo incidentų valdymo procesą, paskiria už sprendimus atsakingą asmenį, įtraukia reagavimo komandą, o atitinkamu atveju – ir draudiką, bei nustato, kas tvirtina išorinį pranešimą ir komunikaciją su klientais. Tiekėjas išsaugo sutartus žurnalus bei techninius pėdsakus ir padeda analizuoti incidentą, riboti jo poveikį bei nustatyti apimtį, tačiau neperima kliento reguliacinės atsakomybės.

Sąlygose taip pat turi būti nustatytos įrodymų išsaugojimo ir pateikimo, jų vientisumo apsaugos, sprendimų dokumentavimo ir pranešimams bei vėlesnei pagrindinių priežasčių analizei reikalingų duomenų parengimo taisyklės. Išorinių pranešimų terminai, gavėjai ir apimtis kiekvienu atveju turi būti tikrinami pagal aktualią teisę, organizacijos statusą ir įvykio pobūdį. Pranešimų, sprendimų, eskalavimo ir veiksmų registrus reikia susieti su medžiaga „NIS2 ir KSC dokumentacija prieš patikrinimą: kokių politikų, registrų ir įrodymų iš tikrųjų reikia“, o pritaikymo grafiką – su medžiaga NIS2 įgyvendinimas po įtraukimo į KSC sąrašą – veiksmų planas iki 2027 m. balandžio 3 d..

Įgyvendinimas, priežiūra ir saugus pasitraukimas

Sutarties priedo pasirašymas neužbaigia tiekėjo valdymo proceso. Sutarties savininkas turi periodiškai peržiūrėti SLA rezultatus, incidentus, išimtis, taisomuosius veiksmus, subtiekėjų pakeitimus ir reikalavimų vykdymą patvirtinančių įrodymų aktualumą. Priežiūros pagrindas yra sutarčių registras, kuriame turi būti nurodyta bent pratęsimo data, savininkas, paslaugos kritiškumas ir saugumo priemonių suderinimo būklė. Atitikties deklaracija nepakeičia ataskaitų, bandymų rezultatų ir pareigų vykdymą patvirtinančių įrašų.

Prieš pratęsiant sutartį arba iš esmės keičiant paslaugą, reikia iš naujo įvertinti jos kritiškumą, technines ir procesines priklausomybes, paslaugų koncentraciją pas vieną tiekėją, saugumo priemonių įgyvendinamumą ir galimybę pereiti prie alternatyvaus sprendimo. Tokia peržiūra leidžia nuspręsti, ar pakanka sutarties priedo, ar būtina nauja pirkimo procedūra. Jeigu strateginis tiekėjas atsisako audito arba sutarties pakeitimų, organizacija turi dokumentuoti spragą ir pasirinkti: įdiegti kompensacinę kontrolės priemonę, formaliai priimti likutinę riziką arba pakeisti tiekėją.

Pasitraukimo planas turi būti praktiškai įgyvendinamas dar prieš nutraukiant sutartį. Jis turi apimti duomenų grąžinimą ir perkėlimą tinkamu naudoti formatu, pagalbą migracijos metu, tęstinumo užtikrinimą pereinamuoju laikotarpiu, prieigos teisių panaikinimą, kopijų ištrynimą ir šių veiksmų atlikimo patvirtinimą. Kartu būtina išsaugoti teisės, įrodymų ir audito tikslais reikalingus įrašus. Praktinis patikrinimas – bandomasis duomenų atkūrimas pas kitą tiekėją, įvertinant jų išsamumą, migracijos trukmę ir galimybę išjungti ankstesnes paskyras.

Sutarčių portfelio atnaujinimą reikia pradėti nuo didžiausią poveikį veiklai turinčių paslaugų, o spragas suskirstyti pagal pasekmes ir skubumą. Pasirinktų mechanizmų veiksmingumą verta patikrinti per incidento valdymo pratybas ir atrinktų įrodymų auditą. SLA, incidentų, išimčių, taisomųjų veiksmų ir pasitraukimo bandymų peržiūrų rezultatai parodys, ar reikalavimai veikia praktiškai, ar lieka tik sutarties tekstu.

Vertinimo apimtį galima susieti su medžiaga „NIS2 auditas gamybos įmonėje – kaip patikrinti organizacijos pasirengimą naujoms pareigoms“. Organizacijos pareigos turi būti nustatomos atsižvelgiant ir į jos statusą, aptartą medžiagoje NIS2 direktyva – kam ji taikoma ir kurios įmonės turi vykdyti naujus reikalavimus?