Išpirkos reikalaujančios programinės įrangos mokėjimų valdysena pagal NIS2 ir DORA

2026 m. darbo dieną, 3:17 val. nakties, sparčiai augančios finansinių technologijų platformos CISO Marija įtraukiama į krizių valdymo konferencinį skambutį po pagrindinio SOC analitiko pranešimo: patvirtintas plataus masto šifravimas, pagrindinės paslaugos neveikia, o išpirkos reikalaujančios programinės įrangos grupuotė teigia pavogusi 2 TB klientų duomenų.

Pirmasis prie skambučio prisijungia generalinis direktorius. Po jo – teisės skyrius. Tada privatumo, finansų ir komunikacijos komandos, kibernetinis draudikas, skaitmeninės kriminalistikos paslaugų teikėjas ir debesijos operacijų komanda. Tamsiojo žiniatinklio portale rodomas 48 valandų atgalinis skaičiavimas ir septynženklė suma kriptovaliuta.

Generalinis direktorius užduoda klausimą, kurio bijo kiekvienas CISO.

„Ar galime mokėti ir kas turi teisę tai nuspręsti?“

Neteisinga tai vertinti kaip derybų klausimą. Teisinga tai vertinti kaip valdysenos klausimą.

2026 m. sprendimų dėl išpirkos reikalaujančios programinės įrangos mokėjimų valdysena nebėra privatus techninis pasirinkimas krizės metu. Ją gali tikrinti reguliuotojai, auditoriai, draudikai, klientai, teisėsaugos institucijos, akcininkai ir valdyba. Sprendimas mokėti susikerta su sankcijų rizika, asmens duomenų saugumo pažeidimo vertinimu, kibernetinio draudimo sąlygomis, sutartinėmis pareigomis, krizių komunikacija, įrodymų išsaugojimu, NIS2 etapiniu pranešimu, DORA incidentų klasifikavimu, GDPR pranešimais ir tobulinimu po incidento.

Todėl Clarysec klientams rekomenduoja sprendimų dėl išpirkos reikalaujančios programinės įrangos mokėjimų valdyseną sukurti ISVS dar prieš incidentą. ISO/IEC 27001:2022 suteikia valdymo sistemos struktūrą. ISO/IEC 27002:2022 kontrolės priemonės apibrėžia veiklos modelį. Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas ir Zenith Controls: kryžminės atitikties vadovas padeda šią struktūrą paversti praktiniais, audituojamais įrodymais.

Išpirkos reikalaujančios programinės įrangos veiksmų planas, kuriame parašyta tik „informuoti teisės skyrių“, nėra pakankamas. Organizacija turi žinoti, kas gali autorizuoti derybas, kaip atliekama sankcijų patikra, kada būtinas draudiko patvirtinimas, kaip dokumentuojamas GDPR, NIS2 ir DORA klasifikavimas ir kaip įrodymai apsaugomi atkūrimo komandoms dirbant spaudimo sąlygomis.

Kodėl ad hoc sprendimai dėl išpirkos reikalaujančios programinės įrangos mokėjimų žlunga

Sprendimas dėl išpirkos reikalaujančios programinės įrangos mokėjimo dažnai apibūdinamas kaip dvejetainis: mokėti arba nemokėti. Iš tikrųjų sprendimas turi bent šešis sluoksnius:

1. Ar įvykis patvirtintas, lokalizuotas ir teisingai suklasifikuotas?
2. Ar paveikti asmens duomenys, reguliuojami duomenys arba kritinių paslaugų teikimas?
3. Ar organizacijai teisiškai leidžiama komunikuoti arba sudaryti sandorį su grėsmės subjektu?
4. Ar kibernetinis draudimas reikalauja išankstinio pranešimo, patvirtintų tiekėjų, sutikimo ar konkrečių įrodymų?
5. Ar mokėjimas sumažintų poveikį verslui, ar padidintų teisinę, finansinę ir reputacinę riziką?
6. Kas turi sprendimo įgaliojimus ir kaip tas sprendimas registruojamas?

Vykstant incidentui, tarpusavyje nesuderintos komandos dažnai traukia skirtingomis kryptimis. Finansų direktorius (CFO) gali vertinti išpirką kaip veiklos sąnaudas, palyginti su didėjančia prastova. Teisės skyrius mato sankcijas, finansinius nusikaltimus ir reguliacinę riziką. Duomenų apsaugos pareigūnas (DPO) vertina, ar užšifruoti arba iškelti duomenys sukuria praneštiną asmens duomenų saugumo pažeidimą. Atitikties funkcija stebi NIS2 ir DORA pranešimų terminus. CISO bando išsaugoti įrodymus ir kartu atkurti paslaugas. Generalinis direktorius nori rekomendacijos iki užpuoliko laikmačio pabaigos.

