Auditointivalmis palautustestaus ISO 27001-, NIS2- ja DORA-vaatimuksiin

On maanantaiaamu kello 07.40, ja nopeasti kasvavan finanssiteknologiayrityksen tietoturvajohtaja Sarah seuraa kriisin kehittymistä reaaliajassa. Talousjohtaja ei saa maksujen hyväksyntäalustaa auki. Palvelupiste arvioi kyseessä olevan tallennusongelma. Infrastruktuuritiimi epäilee kiristyshaittaohjelmaa, koska useissa jaetuissa kansioissa näkyy nyt salattuja tiedostonimiä. Toimitusjohtaja haluaa tietää, onko palkanmaksu turvassa. Lakitoiminto kysyy, onko valvontaviranomaisille ilmoitettava.

Sarah avaa varmuuskopioinnin hallintanäkymän. Se on täynnä vihreitä hyväksyntämerkkejä.

Sen pitäisi rauhoittaa, mutta niin ei käy. Onnistunut varmuuskopiointiajo ei ole näyttö onnistuneesta palautuksesta. Se on kuin näkisi sammuttimen seinällä tietämättä, onko se täynnä, saavutettavissa ja käytettävissä paineen alla.

Sarahin yritys kuuluu ISO 27001:2022 -soveltamisalaan, sitä käsitellään NIS2:n mukaisena tärkeänä toimijana, ja siihen sovelletaan DORA-asetusta rahoitusalan toimijana. Kysymys ei enää ole siitä, tekeekö organisaatio varmuuskopioita. Kysymys on siitä, pystyykö se palauttamaan oikeat järjestelmät oikeaan ajanhetkeen hyväksyttyjen palautumisaikatavoitteiden (RTO) ja palautuspistetavoitteiden (RPO) puitteissa siten, että näyttö kestää auditoijan, valvontaviranomaisen, asiakkaan, vakuuttajan ja hallituksen arvioinnin.

Tässä moni varmuuskopiointiohjelma epäonnistuu. Niillä on varmuuskopiointiajoja. Niillä on hallintanäkymiä. Niillä on tilannevedoksia. Niillä voi olla myös pilvitallennusta. Kun paine kasvaa, ne eivät kuitenkaan pysty osoittamaan, että kriittiset järjestelmät ovat palautuskelpoisia, että palautustestit on tehty, että epäonnistuneet testit käynnistivät korjaavat toimenpiteet ja että näyttö kytkeytyy selkeästi ISO 27001:2022-, NIS2-, DORA-, NIST- ja COBIT 2019 -odotuksiin.

Varmuuskopiointi- ja palautustestauksesta on tullut hallitustason operatiivisen häiriönsietokyvyn kysymys. NIS2 nostaa odotuksia kyberturvallisuuden riskienhallinnalle ja liiketoiminnan jatkuvuudelle. DORA tekee ICT:n operatiivisesta häiriönsietokyvystä keskeisen velvoitteen rahoitusalan toimijoille ja niiden kriittisille ICT-palveluntarjoajille. ISO 27001:2022 tarjoaa hallintajärjestelmärakenteen soveltamisalalle, riskeille, kontrollien valinnalle, näytölle, auditoinnille ja jatkuvalle parantamiselle.

Käytännön haaste on muuntaa tekninen palautustesti auditointivalmiiksi näytöksi.

Varmuuskopio ei ole näyttöä ennen kuin palautus on osoitettu

Onnistuneesti päättynyt varmuuskopiointiajo on vain osittainen signaali. Se kertoo, että tiedot kopioitiin jonnekin. Se ei osoita, että tiedot voidaan palauttaa, että sovellusriippuvuudet ovat ehjät, että salausavaimet ovat saatavilla, että identiteettipalvelut toimivat edelleen tai että palautettu järjestelmä tukee todellisia liiketoimintaprosesseja.

Auditoijat tietävät tämän. Valvontaviranomaiset tietävät tämän. Hyökkääjät tietävät tämän.

Teknisesti kypsä auditoija ei pysähdy kuvakaappaukseen, jossa näkyy varmuuskopiointiajojen 97 prosentin onnistumisaste. Hän kysyy:

