Tämä kurssi on jo päättynyt.

Riskien arvioinnin ja hallinnan periaatteet

Järjestelmän osien ja kokonaisuuden näkökulmat

Riskienhallinta voidaan jakaa kahteen näkökulmaan: 1) osalähtöiseen riskienhallintaan (component-driven risk management), joka keskittyy teknisiin osiin ja niiden uhkiin ja haavoittuvuuksiin (tästä käytetään myös nimitystä alhaalta ylös) ja 2) järjestelmälähtöiseen riskienhallintaan (system-driven risk management), joka analysoi järjestelmän kokonaisuutena (tästä käytetään myös nimitystä ylhäältä alas). Suurin ero näiden kahden välillä on se, että osalähtöiset lähestymistavat keskittyvät yleensä yksittäisen osan riskiin (esim. laitteisto, ohjelmisto, data, henkilökunta), kun taas järjestelmälähtöiset lähestymistavat keskittyvät enemmän koko järjestelmän tavoitteisiin ja vaativat korkean tason tavoitteiden määrittelyä ja tästä seuraten alajärjestelmien ja eri osien vuorovaikutuksen ymmärtämistä.

Osalähtöinen ja järjestelmälähtöinen riskienhallinta täydentävät toisiaan. Järjestelmälähtöinen lähestymistapa määrittää kokonaisuuden tavoitteet ja myös sen, mitä ei ole tarkoitus tehdä. Se auttaa ymmärtämään paremmin järjestelmän eri osien välistä monimutkaisuutta ja osatekijöitä. Näihin voivat kuulua esim. ihmiset, teknologia ja organisaatioprosessit, joiden vuorovaikutukset ja riippuvuudet eivät ole triviaaleja. Osalähtöinen lähestymistapa tarkastelee esim. mitä kyvykkyyksiä ja toimintoja tarvitaan järjestelmän tavoitteiden saavuttamiseen ja tarkastelee riskien toteutumisen vaikutuksia yksittäisiin järjestelmän osiin (esim. laitteisto, ohjelmisto, data, henkilökunta).

Osalähtöiset riskienhallinnan menetelmät sopivat:

  • Yksittäisten teknisten komponenttien riskien analysointiin
  • Vähemmän monimutkaisten järjestelmien (joissa on selkeät komponenttien väliset yhteydet) purkamiseen
  • Työskentelyyn, kun järjestelmän fyysisestä toiminnasta on jo sovittu sidosryhmien kesken

Järjestelmälähtöiset riskienhallinnan menetelmät sopivat:

  • Kun tutkitaan tietoturvaloukkauksia, jotka johtuvat järjestelmän useiden osien vuorovaikutuksesta
  • Järjestelmän turvallisuusvaatimusten määrittämiseen ennen kuin järjestelmän fyysisistä ominaisuuksista on tehty päätöksiä
  • Kokoamaan yhteen useiden sidosryhmien näkemykset siitä, mitä järjestelmän pitäisi ja ei pitäisi tehdä (liittyen esim. fyysiseen turvallisuuteen, tietoturvallisuuteen, laillisuuteen)
  • Analysoimaan tietoturvaloukkauksia, joita ei voida jäljittää yhteen epäonnistuneeseen seikkaan (single point of failure)

Osa-tason riskit koskevat todennäköisesti enemmän operatiivisia työntekijöitä, joille osien toiminta on tärkeää, jotta työt voidaan tehdä ja tavoitteet saavuttaa. Järjestelmä-tason riskit ovat todennäköisesti tärkeämpiä johdolle, jotka tekevät päätöksiä koko järjestelmän strategioista. Haasteena on näiden näkökulmien yhdistäminen toimivaksi riskienhallinnaksi, johon kaikki voivat sitoutua.

Katso uudestaan esimerkkiä riskien arvioinnista ja riskienhallinnasta.

Mistä esimerkissä on kyse?
Mistä edellinen vastaus voidaan päätellä?

Riskien arvioinnin käsitteet