Be formalaus sprendimų priėmimo proceso garsiausias balsas kambaryje gali tapti valdysenos modeliu. Būtent tokiai situacijai šiuolaikinis kibernetinio saugumo reguliavimas ir siekia užkirsti kelią.

NIS2 kibernetinį saugumą paverčia vadovybės atsakomybe. Article 20 apibrėžia valdymo organų valdyseną ir atskaitomybę, o Article 21 reikalauja rizikos valdymo priemonių, apimančių incidentų valdymą, veiklos tęstinumą, atsarginių kopijų valdymą, krizių valdymą, tiekimo grandinės saugumą, prieigos kontrolę, turto valdymą, daugiafaktorį autentifikavimą (MFA) ir veiksmingumo vertinimą. Article 23 nustato etapais teikiamus pranešimus apie reikšmingus incidentus, įskaitant ankstyvąjį perspėjimą per 24 valandas, pranešimą per 72 valandas ir, kai taikoma, galutinę ataskaitą per vieną mėnesį.

Finansų subjektams DORA yra sektoriui skirta skaitmeninės veiklos atsparumo taisyklių sistema. Article 5 nustato valdymo organo atsakomybę už IRT rizikos valdymą. Articles 17, 18 ir 19 reglamentuoja su IRT susijusių incidentų valdymą, didelių su IRT susijusių incidentų klasifikavimą ir pranešimą. DORA taip pat reikalauja reagavimo ir atkūrimo pajėgumų, atsarginių kopijų kūrimo ir atkūrimo, mokymosi po incidento, testavimo ir IRT trečiųjų šalių rizikos valdymo.

GDPR prideda atskirą, bet persidengiantį vertinimą. Jei išpirkos reikalaujanti programinė įranga sukelia atsitiktinį ar neteisėtą asmens duomenų sunaikinimą, praradimą, pakeitimą, neteisėtą atskleidimą arba prieigą prie jų, duomenų valdytojas turi įvertinti, ar įvyko asmens duomenų saugumo pažeidimas. Jei pranešimas būtinas, priežiūros institucijos terminas paprastai skaičiuojamas 72 valandas nuo sužinojimo. Jei asmenims kyla didelė rizika, taip pat gali reikėti informuoti paveiktus asmenis.

Išvada paprasta: išpirkos klausimas neturi būti pirmą kartą užduodamas krizių valdymo kambaryje.

ISO 27001:2022 kontrolės priemonės, kuriomis grindžiama mokėjimų valdysena

ISO/IEC 27001:2022 ISVS nėra kontrolinis sąrašas auditoriams. Tai valdymo sistema rizika grindžiamiems sprendimams priimti. Išpirkos reikalaujančios programinės įrangos mokėjimų valdysena priklauso šiai sistemai, nes ji sujungia rizikos vertinimą, rizikos tvarkymą, vaidmenis, teisines prievoles, reagavimą į incidentus, tęstinumą, tiekėjų valdymą ir nuolatinį tobulinimą.

Svarbiausios ISO 27001:2022 A priedo kontrolės priemonės sudaro susietą kontrolės priemonių grandinę.

Zenith Controls A.5.24 skirsnyje „Informacijos saugumo incidentų valdymo planavimas ir pasirengimas“ ši kontrolės priemonė klasifikuojama kaip korekcinė, susieta su konfidencialumu, vientisumu ir prieinamumu bei suderinta su reagavimo ir atkūrimo koncepcijomis. Jame A.5.24 taip pat siejama su A.5.25 įvykių vertinimu, A.5.27 mokymusi iš incidentų, A.8.15 žurnalų tvarkymu, A.8.16 stebėsena, A.5.29 saugumu sutrikimų metu, tęstinumu ir ryšiu su institucijomis.

Tai svarbu, nes išpirkos reikalaujančios programinės įrangos mokėjimų valdysena yra grandinė. Jei negalite aptikti ir suklasifikuoti įvykio, negalite priimti sprendimo. Jei negalite išsaugoti įrodymų, negalite pagrįsti sprendimo. Jei teisinės prievolės nesusietos, derybos arba mokėjimas gali būti neteisėti. Jei atkūrimo galimybės neištestuotos, vadovybė gali būti spaudžiama priimti sprendimą remdamasi baime, o ne faktais.

Zenith Controls aiškiai apibrėžia pasirengimo ir sprendimų priėmimo ryšį:

„5.25 yra sprendimo taškas, nustatantis, kada įvykis peržengia saugumo incidento slenkstį ir aktyvuoja 5.26 nurodytus veiksmus. Savalaikis ir tikslus įvykio vertinimas užtikrina, kad reagavimas į incidentus nebūtų nei uždelstas, nei nukreiptas klaidinga kryptimi.“