• Mitkä järjestelmät ovat kriittisiä tai vaikutukseltaan suuria?
• Mitkä RTO- ja RPO-tavoitteet koskevat kutakin järjestelmää?
• Milloin viimeisin palautustesti tehtiin?
• Oliko testi täysi, osittainen, sovellustasoinen, tietokantatasoinen vai tiedostotasoinen?
• Kuka validoi liiketoimintaprosessin palautuksen jälkeen?
• Kirjattiinko epäonnistumiset poikkeamina tai parantamistoimenpiteinä?
• Kuinka kauan lokit ja palautustestien tallenteet säilytetään?
• Onko varmuuskopiot eriytetty eri sijainteihin?
• Miten näyttö kytkeytyy riskirekisteriin ja soveltuvuuslausuntoon?

Tästä syystä Clarysecin käytäntökieli on tarkoituksellisesti suoraa. Varmuuskopiointi- ja palautuskäytäntö pk-yrityksille [BRP-SME], osio Hallinnointivaatimukset, käytäntölauseke 5.3.3, edellyttää:

Palautustestit tehdään vähintään neljännesvuosittain, ja tulokset dokumentoidaan palautuskelpoisuuden varmistamiseksi

Tämä yksi lause muuttaa auditointikeskustelun. Organisaatio ei enää sano ”meillä on varmuuskopiot”, vaan ”varmistamme palautuskelpoisuuden määritetyllä rytmillä ja säilytämme tulokset”.

Sama Varmuuskopiointi- ja palautuskäytäntö pk-yrityksille, osio Soveltaminen ja vaatimustenmukaisuus, käytäntölauseke 8.2.2, vahvistaa näyttövelvoitteen:

Lokit ja palautustestien tallenteet säilytetään auditointitarkoituksia varten

Tämä lauseke estää palautustestauksen jäämisen dokumentoimattomaksi hiljaiseksi tiedoksi. Jos infrastruktuuri-insinööri sanoo: ”Testasimme sen maaliskuussa”, mutta tallennetta ei ole, kyse ei ole auditointivalmiista näytöstä.

Sama käytäntö käsittelee myös selviytymiskykyä tallennuksen hajauttamisen kautta. Osiossa Käytännön toteutusvaatimukset, käytäntölauseke 6.3.1.1, varmuuskopiot on:

Säilytettävä vähintään kahdessa sijainnissa (paikallinen ja pilvi)

Tämä on käytännöllinen perustaso. Se ei korvaa riskien arviointia, mutta vähentää mahdollisuutta, että yksi fyysinen tai looginen vikakohde tuhoaa sekä tuotanto- että varmuuskopiotiedot.

ISO 27001:2022 -näyttöketju alkaa ennen testiä

Organisaatiot käsittelevät varmuuskopioinnin vaatimustenmukaisuutta usein IT-operaatioiden aiheena. ISO 27001:2022 -näkökulmasta se on liian kapea lähestymistapa. Varmuuskopiointi- ja palautustestaus on sisällytettävä tietoturvallisuuden hallintajärjestelmään ja kytkettävä soveltamisalaan, riskeihin, kontrollien valintaan, seurantaan, sisäiseen auditointiin ja jatkuvaan parantamiseen.

Clarysecin Zenith Blueprint: auditoijan 30 vaiheen tiekartta [ZB] käynnistää tämän näyttöketjun ennen ensimmäistäkään palautustestiä.

ISMS:n perustan ja johtajuuden vaiheessa, vaihe 2, sidosryhmien tarpeet ja ISMS:n soveltamisala, Zenith Blueprint ohjeistaa organisaatioita määrittämään, mikä kuuluu ISMS:ään:

Toimenpide 4.3: Laadi ISMS:n soveltamisalakuvaus. Luettele, mitä siihen sisältyy (liiketoimintayksiköt, sijainnit, järjestelmät) ja mahdolliset poissulkemiset. Jaa luonnos ylimmälle johdolle kommentoitavaksi – johdon on hyväksyttävä, mitkä liiketoiminnan osat kuuluvat ISMS:n piiriin. Soveltamisala kannattaa myös tarkistaa aiemmin laadittua sidosryhmävaatimusten luetteloa vasten: kattaako soveltamisala kaikki alueet, joita tarvitaan näiden vaatimusten täyttämiseksi?

