Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

ISMS tai ISO27001 -projekti voi lähteä hyvin erilaisista lähtökohtista liikkeelle. Jotkut ovat tutustuneet standardiin, jotkut jo kirjoittaneet ensimmäisiä dokumentteja – joillekin taas tämä on ensikosketus ylipäätään mihinkään määrämuotoiseen tietoturvatyöskentelyyn. Yhteistä kaikille on kuitenkin asiakaskentästä tai toimintaympäristöstä tuleva vaatimus, jota on vaikea muulla tavoin täyttää kuin dokumentoidulla tietoturvan hallintajärjestelmällä. Lisäksi projektin alkuvaiheessa on tyypillistä myös jonkinlainen kuvitelma omista kyvyistä ja aikataulusta asioiden suhteen. Elina on jo kirjoittanut kehittämisen aloittamisesta ja koko hankkeen perusteluista aikaisemmassa blogissa, lue siitä tästä – ja  Saku on kirjoittanut tietoturvan johtamisesta, lue siitä tästä.

Ensimmäinen workshop

Workshop on tehokas työtapa. Workshopeissa istutaan joko virtuaalisesti tai samoissa tiloissa. Hyvä on varat kuitenkin sopivat tilat – joka virtuaalisessa tarkoittaa kaikilla toimivaa kameraa ja että kaikille on hyvät jaetut muistiinpanovälineet tai virtuaalinen whiteboard.

Mitä workshopeissa sitten tulisi käsitellä? Kokonaisuus rakentuu useasti monesta workshopista, mutta jostain on aloitettava. Alla on lista, josta lähdemme vähintäänkin liikkeelle.

  • Mikä on ISMS ja mikä on ISO27001
  • Tietoturvan tahtotila
  • Roadmap ja asetettujen tietoturvatavoitteiden saavuttaminen halutussa ajassa
  • Mitä pitää dokumentoida – pakolliset dokumentit
  • Toimialastandardit ja viitekehykset jotka ohjaavat yrityksen toimintaa
  • Yrityksen sertifiointitavoitteet – tavoitellaanko sertifiointia vai muuten vaan määrämuotoista toimintaa
  • ISMS asettamat minimivaatimukset ja miten niihin päästään
  • Vuosikello ja organisaatio
Ensimmäinen workshop
alkaa tästä
Seuraavat askeleet
Mitä yrityksemme tekeekään?

Monenlaista yrityskohtaista asiaa

Workshopeissa voidaan lisäksi käsitellä tarkemmin muun muassa seuraavia syventäviä otsikoita, kun perusasiat on hallinnassa.

  • Riskirekisteri, riskienhallinta ja miten se liittyy tietoturvaan
  • Auditoinnit, auditointien suunnittelu ja auditointien tavoitteet
  • Jatkuvuuden rooli tietoturvassa
  • Sovelluskehityksen ja tuotekehityksen tietoturvavaatimukset ja tavoitteet
  • Infrastruktuurin, pilven ja muun tuotantoympäristön tietoturvan vaatimukset ja tavoitteet
  • Tekniset ratkaisut: lokienhallinta, riskirekisteri, insidenttienhallinta, haavoittuvuuskannaus, koodiskannaus
  • Omien kyvykkyyksien tunnistaminen ja pohdinta siitä, mitkä asiat voi ostaa palveluna nyt ja jatkossa

Workshopien aihealueet vaihtelevat toimialan mukaisesti ja toteutus tehdään yrityksen oman sisäisen kypsyyden ehdoilla.

Pakolliset dokumentit -keskustelu

Workshop -työskentely auttaa myös rakentamaan hallintajärjestelmän scopea – koko toimintaa ei tarvitse tuoda yhdellä kertaa hallintajärjestelmän piiriin. Tämä on ajankohtaista yrityksissä jossa on monenlaista toimintaa, joka olennaisesti poikkeaa toisistaan – esimerkkinä fyysinen kauppa ja logistiikka sekä tietojärjestelmien kehittäminen ja hallinto yhdessä ja samassa yrityksessä.