Tas pats vadovas A.5.31 „Teisiniai, įstatyminiai, reglamentavimo ir sutartiniai reikalavimai“ sieja su privatumu, įrašų saugojimu, nepriklausoma peržiūra ir vidaus politikų laikymusi. Išpirkos reikalaujančios programinės įrangos atveju A.5.31 yra ta vieta, kur sankcijų patikra, draudimo įsipareigojimai, bendradarbiavimas su teisėsauga, klientų sutartys, duomenų apsaugos pareigos ir sektoriaus reglamentavimo pranešimai suvedami į vieną atitikties registrą.

Clarysec penkių kontrolinių vartų išpirkos reikalaujančios programinės įrangos mokėjimų valdysenos modelis

Clarysec modelis sprendimų dėl išpirkos reikalaujančios programinės įrangos mokėjimų valdyseną suskirsto į penkis kontrolinius vartus. Tikslas nėra palengvinti mokėjimą. Tikslas – užtikrinti, kad bet koks sprendimas, įskaitant atsisakymą mokėti, būtų grindžiamas įrodymais, teisiškai įvertintas, autorizuotas ir audituojamas.

Šis modelis taiko ISO 27001 rizikos tvarkymo logiką. Išpirkos mokėjimas nėra saugumo kontrolės priemonė. Geriausiu atveju tai yra krizės pasirinkimas, svarstomas rizikos tvarkymo ir atkūrimo kontekste. Prieš incidentą organizacija jau turi būti nusprendusi, kaip tvarkoma išpirkos reikalaujančios programinės įrangos rizika: mažinama kontrolės priemonėmis, dalis finansinės rizikos perduodama draudimu, vengiama nepriimtinų senųjų priklausomybių arba aiškiai priimama liekamoji rizika, kai tai pagrįsta.

Rizikos valdymo etape, 13 žingsnyje „Rizikos tvarkymo planavimas ir Taikomumo pareiškimas“, Zenith Blueprint nurodo organizacijoms nustatyti kiekvienos rizikos tvarkymo parinktis ir dokumentuoti jas rizikų registre. Jame įspėjama, kad perdavimas, pavyzdžiui, kibernetinis draudimas, nepanaikina kontrolės priemonių poreikio, nes perdavimas dažnai apima finansinį poveikį, o ne tikimybę. Taip pat nurodoma:

„Priėmimas turi būti aiškus ir patvirtintas vadovybės, ypač bet kokioms vidutinėms rizikoms. Didelės rizikos retai priimamos, nebent jos iš tiesų neišvengiamos ir suderintos aukščiausiu lygiu.“

Ši nuostata tiesiogiai aktuali išpirkos reikalaujančios programinės įrangos mokėjimų valdysenai. Jei valdybos prašoma priimti liekamąją riziką nemokant arba teisinę ir reputacinę riziką patvirtinant derybas, priėmimas turi būti aiškus, užregistruotas ir patvirtintas tinkamus įgaliojimus turinčio subjekto.

Clarysec Rizikos valdymo politika sustiprina tą pačią mintį:

„Rizikos tvarkymo sprendimai turi atitikti iš anksto apibrėžtas parinktis“
Iš 5.5 punkto.

Todėl sprendimas dėl išpirkos nėra trumpasis kelias apeiti rizikos valdymą. Jis turi būti tvarkomas kaip formalus, dokumentuotas rizikos tvarkymo sprendimas pagal apibrėžtus įgaliojimus.

Politikos įgaliojimai: kas gali spręsti spaudimo sąlygomis?

Daugelis išpirkos reikalaujančios programinės įrangos nesėkmių yra valdysenos nesėkmės, užmaskuotos kaip techninės nesėkmės. Kažkas susisiekia su užpuoliku nepatvirtintu kanalu. Kažkas pažada mokėti prieš draudiko patvirtinimą. Kažkas atkuria sistemas ir perrašo skaitmeninės kriminalistikos įrodymus. Kažkas informuoja klientus per anksti, per vėlai arba pateikdamas netikslius faktus.

Clarysec politikos skirtos pašalinti tokį neapibrėžtumą.

MVĮ atveju Valdysenos vaidmenų ir atsakomybių politika MVĮ pateikia paprastą taisyklę:

„Visi reikšmingi saugumo sprendimai, išimtys ir eskalavimai turi būti registruojami ir atsekami.“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.5 punkto.

MVĮ Reagavimo į incidentus politika MVĮ priskiria eskalavimo įgaliojimus:

„Generalinis vadovas (GM) yra atsakingas už visų incidentų eskalavimo sprendimų, pranešimų reguliuotojams ir išorinės komunikacijos autorizavimą.“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.1.1 punkto.

Ji taip pat susieja klientų duomenų incidentus su reglamentavimo įpareigojimais:

„Kai susiję klientų duomenys, generalinis vadovas turi įvertinti teisinius pranešimo įpareigojimus pagal GDPR, NIS2 arba DORA taikomumą.“
Iš skyriaus „Rizikos tvarkymas ir išimtys“, politikos 7.4.1 punkto.

Didesnėms organizacijoms skirta organizacijos Valdysenos vaidmenų ir atsakomybių politika reikalauja nedelsiant eskaluoti, kai gali būti teisinė rizika arba praneštini duomenų saugumo pažeidimai:

„Perdavimas teisiniam / reglamentavimo vertinimui: incidentai, susiję su galima teisine rizikos ekspozicija arba praneštinais duomenų saugumo pažeidimais, turi būti nedelsiant perduodami teisės ir atitikties pareigūnui bei vadovybei.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.4.3 punkto.

Organizacijos Reagavimo į incidentus politika apibrėžia vykdomuosius įgaliojimus sunkių incidentų metu. 4.6.1 punkte nurodyta, kad vadovybės komandos vaidmuo yra:

„Priimti strateginius sprendimus didelio sunkumo incidentų metu, įskaitant pranešimų ir viešosios komunikacijos patvirtinimą.“

Išpirkos reikalaujančios programinės įrangos kontekste Clarysec mokėjimo aptarimą, derybų autorizavimą, klientų informavimą, reglamentavimo pareiškimą ir viešąją komunikaciją laiko strateginiais sprendimais, o ne techniniais veiksmais.

Iš to kyla praktinė valdysenos taisyklė: CISO gali rekomenduoti, incidentų komanda gali vertinti, teisės skyrius gali konsultuoti, finansai gali patikrinti mokėjimo mechaniką, draudikas gali sutikti arba atsisakyti draudimo apsaugos, tačiau sprendimo savininkas pagal iš anksto apibrėžtus įgaliojimus turi būti vadovybė arba valdyba.

Sankcijų požiūriu saugus eskalavimas prieš bet kokias derybas

Sankcijų požiūriu saugus išpirkos reikalaujančios programinės įrangos procesas prasideda draudimu: joks darbuotojas, rangovas, tiekėjas, brokeris, derybininkas ar reagavimo į incidentus specialistas negali derėtis, žadėti, tarpininkauti ar perduoti vertės grėsmės subjektui be patvirtintos teisinės peržiūros.

Teisinis kontrolės taškas turi įvykti prieš bet kokį aktyvų bendravimą su užpuoliku, o ne po to, kai pasirodo piniginės adresas. Procesas turi apimti:

• Teisininko įtraukimą prieš bet kokią komunikaciją, viršijančią pasyvų įrodymų fiksavimą.
• Grėsmės subjekto identifikavimą naudojant skaitmeninės kriminalistikos, žvalgybos ir teisėsaugos duomenis, kai jų yra.
• Sankcijų ir ribojamų šalių patikrą pagal grupuočių pavadinimus, slapyvardžius, piniginių adresus, infrastruktūrą, tarpininkus ir mokėjimo kanalus.
• Konsultacijos su teisėsauga apsvarstymą ir registravimą.
• Kibernetinio draudiko informavimą pagal poliso sąlygas prieš paskiriant tiekėjus arba pradedant derybas.
• DPO arba privatumo vadovo įtraukimą, jei gali būti susiję asmens duomenys.
• CFO arba finansų vadovo patvirtinimą dėl mokėjimo kontrolės priemonių, pareigų atskyrimo, sukčiavimo prevencijos patikrų ir valdybos patvirtinimo reikalavimų.
• Vadovybės sprendimo registravimą nurodant apsvarstytas alternatyvas, įskaitant atkūrimą, lokalizavimą, paslaugos sustabdymą, klientų komunikaciją ir atsisakymą mokėti.
• Įrodymų dėl užpuoliko komunikacijos, indikatorių, piniginės duomenų, sprendimų posėdžių, patvirtinimų ir išorinių konsultacijų išsaugojimą.

Išpirkos reikalaujančios programinės įrangos atveju teisinių reikalavimų registre turi būti bent šie įpareigojimų šaltiniai.

Organizacijos taip pat turi apibrėžti, kas gali sustabdyti mokėjimo sprendimą. Teisės skyrius, atitiktis, DPO, sankcijų teisininkas arba valdyba turi turėti aiškius įgaliojimus pristabdyti derybas ar mokėjimą, jei patikra nebaigta, įrodymai nepatikimi, draudiko sąlygos neįvykdytos arba veiksmas gali pažeisti teisės aktus ar sutartį.

Įrodymų išsaugojimas: neatkurkite paslaugos sunaikindami įrodymus

