Mikä on ISMS? Yhdistä tietoturvatyö liiketoiminnan päätöksiin

Tietoturvatyö voi näyttää kiireiseltä olematta koordinoitua. Ohjelmistokehitys päivittää järjestelmiä, henkilöstöhallinto hoitaa lähtijät, hankinta arvioi toimittajia ja johto hyväksyy poikkeuksia. Tietoturvallisuuden hallintajärjestelmä (ISMS) yhdistää nämä toiminnot yhteisiin tavoitteisiin ja selkeään päätöksentekoprosessiin.

Toimitusjohtajalle tärkeä kysymys ei ole se, onko yrityksellä tarpeeksi tietoturva-asiakirjoja. Kysymys on siitä, pystyykö johto selittämään, mitä on suojattava, mitkä riskit ovat merkityksellisiä, kuka on vastuussa ja miksi nykyinen suojaustaso on hyväksyttävä. ISMS tekee näistä vastauksista toistettavia liiketoiminnan muuttuessa.

Mitä ISMS todella hallitsee

Tietoturvallisuuden hallintajärjestelmä on organisaation järjestelmä tietoturvariskien hallintaan. Siihen kuuluvat vastuut, politiikat, prosessit, resurssit, hallintakeinot ja arviointi. Ohjelmistot voivat tukea sitä, mutta ohjelmisto ei ole järjestelmä. Asiakirjakirjasto voi kuvata sitä, mutta pelkät asiakirjat eivät osoita, että se toimii.

Sen tarkoitus on suojata tiedon kolmea ominaisuutta:

• Luottamuksellisuus: tieto on vain valtuutettujen henkilöiden ja järjestelmien saatavilla.
• Eheys: tieto pysyy oikeana ja täydellisenä ja on suojattu asiattomilta muutoksilta.
• Saatavuus: valtuutetut käyttäjät saavat tiedon ja voivat käyttää tukipalveluja tarvittaessa.

Nämä ominaisuudet muuttuvat liiketoiminnan huolenaiheiksi. Paljastuneet asiakastiedot voivat heikentää luottamusta ja synnyttää oikeudellisia velvoitteita. Virheelliset maksuohjeet voivat aiheuttaa taloudellisia menetyksiä. Käyttökatkossa oleva asiakastukialusta voi estää yritystä täyttämästä asiakassitoumuksiaan.

ISO/IEC 27001 asettaa tunnustetut vaatimukset rajatulle ISMS:lle. Kohdat 4–10 käsittelevät organisaation toimintaympäristöä, johtajuutta, suunnittelua, tukea, toimintaa, suorituskyvyn arviointia ja parantamista. Organisaatio voi kehittää ja ylläpitää ISMS:ää ennen kuin se hakee sertifiointia.

Hallintajärjestelmä luo yhteyden yksittäisten suojatoimien ja liiketoiminnan päätösten välille. Varmuuskopio on hallintakeino. Sen päättäminen, minkä on oltava palautettavissa, palautumiskyvyn rahoittaminen, sen testaaminen ja epäonnistuneisiin testeihin reagoiminen on hallintajärjestelmätyötä.

Miksi johto tarvitsee nämä yhteydet

Tietoturvapäätöksiä tehdään jo kaikkialla yrityksessä riippumatta siitä, kutsutaanko sitä ISMS:ksi. Joku valitsee SaaS-palveluntarjoajan, hyväksyy etuoikeutetun käyttöoikeuden, hyväksyy viivästyneen päivityksen tai sitoutuu asiakkaan palautumisvaatimukseen. Ilman yhteistä prosessia näissä päätöksissä voidaan käyttää eri oletuksia, eikä kukaan vastaa niiden yhteisvaikutuksesta.

ISMS antaa johdolle perustan rajallisten resurssien priorisointiin. Se auttaa tiimejä myös vastaamaan asiakkaiden kysymyksiin ylläpidettyjen kirjausten pohjalta sen sijaan, että käytännöt jouduttaisiin rekonstruoimaan jokaisessa myyntiarvioinnissa. Tämä ei takaa onnistunutta hankintatulosta, mutta tekee taustalla olevista väitteistä paremmin perusteltavissa olevia.