Mutta entä ne pakolliset dokumentit. Pakolliset dokumentit on monen pettymykseksi aika hähmäinen kokonaisuus. Pakolliset dokumentit ja niiden pakollinen sisältö kun muodostuu – yllättäen ei valmiista templateista – vaan yrityksen ja liiketoiminnan tarpeista ja vaatimuksista. Sertifiointiauditoinneissa tarkastellaan asioita näkökulmasta jossa arvioidaan tietoturvan hallintajärjestelmän realistiset ja tarpeelliset vastaukset ja toimenpiteet niihin asioihin, mitkä ovat yrityksessä kriittisiä ja riippuvaisia tietoturvasta. Se, valmistatko softaa vai meridieseleitä vaikuttaa siis merkittävästi siihen, miten tietoturvan hallintajärjestelmä muodostuu.

Dokumentit
Kasoittain dokumenttaja

Miten liiketoiminta ja tekniset kontrollit liittyvät toisiinsa?

Yritän vielä avata tätä asiaa, joka nyt vielä saattaa vaikuttaa ympäripyöreältä konsulttijargonilta. Oikeanlaiseen tekemiseen ja projektin kokonaisuuden mallintamiseen päästään helpoiten ajattelemalla ketjua jonka avaan tässä alla. Ketjua kuljetaan ylös tai alas ja löydetään oikeita vastauksia.

LIIKETOIMINTA JA STRATEGIA

Tapa jolla yritys tuottaa tai on tarkoitus tuottaa omistajilleen arvoa

SCOPE

Mitkä asiat liiketoiminnasta ja/tai yrityksestä halutaan olevan tietoturvan hallintajärjestelmässä mukana ja katettuna

SECURITY OBJECTIVES

Tietoturvan tavoitetila eli mitkä asiat ovat tietoturvan näkökulmasta olennaisia, jotta scopessa oleva strategia voi toteutua ja scopessa oleva liiketoiminta voi tuottaa arvoa

ASSETS

Kaikki ne materiaaliset ja immateriaaliset varat jotka ovat olennaisia liiketoiminnan tekemisen kannalta sekä tietoturvan tavoitetilan kannalta

RISKIT JA RISKIREKISTERI

Listatut ja vakavuusarvioidut riskit jotka toteutuessaan uhkaavat niitä materiaalisia ja immateriaalisia varoja, joiden varassa liiketoiminta ja tietoturvan tavoitetilat lepäävät

KONTROLLIT

Annex A, eli ISO27002 listasta jokaisen kontrollin on vastattava asianmukaisesti ja arvioitujen riskien suuruuksien mukaisesti siitä, miten kutakin assettia turvataan ja suojataan

Kuten näemme, ottamalla jonkun yksittäisen kontrollin irti kontekstista – ”salasanan on oltava 16 merkkiä” – ei välttämättä vastaa mihinkään oikeaan kysymykseen ylläolevassa arvoketjussa. Miksi sen on oltava määritellynkaltainen, missä järjestelmissä kontrollin on oltava niin kun on määrätty, mitä tällä kontrollilla tällaisenaan suojataan ja mitä faktista riskiä sillä taklataan. 

Entä jos tunnistamme assetin jolla ei ole riskejä? Entä jos tunnistamme riskin, mutta emme ole listanneet assettia? Jos teemme liiketoimintaa, asseteilla jotka eivät ole tiedossa teemme käytännössä tiedä niihin liittyviä riskejä, meillä ei voi olla mitään käsitystä konkreettisista tietoturvatavoitteista.

Kaikki asiat liittyvät toisiinsa. Iteratiiviselle prosessille on annettava aikaa. Liiketoiminta on todennäköisesti monimutkaisempaa kuin mitä workshopiin tullessa muistikaan. Konsultti osaa monesti kysyä kysymyksiä, joita ei ole aikoihin pohdittu – myös liiketoiminnasta. Suuria riskejä voivat olla itsestäänselvyydet, jotka ei arkisin tule edes mieleen.

Tarvitaanko konsultteja mihinkään?