Palautustestauksessa soveltamisala määrittää palautuksen kohdejoukon. Jos maksualusta, identiteetintarjoaja, ERP-tietokanta, päätelaitteiden hallintapalvelin ja pilven objektitallennus kuuluvat soveltamisalaan, palautusnäytön on katettava ne tai perusteltava poikkeama. Jos järjestelmä rajataan ulkopuolelle, poissulkemisen on kestettävä sidosryhmävaatimusten, sopimusvelvoitteiden, sääntelyvelvoitteiden ja liiketoiminnan jatkuvuustarpeiden arviointi.

Seuraava lenkki on riski. Riskienhallintavaiheessa, vaihe 11, riskirekisterin rakentaminen ja dokumentointi, Zenith Blueprint kuvaa riskirekisterin riskien, omaisuuserien, uhkien, haavoittuvuuksien, nykyisten kontrollien, omistajien ja käsittelypäätösten päätallenteeksi.

Varmuuskopiointiin liittyvän riskimerkinnän on oltava käytännöllinen, ei teoreettinen.

Tässä varmuuskopioinnista tulee auditoitavaa. Kyse ei enää ole siitä, että ”meillä on varmuuskopiot”. Kyse on siitä, että ”tunnistimme liiketoimintariskin, valitsimme kontrollit, osoitimme omistajuuden, testasimme kontrollin ja säilytimme näytön”.

Zenith Blueprint, riskienhallintavaihe, vaihe 13, riskienkäsittelyn suunnittelu ja soveltuvuuslausunto, sulkee jäljitettävyysketjun:

Kartoita kontrollit riskeihin ja lausekkeisiin (jäljitettävyys)

Nyt kun sinulla on sekä riskienkäsittelysuunnitelma että SoA:

✓ Kartoita kontrollit riskeihin: Riskirekisterisi käsittelysuunnitelmassa olet listannut tietyt kontrollit kullekin riskille. Voit lisätä sarakkeen ”liite A:n kontrolliviite” kuhunkin riskiin ja luetella kontrollinumerot.

Varmuuskopiointi- ja palautustestauksessa soveltuvuuslausunnon on yhdistettävä riskiskenaario ISO/IEC 27001:2022 liite A:n kontrolleihin, erityisesti 8.13 Tietojen varmuuskopiointi, 5.30 ICT-valmius liiketoiminnan jatkuvuutta varten, 8.14 Tietojenkäsittelypalvelujen redundanssi ja 5.29 Tietoturvallisuus häiriötilanteissa.

SoA:ssa ei pidä vain merkitä näitä kontrolleja soveltuviksi. Sen on selitettävä, miksi ne soveltuvat, mitä toteutusnäyttöä on olemassa, kuka omistaa kontrollin ja miten poikkeukset käsitellään.

Kontrollikartta, jonka auditoijat odottavat näkevänsä

Clarysecin Zenith Controls: ristiinvaatimustenmukaisuuden opas [ZC] ei luo erillisiä tai omia kontrolleja. Se järjestää viralliset standardit ja viitekehykset käytännölliseksi ristiinvaatimustenmukaisuuden näkymäksi, jotta organisaatiot ymmärtävät, miten yksi operatiivinen käytäntö, kuten palautustestaus, tukee useita velvoitteita.

ISO/IEC 27002:2022 -kontrollin 8.13 Tietojen varmuuskopiointi osalta Zenith Controls luokittelee kontrollin korjaavaksi, eheyteen ja saatavuuteen kytkeytyväksi, Recover-kyberturvallisuuskonseptiin linjautuvaksi, jatkuvuuden operatiivista kyvykkyyttä tukevaksi ja Protection-tietoturva-alueelle sijoittuvaksi. Tämä profiili asemoi varmuuskopiot palautuskyvykkyydeksi, ei pelkäksi tallennusprosessiksi.

