DORA TLPT -näyttö ISO 27001 -kontrollien avulla

On maanantaiaamu kello 07.40, ja keskisuuren maksulaitoksen tietoturvajohtaja katsoo kolmea versiota samasta epämukavasta kysymyksestä.

Hallitus haluaa tietää, selviääkö organisaatio kiristyshaittaohjelman aiheuttamasta asiakasmaksuportaalin käyttökatkosta. Valvontaviranomainen haluaa näyttöä siitä, ettei digitaalisen operatiivisen häiriönsietokyvyn testaus ole PowerPoint-harjoitus. Sisäinen auditointi haluaa selkeän jäljen DORA-velvoitteista ICT-riskiin, ISO 27001 -kontrolleihin, testituloksiin, korjaussuunnitelmiin, toimittajanäyttöön ja johdon hyväksyntään.

Tietoturvajohtajalla on red team -raportti. SOC:lla on kuvakaappauksia hälytyksistä. Infrastruktuuritiimillä on varmuuskopion palautusloki. Lakiasioilla on DORA-valmiuden seurantataulukko. Hankinnalla on pilvipalveluntarjoajien vaatimustenmukaisuusvakuutuksia.

Mikään näistä ei ole kytketty toisiinsa.

Tässä kohtaa monet DORA TLPT - ja häiriönsietokyvyn testausohjelmat epäonnistuvat. Ei siksi, että testaus olisi heikkoa, vaan siksi, että näyttö on hajallaan. Kun auditoija kysyy: “Näytä, miten tämä testi osoittaa kriittisen tai tärkeän toiminnon häiriönsietokyvyn”, vastaus ei voi olla kuvakaappauksia täynnä oleva kansio. Sen on oltava puolustettava näyttöketju.

Tässä ketjussa ISO/IEC 27001:2022 -standardin mukainen ISMS ISO/IEC 27001:2022 on tehokas. ISO 27001 antaa rakenteen soveltamisalalle, riskien arvioinnille, kontrollien valinnalle, soveltuvuuslausunnolle, operatiiviselle ohjaukselle, sisäiselle auditoinnille, johdon katselmukselle ja jatkuvalle parantamiselle. DORA tuo sektorikohtaisen sääntelypaineen. Clarysecin menetelmä ja eri sääntelykehysten välinen työkalutuki yhdistävät nämä yhdeksi auditointivalmiiksi näyttömalliksi.

DORA TLPT on hallinnointitesti, ei pelkkä hyökkäyssimulaatio

Uhkaperusteinen penetraatiotestaus eli TLPT on helppo ymmärtää väärin. Teknisesti se voi näyttää kehittyneeltä red team -harjoitukselta: uhkatiedustelua, realistisia hyökkäyspolkuja, huomaamatonta etenemistä, hyväksikäyttöyrityksiä, lateraalisen liikkumisen skenaarioita ja blue team -reagoinnin validointia.

DORA:n näkökulmasta syvempi kysymys on digitaalinen operatiivinen häiriönsietokyky. Pystyykö finanssialan toimija kestämään vakavan ICT-häiriön, reagoimaan siihen ja palautumaan siitä, kun häiriö vaikuttaa liiketoimintaprosesseihin? Voiko se osoittaa, että kriittiset tai tärkeät toiminnot pysyvät vaikutusten sietorajojen sisällä? Voiko johto osoittaa, että ICT-riskiä hallinnoidaan, resursoidaan, testataan, korjataan ja parannetaan?

DORA Article 1 luo yhdenmukaisen EU-kehyksen finanssialan toimijoiden liiketoimintaprosesseja tukevien verkko- ja tietojärjestelmien turvallisuudelle. Se kattaa ICT-riskien hallinnan, merkittävien ICT-poikkeamien raportoinnin, digitaalisen operatiivisen häiriönsietokyvyn testauksen, ICT-kolmansien osapuolten riskienhallinnan, ICT-toimittajasopimusten pakolliset vaatimukset, kriittisten ICT-kolmansien osapuolten palveluntarjoajien valvonnan sekä valvontaviranomaisten yhteistyön. DORA:a sovelletaan 17. tammikuuta 2025 alkaen.

Organisaatioille, joihin sovelletaan myös NIS2:ta, DORA toimii päällekkäisten kyberturvallisuusvaatimusten osalta sektorikohtaisena unionin säädöksenä. Käytännössä finanssialan toimijoiden on priorisoitava DORA:a ICT-riskien hallinnassa, poikkeamien raportoinnissa, testauksessa ja ICT-kolmansien osapuolten riskeissä silloin, kun sääntelykehykset ovat päällekkäisiä. Samalla niiden on ymmärrettävä NIS2:n odotukset konsernirakenteista, toimittajista ja finanssialan ulkopuolisista digitaalisista palveluista.

DORA asettaa vastuun myös ylimmälle tasolle. Article 5 edellyttää, että hallintoelin määrittelee, hyväksyy ja valvoo ICT-riskienhallintajärjestelyjä sekä vastaa niiden toteuttamisesta. Tämä sisältää digitaalisen operatiivisen häiriönsietokyvyn strategian, ICT-liiketoiminnan jatkuvuuspolitiikan, reagointi- ja palautumissuunnitelmat, auditointisuunnitelmat, budjetit, ICT-kolmansia osapuolia koskevat periaatteet, raportointikanavat sekä riittävän ICT-riskiosaamisen säännöllisen koulutuksen avulla.

