Ilmainen e-kirja: NIS2 haltuun hyödyntäen ISO 27001 -käytäntöjä
Lataa e-kirja

Tutustu tehtävään liittyviin vaatimuskehikkoihin tarkemmin

GDPR

Yleinen tietosuoja-asetus

1.3.2
TISAX

TISAX: Information security

1.6.1
TISAX

TISAX: Information security

10
Kokonaiskuva (DVV)

Digiturvan kokonaiskuvapalvelu (DVV)

16.1.2
ISO27 Täysi

ISO 27001 (2013): Täysi

16.1.3
ISO27 Täysi

ISO 27001 (2013): Täysi

21.2.b (incidents)
NIS2

NIS2-direktiivi

5.10
ISO27k1 Täysi

ISO 27001 (2022): Täysi

6.2b
Tietoturvasuunnitelma

Tietoturvasuunnitelma (THL 3/2024)

6.4
Omavalvonta

Tietoturvan ja tietosuojan omavalvontasuunnitelma

6.8
ISO27k1 Täysi

ISO 27001 (2022): Täysi

9.9a §
KyberTL

Kyberturvallisuuslaki (NIS2)

CC7.3
SOC 2

SOC 2 (järjestelmät ja organisaation hallintakeinot)

CC7.4
SOC 2

SOC 2 (järjestelmät ja organisaation hallintakeinot)

DE.CM-3
NIST

NIST Cybersecurity Framework

DE.CM-3
CyFun

CyberFundamentals (Belgia)

HAL-08
Julkri

Julkri: TL IV-I

ID.RA-3
NIST

NIST Cybersecurity Framework

RS.CO-1
NIST

NIST Cybersecurity Framework

RS.CO-1
CyFun

CyberFundamentals (Belgia)

RS.CO-2
NIST

NIST Cybersecurity Framework

RS.CO-2
CyFun

CyberFundamentals (Belgia)

T-06
Katakri 2020

Katakri 2020

T-07
Katakri 2020

Katakri 2020

Muita saman teeman digiturvatehtäviä

Tapahtuneiden tietoturvahäiriöiden käsittelyprosessi ja dokumentointi

Critical
High
Normal
Low

Kaikki tietoturvahäiriöt käsitellään johdonmukaisesti, jotta tietoturvaa voidaan parantaa tapahtuneen perusteella.

Häiriöiden käsittelyprosessissa:

  • vahvistetaan raportoitu häiriö (tai todetaan tarpeettomaksi kirjata ylös)
  • dokumentoidaan häiriön tyyppi ja syy
  • dokumentoidaan häiriöön liittyneet riskit
  • käsitellään riskit, mikäli häiriön perusteella niiden käsittelyä täytyy päivittää
  • määritellään ja dokumentoidaan toimenpiteet riskien pienentämiseksi tai päätös niiden hyväksymisestä
  • määritellään tahot, joille on tärkeää tiedottaa käsittelyn tuloksista (myös organisaation ulkopuoliset)
  • määritetään tarve häiriön jälkianalyysille
T06: Turvallisuuspoikkeamien hallinta
Katakri
32. Käsittelyn turvallisuus
GDPR
12. Läpinäkyvä informointi, viestintä ja yksityiskohtaiset säännöt rekisteröidyn oikeuksien käyttöä varten
GDPR
16.1.5: Tietoturvahäiriöihin vastaaminen
ISO27 Täysi
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Omavalvonta

Häiriöhallinnan vastuutiimin nimeäminen

Critical
High
Normal
Low

Organisaatio huolehtii siitä, että häiriöhallintaan on nimetty selkeät vastuuhenkilöt, jotka vastaavat esimerkiksi häiriöiden ensimmäisen tason käsittelystä.

Häiriöiden hallinnasta vastaavia henkilöitä on ohjeistettava ja koulutettava, jotta he ymmärtävät organisaation prioriteetit tietoturvahäiriöiden käsittelyssä.

16.1.3: Tietoturvaheikkouksien raportointi
ISO27 Täysi
16.1.2: Tietoturvatapahtumien raportointi
ISO27 Täysi
ID.RA-3: Threat identification
NIST
RS.CO-1: Personnel roles
NIST
5.25: Tietoturvatapahtumien arviointi ja niitä koskevien päätösten tekeminen
ISO27k1 Täysi

Ohjeistukset ja ilmoitusprosessi häiriöiden ilmoittamiseen henkilöstölle

Critical
High
Normal
Low

Häiriöiden ilmoittamiseen ylläpidetään prosessia, joka auttaa henkilöstöä ilmoittamaan häiriöistä tehokkaasti ja johdonmukaisesti.

Häiriönä ilmoitettavia asioita ovat mm.:

  • luvaton pääsy tietoihin / tiloihin
  • tietoturvaohjeiden vastainen toiminta
  • epäilty tietoturvaongelma (esim. tietojenkalastelu, haittaohjelmatartunta)
  • tietojärjestelmän käyttökatko
  • tietojen tuhoutuminen / muuttuminen vahingossa tai tahallaan
  • kadonnut tai varastettu laite
  • vaarantunut salasana
  • kadonnut fyysinen tunniste (esim. avaimenperä, älykortti, älytarra)
  • epäilty tietoturvaheikkous (esim. käytetyssä tietojärjestelmässä tai muissa toimintatavoissa)