ISO/IEC 27002:2022 -kontrollin 5.30 ICT-valmius liiketoiminnan jatkuvuutta varten osalta Zenith Controls luokittelee kontrollin korjaavaksi, saatavuuteen keskittyväksi, Respond-toimintoon linjautuvaksi, jatkuvuutta tukevaksi ja häiriönsietokyvyn tietoturva-alueelle sijoittuvaksi. Tässä palautustestaus kytkeytyy suoraan operatiiviseen häiriönsietokykyyn.

ISO/IEC 27002:2022 -kontrollin 8.14 Tietojenkäsittelypalvelujen redundanssi osalta Zenith Controls tunnistaa ennaltaehkäisevän kontrollin, joka keskittyy saatavuuteen, linjautuu Protect-toimintoon, tukee jatkuvuutta ja omaisuudenhallintaa sekä liittyy Protection- ja Resilience-alueisiin. Redundanssi ja varmuuskopiot eivät ole sama asia. Redundanssi auttaa ehkäisemään keskeytyksiä. Varmuuskopiot mahdollistavat palautumisen menetyksen, vioittumisen tai hyökkäyksen jälkeen.

ISO/IEC 27002:2022 -kontrollin 5.29 Tietoturvallisuus häiriötilanteissa osalta Zenith Controls näyttää laajemman profiilin: ennaltaehkäisevä ja korjaava, joka kattaa luottamuksellisuuden, eheyden ja saatavuuden, linjautuu Protect- ja Respond-toimintoihin, tukee jatkuvuutta ja liittyy Protection- ja Resilience-alueisiin. Tämä on olennaista kiristyshaittaohjelmasta palautumisessa, koska palautus ei saa synnyttää uusia tietoturvapuutteita, kuten haavoittuvien levykuvien palauttamista, lokituksen ohittamista tai liiallisten käyttöoikeuksien uudelleenaktivointia.

Käytännön opetus on yksinkertainen. Palautustesti ei ole yksi erillinen kontrolli. Se on näyttöä koko häiriönsietoketjusta.

Piilossa oleva auditointiaukko: RTO ja RPO ilman näyttöä

Yksi yleisimmistä jatkuvuusauditointien havainnoista on kuilu dokumentoitujen RTO/RPO-tavoitteiden ja todellisen palautuskyvykkyyden välillä.

Liiketoiminnan jatkuvuussuunnitelmassa voi lukea, että asiakasportaalin RTO on neljä tuntia ja RPO yksi tunti. Varmuuskopiointialusta voi ajaa varmuuskopion tunnin välein. Ensimmäisessä realistisessa palautusharjoituksessa tiimi kuitenkin huomaa, että tietokannan palautus kestää kolme tuntia, DNS-muutokset vaativat vielä tunnin, sovellusvarmenne on vanhentunut eikä identiteetti-integraatiota ole koskaan sisällytetty palautusohjeeseen. Todellinen palautumisaika on kahdeksan tuntia.

Dokumentoitu RTO oli fiktiota.

Clarysecin Liiketoiminnan jatkuvuus- ja katastrofipalautuskäytäntö pk-yrityksille [BCDR-SME], osio Hallinnointivaatimukset, käytäntölauseke 5.2.1.4, tekee jatkuvuusvaatimuksesta eksplisiittisen:

Recovery Time Objectives (RTOs) ja Recovery Point Objectives (RPOs) kullekin järjestelmälle

Tämä on tärkeää, koska ”palauta kriittiset palvelut nopeasti” ei ole mitattavissa. ”Palauta maksujen hyväksyntätietokanta neljässä tunnissa siten, että tietohävikki on enintään yksi tunti” on mitattavissa.

Sama Liiketoiminnan jatkuvuus- ja katastrofipalautuskäytäntö pk-yrityksille, osio Käytännön toteutusvaatimukset, käytäntölauseke 6.4.2, muuttaa testauksen parantamiseksi:

Kaikki testitulokset on dokumentoitava, ja opit on kirjattava ja käytettävä BCP:n päivittämiseen.

Epäonnistunut palautus ei automaattisesti ole auditointikatastrofi. Epäonnistunut palautus ilman dokumentoitua oppia, omistajaa, korjausta ja uusintatestiä on.

Yritysympäristöihin Clarysecin Varmuuskopiointi- ja palautuskäytäntö [BRP] tarjoaa muodollisemman hallinnoinnin. Osiossa Hallinnointivaatimukset, käytäntölauseke 5.1, siinä todetaan:

Päävarmuuskopiointiaikataulu on ylläpidettävä ja katselmoitava vuosittain. Sen on määritettävä:

Tämä avausvaatimus määrittää keskeisen hallinnointiaineiston. Päävarmuuskopiointiaikataulun on yksilöitävä järjestelmät, tietoaineistot, varmuuskopiointitiheys, säilytys, sijainti, omistajuus, luokittelu, riippuvuudet ja testausrytmi.

Sama Varmuuskopiointi- ja palautuskäytäntö, osio Hallinnointivaatimukset, käytäntölauseke 5.2, yhdistää varmuuskopiointiodotukset liiketoimintavaikutuksiin:

Kaikkien järjestelmien ja sovellusten, jotka on luokiteltu kriittisiksi tai vaikutukseltaan suuriksi liiketoimintavaikutusten arvioinnissa (BIA), on:

Tässä BIA ja varmuuskopioinnin hallinnointi kohtaavat. Kriittiset ja vaikutukseltaan suuret järjestelmät edellyttävät vahvempaa palautusvarmuutta, tiheämpää testausta, parempaa riippuvuuskartoitusta ja kurinalaisempaa näyttöä.

Yksi näyttömalli ISO 27001:2022-, NIS2-, DORA-, NIST- ja COBIT 2019 -tarpeisiin

Vaatimustenmukaisuustiimit kamppailevat usein viitekehysten päällekkäisyyden kanssa. ISO 27001:2022 edellyttää riskiperusteista kontrollien valintaa ja näyttöä. NIS2 odottaa kyberturvallisuuden riskienhallintatoimenpiteitä, mukaan lukien liiketoiminnan jatkuvuus. DORA odottaa ICT:n operatiivista häiriönsietokykyä, reagointia ja palautumista, varmuuskopiointi- ja palautusmenettelyjä sekä digitaalisen operatiivisen häiriönsietokyvyn testausta. NIST ja COBIT 2019 käyttävät jälleen erilaista kieltä.

Ratkaisu ei ole rakentaa erillisiä varmuuskopiointiohjelmia jokaiselle viitekehykselle. Ratkaisu on rakentaa yksi näyttömalli, jota voidaan tarkastella useista auditointinäkökulmista.

NIS2:n osalta suorin viittaus on Article 21 kyberturvallisuuden riskienhallintatoimenpiteistä. Article 21(2)(c) sisältää nimenomaisesti liiketoiminnan jatkuvuuden, kuten varmuuskopioinnin hallinnan, katastrofipalautuksen ja kriisinhallinnan. Myös Article 21(2)(f) on olennainen, koska se käsittelee toimintaperiaatteita ja menettelyjä kyberturvallisuuden riskienhallintatoimenpiteiden tehokkuuden arvioimiseksi. Palautustestaus on juuri tätä: näyttöä siitä, että toimenpide toimii.

DORA:n osalta vahvimmat yhteydet ovat Article 11 reagoinnista ja palautumisesta, Article 12 varmuuskopiointikäytännöistä ja -menettelyistä sekä palautusmenettelyistä ja -menetelmistä, ja Article 24 digitaalisen operatiivisen häiriönsietokyvyn testauksen yleisistä vaatimuksista. Rahoitusalan toimijoille pelkkä tietokannan palautustesti voi olla riittämätön, jos liiketoimintapalvelu riippuu pilvi-identiteetistä, maksuyhdyskäytäväyhteyksistä, ulkoistetusta hostingista tai hallitusta valvonnasta. DORA-tyylisen näytön on oltava palvelutasolla, ei vain palvelintasolla.

Tässä näkyy yhtenäisen vaatimustenmukaisuusstrategian tehokkuus. Maksujärjestelmän neljännesvuosittainen palautustesti voi tukea ISO 27001:2022 liite A:n näyttöä, NIS2:n jatkuvuusodotuksia, DORA:n ICT-palautusvaatimuksia, NIST CSF Recover -tuloksia ja COBIT 2019 -hallinnointiraportointia, jos näyttö on rakenteistettu oikein.

Käytännön palautustesti, josta syntyy auditointivalmis näyttö