Haavoittuvuus
(vulnerability) on jotakin, jota vastaan voidaan hyökätä tai jota voidaan käyttää väärin, ja nämä voivat johtaa ei-toivottuun lopputulokseen. Jos haavoittuvuutta hyväksikäytetään, se voi vaikuttaa prosessiin tai järjestelmään. Haavoittuvuudet voivat olla monimuotoisia ja niihin voi sisältyä teknologia (esim. käyttöliittymä, joka hyväksyy virheellisen syötteen), ihmiset (esim. liiketoiminta kärsii henkilöresurssien puutteesta), lakiasiat (esim. tietokanta on haavoittuva ja jos tiedot paljastuvat, saadaan suuret sakot) jne. Tämä ei ole täydellinen esitys siitä, mitä haavoittuvuus voi olla, mutta korostaa, että haavoittuvuudet ovat sosioteknisiä eli usein niihin liittyvät sekä ihmiset että tekniset järjestelmät.
Uhka
(threat) on henkilö, tapahtuma tai toiminta, joka pystyy hyödyntämään haavoittuvuutta. Uhkat ovat myös sosioteknisiä ja voivat sisältää hakkereita, tyytymättömiä tai huonosti koulutettuja työntekijöitä, huonosti suunniteltuja ohjelmistoja, huonosti kuvattuja tai ymmärrettyjä toimintaprosesseja jne. Konkreettinen esimerkki, jolla erottaa haavoittuvuus uhkasta: käyttöliittymässä on haavoittuvuus, jossa haitallinen syöte voi saada ohjelman käyttäytymään ei-toivotulla tavalla (esim. poistamaan taulukoita järjestelmän tietokannasta), kun taas uhka on toiminto tai tapahtuma, joka hyödyntää haavoittuvuutta (esim. hakkeri, joka syöttää haitallisen syötteen käyttöliittymään).
Todennäköisyys
(likelihood) on mitta, joka mittaa mahdollisuuden, että uhka käyttää hyväkseen haavoittuvuutta ja aiheuttaa ei-toivotun lopputuloksen suojattavan kohteen arvoon. Todennäköisyys voi olla laadullinen (esim. alhainen, keskitaso, korkea) tai määrällinen arvo (esim. asteikko välillä 1-10 tai prosentti).
Vaikutus
(impact) on seuraus haavoittuvuutta hyödyntävästä uhasta, jolla on negatiivinen vaikutus niihin tavoitteisiin, joihin kohdistuvaa riskiä arvioidaan. Vaikutuksiin vaikuttaa tarkastelunäkökulma, esim. kun tarkastellaan toteutunutta riskiä järjestelmän osien ja kokonaisuuksien näkökulmista, järjestelmälähtöisestä eli kokonaisnäkökulmasta vaikutus oli, että uutta tuotetta ei onnistuttu valmistamaan ajoissa, kun taas osalähtöisestä näkökulmasta vaikutus oli, että yksi komponentti meni rikki.

Riskien arvioinnin ja hallinnan menetelmät

Riskien arviointiin ja hallintaan on olemassa useita standardeja ja ohjeita. Kaikkien niiden tavoitteena on tarjota systemaattinen tapa muuntaa haavoittuvuudet, uhat, todennäköisyydet ja vaikutukset järjestetyksi listaksi, jotta riskit voidaan priorisoida ja hoitaa. Kaikilla standardeilla on omat erityispiirteensä, mutta niillä on myös yhteisiä tekijöitä. Yhteiset piirteet on koottu alla olevaan kuvaan, ja ne löytyvät jossakin muodossa yleisimmistä riskien arviointiin ja hallintaan käytetyistä standardeista. Yhteiset piirteet ovat siis tietyllä tapaa riskien arviointiin ja hallintaan liittyviä periaatteita.


Riskienhallintajärjestelmän rakenne

  • Riskien tunnistaminen (pre-assessment) -vaiheessa tunnistetaan riski, riskiin liittyvät toimijat ja sidosryhmät, sekä riskiin liittyvät näkökulmat.
  • Riskien ja huolenaiheiden arviointi (appraisal) -vaiheessa riskin syyt ja seuraukset arvioidaan ja samalla kehitetään tietoa riskeistä ja lieventämisvaihtoehdoista (esim. ennaltaehkäisy, jakaminen jne.).
  • Luonnehdinta ja evaluointi (characterisation and evaluation) -vaiheessa tehdään päätöksiä riskin merkityksestä ja siitä, miten paljon riskiä voidaan sietää.
  • Riskienhallinta (management) -vaiheessa tehdään päätöksiä riskinhallintasuunnitelmasta ja sen toteuttamisesta, mukaan lukien riskinsietokyky (riskin hyväksyminen, välttäminen, vähentäminen, jakaminen, siirtäminen).