Henkilöstön ohjeissa korostetaan velvollisuutta raportoida tietoturvahäiriöistä mahdollisimman pian sovitun prosessin mukaisesti. Ohjeistus kuvaa myös muun toiminnan häiriön tapauksessa (mm. virheilmoitusten ja muiden yksityiskohtien kirjaaminen ylös).

T06: Turvallisuuspoikkeamien hallinta
Katakri
24. Rekisterinpitäjän vastuu
GDPR
16.1.3: Tietoturvaheikkouksien raportointi
ISO27 Täysi
16.1.2: Tietoturvatapahtumien raportointi
ISO27 Täysi
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Omavalvonta

Häiriöilmoitusten vaiheittainen prosessi viranomaisille

Critical
High
Normal
Low

Organisaatio ilmoittaa ilman viivästystä lainsäädännössä määritellylle viranomaiselle (CSIRT) merkittävästi palveluidensa tarjontaan vaikuttaneista häiriöistä. 

Häiriö on merkittävä, kun vähintään toinen seuraavista toteutuu:

  • häiriö voi aiheuttaa vakavan häiriön palvelujen toiminnassa tai vakavia taloudellisia menetyksiä palveluntarjoajalle
  • häiriö voi aiheuttaa merkittävää aineellista tai aineetonta vahinkoa liittyville ihmisille tai muille organisaatioille

Ilmoitukset on tehtävä vaiheittain allaolevien kuvausten mukaisesti. Lisäksi häiriön ollessa käynnissä organisaation on toimitettava viranomaisen pyytämät statuspäivitykset.

Aikainen varoitus (viimeistään 24h kuluessa häiriön havaitsemisesta)

  • epäilläänkö syyksi laittomia toimia
  • voiko häiriö aiheuttaa vaikutuksia muihin maihin

Tarkempi häiriöilmoitus (viimeistään 72h kuluessa häiriön havaitsemisesta)

  • päivitetään aiempaa tietoa
  • annetaan tämänhetkinen arvio häiriöstä, sen vakavuudesta sekä vaikutuksista
  • listataan mahdolliset todisteet vuodon tapahtumisesta

Lopullinen raportti (viimeistään 1kk kuluessa häiriöilmoituksesta)

  • yksityiskohtainen kuvaus tapahtumasta, mukaan lukien sen vakavuus ja vaikutukset
  • uhan tyyppi tai perimmäinen syy, joka todennäköisesti laukaisi tapahtuman
  • sovelletut ja meneillään olevat lieventämistoimenpiteet
  • mahdolliset vaikutukset muihin maihin
23.1: Incident notifications to CSIRT and recipients of services
NIS2
Article 19: Reporting of major ICT-related incidents and voluntary notification of significant cyber threats
DORA
11 §: Poikkeamailmoitukset viranomaiselle
KyberTL
12 §: Poikkeamaa koskeva väliraportti
KyberTL
13 §: Poikkeamaa koskeva loppuraportti
KyberTL

Tiedottaminen häiriötilanteissa ja varautuminen

Critical
High
Normal
Low

Viranomaisen on viipymättä tiedotettava niille, jotka hyödyntävät sen tietoaineistoja, jos viranoman tietojenhallintaan kohdistuu häiriö, joka estää tai uhkaa estää tietoaineistojen saatavuuden. Tiedotuksessa on annettava seuraavat tiedot:

a) Häiriön tai sen uhan arvioitu kesto.

b) Mahdolliset korvaavat tavat hyödyntää viranomaisen tietoaineistoja, jos sellaisia on.

c) Häiriön tai uhan päättyessä.

Viranomaisen on noudatettava digitaalisten palvelujen ja muiden sähköisten tiedonsiirtomenetelmien käyttökatkoista tiedottamisesta yleisölle annettuja ohjeita, kuten ne on säädetty digitaalisten palvelujen tarjoamisesta annetun lain (306/2019) 4 §:n 2 momentissa.

13 a §: Häiriötilanteista tiedottaminen ja varautuminen häiriötilanteisiin
TiHL
2.8: Häiriötilanteista tiedottaminen
TiHL: Tietoturva

Merkittävien häiriöiden ilmoittaminen toimivaltaisille viranomaisille

Critical
High
Normal
Low

Merkittävien häiriliden sattuessa organisaation on ilmoitettava niistä kansallisessa DORA:n asetuksessa määritellyille viranomaisille. Merkittävien häiriöiden ilmoituksen tulee sisältää:

  1. Ensimmäinen ilmoitus
  2. Väliraportti (tapahtuman tilan muuttuessa)
  3. Loppuraportti, kun perussyyanalyysi on tehty

Jos tapahtumalla on vaikutusta asiakkaiden taloudellisiin etuihin, heille on ilmoitettava mahdollisimman pian tarvittavilla toimenpiteillä tilanteen lieventämiseksi. Kyberuhkien sattuessa asiakkaille tulee ilmoittaa, jos he saattavat vaikuttaa heihin suojatoimenpiteistä, joita heidän tulisi harkita.