Palataan Sarahin maanantaiaamun tilanteeseen, mutta kuvitellaan, että organisaatio on valmistautunut Clarysecin työkalupakilla.

Maksujen hyväksyntäalusta on luokiteltu BIA:ssa kriittiseksi. Hyväksytty RTO on neljä tuntia. Hyväksytty RPO on yksi tunti. Alusta riippuu tietokantaklusterista, identiteetintarjoajasta, salaisuusholvista, lokitusputkesta, DNS:stä, varmenteista ja lähtevän sähköpostin välityspalvelusta.

Sarahin tiimi rakentaa neljännesvuosittaisen palautustestin kuuden vaiheen ympärille.

Vaihe 1: Vahvista soveltamisala ja riippuvuudet

Käyttäen Zenith Blueprint -vaihetta 2 Sarah vahvistaa, että maksualusta, tietokanta, identiteetti-integraatio, varmuuskopiointi-infrastruktuuri ja palautusympäristö kuuluvat ISMS:n soveltamisalaan. Lakitoiminto vahvistaa sääntelyrelevanssin. Talous vahvistaa liiketoimintavaikutuksen. IT vahvistaa riippuvuudet.

Tämä estää klassisen virheen, jossa palautetaan vain tietokanta mutta sivuutetaan todennuspalvelu, jota sovelluksen käyttö edellyttää.

Vaihe 2: Kytke testi riskirekisteriin

Käyttäen Zenith Blueprint -vaihetta 11 riskirekisteri sisältää skenaarion: ”Maksujen hyväksyntäalustan tietojen menetys tai salaus estää maksutoiminnot ja aiheuttaa sääntelyyn liittyvän altistumisen.”

Nykyisiin kontrolleihin sisältyvät päivittäiset varmuuskopiot, muuttumaton pilvitallennus, usean sijainnin varmuuskopiot, neljännesvuosittainen palautustestaus ja dokumentoidut palautusohjeet. Riskinomistaja on infrastruktuurista vastaava johtaja. Liiketoimintavastaava on Finance Operations. Käsittelypäätös on riskin lieventäminen.

Vaihe 3: Kartoita käsittely SoA:han

Käyttäen Zenith Blueprint -vaihetta 13 SoA kartoittaa riskin ISO/IEC 27001:2022 liite A:n kontrolleihin 8.13, 5.30, 8.14 ja 5.29. SoA selittää, että varmuuskopiointitestaus tuottaa korjaavan palautuskyvykkyyden, ICT-jatkuvuusmenettelyt tukevat liiketoiminnan jatkuvuutta, redundanssi vähentää katkoksen todennäköisyyttä ja tietoturva häiriön aikana estää turvattomat palautuksen oikopolut.

Vaihe 4: Käytä käytäntölausekkeita testikriteereinä

Tiimi käyttää Varmuuskopiointi- ja palautuskäytäntö pk-yrityksille -lauseketta 5.3.3 neljännesvuosittaiseen palautustestaukseen, lauseketta 8.2.2 näytön säilyttämiseen ja lauseketta 6.3.1.1 usean sijainnin tallennukseen. Se käyttää Liiketoiminnan jatkuvuus- ja katastrofipalautuskäytäntö pk-yrityksille -lauseketta 5.2.1.4 RTO/RPO-tavoitteisiin ja lauseketta 6.4.2 oppeihin ja BCP-päivityksiin.

Vaihe 5: Suorita palautus ja kirjaa tosiasiat

Palautus tehdään eristetyssä palautusympäristössä. Tiimi kirjaa aikaleimat, varmuuskopiosarjojen tunnisteet, palautusvaiheet, virheet, validointitulokset ja hyväksynnät.

Vahvan palautustestitallenteen on sisällettävä:

Testin aikana tiimi havaitsee yhden ongelman. Palautettu sovellus ei voi lähettää ilmoitussähköposteja, koska sähköpostin välityspalvelun sallittujen luettelo ei sisällä palautusaliverkkoa. Maksujen hyväksynnän ydintoiminto toimii, mutta työnkulku on heikentynyt.

Vaihe 6: Kirjaa opit ja korjaavat toimenpiteet

