Kiristyshaittaohjelmien lunnasmaksujen hallinta NIS2:n ja DORA:n näkökulmasta

On arkiyö vuonna 2026, kello 3.17. Nopeasti kasvavan fintech-alustan tietoturvajohtaja Maria kutsutaan kriisipuheluun SOC-pääanalyytikon viestillä: laajamittainen salaus on vahvistettu, keskeiset palvelut ovat alhaalla ja kiristyshaittaohjelmaryhmä väittää varastaneensa 2 Tt asiakastietoja.

Toimitusjohtaja liittyy puheluun ensimmäisenä. Perässä tulevat lakiasiat, tietosuoja, talous, viestintä, kybervakuutusyhtiö, forensiikkapalveluntarjoaja ja pilvioperaatiotiimi. Pimeän verkon portaalissa näkyy 48 tunnin lähtölaskenta ja seitsemännumeroisen summan vaatimus kryptovaluuttana.

Toimitusjohtaja esittää kysymyksen, jota jokainen tietoturvajohtaja pelkää.

“Voimmeko maksaa, ja kuka saa päättää siitä?”

Väärä vastaus on käsitellä tilannetta neuvotteluongelmana. Oikea vastaus on käsitellä sitä hallintaongelmana.

Vuonna 2026 kiristyshaittaohjelmien lunnasmaksupäätösten hallinta ei ole enää yksityinen, tekninen kriisipäätös. Sitä voivat tarkastella viranomaiset, auditoijat, vakuutusyhtiöt, asiakkaat, lainvalvontaviranomaiset, osakkeenomistajat ja hallitus. Maksupäätös kytkeytyy pakoteriskialtistukseen, henkilötietojen tietoturvaloukkauksen arviointiin, kybervakuutuksen ehtoihin, sopimusvelvoitteisiin, kriisiviestintään, näytön säilyttämiseen, NIS2:n vaiheistettuun raportointiin, DORA:n poikkeamaluokitteluun, GDPR-ilmoituksiin ja poikkeaman jälkeiseen parantamiseen.

Siksi Clarysec suosittelee asiakkaille, että kiristyshaittaohjelmien lunnasmaksupäätösten hallinta rakennetaan ISMS:n sisään ennen poikkeamaa. ISO/IEC 27001:2022 antaa johtamisjärjestelmän rakenteen. ISO/IEC 27002:2022 -hallintakeinot antavat operatiivisen mallin. Zenith Blueprint: auditoijan 30 vaiheen tiekartta ja Zenith Controls: vaatimustenmukaisuuskehysten välinen opas auttavat muuntamaan rakenteen käytännölliseksi ja auditoitavaksi näytöksi.

Kiristyshaittaohjelmien toimintapelikirja, jossa todetaan vain “ilmoita lakiasioille”, ei riitä. Organisaation on tiedettävä, kuka saa valtuuttaa neuvottelut, miten pakoteseulonta tehdään, milloin vakuutusyhtiön hyväksyntä tarvitaan, miten GDPR-, NIS2- ja DORA-luokittelu dokumentoidaan ja miten näyttö suojataan, kun palautustiimit työskentelevät paineen alla.

Miksi ad hoc -päätökset kiristyshaittaohjelmien lunnasmaksuista epäonnistuvat

Kiristyshaittaohjelman lunnasmaksupäätöstä kuvataan usein kaksijakoisena: maksetaan tai ei makseta. Todellisuudessa päätöksessä on vähintään kuusi tasoa:

1. Onko tapahtuma vahvistettu, rajattu ja luokiteltu oikein?
2. Vaikuttaako se henkilötietoihin, sääntelyn alaisiin tietoihin tai kriittisten palvelujen tuottamiseen?
3. Saako organisaatio lain mukaan viestiä tai tehdä transaktion uhkatoimijan kanssa?
4. Edellyttääkö kybervakuutus ennakkoilmoitusta, hyväksyttyjä toimittajia, suostumusta tai tiettyä näyttöä?
5. Vähentäisikö maksu liiketoimintavaikutusta vai lisäisikö se oikeudellista, taloudellista ja maineeseen kohdistuvaa riskiä?
6. Kenellä on toimivalta päättää, ja miten päätös kirjataan?

Käynnissä olevan poikkeaman aikana toisistaan irrallaan toimivat tiimit vetävät usein eri suuntiin. Talousjohtaja voi nähdä lunnaat liiketoimintakuluna suhteessa kasvavaan käyttökatkoon. Lakiasiat näkee pakotteet, talousrikosriskit ja sääntelyaltistuksen. Tietosuojavastaava arvioi, aiheuttavatko salatut tai luvattomasti siirretyt tiedot ilmoitettavan henkilötietojen tietoturvaloukkauksen. Vaatimustenmukaisuustoiminto seuraa NIS2- ja DORA-raportoinnin määräaikoja. Tietoturvajohtaja yrittää säilyttää näytön samalla kun palveluja palautetaan. Toimitusjohtaja haluaa suosituksen ennen hyökkääjän ajastimen umpeutumista.