Asianomaiset toimivaltaiset viranomaiset määritellään DORA:n 46 artiklassa

Article 19: Reporting of major ICT-related incidents and voluntary notification of significant cyber threats
DORA

Tietoturvahäiriöiden ensimmäisen tason reagointiprosessi

Critical
High
Normal
Low

Organisaatio on määritellyt prosessin ja siihen osallistuvan tiimin, jonka avulla tietoturvahäiriöihin reagoidaan pikaisesti ja sopivat jatkotoimet päätetään johdonmukaisesti.

Ensimmäisen tason reagointiprosessissa vähintään:

  • pyritään tehokkaasti vahvistamaan todettu häiriö
  • päätetään tarpeesta välittömään reagointiin
16.1.4: Tietoturvatapahtumien arviointi ja niitä koskevien päätösten tekeminen
ISO27 Täysi
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Omavalvonta
DE.AE-4: Impact of events
NIST
RS.RP: Response Planning
NIST
RS.RP-1: Incident response plan
NIST

Tietoturvahäiriöihin liittyvien todisteiden hallinta

Critical
High
Normal
Low

Organisaation on luotava toimintatavat, joiden avulla tunnistetaan, kerätään ja säilytetään tietoturvahäiriöihin liittyvä relevantti todistetieto. Todisteiden voi olla tarpeen olla kerätty tavalla, joka voidaan hyväksyä relevanteissa tuomioistuimissa tai muissa vastaavissa kurinpitoelimissä.

Todistemateriaaliin liittyen pitäisi pystyä osoittamaan mm.:

  • tietueet ovat täydellisiä, eikä niitä ole muokattu millään tavalla
  • kopiot sähköisistä todisteista ovat todennäköisesti identtisiä alkuperäisten kanssa
  • tietojärjestelmä, josta todisteita on kerätty, toimi oikein keräyshetkellä

Liittyvän henkilökunnan sekä työkalujen sertifiointia tai muita pätevyystodisteita voidaan lisäksi harkita sovellettavan todisteiden arvon vahvistamiseksi.

5.28: Todisteiden kerääminen
ISO27k1 Täysi
6.2b: Häiriöiden hallinta ja menettelyt ongelmatilanteissa
Tietoturvasuunnitelma

Häiriötilanteiden säännöllinen harjoittelu

Critical
High
Normal
Low

Organisaation tulisi säännöllisesti, vähintään kerran vuodessa, harjoitella siihen kohdistuvia mahdollisia häiriö- tai hyökkäystilanteita.

Harjoitus voi kohdistua joko häiriön havaitsemisen, reagoinnin tai johtamisen kehittämiseen tai kaikkiin näistä.

Harjoitusten toteuttamisesta ja havainnoista tulee ylläpitää dokumentaatiota.

36: Häiriötilanteiden säännöllinen harjoittelu
Kokonaiskuva (DVV)

Tietoturvahäiriöiden ilmoittaminen viranomaisille

Critical
High
Normal
Low

Organisaatiolla tulee olla olemassa menettely sen toimintaan kohdistuvien häiriöiden, hyökkäysten ja loukkausten ilmoittamiseksi viranomaisille. Esimerkiksi:

  • Poliisi
  • Tietosuojavaltuutetun toimisto
  • Kyberturvallisuuskeskus
35: Häiriöiden ilmoittaminen viranomaisille
Kokonaiskuva (DVV)

Häiriön rajaustoimet

Critical
High
Normal
Low

Organisaation on otettava keinoja käyttöön, jolla häiriön vaikutus voidaan rajata mahdollisimman pieneen osaan. Keinot tulisivat vastata tehtyjä suunnitelmia ja sisältää häiriön:

  • Vastaisen valmistelun
  • Analysoinnin
  • Eristämisen
  • Hävittämisen
  • Palautumisen käynnistämisen
RS.MI-1: Incident containment
NIST
Article 17: ICT-related incident management process
DORA
RS.MI-1: Incidents are contained.
CyFun

Havaitsemisprosessien testaus ja vaatimustenmukaisuus

Critical
High
Normal
Low

Havaitsemisprosesseja ja menettelyjä ylläpidetään ja testataan, jotta varmistetaan tietoisuus poikkeavista tapahtumista. Havaitsemistoimien täytyy sopia kaikkiin asiaan liittyviin vaatimuksiin.

DE.DP-2: Detection activities
NIST
TEK-13: Poikkeamien havainnointikyky ja toipuminen
Julkri
CC7.2: Monitoring of system components for anomalies
SOC 2
DE.DP-2: Detection activities comply with all applicable requirements.
CyFun

Tietoturvahäiriön rajan määrittely

Critical
High
Normal
Low

Organisaation täytyy määritellä raja, jolloin tietoturvatapahtumasta tulee tietoturvahäiriö.

DE.AE-5: Incident alert thresholds
NIST
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA
DE.AE-5: Incident alert thresholds are established.
CyFun

Tapahtumalähteiden määrittely ja seuranta

Critical
High
Normal
Low

Organisaation on määriteltävä, millaisia tietoturvatapahtumia se seuraa ja millä toimintatavoilla.