Išpirkos reikalaujančios programinės įrangos komandos natūraliai skuba atkurti operacijas. Tačiau jei atkūrimas sunaikina žurnalus, momentines kopijas, išpirkos raštelius, kenkimo programinės įrangos pavyzdžius, atminties atvaizdus ar užpuoliko žinutes, organizacija gali prarasti galimybę įrodyti, kas įvyko.

„Controls in Action“ etape, 23 žingsnyje „Organizacinės kontrolės priemonės“, Zenith Blueprint nurodo organizacijoms validuoti ir testuoti incidentų valdymo pajėgumus apibrėžiant praneštinus saugumo įvykius, dokumentuojant sprendimų priėmimą ir išsaugant kriminalistinius įrodymus. Komandoms nurodoma:

„Fiksuoti ir registruoti žurnale visus sprendimus, vaidmenis ir komunikaciją (5.26), taip pat atnaujinti planą pagal įgytą patirtį (5.27). Patvirtinti, kad procedūros yra parengtos kriminalistiniams įrodymams (5.28) išsaugoti, įskaitant žurnalų momentines kopijas, atsargines kopijas ir saugų paveiktų sistemų izoliavimą.“

Tas pats žingsnis A.5.28 paaiškina kalba, kurią turi suprasti kiekviena valdyba:

„tai, ką galite įrodyti, yra taip pat svarbu kaip tai, kas iš tikrųjų įvyko“

Clarysec organizacijos Įrodymų rinkimo ir kriminalistikos politika pabrėžia, kad įrodymai turi išlikti atsekami:

„Perdavimo grandinės žurnalas turi lydėti visus fizinius arba skaitmeninius įrodymus nuo įgijimo momento iki archyvavimo ar perdavimo ir turi dokumentuoti:“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.6 punkto.

MVĮ skirta Įrodymų rinkimo ir kriminalistikos politika MVĮ sąmoningai praktinė:

„Visada turi būti sukuriama kriminalistinė kopija arba eksportas; pradinis įrodymas niekada negali būti tiesiogiai redaguojamas.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.1 punkto.

Ji taip pat reikalauja teisinių konsultacijų, kai gali būti poveikis personalui, teisei arba klientams:

„Jei incidentas susijęs su galimu Žmogiškųjų išteklių (HR), teisiniu arba klientų poveikiu, GM prieš pradėdamas politikos taikymą ar eskalavimą turi pasikonsultuoti su teisininku.“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.4.2 punkto.

Praktinis įrodymų paketas turi būti atidarytas 2 vartuose. Sukurkite ribotos prieigos incidento įrodymų aplanką. Eksportuokite SIEM laiko juostas, EDR aptikimus, debesijos audito žurnalus, tapatybės teikėjo prisijungimo žurnalus, atsarginių kopijų užduočių būseną, išpirkos raštelius, ekrano kopijas, užpuoliko žinutes, piniginių adresus, failų pavyzdžius, teisinių konsultacijų nuorodas, susirašinėjimą su draudiku ir posėdžių sprendimus. Paskirkite atsakingą saugotoją. Kai tinkama, užregistruokite maišos reikšmes. Neleiskite administratoriams išvalyti paveiktų sistemų prieš kriminalistinį paėmimą, nebent tai būtina gyvybės saugai, kritinių paslaugų apsaugai arba vadovybės patvirtintam lokalizavimui.

Vienas NIS2, DORA ir GDPR klasifikavimo darbalapis

Išpirkos reikalaujančios programinės įrangos incidentas gali paleisti kelis terminų skaičiavimus. Iššūkis yra ne tik žinoti terminus. Reikia žinoti, kada organizacija sužinojo, ką tuo metu žinojo ir kaip buvo priimti klasifikavimo sprendimai.

NIS2 Article 23 reikalauja, kad esminiai ir svarbūs subjektai be nepagrįsto delsimo praneštų CSIRT arba kompetentingai institucijai apie reikšmingus incidentus. Reikšmingumas siejamas su dideliu veiklos sutrikimu, finansiniais nuostoliais arba reikšminga materialine ar nematerialine žala kitiems. Etapinis modelis apima ankstyvąjį perspėjimą per 24 valandas, pranešimą per 72 valandas, tarpinius atnaujinimus, jei jų prašoma, ir galutinę ataskaitą per vieną mėnesį nuo pranešimo apie incidentą, kai taikoma.

DORA reikalauja, kad finansų subjektai apibrėžtų ir įgyvendintų su IRT susijusių incidentų valdymą, registruotų incidentus ir reikšmingas kibernetines grėsmes, klasifikuotų incidentus pagal tokius kriterijus kaip paveikti klientai, trukmė, geografinis paplitimas, duomenų praradimas, kritiškumas ir ekonominis poveikis, ir apie didelius su IRT susijusius incidentus praneštų kompetentingoms institucijoms pirminėmis, tarpinėmis ir galutinėmis ataskaitomis.