Ilman muodollista päätösprosessia kokouksen äänekkäimmästä henkilöstä voi tulla hallintamalli. Juuri tämän tilanteen nykyaikainen kyberturvallisuussääntely pyrkii estämään.

NIS2 tekee kyberturvallisuudesta johdon vastuun. 20 artikla käsittelee johtavien elinten hallintaa ja osoitusvelvollisuutta, kun taas 21 artikla edellyttää riskienhallintatoimenpiteitä, jotka kattavat poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, varmuuskopioinnin hallinnan, kriisinhallinnan, toimitusketjun turvallisuuden, pääsynhallinnan, omaisuudenhallinnan, MFA:n ja vaikuttavuuden arvioinnin. 23 artikla luo merkittäville poikkeamille vaiheistetun raportoinnin, mukaan lukien varhaisvaroituksen 24 tunnin kuluessa, ilmoituksen 72 tunnin kuluessa ja soveltuvissa tapauksissa loppuraportin yhden kuukauden kuluessa.

Rahoitusalan toimijoille DORA on toimialakohtainen operatiivisen häiriönsietokyvyn sääntökirja. 5 artikla asettaa ICT-riskien hallinnan vastuun johtavalle elimelle. 17, 18 ja 19 artikla käsittelevät ICT:hen liittyvien poikkeamien hallintaa, merkittävien ICT:hen liittyvien poikkeamien luokittelua ja raportointia. DORA edellyttää myös reagointi- ja palautumiskyvykkyyttä, varmuuskopiointia ja palautusta, poikkeaman jälkeistä oppimista, testausta ja ICT-kolmansien osapuolten riskienhallintaa.

GDPR lisää erillisen mutta osin päällekkäisen arvioinnin. Jos kiristyshaittaohjelma aiheuttaa henkilötietojen vahingossa tapahtuvan tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai niihin pääsyn, rekisterinpitäjän on arvioitava, onko kyseessä henkilötietojen tietoturvaloukkaus. Jos ilmoitus vaaditaan, valvontaviranomaisen 72 tunnin määräaika alkaa yleensä siitä, kun loukkaus on tullut tietoon. Jos henkilöille aiheutuu korkea riski, myös viestintä asianomaisille henkilöille voi olla tarpeen.

Johtopäätös on yksinkertainen: lunnaisiin liittyvää kysymystä ei saa esittää ensimmäistä kertaa kriisihuoneessa.

ISO 27001:2022 -hallintakeinot, jotka ankkuroivat maksujen hallinnan

ISO/IEC 27001:2022 -standardin mukainen ISMS ei ole auditoijien tarkistuslista. Se on johtamisjärjestelmä riskiperusteisten päätösten tekemiseen. Kiristyshaittaohjelmien lunnasmaksujen hallinta kuuluu tähän järjestelmään, koska se yhdistää riskien arvioinnin, riskien käsittelyn, roolit, lakisääteiset velvoitteet, tietoturvapoikkeamiin reagoinnin, jatkuvuuden, toimittajahallinnan ja jatkuvan parantamisen.

Keskeisimmät ISO 27001:2022 liitteen A hallintakeinot muodostavat toisiinsa kytkeytyvän kontrolliketjun.

Zenith Controls -oppaassa A.5.24:ää, tietoturvapoikkeamien hallinnan suunnittelua ja valmistelua, käsittelevä osio luokittelee hallintakeinon korjaavaksi, liittää sen luottamuksellisuuteen, eheyteen ja saatavuuteen sekä kohdistaa sen Respond- ja Recover-käsitteisiin. Se kytkee A.5.24:n myös A.5.25:n tapahtumien arviointiin, A.5.27:n poikkeamista oppimiseen, A.8.15:n lokitukseen, A.8.16:n seurantaan, A.5.29:n tietoturvallisuuteen häiriötilanteessa, jatkuvuuteen ja yhteydenpitoon viranomaisiin.

Tällä on merkitystä, koska kiristyshaittaohjelmien lunnasmaksujen hallinta on ketju. Jos tapahtumaa ei voida havaita ja luokitella, päätöstä ei voida tehdä. Jos näyttöä ei voida säilyttää, päätöstä ei voida puolustaa. Jos lakisääteisiä velvoitteita ei ole kartoitettu, neuvottelu tai maksu voi olla lainvastainen. Jos palautusvaihtoehtoja ei ole testattu, ylin johto voi ajautua tekemään päätöksen pelon eikä tosiseikkojen perusteella.

Zenith Controls kuvaa valmistautumisen ja päätöksenteon suhteen selkeästi:

“5.25 on päätöspiste, jossa määritetään, milloin tapahtuma ylittää kynnyksen ja muuttuu tietoturvapoikkeamaksi, joka käynnistää kohdassa 5.26 kuvatut toimet. Oikea-aikainen ja tarkka tapahtuma-arviointi varmistaa, ettei tietoturvapoikkeamiin reagointi viivästy tai suuntaudu väärin.”