Tietoturvatapahtumia tulisi seurata useista eri lähteistä, joiden avulla tärkeä, reagointia vaativat mahdolliset häiriöt voidaan tunnistaa. Tietoa voidaan saada mm. suoraan hallintajärjestelmästä, ulkoisilta kumppaneilta tai organisaation laitteiden tuottamista lokeista.

Esimerkkejä seurattavista tietoturvatapahtumista voivat olla mm.:

  1. Palvelimen hidas toiminta
  2. Toistuvat kirjautumisvirheet
  3. Tuntemattomat kirjautumisyritykset
  4. Poikkeuksellinen verkkoliikenne
  5. Tallennustilan loppuminen
  6. Muutokset koodiprojekteissa
  7. Konfiguraatiomuutokset palomuurilla
  8. Käyttöoikeusmuutokset kriittisiin järjestelmiin / palvelimiin / tietokantoihin
  9. Isot tietokantalataukset
  10. Luvattomat ohjelmistoasennukset päätelaitteille
  11. Liikenne haitalliseksi tiedetyistä IP-osoitteista
DE.AE-3: Event data
NIST
TEK-13: Poikkeamien havainnointikyky ja toipuminen
Julkri
RESPONSE-1: Detect Cybersecurity Events
C2M2: MIL1
DE.AE-3: Event data are collected and correlated from multiple sources and sensors.
CyFun

Prosessit tarjottuihin digipalveluihin liittyvien tietoturvatapahtumien raportoimiseksi

Critical
High
Normal
Low

Pilvipalveluita tarjoaessaan organisaatiolla tulee olla suunnitellut prosessit tai menettelyt:

  • miten pilvipalvelun asiakas raportoi tietoturvatapahtumasta organisaatiolle
  • miten organisaatio raportoi tietoturvatapahtumista pilvipalveluasiakkaille
  • miten pilvipalvelun asiakas voi seurata aiemmin raportoidun tietoturvatapahtuman tilaa
16: Tietoturvahäiriöiden hallinta
ISO 27017
16.1: Tietoturvahäiriöiden ja tietoturvallisuuden parannusten hallinta
ISO 27017
16.1.2: Tietoturvatapahtumien raportointi
ISO 27017
ID.RA-3: Threat identification
NIST
DE.DP-4: Event detection
NIST

Tietoturvahäiriöihin liittyvien tietoturvamittarien määrittely

Critical
High
Normal
Low

Organisaatiolla on määritellyt seurattavat mittarit, jotka liittyvät tietoturvahäiriöiden hallintaan. Parhaimmillaan hyvät mittarit auttavat havaitsemaan heikkouksia häiriöiden tunnistamiseen liittyen.

Mahdollisia mittareita ovat mm.:

  • tietoturvatapahtumien määrä ja suhde häiriöihin
  • häiriöiden määrä tarjottavan palvelun, osaston, vakavuuden tai tyypin mukaan
  • vaadittu aika häiriöin tunnistamiseen, tutkimiseen ja käsittelyyn
  • poikkeamat dokumentoiduista toimintatavoista
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA

Siedettävien toimintakatkosten määrittely

Critical
High
Normal
Low

Organisaation tulisi määritellä jokaisen tunnistetun kriittisen toiminnon suhteen, kuinka pitkä toimintakatkos siedetään ilman, että organisaation toiminta häiriintyy.

Määrittelyssä on otettava huomioon:

  • Lainsäädännön vaatimukset liittyen organisaation järjestelmien, rekistereiden ja palveluiden saatavuuteen
  • Oman toiminnan ja sidosryhmien vaatimukset
27: Siedettävien toimintakatkoksien määrittely
Kokonaiskuva (DVV)

Palveluiden käyttäjiin vaikuttavista tietoturvauhkista ja suojatoimenpiteistä viestintä

Critical
High
Normal
Low

Kun organisaation palveluiden käyttäjät ovat mahdollisesti alttiina merkittävälle tietoturvauhkalle, organisaation on viestittävä tästä heille sisältäen kaikki mahdolliset korjaustoimenpiteet, joita käyttäjät voivat itse toteuttaa suojautuakseen uhkaa vastaan.

Kun viestinnän selkeyden kannalta on tarpeen, organisaation on sisällytettävä viestintäänsä myös yleisempää tietoa liittyvästä tietoturvauhkasta.

23.2: Threat notifications to recipients of services
NIS2
14 §: Poikkeamasta ja kyberuhkasta ilmoittaminen muulle kuin viranomaiselle
KyberTL
RS.CO-3: Information is shared consistent with response plans.
CyFun

Häiriöilmoitukset omien palveluiden käyttäjille

Critical
High
Normal
Low

Mikäli organisaation tarjoaman palvelun näkökulmasta on tarkoituksenmukaista, organisaatio ilmoittaa ilman viivästystä palveluidensa käyttäjille merkittävistä häiriöistä, jotka todennäköisesti vaikuttavat negatiivisesti kyseisten palveluiden toimittamiseen.

Häiriö on merkittävä, kun vähintään toinen seuraavista toteutuu:

  • häiriö voi aiheuttaa vakavan häiriön palvelujen toiminnassa tai vakavia taloudellisia menetyksiä palveluntarjoajalle
  • häiriö voi aiheuttaa merkittävää aineellista tai aineetonta vahinkoa liittyville ihmisille tai muille organisaatioille