GDPR kelia kitokį, bet persidengiantį klausimą: ar incidentas sukėlė asmens duomenų saugumo pažeidimą? Jei taip, ar tikėtina, kad jis sukels riziką asmenims? Jei pasiektas pranešimo slenkstis, pranešimas priežiūros institucijai turi būti vertinamas pagal 72 valandų terminą. Jei kyla didelė rizika, taip pat gali reikėti informuoti asmenis.

Clarysec rekomenduoja naudoti vieną išpirkos reikalaujančios programinės įrangos klasifikavimo darbalapį su atskirais skyriais kiekvienam režimui.

Šis požiūris atitinka ISO 27001 nuostatas dėl rizikos vertinimo, rizikos tvarkymo ir dokumentuotos informacijos. Jis taip pat suderintas su NIST CSF 2.0. NIST CSF 2.0 GOVERN funkcija tikisi, kad organizacijos supras suinteresuotąsias šalis, teisines ir reglamentavimo prievoles, rizikos apetitą, vaidmenis, politiką, priežiūrą ir trečiųjų šalių riziką. Aptikimo, reagavimo ir atkūrimo rezultatai palaiko incidento paskelbimą, analizę, reagavimo koordinavimą, suinteresuotųjų šalių informavimą, atkūrimo vykdymą ir atkūrimo validavimą.

Finansų subjektams DORA gali veikti kaip sektoriui skirtas kibernetinio saugumo režimas persidengiantiems NIS2 įpareigojimams, tačiau tai nepanaikina poreikio suprasti NIS2 taikomumą grupės subjektams, IRT teikėjams, valdomoms paslaugoms ar debesijos priklausomybėms. Praktinis atsakymas nėra palaikyti atskirus veiksmų planus. Reikia naudoti vieną ISVS įrodymų modelį, susietą su visais aktualiais įpareigojimais.

Kibernetinis draudimas ir tiekėjų koordinavimas yra valdysenos kontrolės priemonės

Kibernetinis draudimas gali būti vertingas, tačiau jis nėra išpirkos reikalaujančios programinės įrangos strategija. Tai rizikos perdavimo mechanizmas su sąlygomis. Išpirkos reikalaujančios programinės įrangos įvykio metu draudikas gali reikalauti nedelsiant pranešti, naudoti patvirtintų įmonių sąrašą, gauti išankstinį derybų patvirtinimą, išsaugoti įrodymus, pateikti atsarginių kopijų nesėkmės įrodymus, pagrįsti tinkamas kontrolės priemones ir atlikti teisinę peržiūrą prieš svarstant bet kokį mokėjimą.

DORA IRT trečiųjų šalių riziką paverčia visaverte atitikties sritimi. NIS2 Article 21 taip pat reikalauja tiekimo grandinės saugumo ir atsižvelgti į tiekėjų pažeidžiamumus bei kibernetinio saugumo praktikas. ISO 27001 palaiko tą pačią logiką per tiekėjų ir debesijos kontrolės priemones, tokias kaip A.5.19–A.5.23, taip pat incidentų, tęstinumo ir teisines kontrolės priemones.

Zenith Controls incidentų pasirengimą sieja su išoriniais partneriais, įskaitant skaitmeninės kriminalistikos įmones, teisės skyrių, viešuosius ryšius ir ryšį su institucijomis. Audito požiūriu iš anksto nenustatytų išorinių partnerių nebuvimas gali būti vertinamas kaip pasirengimo spraga, nes realaus incidento metu tai gali uždelsti reagavimą.

Išpirkos reikalaujančios programinės įrangos mokėjimų valdysenai Clarysec rekomenduoja iš anksto suderinti:

• Skaitmeninės kriminalistikos paslaugų rezervavimo arba greitojo reagavimo sąlygas.
• Išorės teisininkų prieinamumą pažeidimo, sankcijų ir teisinio privilegijuotumo strategijai.
• Kibernetinio draudiko pranešimo kelią ir patvirtintų tiekėjų sąrašą.
• Debesijos paslaugų teikėjo eskalavimo kelią momentinėms kopijoms, žurnalams, izoliavimui ir atkūrimui.
• MSSP arba MDR incidentų bendradarbiavimo procedūras.
• Viešųjų ryšių ir krizių komunikacijos peržiūros procesą.
• Bankininkystės arba finansų patvirtinimo kontrolės priemones bet kokiam neeiliniam mokėjimui.
• Teisėsaugos kontaktų protokolą.

Tai gerai dera su NIST CSF 2.0 tiekimo grandinės rezultatais, įskaitant tiekėjų vaidmenis ir atsakomybes, deramą rūpestingumą, sutartinius kibernetinio saugumo reikalavimus, tiekėjų incidentų koordinavimą ir veiklas po sutarties nutraukimo.