Yhteyksien tulee vastata käytännön kysymyksiin:

Nämä yhteydet ovat erityisen tärkeitä kasvun aikana. Epämuodolliset käytännöt, jotka toimivat, kun kaikki tuntevat toisensa, muuttuvat epäluotettaviksi, kun mukaan tulee uusia tiimejä, toimipisteitä, toimittajia ja asiakassitoumuksia.

Määritä liiketoimintaa vastaava soveltamisala

Aloita liiketoiminnan kontekstista, älä hallintakeinojen luettelosta. Tunnista organisaation tuottamat palvelut, niiden käyttämät tiedot, sidosryhmät ja niiden vaatimukset sekä tietoturvaan vaikuttavat sisäiset ja ulkoiset olosuhteet.

Soveltamisala määrittää ISMS:n rajan. Siinä tulee yksilöidä katetut toiminnot, organisaatioyksiköt, tarvittaessa toimipisteet, teknologia sekä rajapinnat liiketoiminnan muihin osiin. Hyödyllinen ensimmäinen soveltamisala voi kattaa yhden asiakkaille suunnatun tuotteen ja sen toimitusoperaatiot sen sijaan, että se kattaisi kaiken yrityksen toiminnan.

Rajattu soveltamisala ei kuitenkaan voi sivuuttaa riippuvuuksia. Jos henkilöstöhallinto käynnistää lähtöprosessin työntekijöille, joilla on pääsy tuotteeseen, tämä rajapinta on merkityksellinen. Jos pilvipalvelujen tarjoaja ylläpitää palvelua, ulkoistaminen ei poista riippuvuutta. Jos asiakastuki vie asiakastietoja, vientiprosessi kuuluu analyysiin.

Kirjoita soveltamisalan kuvaus ja haasta se sitten kolmella kysymyksellä:

• Ymmärtäisikö asiakas, mikä kuuluu soveltamisalaan ja mikä ei?
• Olemmeko sisällyttäneet riippuvuudet, jotka ovat tarpeen katetun palvelun suojaamiseksi?
• Pystyvätkö nimetyt omistajat ylläpitämään järjestelmää tämän rajan sisällä?

Pienestä aloittaminen on käytännön suositus, ei lupa luoda harhaanjohtava raja. Selkeä soveltamisala vastuullisine omistajineen on vahvempi kuin laaja rekisteri, jota kukaan ei päivitä. Laajenna harkitusti, kun uudet palvelut tai riippuvuudet sitä edellyttävät.

Osoita päätöksiä, älä pelkkiä tehtäviä

Ylimmän johdon on annettava suunta ja tuki ISO 27001 -standardin mukaiselle ISMS:lle. Koordinoinnin delegointi tietoturvavastaavalle ei siirrä johdon vastuuta prioriteeteista, resursseista ja hyväksyttävästä riskistä.

Erota toisistaan vastuut, jotka usein niputetaan yhden henkilön tehtäviksi:

Pienessä yrityksessä yhdelle henkilölle voidaan osoittaa useita vastuita. Silti on tunnistettava, missä roolissa henkilö kulloinkin toimii ja missä tarvitaan riippumatonta arviointia, erityisesti sisäisessä auditoinnissa.

Määritä eskalointikynnykset. Tiiminvetäjä voi hyväksyä lyhytaikaisen operatiivisen poikkeuksen sovituissa rajoissa; merkittäviä asiakassitoumuksia uhkaava riski voi edellyttää ylimmän johdon hyväksyntää. Kirjaa perustelut, ehdot, päättymispäivä ja katselmoinnin laukaisija. ”Johto hyväksynyt” ei riitä, jos kukaan ei pysty yksilöimään päätöksentekijää tai hyväksyttyä riskiä.

Tee riskiarvioinnista priorisointiprosessi