Auditointikysymys ei siis ole vain: “Toteutitteko TLPT:n?”

Se on:

• Oliko TLPT kytketty kriittisiin tai tärkeisiin toimintoihin?
• Oliko se valtuutettu, rajattu, turvallinen ja riskinarvioitu?
• Sisällytettiinkö toimittajat, pilviriippuvuudet ja ulkoistetut ICT-palvelut mukaan silloin, kun se oli olennaista?
• Tuottiko testi näyttöä havaitsemisesta, reagoinnista, palautumisesta ja opituista asioista?
• Muunnettiinko havainnot riskien käsittelyksi, seurattaviksi korjauksiksi, uusintatestaukseksi ja johdon raportoinniksi?
• Selittikö soveltuvuuslausunto, mitkä ISO 27001:n liitteen A kontrollit valittiin riskin hallintaan?

Siksi Clarysec käsittelee DORA TLPT -näyttöä ISMS-näyttöongelmana, ei pelkästään penetraatiotestauksen toimituksena.

Rakenna ISO 27001 -näytön runko ennen testin käynnistämistä

ISO 27001 edellyttää, että organisaatio perustaa, toteuttaa, ylläpitää ja jatkuvasti parantaa ISMS:ää, joka suojaa luottamuksellisuutta, eheyttä ja saatavuutta riskienhallintaprosessin avulla. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset ja sääntelyyn perustuvat velvoitteet, rajapinnat ja riippuvuudet sekä dokumentoi tämän perusteella ISMS:n soveltamisalan.

DORA-säännellylle toimijalle tämän soveltamisalan määrittelyn on nimenomaisesti katettava kriittiset tai tärkeät toiminnot, ICT-omaisuuserät, pilvialustat, ulkoistetut toiminnot, maksujärjestelmät, asiakasportaalit, identiteettipalvelut, lokitusalustat, palautusympäristöt ja ICT-kolmansien osapuolten palveluntarjoajat. Jos TLPT:n soveltamisalaa ei voida johtaa ISMS:n soveltamisalasta, auditointijälki on jo lähtökohtaisesti heikko.

ISO 27001 -standardin kohdat 6.1.1, 6.1.2 ja 6.1.3 sekä kohdat 8.2 ja 8.3 edellyttävät riskien arviointi- ja riskienkäsittelyprosessia. Riskit on tunnistettava suhteessa luottamuksellisuuteen, eheyteen ja saatavuuteen. Riskinomistajat on nimettävä. Todennäköisyys ja vaikutus on arvioitava. Kontrollit on valittava ja niitä on verrattava liitteeseen A. Riskinomistajien on hyväksyttävä jäännösriski.

Tämä on silta DORA:n ja auditointivalmiin testauksen välillä.

Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta Zenith Blueprint kuvaa riskienhallintavaiheen vaiheessa 13 tämän jäljitettävyysroolin selkeästi:

SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja riskien käsittelyn käytössä oleviin varsinaisiin kontrolleihin. Kun täydennät sen, varmistat samalla, ettet ole jättänyt mitään kontrolleja huomioimatta.

DORA TLPT:n osalta soveltuvuuslausunnon ei pidä olla staattinen sertifiointiartefakti. Sen on selitettävä, miksi esimerkiksi toimittajaturvallisuutta, poikkeamien hallintaa, ICT-valmiutta liiketoiminnan jatkuvuuteen, lokitusta, valvontaa, teknisten haavoittuvuuksien hallintaa, varmuuskopioita, turvallista kehittämistä ja tietoturvatestausta koskevat kontrollit soveltuvat häiriönsietokyvyn skenaarioon.

Käytännön riskiskenaario voisi olla seuraava:

“Etuoikeutetun identiteetintarjoajan tunnistetietojen vaarantuminen antaa hyökkääjälle pääsyn maksujenkäsittelyn hallintajärjestelmiin, mahdollistaa reitityskonfiguraatioiden muuttamisen ja häiritsee kriittistä maksutoimintoa, mistä seuraa palvelukatkos, sääntelyyn perustuvia raportointivelvoitteita, asiakashaittaa ja mainevahinkoa.”

Tämä yksi skenaario voi ohjata TLPT:n soveltamisalaa, havaitsemiskäyttötapauksia, toimittajien osallistamista, palautusharjoitusta, hallitusraportointia ja näyttökokonaisuutta.

Zenith Blueprint suosittelee myös sääntelyyn liittyvän jäljitettävyyden tekemistä näkyväksi:

Ristiinviittaa sääntelyyn: jos tietyt kontrollit on toteutettu nimenomaan GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit kirjata sen joko riskirekisteriin osana riskivaikutuksen perustelua tai SoA:n huomautuksiin.