Mikään ei vaadi tai edellytä konsulttien käyttöä, jokainen yritys voi yllä esitetyllä agendalla myös työstää asioita itse. Workshopit järjestetään kuitenkin yleensä konsulttivetoisesti seuraavista syistä

  • Ulkopuolinen ja neutraali näkemys kokonaisuuteen
  • Kokemus siitä, ”kannattaako tehdä näin vai näin”
  • Seuraavien vaiheiden toimenpidesuunnitelmat saadaan nopeasti ja ajallaan
  • Toiminta on heti organisoitunutta
  • Omaa aikaa ei yksinkertaisesti ole
  • Valmiita hyvässä voissa paistettuja näkemyksiä ja aihioita työstettäväksi

Työmäärät kokonaisprojektissa on aina hirveän vaikea arvioida. Mitä enemmän asiakasyritys itse panostaa ja tekee, sitä vähemmän tietenkin konsultille jää tehtäväksi. Jotkut tekevät projektinsa ilman konsultteja, jotkut lataavat kirjoittamisen ja prosessien mallintamisen ulkopuoliselle. Asiakkaan täytyy kuitenkin aina omistaa oma hallintajärjestelmänsä – vastaavasti kuten pakolliset dokumentit -keskustelussa löytyy projektista myös pakolliset omistajat -keskustelu. 

Jos yritys tekee yhtä palvelua ja sovellusta, yrityksen HR on kokonaisuudessaan toimitusjohtaja ja toimitusjohtaja on kokonaisuudessaan CISO ja tietoturvatoiminto, on tilanne hyvin erilainen kun jos yritys toimittaa monta tuotetta moneen maahan monella teknologialla ja toimitustavalla, kompleksisella organisaatiolla ja hajautetuilla yrityskulttuureilla. Hyviä arvioita konsulttityön määrälle voi olla ”enemmän kuin päivä ja vähemmän kuin viisi päivää viikossa”. Kannattaa pyrkiä joustavaan malliin, jossa konsultin työt mukailevat omaa vastaanottokykyä.

Alun jälkeen

Seuraavaksi pitää organisoitua, tehdä jonkinlainen projektisuunnitelma ja päättää mitä projektityö tulee tuottamaan. Kannattaa varautua siihen, että hallintajärjestelmän kehittäminen ja sen käyttöönotto – saaminen osaksi yrityksen toimintaa johdosta ruohonjuuritasolle – kestää aikansa. Kalenteriajassa puhutaan vähintään puolen vuoden ponnistuksesta jos halutaan saavuttaa sertifioitava kokonaisuus, taas kerrna riippuen organisaation monimutkaisuudesta ja nykyisestä kypsyystasosta. Vaikka dokumentteja ja prosesseja syntyisikin nopeammin, on kuitenkin vastaanottajina työntekijät – ihmiset- joiden pääasiallinen tehtävä ei kuitenkaan ole tietoturva, vaan ydinliiketoiminta tai tukiprosessit.

Arjessa pitää pyöriä liiketoiminnan lisäksi sitten muun muassa insidenttienhallinta, jatkuvuus ja myös osaamisen ylläpitäminen eli koulutus. Kaikki vaatii vähän tekemistä ja organisoitumista ja ”jatkuvaa parantamista”. 

ISMS – mikä se on ja mihin sitä tarvitaan?

Julkaisemme sarjan blogikirjoituksia, joissa käsitellään tietoturvallisuuden johtamista ja tietoturvaprosesseja. Luvassa on hyödyllistä asiaa kaikenkokoisille yrityksille, joilla on hallussaan luottamuksellista tietoa — missä tahansa muodossa — ja halu suojata niitä sekä tarve osoittaa suojaamisen tärkeys omassa liiketoiminnassaan.

Lue lisää »
Mint Security people

Tietoturvaprosessit

Tietoturvaprosessien kehittäminen & ISMS Tietoturvaprosessien kehittäminen lyhyesti Tietoturva liittyy olennaisena osana sekä ylläpidon että kehityksen eri vaiheisiin aina hankintapäätösten valmistelusta tuotannon ylläpitoon tai ulkoistamiseen. Tietoturvaprosesseja

Lue lisää »
Thomas

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

ota yhteyttä

Pyydä rohkeasti lisätietoa. Vastaamme todennäköisesti nopeammin kuin osasit kuvitella.