Riskiarvioinnin tulee kuvata uskottavia skenaarioita, ei pelkästään nimetä omaisuutta tai luetella heikkouksia. ”Asiakastietokanta” on omaisuuserä. ”Vaarantunut ylläpitäjätili mahdollistaa asiakastietojen massapoiminnan” on riskiskenaario, jolla on syy ja seuraus.

Laadi dokumentoitu arviointimenetelmä ja riskin hyväksymiskriteerit. ISO 27001 ei edellytä mitään tiettyä pisteytyskaavaa. Käytännön lähestymistapana määrittele todennäköisyys- ja vaikutusluokat kielellä, jonka päätöksentekijäsi ymmärtävät, mukaan lukien toiminnan häiriöt, taloudelliset menetykset, sopimusseuraamukset ja tarvittaessa yksilöille aiheutuva haitta.

Kirjaa jokaisesta olennaisesta skenaariosta:

• Palvelu, tiedot ja riippuvuudet, joihin se vaikuttaa.
• Uhka tai tapahtuma ja asiaankuuluvat haavoittuvuudet.
• Olemassa olevat hallintakeinot ja niiden tunnetut rajoitukset.
• Todennäköisyys, vaikutus ja niistä johtuva prioriteetti.
• Riskin omistaja ja ehdotettu käsittely.

Käsittely voi tarkoittaa riskin pienentämistä hallintakeinoilla, toiminnasta luopumista, riskin osien jakamista sopimusten tai vakuutusten kautta tai riskin hyväksymistä hyväksyttyjen kriteerien puitteissa. Vakuutus ei palauta menetettyjä tietoja, eikä toimittajasopimus poista organisaation vastuita.

Erota nykyinen riski käsittelyn jälkeisestä jäännösriskistä. Älä alenna riskiluokitusta vain siksi, että tehtävä on aikataulutettu. Arvioi uudelleen toteutuksen ja asianmukaisen toimintaa osoittavan näytön jälkeen. Hanki käsittelysuunnitelmalle ja jäännösriskin hyväksymiselle hyväksyntä määritellyltä päätöksentekijältä.

Operatiivisen riskirekisterin tulee pysyä päätöskirjauksena: mikä muuttui, miksi tietty käsittely valittiin ja milloin arvio on katselmoitava.

Valitse hallintakeinot ja perustele niiden soveltuvuus

Hallintakeinot ovat toimenpiteitä, joilla riskiä muutetaan. Niihin kuuluvat tekniset suojatoimet, kuten monivaiheinen tunnistautuminen, organisatoriset prosessit, kuten toimittaja-arvioinnit, henkilöstöön liittyvät toimet, kuten koulutus, sekä laitteiden ja toimitilojen fyysinen suojaus.

ISO/IEC 27001:2022 -standardin liite A sisältää 93 viitehallintakeinoa: 37 organisatorista, 8 henkilöstöön liittyvää, 14 fyysistä ja 34 teknologista. Valinta perustuu riskeihin; organisaatio ei automaattisesti toteuta jokaista hallintakeinoa. ISO/IEC 27002 antaa toteutusohjeita, eikä se ole erillinen ISMS-sertifiointivaatimus.

ISO 27001:n osalta määritä riskien käsittelyyn tarvittavat hallintakeinot ja vertaa niitä liitteeseen A varmistaaksesi, ettei tarpeellisia hallintakeinoja ole jäänyt pois. Hallintakeinoja voidaan tarvita myös lakisääteisten tai sopimuksellisten vaatimusten vuoksi, eikä niiden tarvitse rajoittua liitteeseen A.

Soveltuvuuslausuntoon (Statement of Applicability) kirjataan tarpeelliset hallintakeinot, perustelut niiden sisällyttämiselle, toteutuksen tila ja perustelut liitteen A hallintakeinojen poisjättämiselle. Se on eri asia kuin riskien käsittelysuunnitelma: toinen selittää sovellettavat hallintakeinot, toinen riskien käsittelyyn tarvittavat toimenpiteet. Tutustu tähän viiterakenteeseen liitteen A hallintakeinoja käsittelevässä oppaassa.