Neuvo on yksinkertainen, mutta se muuttaa auditointikeskustelun. Sen sijaan, että organisaatio kertoisi auditoijalle DORA:n tulleen huomioiduksi, se voi näyttää, missä DORA näkyy riskirekisterissä, SoA:ssa, testausohjelmassa, politiikkakokonaisuudessa ja johdon katselmuksessa.

Yhdistä DORA-testaus auditoijien tunnistamiin ISO 27001 -kontrolleihin

DORA Article 6 odottaa dokumentoitua ICT-riskienhallinnan viitekehystä, joka on integroitu kokonaisriskienhallintaan. ISO 27001:n liite A antaa kontrollikatalogin, jolla tämä tehdään operatiiviseksi.

DORA TLPT:n ja häiriönsietokyvyn testauksen kannalta seuraavat ISO/IEC 27001:2022 -standardin liitteen A kontrollit ovat erityisen tärkeitä:

Clarysecin Zenith Controls: eri sääntelykehysten vaatimustenmukaisuuden opas Zenith Controls auttaa organisaatioita välttämään sen, että näitä kontrolleja käsitellään erillisinä tarkistuslistakohtina. Se kartoittaa ISO/IEC 27002:2022 -kontrollit attribuutteihin, osa-alueisiin, operatiivisiin kyvykkyyksiin, auditointiodotuksiin ja eri viitekehysten välisiin malleihin.

Esimerkiksi Zenith Controls luokittelee ISO/IEC 27002:2022 -kontrollin 5.30, ICT-valmius liiketoiminnan jatkuvuuteen, korjaavaksi kontrolliksi, joka kohdistuu saatavuuteen, liittyy Respond-kyberturvallisuuskonseptiin ja sijoittuu Resilience-osa-alueeseen. Tämä luokittelu on hyödyllinen, kun auditoijille selitetään, miksi palautusharjoitus ei ole vain IT-operaatio vaan häiriönsietokyvyn kontrolli, jolla on määritelty rooli kontrolliympäristössä.

Zenith Controls luokittelee myös kontrollin 8.29, turvallisuustestaus kehityksessä ja hyväksynnässä, ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja jonka operatiiviset kyvykkyydet liittyvät sovellusturvallisuuteen, tietoturvan varmentamiseen sekä järjestelmä- ja verkkoturvallisuuteen. Kun TLPT-havainnot palautuvat sovellussuunnittelun heikkouteen, turvattomaan API-käyttäytymiseen, heikkoon todennusvirtaan tai puutteelliseen validointiin, tämä on kontrollipolku turvallisen kehittämisen hallinnointiin.

Myös kontrolli 5.35, tietoturvallisuuden riippumaton katselmointi, on tärkeä. Se tukee riippumatonta haastamista, hallinnollista varmentamista ja korjaavaa parantamista. Sisäiset tiimit voivat koordinoida testausta, mutta auditointivalmius edellyttää katselmointia, eskalointia ja valvontaa myös niiden henkilöiden ulkopuolelta, jotka ovat rakentaneet tai operoineet testattuja järjestelmiä.

Suojaa järjestelmä samalla kun testaat sitä

Yksi vaarallinen oletus häiriönsietokyvyn testauksessa on, että testaus on automaattisesti hyvä asia. Todellisuudessa tunkeileva testaus voi aiheuttaa käyttökatkoja, paljastaa arkaluonteisia tietoja, sekoittaa lokeja, laukaista automatisoituja puolustuksia, katkaista asiakasistuntoja tai saada toimittajat käynnistämään hätämenettelyjä.

Clarysecin Tietoturvatestauksen ja Red Team -harjoitusten politiikka Tietoturvatestauksen ja Red Team -harjoitusten politiikka antaa organisaatioille hallinnointimallin turvalliseen toteutukseen. Kohta 6.1 toteaa:

Testityypit: tietoturvatestausohjelman on sisällettävä vähintään: (a) haavoittuvuusskannaus, joka koostuu verkkojen ja sovellusten automatisoiduista viikoittaisista tai kuukausittaisista skannauksista tunnettujen haavoittuvuuksien tunnistamiseksi; (b) penetraatiotestaus, joka koostuu osaavien testaajien tekemästä tiettyjen järjestelmien tai sovellusten manuaalisesta syvätestauksesta monimutkaisten heikkouksien tunnistamiseksi; ja (c) red team -harjoitukset, jotka koostuvat todellisten hyökkäysten skenaariopohjaisista simulaatioista, mukaan lukien sosiaalinen manipulointi ja muut taktiikat, organisaation havaitsemis- ja reagointikyvykkyyden testaamiseksi kokonaisuutena.

TLPT:ssä red team -elementti on ilmeinen, mutta auditointiarvo syntyy ohjelmasuunnittelusta. Haavoittuvuusskannauksen, penetraatiotestauksen, red team -harjoitusten, häiriönsietokyvyn harjoitusten ja uusintatestauksen on muodostettava sykli, ei irrallisten testien kokoelmaa.

Saman politiikan kohta 6.2 käsittelee turvallista toteutusta:

Soveltamisala ja toimintasäännöt: tietoturvatestauksen koordinaattorin (STC) on määritettävä kunkin testin tai harjoituksen soveltamisala, mukaan lukien soveltamisalaan kuuluvat järjestelmät ja IP-alueet, sallitut testimenetelmät, tavoitteet, ajankohta ja kesto. Toimintasäännöt on dokumentoitava. Esimerkiksi operatiivisesti arkaluonteiset järjestelmät voidaan määrittää vain seurannan piiriin häiriöiden välttämiseksi, ja kaikki tuotantoympäristön testaus on sisällytettävä palautus- ja pysäytysmenettelyihin. Tahattomien palvelukatkosten estämiseksi on otettava käyttöön turvallisuustoimenpiteitä, kuten määritellyt aikaikkunat ja viestintäkanavat.

Tämä kytkeytyy suoraan Zenith Blueprint -mallin Kontrollit käytännössä -vaiheen vaiheeseen 21, joka keskittyy ISO 27001:n liitteen A kontrolliin 8.34, tietojärjestelmien suojaaminen auditointitestauksen aikana. Zenith Blueprint varoittaa, että auditoinnit, penetraatiotestit, forensiset katselmoinnit ja operatiiviset arvioinnit voivat sisältää korotettuja käyttöoikeuksia, tunkeilevia työkaluja tai tilapäisiä muutoksia järjestelmän käyttäytymiseen. Se korostaa valtuutusta, soveltamisalaa, aikaikkunoita, järjestelmäomistajan hyväksyntää, muutoksen peruuttamista, valvontaa ja testidatan turvallista käsittelyä.

Auditointivalmiin näyttökokonaisuuden on sisällettävä:

• TLPT-toimeksianto ja tavoitteet
• uhkatiedustelun yhteenveto ja skenaarion perustelu
• soveltamisalaan kuuluvat kriittiset tai tärkeät toiminnot
• soveltamisalaan kuuluvat järjestelmät, IP-alueet, identiteetit, toimittajat ja ympäristöt
• poissulut ja vain seurannan piirissä olevat järjestelmät
• toimintasäännöt
• tuotantotestauksen riskien arviointi
• palautus- ja pysäytysmenettelyt
• SOC-ilmoitusmalli, mukaan lukien mitä paljastetaan ja mitä pidätetään
• laki-, tietosuoja- ja toimittajahyväksynnät
• testitilien luonnin ja perumisen näyttö
• testiartefaktien ja lokien turvallinen säilytyspaikka

DORA TLPT, joka ei pysty osoittamaan testitoiminnan turvallista valtuutusta ja hallintaa, voi paljastaa häiriönsietokyvyn puutteita, mutta se luo samalla hallinnointipuutteita.

Muunna TLPT:n tulokset riskien käsittelyksi

Yleisin testauksen jälkeinen epäonnistuminen on red team -raportin hyllyongelma. Laadukas raportti toimitetaan, jaetaan, käsitellään ja menettää sitten vähitellen vauhtinsa. Havainnot jäävät avoimiksi. Korvaavia kontrolleja ei dokumentoida. Hyväksytyt riskit jäävät epämuodollisiksi. Uusintatestausta ei koskaan tehdä.

Tietoturvatestauksen ja Red Team -harjoitusten politiikka tekee tästä hyväksymätöntä. Kohta 6.6 toteaa:

Havaintojen korjaaminen: kaikki tunnistetut haavoittuvuudet tai heikkoudet on dokumentoitava havaintoraporttiin vakavuusluokituksineen. Raportin vastaanottamisen jälkeen järjestelmäomistajat vastaavat korjaussuunnitelman laatimisesta määräpäivineen; esimerkiksi kriittiset havainnot on korjattava 30 päivän kuluessa ja korkean vakavuuden havainnot 60 päivän kuluessa organisaation Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikan mukaisesti. Tietoturvatestauksen koordinaattorin (STC) on seurattava korjausten etenemistä. Uusintatestaus on tehtävä sen varmistamiseksi, että kriittiset ongelmat on ratkaistu tai riittävästi lievennetty.

Kohta 6.7 lisää hallinnointikerroksen:

Raportointi: kunkin testin päätyttyä on laadittava muodollinen raportti. Penetraatiotestauksen osalta raportin on sisällettävä johdon yhteenveto, menetelmäkuvaus sekä yksityiskohtaiset havainnot niitä tukevine näyttöineen ja suosituksineen. Red team -harjoitusten osalta raportin on kuvattava skenaariot, onnistuneet hyökkäyspolut, Blue Team -tiimin havaitsemat asiat sekä opit havaitsemisen ja reagoinnin puutteista. Tietoturvajohtajan on esitettävä tiivistetyt tulokset ja korjausten tila ylimmälle johdolle ja tarvittaessa sisällytettävä ne vuosittaiseen tietoturvaraporttiin hallitukselle.

Tämä on linjassa ISO/IEC 27005:2022 -standardin riskienkäsittelyohjeistuksen kanssa: valitaan käsittelyvaihtoehdot, määritetään kontrollit ISO 27001:n liitteestä A ja sektorikohtaisista vaatimuksista, laaditaan riskienkäsittelysuunnitelma, nimetään vastuuhenkilöt, määritellään aikataulut, seurataan tilaa, hankitaan riskinomistajan hyväksyntä ja dokumentoidaan jäännösriskin hyväksyntä.