Tässä moni organisaatio pysähtyy liian aikaisin. Clarysecin lähestymistapa vie ongelman parantamisjärjestelmään.

Auditointi-, katselmointi- ja parantamisvaiheessa, vaihe 29, Jatkuva parantaminen, Zenith Blueprint käyttää CAPA-lokia ongelman kuvauksen, juurisyyn, korjaavan toimenpiteen, omistajan, tavoitepäivän ja tilan seuraamiseen.

Tämä yksittäinen palautustesti tuottaa nyt auditointivalmiin näyttöketjun: käytäntövaatimus, soveltamisalan vahvistus, riskikartoitus, SoA-kartoitus, testisuunnitelma, suoritustallenne, liiketoiminnan validointi, tietoturvavalidointi, ongelmatallenne, korjaava toimenpide ja BCP-päivitys.

Miten eri auditoijat tarkastavat samaa näyttöä

Vahva näyttöpaketti ennakoi auditoijan näkökulman.

ISO 27001:2022 -auditoija aloittaa yleensä hallintajärjestelmästä. Hän kysyy, ovatko varmuuskopiointi- ja palautusvaatimukset soveltamisalassa, riskiperusteisia, toteutettuja, seurattuja, sisäisesti auditoituja ja parannettuja. Hän odottaa jäljitettävyyttä riskirekisteristä SoA:han ja operatiivisiin tallenteisiin. Hän voi myös yhdistää epäonnistuneet testit ja korjaavat toimenpiteet ISO/IEC 27001:2022 -standardin lausekkeeseen 10.2 poikkeamista ja korjaavista toimenpiteistä.

DORA-arvioija keskittyy ICT:n operatiiviseen häiriönsietokykyyn kriittisissä tai tärkeissä toiminnoissa. Hän haluaa nähdä palvelutason palautumisen, kolmannen osapuolen ICT-riippuvuudet, skenaariopohjaisen testauksen, hallintoelimen valvonnan ja näytön siitä, että palautusmenettelyt ovat tehokkaita.

NIS2-valvontanäkökulma etsii asianmukaisia ja oikeasuhtaisia kyberturvallisuuden riskienhallintatoimenpiteitä. Varmuuskopiointi- ja katastrofipalautusnäytön on osoitettava, että keskeiset tai tärkeät palvelut voivat ylläpitää tai palauttaa toiminnan poikkeamien jälkeen ja että johto on tietoinen jäännösriskistä.

NIST-suuntautunut arvioija keskittyy kyberturvallisuustuloksiin Identify-, Protect-, Detect-, Respond- ja Recover-toiminnoissa. Hän voi kysyä muuttumattomista varmuuskopioista, etuoikeutetusta pääsystä varmuuskopiointitietovarastoihin, palautuksesta puhtaisiin ympäristöihin, viestinnästä ja opeista.

COBIT 2019- tai ISACA-tyylinen auditoija painottaa hallinnointia, prosessinomistajuutta, mittareita, johdon raportointia ja ongelmien seurantaa. Teknisesti elegantti palautus ei vakuuta häntä, jos omistajuus ja raportointi ovat epäselviä.

Sama näyttö voi täyttää kaikki nämä näkökulmat, mutta vain jos se on täydellistä.

Yleiset palautustestauksen epäonnistumiset, jotka synnyttävät auditointihavaintoja

Clarysec näkee toistuvasti samoja ehkäistävissä olevia näyttöaukkoja.

Tavoite ei ole byrokratia. Tavoite on luotettava palautuminen paineen alla ja puolustettavissa oleva näyttö auditoinnissa.

Rakenna hallitustason palautusnäyttöpaketti

Ylin johto ei tarvitse raakamuotoisia varmuuskopiolokeja. Se tarvitsee varmuuden siitä, että kriittiset palvelut ovat palautuskelpoisia, poikkeukset tunnetaan ja parantamistoimenpiteet etenevät.

Raportoi jokaisesta kriittisestä palvelusta:

• Palvelun nimi ja liiketoimintavastaava
• Kriittisyys BIA:n perusteella
• Hyväksytty RTO ja RPO
• Viimeisimmän palautustestin päivämäärä
• Saavutettu RTO ja RPO
• Testitulos
• Avoimet korjaavat toimenpiteet
• Palautumiseen vaikuttavat kolmannen osapuolen riippuvuudet
• Jäännösriskilausuma
• Seuraava suunniteltu testi