23.1: Incident notifications to CSIRT and recipients of services
NIS2
14 §: Poikkeamasta ja kyberuhkasta ilmoittaminen muulle kuin viranomaiselle
KyberTL

Turvallisuuspoikkeamista ilmoittaminen viranomaisille

Critical
High
Normal
Low

Organisaatiolla tulee olla prosessi tapahtuneen tai epäillyn kansainvälisen turvallisuusluokitellun tiedon vaarantaneen tietoturvapoikkeaman ilmoittamisesta toimivaltaiselle turvallisuusviranomaiselle.

Organisaatiolla tulee olla myös ohjeistus ja menettelytavat turvallisuusluokitellun tiedon vaarantaneiden tietoturvapoikkeamien havaitsemiseen ja tiedottamiseen organisaation sisällä ja kenelle kaikille tietoturvapoikkeamasta tai sen epäilystä tulee ilmoittaa. Lisäksi täytyy olla selvillä millaiset tietoturvapoikkeamasta vaativat yhteydenottoa viranomaisiin.

Turvallisuusluokiteltujen tietojen katsotaan vaarantuneen, kun ne ovat tietoturvatapahtuman seurauksena paljastuneet tai voineet paljastua sivullisille henkilöille. Useat tiedon omistajat (esimerkiksi EU) sekä myös voimassa olevat viranomaishyväksynnät edellyttävät välitöntä ilmoitusta turvallisuusluokitellun tiedon vaarantaneista poikkeamista tai niiden epäilyistä.

T-07: TURVALLISUUSPOIKKEAMIEN HALLINTA
Katakri 2020

Turvallisuusluokiteltujen tietojen huomiointi häiriöiden hallinnassa

Critical
High
Normal
Low

Häiriöiden hallinnassa on huomioitava myös:

  • Turvallisuusluokiteltujen tietojen suojaaminen hätä- ja häiriötilanteissa
  • Turvallisuusluokitellulla tiedolla on riittävät suojaustoimenpiteet tietoihin luvattoman pääsyn ja eheyden ja käytettävyyden turvaamuseksi
  • Turvallisuusluokiteltu tieto tulee olla suojattu teknisiltä ja fyysisiltä vahingoilta.

Organisaatiolla tulee olla varmuus siitä, että käsiteltävä tieto tai järjestelmä on suojattu hätä- tai häiriötilanteissa fyysisiltä vahingoilta kuten tulipalot, vesivahingot tai ilkivalta tai luvaton tunkeutuminen sekä sähköisiä menetelmiä käyttäen aiheutetuilta fyysisiltä vahingoilta kuten laitteiden rikkoutuminen. Tietoa tai järjestelmää tulee suojata asianmukaisin, mutta riskiarvioinnin perusteella tarkoituksenmukaisin toimin.

T-06: TOIMINTAHÄIRIÖT JA POIKKEUSTILANTEET
Katakri 2020

ICT-ympäristön seurannan riittävä resursointi

Critical
High
Normal
Low

Organisaation tulee osoittaa riittävästi resursseja käyttäjien toiminnan, ICT-ympäristön poikkeavuuksien ja kyberhyökkäysten seurantaan.

Valvomalla organisaation tulee tunnistaa perustoiminnan poikkeamat ja häiriöt.

Article 10: Detection
DORA

Häiriöiden luokittelu

Critical
High
Normal
Low

Organisaatioiden tulee suorittaa häiriöiden luokittelu ja vaikutustenarviointi seuraavien kriteerien perusteella:

  • Asianomaisten osapuolten (asiakkaat, muut organisaatiot) lukumäärä ja mahdollisuuksien mukaan niiden tapahtumien määrä, joihin vaikutus vaikuttaa.
  • Mainevaikutus
  • Häiriön kesto
  • Vaikutusten maantieteellinen leviäminen
  • Mahdollisia tietojen menetyksiä suhteessa CIA-arvoihin
  • Vaikutuksen kohteena olevien palveluiden kriittisyys
  • Taloudellinen vaikutus
Article 18: Classification of ICT-related incidents and cyber threats
DORA

Tietoturvahäiriöiden luokitteluprosessi

Critical
High
Normal
Low

Organisaatiolla olisi oltava menettely tietoturvahäriöiden luokittelemiseksi käsittelyn aikana. Häiriö olisi luokiteltava vähintään seuraaviin luokkiin:

  • Henkilöstö
  • Fyysinen
  • Kyber

Tämän jälkeen vaaratilanne olisi luokiteltava sen vaikutusten perusteella esimerkiksi seuraavasti:

  • Ei turvallisuusriskiä
  • Havainto
  • Parannusehdotus
  • Haavoittuvuus
  • Tietoturvahäiriö

Tämän jälkeen vaaratilanteet olisi asetettava tärkeysjärjestykseen vaaratilanteen vakavuuden perusteella.

1.6.2: Management of reported events
TISAX

Sisäinen viestintä häiriötilanteessa

Critical
High
Normal
Low