Määritä jokaiselle valitulle hallintakeinolle omistaja, tavoiteltu tulos, toimintatapa ja näyttö, joka osoittaa vaikuttavuuden. ”Pääsynhallinta toteutettu” on vähemmän hyödyllinen kuin selkeä prosessi, joka kattaa hyväksynnän, käyttöoikeuksien myöntämisen, katselmoinnin ja poistamisen.

Politiikkojen tulee asettaa sääntöjä, joita ihmiset pystyvät noudattamaan. Menettelyjen tulee selittää toteutus. Kummassakaan ei pidä luvata katselmointeja tai teknisiä rajoituksia, joita organisaatio ei todellisuudessa pysty ylläpitämään.

Rakenna näyttö osaksi tavallista toimintaa

Näytön tulee syntyä työtä tehtäessä, ei tarinan uudelleenrakentamisesta ennen auditointia. Käyttöoikeuskatselmointi voi tuottaa päivätyn käyttäjäluettelon, tarkastajan päätökset, poistotiketit ja vahvistuksen siitä, että muutokset tehtiin. Palautumisharjoitus voi tuottaa testiolosuhteet, tulokset, havaitut rajoitukset ja jatkotoimenpiteet.

Kuvakaappaus voi näyttää asetuksen yhdellä hetkellä. Se ei välttämättä todista, että asetus kattaa jokaisen asiaankuuluvan järjestelmän tai pysyi vaikuttavana koko ajanjakson ajan. Tarkastajien tulee tarkastella näytön kattavuutta, päivämäärää, lähdettä, täydellisyyttä ja sitä, mitä johtopäätöstä näyttö todella tukee.

Käytännöllinen ISMS-näyttökokonaisuus sisältää:

Jokainen rivi ei tarvitse erillistä asiakirjaa. Pieni organisaatio voi yhdistää kirjauksia, kunhan selkeys ja jäljitettävyys säilyvät. Suojaa myös itse näyttö: käyttäjävienneissä, poikkeamakirjauksissa ja kuvakaappauksissa voi olla arkaluonteisia tietoja, joten niille tarvitaan asianmukaiset käyttöoikeus- ja säilytysjärjestelyt.

Esimerkki: asiakastukialusta

Tarkastellaan kuvitteellista 30 hengen ohjelmistoyritystä, joka käyttää SaaS-asiakastukialustaa. Oletetaan, että alustalla on asiakkaiden nimiä, yhteystietoja, tikettihistorioita ja satunnaisia diagnostiikkaliitteitä. Henkilöstö käyttää henkilökohtaisia tilejä, ulkoinen palveluntarjoaja ylläpitää sovellusta ja joitakin tikettejä viedään vianmääritystä varten. Nämä ovat esimerkkioletuksia, eivät määrätty yritysmalli.

ISMS:n soveltamisala kattaa asiakastukitoiminnot ja niiden riippuvuudet: henkilöstön identiteetit, SaaS-toimittajan, päätelaitteiden käytön, viennit, säilytyksen ja palautumisjärjestelyt. Asiakastuen päällikkö omistaa palvelun; IT hoitaa pääsynhallinnan; hankinta koordinoi toimittaja-arvioinnin; johto hyväksyy riskit, jotka ylittävät delegoidut valtuudet.

Alustavassa arvioinnissa tunnistetaan kolme skenaariota:

Oletetaan, että tilien täsmäytyksessä havaitaan entisen työntekijän käyttöoikeuden olevan yhä voimassa. Välitön toimenpide on poistaa se ja arvioida, onko tiliä käytetty asiattomasti. Hallintajärjestelmän toimenpide on selvittää, miksi poisto epäonnistui. Ehkä henkilöstöhallinto ilmoitti IT:lle, mutta asiakastukisovellus puuttui lähtijän tarkistuslistasta.

Korjaava toimenpide päivittää sitten sovellusluettelon, lisää asiakastukialustan lähtöprosessiin, nimeää vahvistusvastuun ja tarkistaa seuraavat lähtötapaukset. Pelkkä poistotiketin sulkeminen korjaisi välittömän tilanteen poistamatta sen syytä.