Kaikkiin neljään kuuluvat kuvassa keskellä näkyvät viestintä, sidosryhmien sitoutuminen ja asiayhteyden määrittely avoimen ja osallistavan vuoropuhelun kautta. On tärkeää huomata, että riskien arviointi ja hallinta on aina iteratiivinen prosessi, jota on tärkeää toteuttaa jatkuvasti, kun tilanteet ja toimintaympäristö muuttuvat. Kun tietoturvapoikkeamia tapahtuu, on tärkeää, että niistä otetaan opiksi, ja riskienhallintapolitiikkoja parannetaan.

Standardeja ja ohjeita riskien arviointiin ja hallintaan ovat esim. NIST SP-800-30 ja ISO/IEC 27005. Näiden prosesseista on kuvat alla. Molemmista löytyy vastaavuudet yllä esitettyihin vaiheisiin.


NIST SP-800-30 Risk Assessment Process

NIST SP800-30/39 ovat Yhdysvaltain hallituksen käyttämät riskien arviointi ja hallintamenetelmät ja niitä käytetään Yhdysvaltain valtion virastoissa. Niissä on selkeitä ohjaavia vaiheita tukemaan koko riskien arviointi- ja hallintaprosessia asiayhteyden määrittämisestä riskinsietokykyyn ja tehokkaaseen valvontaan. Ne ovat vapaasti saatavilla ja ISO-standardien mukaisia.


ISO/IEC 27005 Information security risk management

ISO/IEC 27005:2018 on kansainvälinen standardiohjeisto tietoturvallisuusriskien hallintaan. Siinä ei esitetä erityistä riskien arviointitekniikkaa. Standardi painottaa osalähtöisyyttä ja vaatii haavoittuvuuksien, uhkien ja vaikutusten määrittelyn.

Tutki jälleen esimerkkiä riskien arvioinnista ja riskienhallinnasta. Vertaa esimerkkiä riskien arvioinnin ja hallinnan menetelmiin. Valitse yksi tai useampi vaihtoehto.

Mikä esimerkissä vastaa riskien tunnistamista?
Mikä esimerkissä vastaa riskien ja huolenaiheiden arviointia?
Mikä esimerkissä vastaa luonnehdintaa ja evaluointia?
Mikä esimerkissä vastaa riskienhallintaa?
Mitä huomasit, kun vertasit esimerkkiä riskien arvioinnin ja hallinnan periaatteisiin?

Riskien arvioinnin ja hallinnan menetelmät kyberfyysisissä järjestelmissä

Perinteinen tietoturvallisuus (esim. pöytäkoneet, laitteet ja palvelimet) arvioi usein riskejä liittyen esim. pääsynvalvontaan (luottamuksellisuus), tietojen muuntumiseen (eheys) ja verkkokatkoksiin (saatavuus) ja yrittää minimoida näihin liittyvät riskit komponenttien ja järjestelmien sisällä. Kyberfyysisissä järjestelmissä ja operatiivisessa teknologiassa kiinnitetään yleensä enemmän huomiota myös fyysiseen turvallisuuteen. Kyberfyysiset järjestelmät ovat esim. teollisuusautomaation ohjausjärjestelmiä (industrial control systems, ICS), jotka ovat osa kriittistä kansallista infrastruktuuria (esim. energiahuolto, logistiikka ja vedenkäsittely). Ne voivat olla myös monimutkaisia ​​teollisuuden valmistusjärjestelmiä, joissa prosessit ovat liian raskaita, yksitoikkoisia tai vaarallisia ihmistyöntekijöille. Tämän seurauksena kyberfyysisten järjestelmien riskit liittyvät useammin fyysiseen turvallisuuteen tai toimintavarmuuteen, koska epäonnistuminen turvallisuudessa voi vaarantaa työntekijät tai yleisen turvallisuuden. Tämä johtuu siitä, että näillä järjestelmillä on suora vaikutus fyysiseen maailmaan. Riskien arvioinnissa ja hallinnassa tulisi kyberfyysisissä järjestelmissä käyttää järjestelmälähtöisiä menetelmiä, joiden lähtökohtana on korkean tason tavoitteet (esim. kuoleman välttäminen, säännösten noudattaminen). Tällöin fyysisen turvallisuuden näkökulma tulee huomioitua.

