DORA finansų įstaigoms ir jų IT tiekėjams: ko reikalaus iš jūsų

Penki DORA ramsčiai paprastai: ką reglamentas reiškia finansų įstaigai ir ką jis reikalauja iš jos IT tiekėjų – sutarčių, registro, išėjimo planų ir atstatymo.

DORA finansų įstaigoms ir jų IT tiekėjams: ko reikalaus iš jūsų

Jei esate kredito unija, mokėjimo įstaiga, draudimo brokeris ar investicinių fondų valdytojas, DORA jums taikoma jau dabar. Jei esate IT įmonė, kuri tokiems klientams prižiūri serverius, teikia debesijos paslaugas ar kuria programinę įrangą, DORA jus pasiekia per klientų sutartis – dažniausiai netikėtai, su prašymu per dvi savaites pasirašyti naują priedą.

DORA – tai ES reglamentas 2022/2554 dėl skaitmeninės veiklos atsparumo finansų sektoriuje, taikomas nuo 2025 m. sausio 17 d. Kitaip nei direktyva, reglamentas veikia tiesiogiai, be perkėlimo į nacionalinę teisę, todėl Lietuvos bankas jį prižiūri tokį, koks jis yra.

Šiame straipsnyje paaiškinsime penkis reglamento ramsčius žmonių kalba, parodysime, ką jie praktiškai reiškia IT tiekėjui, ir pasidalinsime, kaip tai sprendžiame savo klientams.

Penki DORA ramsčiai

Reglamentas sudarytas iš penkių sričių. Kiekviena jų turi ir dokumentinę, ir techninę pusę.

IRT rizikos valdymas

Finansų įstaiga privalo turėti vadovybės patvirtintą informacinių ir ryšių technologijų (IRT) rizikos valdymo sistemą: turto registrą, rizikų vertinimą, apsaugos priemones, aptikimo galimybes, atsako ir atkūrimo planus. Už visa tai atsako valdymo organas, ne IT skyrius. Praktiškai tai reiškia, kad vadovybė turi suprasti, kokios sistemos kritinės, kas nutiks joms sustojus ir kiek laiko įstaiga gali veikti be jų.

Incidentų valdymas ir pranešimas

Visi su IRT susiję incidentai registruojami, klasifikuojami pagal poveikį, o reikšmingi – pranešami priežiūros institucijai pagal griežtus terminus: pradinis pranešimas per kelias valandas, tarpinis ir galutinis vėliau. Įstaiga turi gebėti greitai įvertinti, kiek klientų paveikta, kiek laiko paslauga neveikė ir ar nutekėjo duomenys. Be žurnalų ir stebėsenos tai neįmanoma.

Skaitmeninės veiklos atsparumo testavimas

Nepakanka turėti apsaugą – reikia ją reguliariai tikrinti. Pagrindinis lygis: pažeidžiamumų skenavimas, konfigūracijų peržiūra, atstatymo iš kopijų testai, scenarijų pratybos. Didesnėms ir sisteminės svarbos įstaigoms numatytas grėsmėmis grįstas įsiskverbimo testavimas, kai specialistai imituoja realią ataką. Testų rezultatai dokumentuojami, o trūkumai šalinami pagal planą.

Trečiųjų šalių IRT rizikos valdymas

Tai ramstis, kuris labiausiai liečia IT tiekėjus. Įstaiga privalo vesti visų IRT paslaugų tiekėjų registrą, įvertinti kiekvieno riziką, įtraukti į sutartis privalomas sąlygas ir turėti išėjimo strategiją, jei tiekėjas nustotų teikti paslaugą. Ypač griežtai žiūrima į paslaugas, palaikančias kritines funkcijas – pavyzdžiui, apskaitos sistemos talpinimą ar atsargines kopijas.

Informacijos mainai

Įstaigos skatinamos dalintis informacija apie grėsmes ir pažeidžiamumus tarpusavyje ir su institucijomis. Mažai įstaigai tai dažniausiai reiškia dalyvavimą sektoriaus grupėse ir Nacionalinio kibernetinio saugumo centro įspėjimų sekimą.

Ką tai reiškia IT tiekėjui

Jei teikiate IT paslaugas finansų įstaigai, klientas negalės su jumis dirbti, jei neatitiksite jo DORA įsipareigojimų. Mūsų praktikoje tiekėjo pusėje tai virsta trimis konkrečiais dalykais.

Sutartys

Sutartyje su finansų įstaiga turi atsirasti aiškios nuostatos: tiksliai aprašytos paslaugos ir jų lygis, duomenų saugojimo vieta (ES ar ne), incidentų pranešimo terminai klientui, kliento ir priežiūros institucijos teisė atlikti auditą, subrangovų naudojimo taisyklės, paslaugos nutraukimo sąlygos ir pereinamasis laikotarpis. Jei jūsų standartinė sutartis to neturi, klientas atsiųs savo priedą. Geriau turėti savo, paruoštą iš anksto.

Registras

Klientas pildo tiekėjų registrą pagal nustatytą formą ir jam reikės informacijos apie jus: juridinio asmens duomenų, paslaugos tipo, kritiškumo, duomenų vietos, subrangovų. Tiekėjui verta turėti paruoštą atsakymų rinkinį, nes klausimynai iš skirtingų klientų iš esmės sutampa.