Jokaisen merkittävän TLPT-havainnon on muututtava yhdeksi neljästä asiasta: korjaavaksi toimenpiteeksi, kontrolliparannukseksi, muodolliseksi riskin hyväksynnäksi tai uusintatestauksen vaatimukseksi.

Tavoitteena ei ole tuottaa lisää asiakirjoja. Tavoitteena on, että jokainen asiakirja selittää seuraavan päätöksen.

Häiriönsietokyvyn testauksen on osoitettava palautuminen, ei pelkkää havaitsemista

Onnistunut TLPT voi osoittaa, että SOC havaitsi command-and-control-liikenteen, esti lateraalisen liikkumisen ja eskaloi oikein. Tämä on arvokasta, mutta DORA:n mukainen häiriönsietokyvyn testaus menee pidemmälle. Se kysyy, pystyykö organisaatio jatkamaan liiketoimintapalveluja tai palauttamaan ne.

Zenith Blueprint, Kontrollit käytännössä -vaiheen vaihe 23, selittää kontrollin 5.30, ICT-valmius liiketoiminnan jatkuvuuteen, kielellä, jota jokaisen tietoturvajohtajan tulisi käyttää hallituksen kanssa:

Auditoinnin näkökulmasta tätä kontrollia testataan usein yhdellä lauseella: Näytä minulle. Näytä viimeisin testitulos. Näytä palautusdokumentaatio. Näytä, kuinka kauan failoveriin ja palautukseen meni. Näytä näyttö siitä, että luvattu voidaan toimittaa.

Tämä “Näytä minulle” -standardi erottaa politiikkakypsyyden operatiivisesta häiriönsietokyvystä.

Clarysecin Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - SME Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - SME, osiossa “Politiikan toteutusvaatimukset”, kohta 6.4.1, toteaa:

Organisaation on testattava sekä BCP- että DR-kyvykkyytensä vähintään vuosittain. Testien on sisällettävä:

Saman politiikan soveltamisosio, kohta 8.5.1, tekee näyttövastuusta nimenomaisen:

Toimitusjohtajan on varmistettava, että seuraavat pidetään yllä ja auditointivalmiina:

DORA-säännellylle finanssialan toimijalle vuosittainen testaus voi olla vähimmäistaso, ei tavoitetila. Korkeamman riskin kriittisiä tai tärkeitä toimintoja on testattava useammin erityisesti arkkitehtuurimuutosten, pilvimigraation, merkittävien poikkeamien, uusien ICT-toimittajien, olennaisten sovellusjulkaisujen tai uhka-altistuksen muutosten jälkeen.

Vahvan häiriönsietokykytestin näyttöpaketin on sisällettävä:

• liiketoimintavaikutusten arviointi, joka kartoittaa kriittisen tai tärkeän toiminnon
• liiketoimintavastaavien hyväksymät RTO ja RPO
• järjestelmäriippuvuuksien kartta, mukaan lukien identiteetti, DNS, verkko, pilvi, tietokanta, valvonta, varmuuskopiointi ja kolmansien osapuolten palvelut
• varmuuskopioinnin ja palautuksen testitulokset
• failover- ja failback-aikaleimat
• näyttö tietoturvakontrollien toiminnasta häiriön aikana
• asiakas-, viranomais- ja sisäisen viestinnän mallipohjat
• poikkeamapäällikön ja kriisiryhmän osallistumislokit
• opitut asiat ja parannustoimet
• uusintatestauksen näyttö aiemmista palautumispuutteista

Tässä myös GDPR tulee mukaan kuvaan. GDPR Articles 2 ja 3 tuovat useimmat EU:n henkilötietoja käsittelevät SaaS- ja fintech-käsittelyt soveltamisalaan. Article 4 määrittelee henkilötiedot, käsittelyn, rekisterinpitäjän, käsittelijän ja henkilötietojen tietoturvaloukkauksen. Article 5 edellyttää eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta, mikä tarkoittaa, että organisaation on pystyttävä osoittamaan vaatimustenmukaisuus. Jos TLPT tai palautustestaus käyttää tuotannon henkilötietoja, kopioi tunnisteita sisältäviä lokeja tai validoi loukkausreagointia, tietosuojan suojatoimet on dokumentoitava.

Toimittajanäyttö on DORA:n sokea piste, jota auditoijat eivät sivuuta

Nykyaikaiset finanssipalvelut rakentuvat pilvialustoista, SaaS-sovelluksista, hallinnoiduista tietoturvapalveluntarjoajista, maksunvälittäjistä, data-alustoista, identiteetintarjoajista, havainnointityökaluista, ulkoistetuista kehitystiimeistä ja varmuuskopiointipalveluntarjoajista.