Praktinis išpirkos reikalaujančios programinės įrangos mokėjimo eskalavimo veiksmų planas

Penki vartai gali būti paversti operaciniu veiksmų planu. Kiekvienas žingsnis turi būti dokumentuotas, turėti savininką ir būti repetuojamas.

Tikslas nėra garantuoti patogų sprendimą. Patogaus sprendimo gali nebūti. Tikslas – užtikrinti, kad sprendimas būtų autorizuotas, grindžiamas įrodymais, teisiškai pagrįstas ir apginamas.

90 minučių stalo pratybos, įrodančios pasirengimą

Paprasčiausias būdas patikrinti išpirkos reikalaujančios programinės įrangos mokėjimų valdyseną nėra techninės red team pratybos. Tai sprendimų stalo pratybos.

Naudokite Zenith Blueprint, „Controls in Action“ etapą, 23 žingsnį, kad validuotumėte incidentų valdymo pajėgumą. Pasirinkite išpirkos reikalaujančios programinės įrangos scenarijų ir atlikite laiko ribojamą pratybą. Tikslas nėra iš anksto nuspręsti, kad organizacija mokėtų arba niekada nemokėtų. Tikslas – įrodyti, kad organizacija gali priimti valdysenos kontroliuojamą sprendimą.

Scenarijus: debesijoje veikianti klientų duomenų bazė užšifruota, užpuolikas teigia iškėlęs duomenis, atsarginės kopijos egzistuoja, bet jų vientisumas dar nepatikrintas, draudikas neinformuotas, o užpuolikas pateikia piniginės adresą su 48 valandų terminu.

Pratybų kontrolinis sąrašas:

• Paskelbti incidentą ir paskirti incidento vadovą.
• Atidaryti sprendimų dėl išpirkos reikalaujančios programinės įrangos žurnalą.
• Suklasifikuoti įvykį pagal A.5.25 kriterijus.
• Identifikuoti paveiktą turtą ir verslo paslaugas.
• Nustatyti, ar susiję asmens duomenys.
• Aktyvuoti GDPR, NIS2, DORA ir sutartinio vertinimo darbo eigas.
• Informuoti teisės skyrių, DPO, vadovybę, draudiką ir kriminalistikos paslaugų teikėją.
• Išsaugoti įrodymus prieš destruktyvius atkūrimo veiksmus.
• Patikrinti atsarginių kopijų vientisumą ir atkūrimo parinktis.
• Atlikti sankcijų patikrą prieš bet kokias derybas.
• Užregistruoti, ar reikalinga konsultacija su teisėsauga.
• Parengti preliminarius pareiškimus klientams ir reguliuotojams.
• Pateikti sprendimo parinktis vykdomuosius įgaliojimus turinčiam subjektui.
• Užregistruoti sprendimą, pagrindimą, nesutikimą, patvirtinimus ir kitus veiksmus.
• Suplanuoti peržiūrą po incidento ir kontrolės priemonių tobulinimo veiksmus.

Rezultatas turi būti pilnas įrodymų rinkinys: dalyvių sąrašas, laiko juosta, klasifikavimo darbalapis, sprendimų žurnalas, komunikacijos projektai, teisiniai veiksmai, draudiko veiksmai, atsarginių kopijų išvados ir įgyta patirtis. Toks rinkinys yra audito aukso standartas, nes parodo, kad valdysena veikia dar prieš realią krizę.

Kaip auditoriai ir reguliuotojai tikrins procesą

Skirtingos patirties auditoriai tą patį išpirkos reikalaujančios programinės įrangos procesą vertins per skirtingas prizmes.

Zenith Controls pateikia išsamią A.5.24, A.5.25 ir A.5.31 audito metodiką. A.5.24 atveju auditoriai nagrinėja reagavimo į incidentus planą, sunkumo klasifikacijas, vaidmenis, kontaktų sąrašus, reglamentavimo pranešimų instrukcijas, pratybas ir išorinių partnerių susitarimus. A.5.25 atveju jie tikrina, ar egzistuoja įvykių klasifikavimo kriterijai, ar įspėjimų tvarkymo įrašai rodo tyrimo ir eskalavimo sprendimus, ar naudojama SIEM ir grėsmių žvalgyba, ir ar DPO arba teisės komandos įtraukiamos, kai gali būti paveikti asmens duomenys. A.5.31 atveju auditoriai ieško teisinių reikalavimų registrų, atitikties susiejimo, peržiūros įrodymų, vidaus audito aprėpties ir ataskaitų vyresniajai vadovybei.