Sama opas kytkee A.5.31:n, lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset, tietosuojaan, tallenteiden säilytykseen, riippumattomaan katselmointiin ja sisäisten politiikkojen noudattamiseen. Kiristyshaittaohjelmien osalta A.5.31 on kohta, jossa pakoteseulonta, vakuutusvelvoitteet, yhteydenpito lainvalvontaviranomaisiin, asiakassopimukset, tietosuojavelvoitteet ja toimialakohtainen sääntelyraportointi kootaan yhteen vaatimustenmukaisuusrekisteriin.

Clarysecin viiden portin malli kiristyshaittaohjelmien lunnasmaksujen hallintaan

Clarysecin malli jakaa kiristyshaittaohjelmien lunnasmaksupäätösten hallinnan viiteen porttiin. Tarkoitus ei ole helpottaa maksamista. Tarkoitus on varmistaa, että mikä tahansa päätös, myös maksamisesta kieltäytyminen, perustuu näyttöön, on oikeudellisesti arvioitu, valtuutettu ja auditoitavissa.

Tämä malli käyttää ISO 27001:n riskien käsittelyn logiikkaa. Kiristyshaittaohjelman lunnasmaksu ei ole tietoturvakontrolli. Se on enintään kriisivaihtoehto, jota tarkastellaan riskien käsittelyn ja palautumisen kontekstissa. Ennen poikkeamaa organisaation olisi jo pitänyt päättää, miten kiristyshaittaohjelmariskejä käsitellään: lievennetään hallintakeinoilla, siirretään osa taloudellisesta riskialtistuksesta vakuutuksella, vältetään hyväksymättömiä legacy-riippuvuuksia tai hyväksytään jäännösriski nimenomaisesti silloin, kun se on perusteltua.

Riskienhallintavaiheessa, vaiheessa 13, riskienkäsittelysuunnittelu ja soveltuvuuslausunto, Zenith Blueprint ohjeistaa organisaatioita määrittämään kullekin riskille käsittelyvaihtoehdot ja dokumentoimaan ne riskirekisteriin. Se huomauttaa, että riskin siirto, kuten kybervakuutus, ei poista hallintakeinojen tarvetta, koska siirto kattaa usein taloudellisen vaikutuksen eikä todennäköisyyttä. Siinä todetaan myös:

“Hyväksynnän on oltava nimenomainen ja johdon hyväksymä, erityisesti kaikkien keskitasoisten riskien osalta. Korkeita riskejä hyväksytään harvoin, elleivät ne ole aidosti väistämättömiä ja ylimmän tason hyväksymiä.”

Tämä kohta on suoraan merkityksellinen kiristyshaittaohjelmien lunnasmaksujen hallinnalle. Jos hallitusta pyydetään hyväksymään jäännösriski maksusta kieltäytymisestä tai oikeudellinen ja maineeseen kohdistuva riski neuvottelujen hyväksymisestä, hyväksynnän on oltava nimenomainen, kirjattu ja oikean toimivaltatason hyväksymä.

Clarysecin Riskienhallintapolitiikka vahvistaa saman periaatteen:

“Riskienkäsittelypäätösten tulee olla yhdenmukaisia ennalta määritettyjen vaihtoehtojen kanssa”
Lausekkeesta 5.5.

Lunnaspäätös ei siis ole oikotie riskienhallinnan ohi. Se on käsiteltävä muodollisena, dokumentoituna riskienkäsittelypäätöksenä määritetyn toimivallan puitteissa.

Politiikan mukainen toimivalta: kuka saa päättää paineen alla?

Monet kiristyshaittaohjelmatilanteiden epäonnistumiset ovat hallintapuutteita, jotka näyttävät teknisiltä epäonnistumisilta. Joku ottaa yhteyttä hyökkääjään hyväksytyn kanavan ulkopuolella. Joku lupaa maksun ennen vakuutusyhtiön hyväksyntää. Joku palauttaa järjestelmiä ja ylikirjoittaa forensista todistusaineistoa. Joku kertoo asiakkaille liian aikaisin, liian myöhään tai virheellisin tiedoin.

Clarysecin politiikat on suunniteltu poistamaan tämä epäselvyys.

Pk-yrityksille Hallinnointirooleja ja vastuita koskeva politiikka - pk-yritys antaa yksinkertaisen säännön:

“Kaikki merkittävät tietoturvapäätökset, poikkeukset ja eskaloinnit on kirjattava ja niiden on oltava jäljitettävissä.”
Osion “Hallinnointivaatimukset” politiikkalausekkeesta 5.5.

Pk-yritysten Tietoturvapoikkeamiin reagoinnin politiikka - pk-yritys määrittää eskalointivallan:

“Toimitusjohtaja (GM) vastaa kaikkien poikkeamien eskalointipäätösten, sääntelyilmoitusten ja ulkoisen viestinnän valtuuttamisesta.”
Osion “Hallinnointivaatimukset” politiikkalausekkeesta 5.1.1.

Se kytkee myös asiakastietoja koskevat poikkeamat sääntelyvelvoitteisiin:

“Kun asiakastietoja on mukana, toimitusjohtajan on arvioitava lakisääteiset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n soveltuvuuden perusteella.”
Osion “Riskienkäsittely ja poikkeukset” politiikkalausekkeesta 7.4.1.

Suuremmille organisaatioille yritystason Hallinnointirooleja ja vastuita koskeva politiikka edellyttää välitöntä eskalointia, kun oikeudellista altistusta tai ilmoitettavia tietomurtoja voi olla olemassa:

“Laki- ja sääntelyasioiden eskalointi: Poikkeamat, joihin liittyy mahdollinen oikeudellinen altistus tai ilmoitettava tietomurto, on eskaloitava välittömästi laki- ja vaatimustenmukaisuusvastaavalle ja ylimmälle johdolle.”
Osion “Politiikan toteutusvaatimukset” politiikkalausekkeesta 6.4.3.

Yritystason Tietoturvapoikkeamien hallintapolitiikka määrittää ylimmän johdon toimivallan vakavissa poikkeamissa. Lausekkeessa 4.6.1 todetaan, että ylimmän johtoryhmän tehtävä on:

“Tehdä strategisia päätöksiä erittäin vakavien poikkeamien aikana, mukaan lukien ilmoitusten ja julkisen viestinnän hyväksyminen.”

Kiristyshaittaohjelmien yhteydessä Clarysec käsittelee maksukeskustelua, neuvottelujen valtuuttamista, asiakasilmoitusta, viranomaislausuntoa ja julkista viestintää strategisina päätöksinä, ei teknisinä toimina.

Tästä seuraa käytännön hallintasääntö: CISO voi suositella, poikkeamatiimi voi arvioida, lakiasiat voi neuvoa, talous voi validoida maksutekniikan, vakuutusyhtiö voi antaa suostumuksen tai evätä korvattavuuden, mutta ylimmän johdon tai hallituksen on omistettava päätös ennalta määritetyn toimivallan mukaisesti.

Pakoteriskin huomioiva eskalointi ennen neuvotteluja

Pakoteriskin huomioiva kiristyshaittaohjelmaprosessi alkaa kiellosta: yksikään työntekijä, sopimuskumppani, toimittaja, välittäjä, neuvottelija tai poikkeamiin reagoiva henkilö ei saa neuvotella, luvata, edistää tai siirtää arvoa uhkatoimijalle ilman hyväksyttyä oikeudellista arviointia.

Oikeudellinen tarkistuspiste on tehtävä ennen aktiivista yhteydenpitoa hyökkääjään, ei vasta sen jälkeen, kun lompakko-osoite ilmestyy. Prosessin tulee sisältää:

• Oikeudellinen neuvonantaja otetaan mukaan ennen kaikkea muuta viestintää kuin passiivista näytön talteenottoa.
• Uhkatoimijan tunnistaminen tehdään forensiikan, tiedustelun ja lainvalvontaviranomaisten tietojen perusteella, jos niitä on saatavilla.
• Ryhmänimet, aliakset, lompakko-osoitteet, infrastruktuuri, välittäjät ja maksukanavat tarkistetaan pakote- ja rajoitettujen osapuolten listoista.
• Lainvalvontaviranomaisten konsultointia harkitaan ja se kirjataan.
• Kybervakuutusyhtiölle ilmoitetaan vakuutusehtojen mukaisesti ennen toimittajien nimeämistä tai neuvotteluihin ryhtymistä.
• DPO tai tietosuojavastaava otetaan mukaan, jos henkilötietoja voi olla mukana.
• CFO tai talousvastaava vahvistaa maksukontrollit, tehtävien eriyttämisen, petostentorjuntatarkastukset ja hallituksen hyväksyntävaatimukset.
• Ylimmän johdon päätös kirjataan, ja siinä huomioidaan harkitut vaihtoehdot, kuten palautus, rajaaminen, palvelun keskeyttäminen, asiakasviestintä ja maksusta kieltäytyminen.
• Hyökkääjän viestinnästä, indikaattoreista, lompakkotiedoista, päätöskokouksista, hyväksynnöistä ja ulkoisista neuvoista säilytetään näyttö.

Kiristyshaittaohjelmien osalta lakirekisterin tulee sisältää vähintään seuraavat velvoitelähteet.

Organisaatioiden tulee myös määrittää, kuka voi pysäyttää maksupäätöksen. Lakiasioilla, vaatimustenmukaisuustoiminnolla, DPO:lla, pakotejuristilla tai hallituksella tulee olla nimenomainen toimivalta keskeyttää neuvottelu tai maksu, jos seulonta on kesken, näyttö on epäluotettavaa, vakuutusyhtiön ehdot eivät täyty tai toimi voi rikkoa lakia tai sopimusta.

Näytön säilyttäminen: älä hävitä todistetta palvelun palautuksen aikana

Kiristyshaittaohjelmatiimit pyrkivät luonnostaan palauttamaan toiminnan nopeasti. Jos palautus kuitenkin tuhoaa lokit, tilannevedokset, lunnasviestit, haittaohjelmanäytteet, muistivedokset tai hyökkääjän viestit, organisaatio voi menettää kykynsä todentaa, mitä tapahtui.