Oletetaan nyt, että SaaS-toimittaja muuttaa alihankkijaluetteloaan. Toimittajasuhteen omistaja arvioi muutoksen sopimuksellisia, tietoturva- ja asiaankuuluvia tietosuojavaatimuksia vasten. Hän kirjaa, vaikuttaako muutos tietojen käsittelyyn, riippuvuuksiin tai hyväksyttyyn riskiin ja tarvitaanko asiantuntija-arviota. Muutoksella on omistaja ja katselmointipolku sen sijaan, että se jäisi lukematta yhteiseen postilaatikkoon.

Johto saa käsiteltäväkseen ratkaisemattomat päätökset: rahoitetaanko vahvempi varajärjestely, vähennetäänkö liitteisiin kerättäviä tietoja vai hyväksytäänkö määritelty jäljelle jäävä riski. Näin ISMS yhdistää operatiiviset havainnot liiketoiminnan valintoihin.

Ylläpidä rytmiä, joka havaitsee muutokset

Aikatauluta katselmoinnit riskin, muutostiheyden ja velvoitteiden mukaan. Viikoittainen puutekatselmointi käyttöönoton aikana ja säännöllinen johdon katselmointi voivat olla hyödyllisiä käytännön valintoja, mutta ne eivät ole ISO 27001:n määräämiä yleisiä aikavälejä. Standardi edellyttää sisäisiä auditointeja ja johdon katselmointeja suunnitelluin väliajoin.

Lisää tapahtumiin perustuvat laukaisijat: poikkeamat, suuret julkaisut, yritysostot, toimittajamuutokset, uudet lakisääteiset velvoitteet, merkittävät asiakassitoumukset ja auditointihavainnot. Pelkkä kalenteri ei huomaa tärkeitä muutoksia aikataulutettujen kokousten välillä.

Seurannassa kysytään, toimivatko hallintakeinot ja tavoitteet tarkoitetulla tavalla. Sisäinen auditointi arvioi, onko ISMS vaatimusten mukainen ja onko se toteutettu ja ylläpidetty vaikuttavasti. Johdon katselmointi tarkastelee järjestelmän soveltuvuutta, riittävyyttä ja vaikuttavuutta ja tekee päätöksiä muutoksista ja resursseista. Nämä toiminnot tukevat toisiaan, mutta ne eivät ole keskenään vaihdettavissa.

Johdon tulee saada päätöksentekoa tukevaa tietoa: olennaiset riskit, myöhässä olevat käsittelytoimet, toistuvat epäonnistumiset, auditointihavainnot, muuttuvat vaatimukset ja resurssirajoitteet. Valmiiden tehtävien laskeminen tarkastelematta tuloksia voi kätkeä heikon suorituskyvyn. ISMS-mittareita käsittelevä opas tarkastelee hyödyllisiä mittareita.

Myös poikkeamien hallinta kuuluu tähän sykliin. Määrittele ilmoitusreitit, arviointikriteerit, reagointivastuut, viestintävaltuudet ja palautumisjärjestelyt. Testaa yhteydenottopolut ja päätöksenteko harjoituksilla. Arvioi sovellettavat ilmoitusvelvoitteet sen sijaan, että olettaisit yhden määräajan kattavan jokaisen poikkeaman.

Tietoturvapoikkeaman tai vaatimustenvastaisuuden jälkeen korjaa välitön ongelma, selvitä syyt, toteuta korjaava toimenpide ja arvioi sen vaikuttavuus. Toistuvat havainnot ovat syy harkita uudelleen prosessin suunnittelua tai resursseja, ei pelkästään toistaa samaa muistutusta.

Erota ISMS, sertifiointi ja lakisääteiset velvoitteet toisistaan

ISMS on järjestelmä, jota organisaatio ylläpitää. ISO 27001 on standardi, jota vasten järjestelmää voidaan arvioida. Sertifikaatin myöntää riippumaton sertifiointielin, ei ISO tai Secani, ja se koskee ilmoitettua soveltamisalaa.