Nykyisin kyberfyysisiä järjestelmiä halutaan yhä enemmän käyttää esim. etänä, ja niissä tarvitaan myös perinteisen tietoturvallisuuden näkökulmaa. Tällöin pitää huomioida, että etäkäyttö esim. verkon yli tuo kyberfyysisiin järjestelmiin mukaan kaikki verkkoihin liittyvät riskit. Historiassa turvallisuuskriittisillä järjestelmillä on ohjausjärjestelmien vikaantuessa ollut merkittäviä maailmanlaajuisia vaikutuksia (esim. Tšernobyl, Fukushima), ja kun tähän lisätään yhteys Internetiin, lisääntyy uhkapinta-ala entisestään. Verkkoon liittämisen myötä mukaan tulevat myös globaalin politiikan riskielementit ja erittäin resursoidut hyökkääjät (esim. Stuxnet, BlackEnergy). Lisäksi esim. IoT-laitteet ovat uudempi rajapinta turvallisuuskriittisiin järjestelmiin, ja ne voivat tarjota ikkunan, josta hyökkääjät pääsevät järjestelmään. IoT-tietoturva on lapsenkengissään ja IoT-laitteiden vaikutusta ja niiden tuomaa näkökulmaa riskienhallintaan ei ole vielä täysin ymmärretty. Kyberfyysisistä järjestelmistä lisää tässä luvussa.

Tietoturvan mittaaminen (syventävä)

Turvallisuusmittarit ovat pitkään olleet kiistanalaisia, koska turvallisuutta on usein vaikea arvioida määrällisesti. Laadullista arviointia, kuten matala, keskitaso, korkea tai punainen, keltainen, vihreä käytetään tyypillisesti luotettavan kvantitatiivisten tiedon puuttuessa. Laadullisen arvioinnin ongelma on, että esim. asteikko matala, keskitaso, korkea on subjektiivinen ja tarkoittaa eri asioita eri ihmisille ja sidosryhmille. Avoimia kysymyksiä mittaamiseen liittyen ovat: mitä järjestelmän ominaisuuksia pitäisi mitata riskien suhteen, miten riskiä mitataan ja miksi riskiä ylipäätään mitataan? Jotkut mittarit voivat liittyä riskitasoihin, osa mittareista liittyy järjestelmän suorituskykyyn ja osa liittyy palveluntarjoamiseen tai luotettavuuteen.

Mittareilla on erilaisia ominaisuuksia, mutta jotakin voidaan sanoa hyvistä ja huonoista mittareista. On esitetty, että hyvät mittarit:

  • Mittaavat johdonmukaisesti, ilman subjektiivisia kriteerejä.
  • Ovat helppoja mitata ja kerätä, mieluiten automaattisesti.
  • Ilmaistaan ​​lukuina tai prosentteina, ei laadullisilla tunnisteilla (esim. “korkea”, “keskitasoa”, “matala”).
  • Käyttävät vähintään yhtä mittayksikköä, esim. “virheet”, “tunnit” tai “eurot”.
  • Liittyvät asiayhteyteen ja ovat merkityksellisiä päätöksiä tekeville henkilöille, jotta toimenpiteitä voidaan tehdä perustuen mittareihin. Jos vastaus mittaukseen on olkapäiden kohautus ja “entä sitten?”, ei asiaa kannata edes mitata.

Huonot mittarit puolestaan:

  • Mittaavat epäjohdonmukaisesti, koska ne perustuvat subjektiivisiin arvioihin ja vaihtelevat henkilöstä toiseen.
  • Ei voida mitata ja kerätä helposti ja yksinkertaisesti, vaativat esim. kyselyiden täyttämistä.
  • Eivät käytä lukuja tai prosentteja, vaan asteikko on esim. korkea/keskisuuri/matala, liikennevalomalli ym.

Mittareiden tulisi perustua ymmärrykseen, että koskaan ei olla täysin turvassa, joten todellisen turvallisuuden mittaaminen tarvittavaa turvallisuutta vasten on hyväksyttävä lähestymistapa (actual security vs. necessary security). Tällöin mittarit on räätälöity haavoittuvuuksien hallinnan tehokkuuden mittaamiseen. Erityisesti tulisi miettiä, onko mahdollista mitata numeerisesti, että riskinhallintasuunnitelma ja siihen liittyvät turvatoimet ovat tarkoituksenmukaisia tunnistettuja uhkia vastaan, ja antavatko mittarit todella todisteita siitä, että valitut turvatoimet ovat oikeita? Lisäksi tulisi miettiä, ovatko valitut turvatoimet kustannustehokkaita, eli lisäävätkö ne arvoa enemmän kuin niiden toteuttamiskustannukset ovat?

Palautusta lähetetään...