Organisaatiolla tulee olla selkeät viestintäkanavat tapahtumien raportointia varten:

  • Perustetaan ja ylläpidetään asianmukaisia viestintäkanavia turvallisuustapahtumista raportoiville henkilöille ja varmistetaan, että:
  • Tapahtumista ilmoittamista varten on määritetty yhteinen yhteyspiste, josta tiedotus tapahtuu kaikille asianomaisille osapuolille.
  • Käytettävissä on erilaisia raportointikanavia tapahtumien vakavuuden mukaan, mukaan lukien reaaliaikaiset viestintävaihtoehdot merkittävissä hätätilanteissa ja asynkroniset menetelmät (esim. liput, sähköposti) vähemmän kiireellisissä asioissa.

Organisaation olisi myös harkittava mahdollisuutta ulkoiseen raportointiin. Tämä voi tarkoittaa, että organisaatiolla on järjestelmä, jolla voidaan käsitellä ulkoisten osapuolten raportteja turvallisuustapahtumista, mukaan lukien:

  • Ulkoisesti saatavilla oleva ja hyvin kommunikoitu menetelmä tietoturvatapahtumien raportointia varten.
  • Määritellyt menettelyt ulkoisista lähteistä tuleviin tietoturvatapahtumaraportteihin vastaamista ja niiden käsittelyä varten.

Organisaation olisi myös varmistettava, että häiriötilanteiden raportointimekanismit ja -tiedot ovat helposti kaikkien asianomaisten raportoijien saatavilla, ja otettava käyttöön palautemenettely, jolla turvatapahtumista raportoiville annetaan nopeita vastauksia ja päivityksiä ja jolla varmistetaan, että heille tiedotetaan tuloksista ja tarvittavista jatkotoimista.


1.6.1: Reporting of security events
TISAX

Turvallisuustapahtumien ja häiriötilanteiden määrittely

Critical
High
Normal
Low

Organisaation on laadittava selkeä ja kattava määritelmä siitä, mikä on raportoitava turvallisuustapahtuma tai havainto, ja varmistettava, että se kattaa seuraavat luokat:

  • Henkilöstön rikkomukset tai väärinkäytökset.
  • Tunkeutuminen, varkaus, luvaton pääsy turvavyöhykkeille ja turvavyöhykkeiden haavoittuvuudet.
  • Kyberturvallisuustapahtumat, kuten tietojärjestelmien haavoittuvuudet ja havaitut onnistuneet tai epäonnistuneet kyberhyökkäykset.
  • Toimittajien ja yhteistyökumppaneiden vaaratilanteet, jotka voivat vaikuttaa kielteisesti organisaation turvallisuuteen.

Organisaatiolla on oltava määritelty menettely häiriötilanteiden raportointia varten, ja siitä on tiedotettava henkilöstölle:

  • Suunnitellaan ja otetaan käyttöön tehokkaat raportointimekanismit, jotka on räätälöity havaittujen riskien mukaan.
  • Varmistetaan, että näistä mekanismeista tiedotetaan hyvin ja että ne ovat kaikkien työntekijöiden, sidosryhmien ja asiaankuuluvien osapuolten saatavilla, jotta turvallisuustapahtumista voidaan raportoida ajoissa ja täsmällisesti.
  • Järjestetään koulutustilaisuuksia ja tiedotusohjelmia sen varmistamiseksi, että kaikki asianomaiset työntekijät ja sidosryhmät ymmärtävät raportoitavien turvallisuustapahtumien määritelmän ja tuntevat raportointimekanismit.
1.6.1: Reporting of security events
TISAX

Kriittisten järjestelmien turvallinen vikaantuminen verkkoyhteyksien katketessa

Critical
High
Normal
Low

Jos yhteys katkeaa tai verkkojärjestelmissä ilmenee vika, kuten:

  • Vika organisaation palomuurijärjestelmissä.
  • Verkon menetys
  • Fyysisen komponentin tuhoutuminen

Organisaation tulee varmistaa, että sen kriittiset järjestelmät vikaantuvat turvallisesti, jotta lisävahingoilta voidaan välttyä tai pitää ne mahdollisimman pieninä.

PR.AC-5: Network integrity (network segregation, network segmentation… ) is protected.
CyFun

Yhteydenpito relevanttien osapuolten kanssa tapahtuman jälkeen, mukaan lukien CERTit ja NSM NCSC

Critical
High
Normal
Low

Organisaatiolla on määritellyt menettelyt, joiden avulla se viestii relevanteille viranomaisille ja osapuolille tapahtuman sattuessa. Näitä osapuolia ovat esimerkiksi alakohtaiset tietokonehätätilanteiden torjuntaryhmät ja NSM NCSC.

Developing and executing a recovery plan

Critical
High
Normal
Low

The organization should have a defined and well-documented recovery plan. The recovery plan should be able to be initiated during or after an incident. Recovery actions and measures will vary from incident to incident, for example, the type of incident can affect the actions taken. These actions could include:

  • Reactivating redundant resources lost or damaged during the incident
  • Reinstalling hardware and software on affected components
  • Restoring configuration settings, including any necessary adjustments
  • Restoring services halted during the incident

The organization should adopt a 'build back better' mindset when rebuilding ICT systems. This means that systems should be rebuilt to a better state than they were before the incident.