Sertifiointi voi olla hyödyllinen varmennuskeino, kun asiakkaat tai muut sidosryhmät sitä edellyttävät. Se ei todista, että jokainen yrityksen toiminto on katettu, että jokainen hallintakeino toimii aina tai ettei poikkeamia voi tapahtua. Tarkista soveltamisala ja tila sen sijaan, että pitäisit sertifikaattia koko yrityksen kattavana tietoturvatakuuna.

Lakisääteinen soveltuvuus edellyttää erillistä analyysia. Yleisen tietosuoja-asetuksen (GDPR) 32 artikla edellyttää asianmukaisia teknisiä ja organisatorisia turvatoimia asiaankuuluvien riskien perusteella. NIS2-direktiivi käsittelee kansallisen täytäntöönpanon kautta soveltamisalaan kuuluvien yhteisöjen johdon valvontaa, riskienhallintatoimenpiteitä ja poikkeamista ilmoittamista.

ISMS voi järjestää näitä velvoitteita tukevan näytön ja vastuut, mutta sertifiointi ei osoita GDPR:n tai NIS2:n noudattamista. Ei myöskään pidä paikkaansa, ettei ISMS voisi koskaan olla lakisääteisesti vaadittu: sovellettavat kansalliset tai toimialakohtaiset säännöt on tarkistettava.

Vältä kolme ennustettavaa toteutuksen epäonnistumista

Mallipohjien käyttöönotto muuttamattomina. Mallipohjat voivat antaa rungon, mutta omistajien on tarkistettava jokainen sitoumus todellista käytäntöä vasten. Politiikka, joka edellyttää katselmointeja, joita kukaan ei tee, luo hallitsemattoman puutteen.

Rajan vetäminen niin, ettei kukaan pysty ylläpitämään sitä. Kunnianhimoinen luettelo ei ole hyödyllinen, jos omistajuus ja riippuvuudet ovat epäselviä. Aloita perusteltavissa olevasta palvelurajasta ja laajenna sitten selkeän suunnitelman mukaisesti.

Sertifioinnin pitäminen maaliviivana. Järjestelmän on jatkettava toimintaansa henkilöstömuutosten, toimittajamuutosten, poikkeamien ja uusien tuotteiden läpi. Budjetoi ylläpitoon, katselmointiin ja parantamiseen, ei pelkästään alkuvaiheen dokumentointiin.

Tähän liittyvä varoitus koskee katselmoimatonta automaatiota. Automaattisesti kerätyt kirjaukset ja tekoälyn tuottamat tiivistelmät voivat tukea työtä, mutta ihmisten on silti arvioitava merkityksellisyys, arvioitava puutteet ja hyväksyttävä johtopäätökset.

Tee johdon ensimmäisestä päätöksestä konkreettinen

Valitse yksi edustava palvelu ja pyydä sen omistajaa tuomaan soveltamisalan kuvaus, riippuvuuskartta, alustavat riskiskenaariot, nykyiset hallintakeinot ja ratkaisemattomat päätökset. Sopikaa, kuka voi hyväksyä riskin, mitä resursseja on käytettävissä ja milloin edistymistä katselmoidaan. Näin syntyy hallittava lähtökohta ilman, että teeskennellään koko organisaation olevan jo katettu.

Secanin työtilamalli tukee tätä työnkulkua mallintamalla palvelut ja niitä tukevat kohdeobjektit, yhdistämällä näytön vaatimuksiin, hallintakeinoihin ja päätöksiin sekä nimeämällä omistajat ja katselmointivastuut. Tiimit voivat muuttaa puuttuvan näytön tai epäselvän omistajuuden tehtäviksi. Tekoälyavusteiset ehdotukset pysyvät luonnoksina ihmisen tarkastettavaksi, ja lähteet ja hyväksynnät pysyvät jäljitettävinä.

Seuraavan johdon keskustelun tulee siksi olla täsmällinen: minkä palvelun suojaamme ensin, mikä riski edellyttää päätöstä nyt ja mikä näyttö osoittaa, että päätös toimi?