Audito rizika yra ne tik tai, kad organizacija sumokėjo arba atsisakė mokėti. Audito rizika yra tai, kad niekas negali įrodyti, kaip sprendimas buvo priimtas.

Nuo šantažo iki kontrolės priemonių tobulinimo

Išpirkos reikalaujančios programinės įrangos valdysena nesibaigia atkūrus sistemas. ISO 27001 reikalauja nuolatinio tobulinimo. A.5.27 mokymasis iš informacijos saugumo incidentų yra šio lūkesčio pagrindas. DORA reikalauja pagrindinės priežasties analizės ir papildomų kontrolės priemonių. NIS2 galutinėse ataskaitose, kai taikoma, tikimasi švelninimo priemonių ir tikėtinos pagrindinės priežasties. GDPR atskaitomybė reikalauja dokumentuoti sprendimus ir apsaugos priemones.

Kiekviena peržiūra po išpirkos reikalaujančios programinės įrangos incidento turi atsakyti:

• Ar pranešimų terminai buvo nustatyti teisingai?
• Ar sprendimų įgaliojimų modelis veikė kaip numatyta?
• Ar teisinė ir sankcijų peržiūra buvo atlikta pakankamai anksti?
• Ar draudiko koordinavimas padėjo ar sulėtino reagavimą?
• Ar atsarginės kopijos buvo pilnos, atskirtos, atkuriamos ir testuotos?
• Ar žurnalų pakako prieigai ir duomenų iškėlimui įvertinti?
• Ar tiekėjai reagavo pagal sutartį?
• Ar klientų komunikacija buvo tiksli ir savalaikė?
• Ar vadovybė gavo tinkamą informaciją tinkamu laiku?
• Kokios kontrolės priemonės, politikos, sutartys ar mokymai turi keistis?

Šie atsakymai turi atnaujinti rizikų registrą, Taikomumo pareiškimą, reagavimo į incidentus planą, atsarginių kopijų strategiją, tiekėjų sutartis, komunikacijos planą ir mokymo programą.

ISVS pagrindų ir lyderystės etape, 5 žingsnyje, Zenith Blueprint pabrėžia išorinės komunikacijos planavimą, įskaitant klientų, reguliuotojų, partnerių ir visuomenės identifikavimą, nustatymą, ką ir kada komunikuoti, ir apibrėžimą, kas komunikuoja. Išpirkos reikalaujančios programinės įrangos atveju šis žingsnis tampa tiltu tarp techninio reagavimo ir pasitikėjimo išsaugojimo.

Sukurkite sprendimo įrašą prieš pasirodant išpirkos rašteliui

Geriausias laikas valdyti sprendimą dėl išpirkos yra prieš užpuolikui nustatant terminą.

Jei jūsų išpirkos reikalaujančios programinės įrangos veiksmų planas neapibrėžia sprendimų įgaliojimų, teisinės peržiūros, sankcijų patikros, draudiko patvirtinimo, įrodymų išsaugojimo, NIS2 ir DORA klasifikavimo, GDPR pažeidimo vertinimo ir valdybos lygmens dokumentavimo, organizacijoje yra valdysenos spraga, laukianti krizės.

Clarysec padeda organizacijoms įdiegti šį pajėgumą į ISVS naudojant:

• Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą, skirtą etapiniam ISO 27001 įgyvendinimui, rizikos tvarkymui, komunikacijos planavimui ir incidentų pajėgumo validavimui.
• Zenith Controls: kryžminės atitikties vadovą, skirtą ISO 27001 kontrolės priemonių susiejimui su NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 ir audito įrodymais.
• Clarysec organizacijų ir MVĮ politikomis, įskaitant Reagavimo į incidentus politiką, Reagavimo į incidentus politiką – MVĮ, Įrodymų rinkimo ir kriminalistikos politiką, Įrodymų rinkimo ir kriminalistikos politiką – MVĮ, Valdysenos vaidmenų ir atsakomybių politiką, Valdysenos vaidmenų ir atsakomybių politiką – MVĮ ir Rizikos valdymo politiką.
• Praktiniais išpirkos reikalaujančios programinės įrangos stalo pratybų šablonais, sprendimų žurnalais, perdavimo teisiniam vertinimui matricomis, įrodymų paketais ir kryžminės atitikties pranešimų darbalapiais.

Nelaukite 3 valandos nakties skambučio, kad sužinotumėte, kas gali priimti sprendimą. Peržiūrėkite savo reagavimo į incidentus planą pagal Clarysec penkis vartus, atlikite 90 minučių išpirkos reikalaujančios programinės įrangos mokėjimo stalo pratybas ir sukurkite sankcijų požiūriu saugų, auditui tinkamą sprendimo įrašą, kuris atlaikytų reguliuotojų, draudikų ir jūsų pačių valdybos patikrą.