DORA Article 28 edellyttää, että finanssialan toimijat hallitsevat ICT-kolmansien osapuolten riskiä osana ICT-riskienhallinnan viitekehystä ja pysyvät täysin vastuullisina myös silloin, kun ICT-palvelut on ulkoistettu. Article 30 edellyttää kirjallisia ICT-palvelusopimuksia, joissa määritellään palvelukuvaukset, alihankinnan ehdot, käsittelysijainnit, tietosuoja, pääsy ja palautuminen, palvelutasot, poikkeamatuki, yhteistyö viranomaisten kanssa, irtisanomisoikeudet, vahvemmat ehdot kriittisille tai tärkeille toiminnoille, auditointioikeudet, turvatoimet, TLPT-osallistuminen tarvittaessa ja exit-järjestelyt.

Tämä tarkoittaa, että TLPT-skenaario ei voi pysähtyä organisaation palomuuriin, jos kriittinen toiminto riippuu toimittajasta.

Clarysecin Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka - SME Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka - SME, osiossa “Politiikan toteutusvaatimukset”, kohta 6.3.1, toteaa:

Kriittiset tai korkean riskin toimittajat on katselmoitava vähintään vuosittain. Katselmoinnin on varmistettava:

Tietoturvatestauksen ja Red Team -harjoitusten politiikka lisää testauskohtaisen toimittajavaatimuksen kohdassa 6.9:

Kolmannen osapuolen testauksen koordinointi: kun organisaation kokonaisturvallisuuden soveltamisalaan kuuluu kriittinen toimittaja tai palveluntarjoaja Kolmansien osapuolten ja toimittajien turvallisuuspolitiikan mukaisesti, organisaation on mahdollisuuksien mukaan hankittava varmuus sen tietoturvatestauskäytännöistä tai koordinoitava yhteistestausta. Esimerkiksi pilvipalveluntarjoajaa (CSP) käytettäessä organisaatio voi tukeutua sen penetraatiotestausraportteihin tai sisällyttää sen yhteisiin red team -skenaarioihin sopimusmääräysten mukaisesti.

Auditointivalmiissa DORA-näytössä toimittajan varmentaminen on kytkettävä samaan riskiskenaarioon kuin TLPT. Jos identiteetintarjoaja on olennainen maksujen palautumiselle, näyttöpaketin on sisällettävä toimittajan due diligence -arviointi, sopimukselliset tietoturvavaatimukset, poikkeamatukea koskevat ehdot, testauskoordinointi, varmennusraportit, palvelutason näyttö, exit-strategia ja testaukseen liittyvät rajoitteet.

NIS2 Article 21 on merkityksellinen myös SaaS-, pilvi-, hallinnoitujen palvelujen, hallinnoidun tietoturvan, datakeskusten, CDN-, luottamuspalvelu-, DNS-, TLD-, verkkomarkkinapaikka-, hakukone- ja sosiaalisen verkostoitumisen palveluntarjoajille. Se edellyttää kaikki vaarat huomioivaa lähestymistapaa, joka kattaa riskianalyysin, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen kehittämisen, vaikuttavuuden arvioinnin, koulutuksen, kryptografian, pääsynhallinnan, omaisuudenhallinnan, MFA:n ja turvallisen viestinnän.

Käytännön johtopäätös on yksinkertainen: finanssialan toimijoiden on rakennettava yksi näyttömalli, joka täyttää ensin DORA-vaatimukset ja ristiinviittaa sitten NIS2-odotuksiin silloin, kun mukana on toimittajia, konserniyksiköitä tai finanssialan ulkopuolisia digitaalisia palveluja.

Käytännön Clarysec TLPT -näyttörekisteri

Oletetaan skenaario:

“Uhkatoimija vaarantaa SaaS-tukialustan ylläpitäjätilin, siirtyy maksutoimintojen ympäristöön, muuttaa konfiguraatiota ja häiritsee tapahtumien käsittelyä.”

Luo näyttörekisteri, jossa on yksi rivi kutakin näyttökohdetta kohti. Älä odota testin päättymistä. Täydennä sitä suunnittelun, toteutuksen, korjaamisen ja sulkemisen aikana.

Käytä sen jälkeen Zenith Blueprint -mallin vaihetta 13 lisätäksesi jäljitettävyyden riskirekisteriin ja soveltuvuuslausuntoon. Jokaisen näyttökohteen on liityttävä riskiskenaarioon, riskinomistajaan, valittuun kontrolliin, käsittelysuunnitelmaan ja jäännösriskipäätökseen.

Jos havainto liittyy ohjelmistoheikkouteen, viittaa turvallisen kehittämisen ja testauksen kontrolleihin. Clarysecin Turvallisen kehityksen politiikka - SME Turvallisen kehityksen politiikka - SME, osiossa “Politiikan toteutusvaatimukset”, kohta 6.5.2, edellyttää:

Testaus on dokumentoitava seuraavilla tiedoilla:

Jos havainto tuottaa forensista materiaalia, säilytä hallussapitoketju. Clarysecin Todisteiden keräämisen ja forensiikan politiikka - SME Todisteiden keräämisen ja forensiikan politiikka - SME, osiossa “Hallinnointivaatimukset”, kohta 5.2.1, toteaa:

Jokainen digitaalisen todistusaineiston kohde on kirjattava lokiin seuraavilla tiedoilla:

Tämän kohdan monet tiimit ohittavat. Näyttö ei ole vain loppuraportteja. Se on hallittu tallenne siitä, kuka hyväksyi, kuka toteutti, mitä tapahtui, mitä havaittiin, mitä palautettiin, mitä muutettiin, mikä jää edelleen alttiiksi ja kuka hyväksyi tämän altistuksen.

Miten auditoijat tarkastavat samaa TLPT-näyttöä

DORA TLPT -näyttöä luetaan eri tavoin auditoijan taustan mukaan. Clarysec suunnittelee näyttöpaketit niin, että kukin näkökulma löytää tarvitsemansa ilman, että tiimien on tehtävä päällekkäistä työtä.

COBIT 2019 esiintyy Zenith Blueprint -mallin eri viitekehysten välisessä viittauksessa turvalliseen auditoinnin ja testauksen toteutukseen, mukaan lukien DSS05.03 ja MEA03.04. Olennaista ei ole, että COBIT korvaisi DORA:n tai ISO 27001:n, vaan se, että ISACA-tyyppiset varmentamisen ammattilaiset etsivät hallittua toteutusta, seurantaa, arviointia ja vaatimustenmukaisuusnäyttöä.

Hallitusnarratiivi: mitä johdon on hyväksyttävä

Hallitusraportoinnin tulee välttää teknistä teatteria. Hallitus ei tarvitse hyötykuormia. Se tarvitsee päätöksenteon tasoista näyttöä:

• Mikä kriittinen tai tärkeä toiminto testattiin?
• Mitä uhkaskenaariota simuloitiin ja miksi?
• Toimiko havaitseminen?
• Toimiko reagoinnin eskalointi?
• Täyttikö palautuminen RTO- ja RPO-tavoitteet?
• Mitkä toimittajat olivat mukana tai rajoittivat testausta?
• Mitä olennaisia heikkouksia on jäljellä?
• Mitkä ovat korjausten kustannukset, omistaja ja aikataulu?
• Mitkä jäännösriskit edellyttävät muodollista hyväksyntää?
• Mitä testataan uudelleen?

Tässä ISO 27001 -standardin kohta 5 on tärkeä. Ylimmän johdon on varmistettava, että tietoturvapolitiikka ja tavoitteet on määritetty, sovitettu strategiseen suuntaan, integroitu liiketoimintaprosesseihin, resursoitu, viestitty ja jatkuvasti parannettu. Roolit ja vastuut on osoitettava. Tavoitteiden on oltava mahdollisuuksien mukaan mitattavia ja huomioitava sovellettavat vaatimukset sekä riskien käsittelyn tulokset.

Jos TLPT osoittaa, että palautumisaika on kuusi tuntia neljän tunnin liiketoiminnan sietorajaa vastaan, kyse ei ole pelkästään infrastruktuurin työjonokohteesta. Se on johdon päätös, joka koskee riskinottohalukkuutta, budjettia, asiakassitoumuksia, sääntelyaltistusta, sopimuksia, arkkitehtuuria ja operatiivista kapasiteettia.

Yleiset näyttöpuutteet DORA:n mukaisessa häiriönsietokyvyn testauksessa

Clarysecin katselmoinneissa löydetään usein samoja näyttöpuutteita DORA:an valmistautuvissa finanssialan toimijoissa ja ICT-palveluntarjoajissa.

Ensinnäkin TLPT:n soveltamisala ei kytkeydy kriittisiin tai tärkeisiin toimintoihin. Testi voi olla teknisesti vaikuttava, mutta se ei osoita sääntelijän kannalta olennaisen liiketoimintaprosessin häiriönsietokykyä.

Toiseksi toimittajariippuvuudet tunnistetaan, mutta niitä ei osoiteta näytöllä. Tiimit sanovat, että pilvipalveluntarjoaja, hallinnoitu SOC tai SaaS-alusta kuuluu soveltamisalaan, mutta sopimukset, auditointioikeudet, testausluvat, poikkeamatukea koskevat ehdot ja exit-suunnitelmat puuttuvat.

Kolmanneksi testaus tuottaa näyttöä mutta ei käsittelyä. Havainnot jäävät red team -raporttiin sen sijaan, että ne muunnettaisiin riskirekisterin päivityksiksi, kontrollimuutoksiksi, omistajiksi, päivämääriksi, uusintatestauksiksi ja jäännösriskipäätöksiksi.

Neljänneksi palautuminen oletetaan osoittamisen sijaan. Varmuuskopiointipolitiikat ovat olemassa, mutta kukaan ei pysty näyttämään failover-aikaleimoja, palautuksen eheystarkastuksia, käyttöoikeuksien tarkistusta tai liiketoimintavastaavan vahvistusta.

Viidenneksi tietosuoja- ja forensinen näyttö ovat hallitsemattomia. Lokit ja kuvakaappaukset sisältävät henkilötietoja, testiartefakteja säilytetään jaetuilla levyillä, tilapäiset tilit jäävät aktiivisiksi ja todistusaineiston hallussapitoketju on puutteellinen.

Kuudenneksi johdon raportointi on liian teknistä. Ylin johto ei näe, parantuiko häiriönsietokyky, pysyykö riski riskinottohalukkuuden rajoissa tai millaisia investointipäätöksiä tarvitaan.