Controls in Action -vaiheessa, vaiheessa 23, organisatoriset kontrollit, Zenith Blueprint ohjeistaa organisaatioita validoimaan ja testaamaan poikkeamien hallintakyvykkyyttä määrittämällä ilmoitettavat tietoturvatapahtumat, dokumentoimalla päätöksenteon ja säilyttämällä forensisen todistusaineiston. Se ohjeistaa tiimejä:

“Tallenna ja kirjaa lokiin kaikki päätökset, roolit ja viestintä (5.26) ja päivitä suunnitelma opittujen asioiden perusteella (5.27). Varmista, että menettelyt forensisen todistusaineiston säilyttämiseksi (5.28) ovat käytössä, mukaan lukien lokien tilannevedokset, varmuuskopiot ja vaikutuksen alaisten järjestelmien turvallinen eristäminen.”

Sama vaihe selittää A.5.28:n kielellä, jonka jokainen hallitus ymmärtää:

“sillä, mitä voit todistaa, on yhtä suuri merkitys kuin sillä, mitä todellisuudessa tapahtui”

Clarysecin yritystason Todisteiden keräämisen ja forensiikan politiikka vahvistaa, että näytön on pysyttävä jäljitettävissä:

“Hallussapitoketjulokin tulee seurata kaikkea fyysistä tai digitaalista todistusaineistoa hankintahetkestä arkistointiin tai siirtoon asti, ja sen tulee dokumentoida:”
Osion “Hallinnointivaatimukset” politiikkalausekkeesta 5.6.

Pk-yrityksille Todisteiden keräämisen ja forensiikan politiikka - pk-yritys on tarkoituksella käytännöllinen:

“Forensinen kopio tai vienti on aina luotava; alkuperäistä todistusaineistoa ei saa koskaan muokata suoraan.”
Osion “Politiikan toteutusvaatimukset” politiikkalausekkeesta 6.1.1.

Se edellyttää myös oikeudellista konsultointia, jos tilanteella voi olla HR-, oikeudellisia tai asiakasvaikutuksia:

“Jos poikkeamaan liittyy mahdollinen henkilöstöhallinnon (HR), oikeudellinen tai asiakasvaikutus, GM:n on konsultoitava oikeudellista neuvonantajaa ennen soveltamisen tai eskaloinnin jatkamista.”
Osion “Hallinnointivaatimukset” politiikkalausekkeesta 5.4.2.

Käytännön näyttöpaketti tulee avata portin 2 aikana. Luo rajoitettu poikkeaman todistusaineistokansio. Vie SIEM-aikajanat, EDR-havainnot, pilvipalvelujen auditointilokit, identiteetintarjoajan kirjautumislokit, varmuuskopiointiajojen tila, lunnasviestit, kuvakaappaukset, hyökkääjän viestit, lompakko-osoitteet, tiedostonäytteet, viittaukset oikeudelliseen neuvontaan, vakuutusyhtiön kirjeenvaihto ja kokouspäätökset. Nimeä vastuuhenkilö. Kirjaa tiivistearvot soveltuvin osin. Älä anna järjestelmänvalvojien siivota vaikutuksen alaisia järjestelmiä ennen forensista hankintaa, elleivät henkeen ja turvallisuuteen liittyvät syyt, kriittisen palvelun suojaaminen tai ylimmän johdon hyväksymä rajaaminen sitä edellytä.

Yksi luokittelulomake NIS2:lle, DORA:lle ja GDPR:lle

Kiristyshaittaohjelmapoikkeama voi käynnistää useita määräaikoja. Haaste ei ole vain määräaikojen tunteminen. Haaste on tietää, milloin organisaatio tuli tietoiseksi tilanteesta, mitä se silloin tiesi ja miten luokittelupäätökset tehtiin.

NIS2:n 23 artikla edellyttää, että keskeiset ja tärkeät toimijat ilmoittavat CSIRTille tai toimivaltaiselle viranomaiselle merkittävistä poikkeamista ilman aiheetonta viivytystä. Merkittävyys liittyy vakavaan toiminnalliseen häiriöön, taloudelliseen tappioon tai muille aiheutuvaan huomattavaan aineelliseen tai aineettomaan vahinkoon. Vaiheistettu malli sisältää varhaisvaroituksen 24 tunnin kuluessa, ilmoituksen 72 tunnin kuluessa, välipäivitykset pyydettäessä ja soveltuvissa tapauksissa loppuraportin yhden kuukauden kuluessa poikkeamailmoituksesta.

DORA edellyttää, että rahoitusalan toimijat määrittävät ja toteuttavat ICT:hen liittyvien poikkeamien hallinnan, kirjaavat poikkeamat ja merkittävät kyberuhat, luokittelevat poikkeamat käyttämällä kriteerejä, kuten vaikutuksen alaiset asiakkaat, kesto, maantieteellinen laajuus, tietojen menetys, kriittisyys ja taloudellinen vaikutus, sekä raportoivat merkittävät ICT:hen liittyvät poikkeamat toimivaltaisille viranomaisille alku-, väli- ja loppuraporttien kautta.