Tällainen raportointi rakentaa sillan teknisten tiimien, auditoijien ja johdon välille. Se tukee myös ISMS:n johdon katselmointia sekä häiriönsietokyvyn valvontaa NIS2:n ja DORA:n mukaisesti.

Käytännön auditointitarkistuslista seuraaville 30–90 päivälle

Jos auditointi lähestyy, aloita jo olemassa olevasta näytöstä ja sulje ensin suurimman riskin aukot.

• Tunnista kaikki kriittiset ja vaikutukseltaan suuret järjestelmät BIA:sta.
• Vahvista RTO ja RPO jokaiselle kriittiselle järjestelmälle.
• Varmista, että jokainen kriittinen järjestelmä sisältyy päävarmuuskopiointiaikatauluun.
• Vahvista varmuuskopioiden sijainnit, mukaan lukien paikalliset, pilvipohjaiset, muuttumattomat tai eriytetyt tietovarastot.
• Valitse vähintään yksi tuore palautustesti kutakin kriittistä palvelua kohden tai aikatauluta testi välittömästi.
• Varmista, että palautustestien tallenteissa näkyvät soveltamisala, aikaleimat, varmuuskopiosarja, tulos, saavutettu RTO/RPO ja validointi.
• Hanki liiketoimintavastaavan hyväksyntä sovellustason palautumiselle.
• Validoi tietoturva palautuksen jälkeen, mukaan lukien pääsynhallinta, lokitus, seuranta, salaisuudet, varmenteet ja haavoittuvuuksille altistuminen.
• Kartoita näyttö riskirekisteriin ja SoA:han.
• Kirjaa ongelmat CAPA:an, nimeä omistajat ja seuraa uusintatestiä.
• Tee tuloksista yhteenveto johdon katselmointia varten.
• Valmistele ristiinvaatimustenmukaisuuden näkymä ISO 27001:2022-, NIS2-, DORA-, NIST CSF- ja COBIT 2019 -auditointikeskusteluihin.

Jos et pysty suorittamaan kaikkia kohtia ennen auditointia, ole läpinäkyvä. Auditoijat suhtautuvat yleensä paremmin dokumentoituun aukkoon ja korjaavien toimenpiteiden suunnitelmaan kuin epämääräisiin väitteisiin kypsyystasosta.

Tee palautustestauksesta vahvin häiriönsietokykysi näyttö

Varmuuskopiointi- ja palautustestaus on yksi selkeimmistä tavoista osoittaa operatiivinen häiriönsietokyky. Se on konkreettista, mitattavaa, liiketoimintarelevanttia ja suoraan yhteydessä ISO 27001:2022-, NIS2-, DORA-, NIST- ja COBIT 2019 -vaatimuksiin, hallitusraportointiin, asiakkaiden varmennuksiin ja vakuuttajien odotuksiin.

Mutta vain, jos se dokumentoidaan asianmukaisesti.

Clarysec auttaa organisaatioita muuttamaan varmuuskopiointioperaatiot auditointivalmiiksi näytöksi Varmuuskopiointi- ja palautuskäytännön, Varmuuskopiointi- ja palautuskäytännön pk-yrityksille, Liiketoiminnan jatkuvuus- ja katastrofipalautuskäytännön pk-yrityksille, Zenith Blueprintin ja Zenith Controlsin avulla.

Seuraava käytännön askel on yksinkertainen. Valitse tällä viikolla yksi kriittinen palvelu. Suorita palautustesti sen hyväksyttyjä RTO- ja RPO-tavoitteita vasten. Dokumentoi tulos. Kartoita se riskirekisteriin ja SoA:han. Kirjaa jokainen oppi lokiin.

Jos haluat prosessin olevan toistettava ISO 27001:2022-, NIS2-, DORA-, NIST- ja COBIT 2019 -ympäristöissä, Clarysecin työkalupakki antaa rakenteen palautumisen osoittamiseen ilman, että rakennat vaatimustenmukaisuuslabyrinttia alusta alkaen.