Documenting incident activities by establishing a response timeline

Critical
High
Normal
Low

The organization should establish clear processes for building a timeline whenever an incident occurs. This timeline should include both the organization's actions and the threat actor's activities. The timeline should encompass:

  • When and how the initial breach occurred
  • The threat actor's movements within the ICT system (e.g., possible privilege escalation)
  • Key decisions made by the organization during the response phase
  • Communication between relevant parties

This aids the organization in understanding the full scope of the incident and improving responses in future events.

Enriching incident information to ensure an effective response

Critical
High
Normal
Low

The organization should have a clear process for enriching incident information to ensure an effective response. This process should include continuously updating event data, monitoring situational awareness, and collecting information from multiple sources. Enriching incident information should help the organization manage incidents more effectively.


Identifying the impact on business processes

Critical
High
Normal
Low

Identify the extent and impact of the incident on business processes to understand how operations may be disrupted. This assessment should include a thorough evaluation of the effects on underlying ICT functions. Also, it should be examined how the incident impacts ICT services, including cloud-based applications and internal systems, as well as the various ICT systems that support business activities.

Poikkeamanhallintasuunnitelman laatiminen ja ylläpito

Critical
High
Normal
Low

Organisaation tulisi laatia ja ylläpitää poikkeamanhallintasuunnitelmia. Hallintasuunnitelmien tulisi sisältää ainakin seuraavat seikat

  • Poikkeama tai poikkeamatyyppi, jota varten suunnitelma on laadittu
  • Suunnitelman tavoite
  • Vastuuhenkilöt ja asiaan liittyvät sidosryhmät sekä yhteystiedot
  • Suunnitellut välittömät toimet
  • Suunnitellut seuraavat vaiheet

Including suppliers in incident management

Critical
High
Normal
Low

Organization should include suppliers and other relevant third parties in its incident management process and planning with means such as:

  • Define and implement rules, roles and protocols for reporting incident response and recovery activities between the organization and its suppliers
  • Include critical suppliers in regular incident response exercises and simulations
  • Establish and coordinate crisis communication methods and protocols between the organization and its critical suppliers
  • Conduct collaborative lessons learned sessions with critical suppliers after incidents to improve joint response capabilities and refine processes for future incidents

Incident response documentation and integrity

Critical
High
Normal
Low

Organization enforces documentation policies for each incident investigation and response process:

  • Require each incident responder or investigator, including system administrators and cybersecurity personnel, to record their actions during the process. Ensure that these records are made immutable to preserve their integrity for future analysis and audits.
  • Assign the incident lead the responsibility to document the incident in detail, capturing all actions, findings, and decisions made throughout the incident response process.
  • Ensure the incident lead is accountable for maintaining the integrity of all documentation and preserving the sources of information being reported, preventing tampering or loss of data.

Public communication on incident recovery measures

Critical
High
Normal
Low

In case of an incident the organization implements recovery measures defined in its incident recovery plan. The measures are implemented and communicated to the public to:

  • Manage the public view and control the narrative
  • Mitigate the impact of the incident on the organization

The organization should explain the steps being taken to recover from the incident and to prevent a recurrence.

Defining threshold for incident recovery measures

Critical
High
Normal
Low

Organization defines criteria for initiating incident recovery measures on incidents. The occurred incident is evaluated against these criteria, and determined whether the incident recovery process shall be initiated, by at least these measures:

  • Apply incident recovery criteria to the known and assumed characteristics of an incident to evaluate whether incident recovery processes should be initiated, considering factors such as severity, impact, and scope
  • Assess the potential operational disruption caused by incident recovery activities and develop strategies to minimize impact on ongoing business operations during the recovery phase
  • Establish clear criteria for prioritizing incident recovery efforts based on the nature of the incident, including data sensitivity, affected systems, and business continuity requirements

Document the decision-making process for initiating recovery actions and ensure that it is communicated to relevant stakeholders for transparency and alignment.

Jälkianalyysi tietoturvahäiriöille

Critical
High
Normal
Low

Mikäli häiriön ensisijaisen käsittelyn perusteella on vaikeaa tunnistaa tietoturvahäiriön lähde, suoritetaan häiriölle erillinen jälkianalyysi, jossa lähde pyritään tunnistamaan.

16.1.6: Tietoturvahäiriöistä oppiminen
ISO27 Täysi
6.4: Menettelytavat virhe- ja ongelmatilanteissa
Omavalvonta
ID.RA-4: Impacts on business
NIST
DE.DP-5: Detection processes improvment
NIST
RS.AN-2: The impact of the incident
NIST

Häiriöiden säännöllinen jaksottainen analysointi ja häiriöistä oppiminen

Critical
High
Normal
Low

Tietoturvahäiriöiden analysoinnista ja ratkaisemisesta saatua tietämystä olisi hyödynnettävä tulevien häiriöiden todennäköisyyden vähentämisessä ja niiden vaikutuksen pienentämisessä.

Organisaatio analysoi säännöllisesti tapahtuneita häiriöitä kokonaisuutena. Tässä prosessissa tutkitaan häiriöiden tyyppiä, määrää ja kustannuksia tavoitteena tunnistaa toistuvia ja vaikutuksiltaan merkittäviä häiriöitä.