GDPR kysyy eri mutta päällekkäisen kysymyksen: aiheuttiko poikkeama henkilötietojen tietoturvaloukkauksen? Jos aiheutti, johtaako se todennäköisesti riskiin henkilöille? Jos ilmoituskynnys täyttyy, ilmoitus valvontaviranomaiselle on arvioitava 72 tunnin määräajan perusteella. Jos korkea riski on olemassa, viestintä henkilöille voi myös olla tarpeen.

Clarysec suosittelee käyttämään yhtä kiristyshaittaohjelmien luokittelulomaketta, jossa on erilliset osiot kullekin sääntelykehikolle.

Tämä lähestymistapa sopii ISO 27001:n riskien arviointia, riskien käsittelyä ja dokumentoitua tietoa koskeviin lausekkeisiin. Se on myös yhdenmukainen NIST CSF 2.0:n kanssa. NIST CSF 2.0:n GOVERN-toiminto edellyttää, että organisaatiot ymmärtävät sidosryhmät, lakisääteiset ja sääntelyvelvoitteet, riskinottohalukkuuden, roolit, politiikan, valvonnan ja kolmannen osapuolen riskin. Sen havaitsemisen, reagoinnin ja palautumisen tulokset tukevat poikkeaman julistamista, analysointia, reagoinnin koordinointia, sidosryhmille ilmoittamista, palautuksen toteutusta ja palautuksen validointia.

Rahoitusalan toimijoille DORA voi toimia toimialakohtaisena kyberturvallisuusjärjestelmänä päällekkäisille NIS2-velvoitteille, mutta se ei poista tarvetta ymmärtää NIS2:n soveltuvuutta konserniyhtiöihin, ICT-palveluntarjoajiin, hallinnoituihin palveluihin tai pilviriippuvuuksiin. Käytännön vastaus ei ole ylläpitää erillisiä toimintapelikirjoja. Vastaus on käyttää yhtä ISMS-näyttömallia, joka on kartoitettu kaikkiin olennaisiin velvoitteisiin.

Kybervakuutus ja toimittajakoordinointi ovat hallintakontrolleja

Kybervakuutus voi olla arvokas, mutta se ei ole kiristyshaittaohjelmastrategia. Se on ehdollinen riskinsiirtomekanismi. Kiristyshaittaohjelmatilanteessa vakuutusyhtiö voi edellyttää välitöntä ilmoitusta, paneeliyritysten käyttöä, ennakkohyväksyntää neuvotteluille, näytön säilyttämistä, todistusta varmuuskopioinnin epäonnistumisesta, näyttöä kohtuullisista hallintakeinoista ja oikeudellista arviointia ennen minkään maksun harkintaa.

DORA tekee ICT-kolmansien osapuolten riskistä keskeisen vaatimustenmukaisuuden osa-alueen. NIS2:n 21 artikla edellyttää myös toimitusketjun turvallisuutta sekä toimittajien haavoittuvuuksien ja kyberturvallisuuskäytäntöjen huomioimista. ISO 27001 tukee samaa logiikkaa toimittaja- ja pilvikontrolleilla, kuten A.5.19–A.5.23, sekä poikkeama-, jatkuvuus- ja lakisääteisillä hallintakeinoilla.

Zenith Controls kytkee poikkeamiin valmistautumisen ulkoisiin kumppaneihin, kuten forensiikkayrityksiin, lakiasioihin, PR:ään ja yhteydenpitoon viranomaisiin. Auditoinnin näkökulmasta ennalta tunnistettujen ulkoisten kumppaneiden puuttuminen voidaan nähdä valmiuspuutteena, koska se voi viivästyttää reagointia todellisen poikkeaman aikana.

Kiristyshaittaohjelmien lunnasmaksujen hallintaa varten Clarysec suosittelee sopimaan ennalta:

• Forensiikan retainer-sopimus tai nopean reagoinnin ehdot.
• Ulkopuolisen oikeudellisen neuvonantajan saatavuus tietoturvaloukkaus-, pakote- ja privilege-strategiaa varten.
• Kybervakuutusyhtiön ilmoituspolku ja hyväksyttyjen toimittajien luettelo.
• Pilvipalveluntarjoajan eskalointireitti tilannevedoksia, lokeja, eristämistä ja palautusta varten.
• MSSP- tai MDR-poikkeamayhteistyön menettelyt.
• PR- ja kriisiviestinnän katselmointiprosessi.
• Pankki- tai taloushyväksyntäkontrollit poikkeuksellista maksua varten.
• Lainvalvontaviranomaisten yhteysprotokolla.

Tämä sopii hyvin NIST CSF 2.0:n toimitusketjutuloksiin, mukaan lukien toimittajien roolit ja vastuut, huolellisuus, sopimusperusteiset kyberturvallisuusvaatimukset, toimittajapoikkeamien koordinointi ja sopimuksen päättymisen jälkeiset toimet.