Išėjimo planai

Kiekviena įstaiga privalo gebėti pereiti nuo vieno tiekėjo prie kito be veiklos sutrikimo. Jūsų pareiga – aprašyti, kaip grąžinsite duomenis, kokiu formatu, per kiek laiko ir ką ištrinsite po perdavimo. Tiekėjas, kuris negali aiškiai atsakyti, kaip klientas gaus savo duomenis išėjus, kelia riziką ir bus pakeistas.

Dar vienas dalykas, kurį tiekėjai dažnai pražiūri – subrangovai. Jei savo klientui teikiate kopijų saugojimą, o kopijos fiziškai guli pas trečią šalį, klientas privalo apie tai žinoti ir turėti teisę prieštarauti. Subrangovų grandinė turi būti aprašyta sutartyje ir atnaujinama, kai keičiasi.

Žemiau – kaip tie patys reikalavimai atrodo iš abiejų pusių.

ReikalavimasFinansų įstaigaIT tiekėjas
Rizikos valdymasRizikų registras, vadovybės sprendimaiSavo saugumo politikos ir kontrolių įrodymai
IncidentaiPranešimas institucijai pagal terminusPranešimas klientui per sutartą laiką, žurnalai
TestavimasTestų planas ir rezultataiDalyvavimas atstatymo testuose, pažeidžiamumų šalinimas
Trečiosios šalysTiekėjų registras, išėjimo strategijaSutarties priedas, subrangovų sąrašas, išėjimo planas
Informacijos mainaiGrėsmių sekimas, dalyvavimas grupėseĮspėjimai klientui apie aktualias grėsmes

Kopijos ir atstatymas: kur dažniausiai klysta

DORA reikalauja ne tik turėti atsargines kopijas, bet ir įrodyti, kad iš jų galima atkurti veiklą per apibrėžtą laiką. Įstaiga turi nusistatyti atkūrimo laiko ir atkūrimo taško tikslus (RTO ir RPO) kiekvienai kritinei sistemai, o kopijos privalo būti fiziškai ir logiškai atskirtos nuo pagrindinės aplinkos.

Dažniausia klaida – kopijos saugomos tame pačiame tinkle arba pas tą patį tiekėją tame pačiame duomenų centre. Išpirkos reikalaujanti programa, užšifravusi serverius, užšifruoja ir jas. Antra klaida – atstatymas niekada neišbandytas, todėl per incidentą paaiškėja, kad kopija nepilna arba atkūrimas trunka dienas, o ne valandas.

Savo klientams siūlome slaptąsias rezervines kopijas, kurios yra nekeičiamos ir iš tinklo nematomos, o kritinėms sistemoms – PlanB infrastruktūros atstatymą, kai visa aplinka gali būti pakelta mūsų debesijoje, jei pagrindinė tampa nepasiekiama. Kopijos pagal poreikį saugomos ir Amazon duomenų centre Vokietijoje, kad geografinis atskyrimas būtų realus, o ne deklaruojamas.

Kaip MDP CLOUD padeda

Dirbame iš abiejų pusių: esame IT tiekėjas finansų įstaigoms ir padedame kitiems IT tiekėjams pasiruošti klientų reikalavimams. Mūsų komanda turi galiojančius ISACA sertifikatus (CISA, CISM, CRISC ir kitus), o paslaugas teikiame dirbdami pagal ISO 27001 reikalavimus, todėl klientų klausimynams atsakymus turime paruoštus.

Finansų įstaigai padedame sudaryti IRT turto ir tiekėjų registrus, atlikti rizikų vertinimą, parengti incidentų valdymo procedūrą su pranešimo šablonais, suplanuoti ir atlikti atsparumo testus. IT tiekėjui – paruošti sutarties priedą, saugumo politikų rinkinį, išėjimo plano šabloną ir techninius įrodymus, kurių prašys klientas.

Nuo ko pradėti

  1. Nustatykite, ar jums DORA taikoma tiesiogiai (esate finansų įstaiga) ar per klientus (esate tiekėjas). Nuo to priklauso darbų eilė.
  2. Sudarykite kritinių funkcijų ir jas palaikančių sistemų bei tiekėjų sąrašą. Tai pagrindas registrui ir rizikų vertinimui.
  3. Peržiūrėkite sutartis su tiekėjais arba klientais ir pažymėkite, kurių sąlygų trūksta.
  4. Patikrinkite kopijas: kur jos, ar atskirtos nuo pagrindinio tinklo, kada paskutinį kartą realiai atkurtos.
  5. Parenkite incidentų pranešimo procedūrą su kontaktais ir terminais, kad per incidentą nereikėtų ieškoti, kam skambinti.

Išsamų kelią nuo pirmo žingsnio iki priežiūros institucijos pasirengimo aprašėme DORA paslaugos puslapyje. Jei norite pradėti nuo pokalbio – susisiekite, ir per pirmą susitikimą pasakysime, kurie reikalavimai jums aktualūs, o kurių galite nesijaudinti.