Jokainen näistä puutteista voidaan ratkaista käsittelemällä DORA TLPT:tä rakenteistettuna ISO 27001 -näyttötyönkulkuna.

Clarysecin integroitu lähestymistapa auditointivalmiiseen häiriönsietokykyyn

Clarysecin lähestymistapa yhdistää kolme kerrosta.

Ensimmäinen kerros on Zenith Blueprint -mallin 30-vaiheinen toteutuksen tiekartta. Tässä aiheessa vaihe 13 rakentaa riskien käsittelyn ja SoA:n jäljitettävyyden, vaihe 21 suojaa järjestelmiä auditointitestauksen aikana ja vaihe 23 validoi ICT-valmiuden liiketoiminnan jatkuvuuteen. Nämä vaiheet muuttavat TLPT:n teknisestä tapahtumasta dokumentoiduksi hallinnointisykliksi.

Toinen kerros on Clarysecin politiikkakirjasto. Tietoturvatestauksen ja Red Team -harjoitusten politiikka määrittelee testityypit, soveltamisalan, toimintasäännöt, korjaamisen, raportoinnin ja toimittajakoordinoinnin. Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - SME asettaa odotukset vuosittaiselle BCP- ja DR-testaukselle sekä auditointivalmiille jatkuvuusnäytölle. Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka - SME tukee toimittajien varmentamista. Turvallisen kehityksen politiikka - SME varmistaa, että tietoturvatestaus dokumentoidaan. Todisteiden keräämisen ja forensiikan politiikka - SME tukee todistusaineiston lokitusta ja hallussapitoketjun kurinalaisuutta.

Kolmas kerros on Zenith Controls, Clarysecin eri sääntelykehysten vaatimustenmukaisuutta yhdistävä opas. Se auttaa kartoittamaan ISO/IEC 27002:2022 -kontrollit attribuutteihin, osa-alueisiin, operatiivisiin kyvykkyyksiin ja eri viitekehysten odotuksiin. DORA TLPT:ssä tärkein malli ei ole yksittäinen kontrolli. Se on testauksen, jatkuvuuden, poikkeamien hallinnan, toimittajahallinnan, lokituksen, valvonnan, turvallisen kehittämisen, riippumattoman katselmoinnin ja hallinnoinnin välinen suhde.

Kun nämä kerrokset toimivat yhdessä, tietoturvajohtajan maanantaiaamun ongelma muuttuu. Hallituksen, valvontaviranomaisen ja sisäisen auditoinnin kolmen irrallisen kysymyksen sijaan organisaatiolla on yksi näyttötarina:

“Tunnistimme kriittisen toiminnon. Arvioimme ICT-riskin. Valitsimme ja perustelimme kontrollit. Valtuutimme ja toteutimme TLPT:n turvallisesti. Havaitsimme, reagoimme ja palauduimme. Osallistimme toimittajat tarvittaessa. Dokumentoimme näytön. Korjasimme havainnot. Testasimme uudelleen. Johto katselmoi ja hyväksyi jäljellä olevan riskin.”

Tämä on auditointivalmista häiriönsietokykyä.

Seuraavat vaiheet

Jos DORA TLPT -ohjelmasi on edelleen järjestetty raporttien eikä näyttöketjujen ympärille, aloita Clarysecin näyttöläpikäynnillä.

Käytä Zenith Blueprint Zenith Blueprint -mallin vaihetta 13 yhdistääksesi TLPT-skenaariot riskeihin, kontrolleihin ja soveltuvuuslausuntoon. Käytä vaihetta 21 varmistaaksesi turvallisen valtuutuksen, toimintasäännöt, muutoksen peruuttamisen, valvonnan ja siivouksen. Käytä vaihetta 23 osoittaaksesi ICT-valmiuden liiketoiminnan jatkuvuuteen palautusnäytöllä.

Sovita sen jälkeen operatiiviset asiakirjasi yhteen Clarysecin Tietoturvatestauksen ja Red Team -harjoitusten politiikan Tietoturvatestauksen ja Red Team -harjoitusten politiikka, Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - SME Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - SME, Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka - SME Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka - SME, Turvallisen kehityksen politiikka - SME Turvallisen kehityksen politiikka - SME ja Todisteiden keräämisen ja forensiikan politiikka - SME Todisteiden keräämisen ja forensiikan politiikka - SME kanssa.

Lopuksi käytä Zenith Controls Zenith Controls -opasta ristiinkartoittaaksesi DORA TLPT -näyttösi ISO 27001 -kontrolleihin, NIS2:een, GDPR:ään, COBIT 2019:ään ja auditoijien odotuksiin.

Jos haluat seuraavan häiriönsietokykytestisi tuottavan muutakin kuin havaintoja, käytä Claryseciä muuttaaksesi sen puolustettavaksi näyttöketjuksi. Lataa työkalupaketit, varaa näytön valmiusarviointi tai pyydä läpikäynti siitä, miten Clarysec kartoittaa DORA TLPT:n ISO 27001:2022 -kontrolleihin suunnittelusta hallituksen hyväksyntään.