Käytännön toimintapelikirja kiristyshaittaohjelmien lunnasmaksujen eskalointiin

Viisi porttia voidaan muuntaa operatiiviseksi toimintapelikirjaksi. Jokainen vaihe tulee dokumentoida, omistaa ja harjoitella.

Tavoitteena ei ole taata miellyttävää päätöstä. Miellyttävää päätöstä ei välttämättä ole. Tavoitteena on varmistaa, että päätös on valtuutettu, näyttöön perustuva, oikeudellisesti informoitu ja puolustettavissa.

90 minuutin pöytäharjoitus, joka todentaa valmiuden

Yksinkertaisin tapa testata kiristyshaittaohjelmien lunnasmaksujen hallintaa ei ole tekninen red team -harjoitus. Se on päätöksenteon pöytäharjoitus.

Käytä Zenith Blueprint -opasta, Controls in Action -vaiheen vaihetta 23, poikkeamien hallintakyvykkyyden validoimiseen. Valitse kiristyshaittaohjelmaskenaario ja toteuta ajastettu harjoitus. Tavoitteena ei ole päättää etukäteen, maksaisiko organisaatio vai ei koskaan maksaisi. Tavoitteena on osoittaa, että organisaatio pystyy tekemään hallitun päätöksen.

Skenaario: pilvipalvelussa ylläpidetty asiakastietokanta on salattu, hyökkääjä väittää siirtäneensä tietoja luvattomasti, varmuuskopioita on olemassa mutta niiden eheyttä ei ole vielä testattu, vakuutusyhtiölle ei ole ilmoitettu ja hyökkääjä antaa lompakko-osoitteen 48 tunnin määräajalla.

Harjoituksen tarkistuslista:

• Julista poikkeama ja nimeä poikkeaman johtaja.
• Avaa kiristyshaittaohjelmapäätöksen loki.
• Luokittele tapahtuma A.5.25-kriteerien perusteella.
• Tunnista vaikutuksen alaiset omaisuuserät ja liiketoimintapalvelut.
• Selvitä, liittyykö tilanteeseen henkilötietoja.
• Käynnistä GDPR-, NIS2-, DORA- ja sopimusperusteiset arviointityönkulut.
• Ilmoita lakiasioille, DPO:lle, ylimmälle johdolle, vakuutusyhtiölle ja forensiikkapalveluntarjoajalle.
• Säilytä näyttö ennen tuhoavia palautustoimia.
• Tarkista varmuuskopioiden eheys ja palautusvaihtoehdot.
• Tee pakoteseulonta ennen neuvotteluja.
• Kirjaa, tarvitaanko lainvalvontaviranomaisten konsultointia.
• Laadi asiakkaille ja viranomaisille alustavat holding-lausumat.
• Esitä päätösvaihtoehdot ylimmälle toimivaltaiselle taholle.
• Kirjaa päätös, perustelut, eriävät näkemykset, hyväksynnät ja seuraavat toimet.
• Aikatauluta poikkeaman jälkiarviointi ja kontrollien parantamistoimet.

Tuloksena tulee olla täydellinen näyttöpaketti: osallistujaluettelo, aikajana, luokittelulomake, päätösloki, viestintäluonnokset, oikeudelliset toimenpiteet, vakuutusyhtiöön liittyvät toimenpiteet, varmuuskopiointihavainnot ja opit. Tämä paketti on auditoinnin kannalta erittäin arvokas, koska se osoittaa hallinnan toimivan ennen todellista kriisiä.

Miten auditoijat ja viranomaiset testaavat prosessin

Eri taustoista tulevat auditoijat tarkastelevat samaa kiristyshaittaohjelmaprosessia eri näkökulmista.

Zenith Controls tarjoaa yksityiskohtaisen auditointimenetelmän A.5.24:lle, A.5.25:lle ja A.5.31:lle. A.5.24:n osalta auditoijat tarkastelevat tietoturvapoikkeamiin reagointisuunnitelmaa, vakavuusluokituksia, rooleja, yhteystietoluetteloita, sääntelyraportointiohjeita, harjoituksia ja ulkoisten kumppanien järjestelyjä. A.5.25:n osalta he arvioivat, ovatko tapahtumien luokittelukriteerit olemassa, osoittavatko hälytysten käsittelytallenteet tutkinta- ja eskalointipäätökset, käytetäänkö SIEMiä ja uhkatiedustelua sekä ovatko DPO tai lakitiimit mukana, kun henkilötietoja voi olla vaikutuksen alaisena. A.5.31:n osalta auditoijat etsivät lakirekistereitä, vaatimustenmukaisuuskartoitusta, näyttöä katselmoinnista, sisäisen tarkastuksen kattavuutta ja ylimmälle johdolle tehtävää raportointia.

Auditointiriski ei ole vain se, maksoiko organisaatio vai kieltäytyikö se maksamasta. Auditointiriski on se, ettei kukaan pysty todistamaan, miten päätös tehtiin.