Mikäli reagointia vaativia toistuvia häiriöitä tunnistetaan, niiden perusteella:

  • luodaan uusia tai laajennetaan olemassaolevia tietoturvan hallintatehtäviä
  • tarkennetaan tai laajennetaan tähän aihepiiriin liittyvää tietoturvaohjeistusta
  • luodaan häiriöstä case-esimerkki, jota käytetään henkilöstön kouluttamiseksi vastaaviin tilanteisiin reagoimiseksi tai niiden välttämiseksi
16.1.6: Tietoturvahäiriöistä oppiminen
ISO27 Täysi
PR.IP-7: Protection processes
NIST
PR.IP-8: Protection effectiveness
NIST
DE.DP-5: Detection processes improvment
NIST
RS.AN-2: The impact of the incident
NIST

Häiriökäsittelyn tuloksista tiedottaminen

Critical
High
Normal
Low

Organisaatio on määritellyt toimintatavat, jotka varmistavat häiriön alkuperäisen raportoijan sekä muuten häiriöön liittyvän henkilöstön saavan tiedon häiriön käsittelyn tuloksista.

Häiriöön liittyvä henkilöstö voidaan kirjata valinnaiseen tietokenttään tietoturvahäiriöiden dokumentaatiopohjassa.

16.1.6: Tietoturvahäiriöistä oppiminen
ISO27 Täysi
PR.IP-8: Protection effectiveness
NIST
DE.DP-4: Event detection
NIST
5.27: Tietoturvahäiriöistä oppiminen
ISO27k1 Täysi
CC2.2: Internal communication of information
SOC 2

Henkilöstön whistle blowing -järjestelmä

Critical
High
Normal
Low

Henkilöstöllä on käytössä whistle blowing -järjestelmä, jonka kautta voi nimettömästi raportoida tietoturvasääntöjen tai -menettelyjen loukkauksista.

Rikostekninen tutkinta häiriöille

Critical
High
Normal
Low

Häiriön jälkeen haitalliselle koodille, tai muille häiriön jäänteille on suoritettava rikostekninen tutkinta. Turvallisesti tehty tutkinta suljetussa ympäristössä voi aukaista häiriön syitä, tavoitteita ja toteutustapoja. Tämä auttaa organisaatiota korjaamaan mahdolliset aukot turvallisuudessa, varautumaan samankaltaisiin häiriöihin ja tunnistamaan tai profiloimaan mahdollisen hyökkääjän.

RS.AN-3: Forensics
NIST
6.8: Asiakas- ja potilastietojärjestelmien pääsynhallinnan ja käytön seurannan käytännöt
Tietoturvasuunnitelma
RS.AN-3: Forensics are performed.
CyFun

Tietoturvatapahtumien lajittelun varmistaminen

Critical
High
Normal
Low

Organisaation on määriteltävä toimintatavat, joiden avulla havaitut tietoturvatapahtumat pystytään selkeästi lajittelemaan. Lajittelun avulla on pystyttäjä priorisoimaan tapahtumat vakavuuden ja mahdollisen vaikutuksen mukaan.

Lajittelun perusteella on tarkoitus tehostaa tietoturvatapahtumien tutkimista ja arviointia, jotta esimerkiksi häiriöön vastaaminen saadaan tarvittaessa käyntiin nopeasti.

Toimintatavat voivat koostua yleisistä prosesseista, teknisistä työkaluista tai koneoppimista hyödyntävistä algoritmeistä. Toimintatapoja on tarkasteltava säännöllisesti, jotta vahvistetaan niiden toimivuus ja sopivuus käyttötarpeisiin.

DE.AE-2: Analyze detected events
NIST
RESPONSE-2: Analyze Cybersecurity Events and Declare Incidents
C2M2: MIL1
Article 17: ICT-related incident management process
DORA
DE.AE-2: Detected events are analysed to understand attack targets and methods.
CyFun

Ympäristöuhkien huomiointi riskien- ja häiriöiden hallinnassa

Critical
High
Normal
Low

Organisaation tulisi ottaa huomioon ympäristöuhat, jotka voivat vaikuttaa järjestelmien käytettävyyteen, osana riskienarviointiprosessia ja myös osana tietoturvahäiriöiden prosessia.

Ympäristöuhkiin kuuluu esimerkiksi:

  • Epäsuotuisa sää
  • Vika ympäristönhallintajärjestelmissä
  • Virtapiikit sähkönjakelussa
  • Tulipalot
  • Vesivahingot


A1.2: Recovery of infrastructure according to objectives
SOC 2

Vapaaehtoiset ilmoitukset tietoturvahäiriöistä

Critical
High
Normal
Low

Organisaatiolla voi olla prosessi, jonka avulla se voi vapaaehtoisesti ilmoittaa tietyt tietoturvaloukkaukset, tietoverkkouhat tai läheltä piti -tilanteet valvontaviranomaiselle.

Vapaaehtoisilla ilmoituksilla tarkoitetaan muita kuin merkittäviä vaaratilanteita koskevia ilmoituksia, jotka ovat NIS2-direktiivin mukaan pakollisia.

15 §: Vapaaehtoinen ilmoittaminen
KyberTL