Kiristyksestä kontrollien parantamiseen

Kiristyshaittaohjelmien hallinta ei pääty, kun järjestelmät on palautettu. ISO 27001 edellyttää jatkuvaa parantamista. A.5.27, oppiminen tietoturvapoikkeamista, on tämän odotuksen ytimessä. DORA edellyttää juurisyyanalyysiä ja lisähallintakeinoja. NIS2:n loppuraportointi odottaa lieventämistoimenpiteitä ja soveltuvissa tapauksissa todennäköistä juurisyytä. GDPR:n osoitusvelvollisuus edellyttää päätösten ja suojatoimien dokumentointia.

Jokaisen kiristyshaittaohjelmapoikkeaman jälkiarvioinnin tulee vastata seuraaviin kysymyksiin:

• Tunnistettiinko raportointimääräajat oikein?
• Toimiko päätöksentekovaltuus suunnitellusti?
• Tehtiinkö oikeudellinen ja pakotearviointi riittävän aikaisin?
• Auttoiko vakuutusyhtiön koordinointi vai viivästyttikö se reagointia?
• Olivatko varmuuskopiot täydellisiä, eriytettyjä, palautettavissa ja testattuja?
• Riittivätkö lokit pääsyn ja tietojen luvattoman siirron arviointiin?
• Reagoivatko toimittajat sopimuksen mukaisesti?
• Oliko asiakasviestintä täsmällistä ja oikea-aikaista?
• Saiko ylin johto oikeat tiedot oikeaan aikaan?
• Mitä hallintakeinoja, politiikkoja, sopimuksia tai koulutusta on muutettava?

Näiden vastausten tulee päivittää riskirekisteri, soveltuvuuslausunto, tietoturvapoikkeamiin reagointisuunnitelma, varmuuskopiointistrategia, toimittajasopimukset, viestintäsuunnitelma ja koulutusohjelma.

ISMS Foundation and Leadership -vaiheessa, vaiheessa 5, Zenith Blueprint korostaa ulkoisen viestinnän suunnittelua, mukaan lukien asiakkaiden, viranomaisten, kumppanien ja yleisön tunnistaminen, sen määrittäminen, mitä ja milloin viestitään, sekä viestijöiden määrittäminen. Kiristyshaittaohjelmien osalta tästä vaiheesta tulee silta teknisen reagoinnin ja luottamuksen säilyttämisen välillä.

Rakenna päätöstallenne ennen lunnasviestiä

Paras aika hallita lunnaspäätöstä on ennen kuin hyökkääjä asettaa määräajan.

Jos kiristyshaittaohjelmien toimintapelikirja ei määritä päätösvaltaa, oikeudellista arviointia, pakoteseulontaa, vakuutusyhtiön hyväksyntää, näytön säilyttämistä, NIS2- ja DORA-luokittelua, GDPR-loukkausarviointia ja hallitustason dokumentointia, organisaatiolla on hallinta-aukko, joka odottaa kriisiä.

Clarysec auttaa organisaatioita rakentamaan tämän kyvykkyyden ISMS:ään käyttämällä:

• Zenith Blueprint: auditoijan 30 vaiheen tiekartta vaiheittaiseen ISO 27001 -toteutukseen, riskien käsittelyyn, viestintäsuunnitteluun ja poikkeamakyvykkyyden validointiin.
• Zenith Controls: vaatimustenmukaisuuskehysten välinen opas ISO 27001 -hallintakeinojen kartoittamiseen NIS2:een, DORA:an, GDPR:ään, NIST CSF:ään, COBIT 2019:ään, ISO/IEC 27035:een, ISO/IEC 27701:een, ISO/IEC 27005:een ja auditointinäyttöön.
• Clarysecin yritys- ja pk-yrityspolitiikat, mukaan lukien Tietoturvapoikkeamien hallintapolitiikka, Tietoturvapoikkeamien hallintapolitiikka - pk-yritys, Todisteiden keräämisen ja forensiikan politiikka, Todisteiden keräämisen ja forensiikan politiikka - pk-yritys, Hallinnointirooleja ja vastuita koskeva politiikka, Hallinnointirooleja ja vastuita koskeva politiikka - pk-yritys ja Riskienhallintapolitiikka.
• Käytännön kiristyshaittaohjelmien pöytäharjoituspohjat, päätöslokit, laki- ja sääntelyasioiden eskalointimatriisit, näyttöpaketit ja vaatimustenmukaisuuskehysten väliset raportointilomakkeet.

Älä odota kello 3:n puhelua selvittääksesi, kuka saa päättää. Katselmoi tietoturvapoikkeamiin reagointisuunnitelmasi Clarysecin viittä porttia vasten, toteuta 90 minuutin kiristyshaittaohjelmien lunnasmaksua koskeva pöytäharjoitus ja rakenna pakoteriskin huomioiva, auditointia varten valmis päätöstallenne, joka kestää viranomaisten, vakuutusyhtiöiden ja oman hallituksesi tarkastelun.