ISO 27001 -standardin mukainen uhkatiedustelu NIS2- ja DORA-vaatimuksiin

Tiistaiaamuna klo 07.42 eurooppalaisen fintech-yhtiön tietoturvajohtaja saa neljä viestiä ennen aamukahvia.

Ensimmäinen on kansallisen CERT-toimijan hälytys, jonka mukaan etäkäytön haavoittuvuutta käytetään aktiivisesti hyväksi. Toinen on toimittajan tiedote, joka vahvistaa, että kyseistä komponenttia käytetään hallinnoidussa tiedostonsiirtopalvelussa. Kolmas on hallinnoidun havainnointi- ja reagointipalvelun ilmoitus, joka nostaa esiin poikkeavaa ulospäin suuntautuvaa liikennettä ei-tuotantoaliverkosta. Neljäs tulee talousjohtajalta: ”Vaikuttaako tämä DORA-valmiusaineistoomme, ja täytyykö meidän ilmoittaa asiasta kenellekään NIS2:n perusteella?”

Tämä on uhkatiedustelun ongelma vuonna 2026. Kyse ei ole uusien syötteiden keräämisestä. Kyse on sen osoittamisesta, että relevantti kyberuhkatieto vastaanotetaan, validoidaan, ohjataan oikeille tahoille, käsitellään ja muunnetaan riski-, havainnointi-, haavoittuvuus-, poikkeama-, toimittaja- ja hallitusnäytöksi.

Monet organisaatiot tilaavat jo toimittajien tietoturvatiedotteita, CISA-hälytyksiä, ENISA-päivityksiä, kansallisia CERT-ilmoituksia, ISAC-tiedotteita, pilvipalveluntarjoajien tietoturvailmoituksia, CVE-syötteitä, MDR-raportteja, hyväksikäytettävyyttä koskevia tietokantoja ja dark web -seurantaa. Kun todellinen tiedote saapuu, tiimit joutuvat silti kiirehtimään. SOC kirjoittaa havaitsemissäännön. Infrastruktuuritiimi etsii omaisuusluetteloista, jotka eivät välttämättä ole ajan tasalla. Vaatimustenmukaisuudesta vastaavat kysyvät, vaikuttaako tapahtuma NIS2:een tai DORA:an. Johto haluaa selkeän vastauksen ennen kuin organisaatio edes tietää, onko haavoittuva komponentti tuotantoympäristössä.

Ongelma ei ole tiedon puute. Ongelma on auditoitavan toimintamallin puute.

Uhkasyöte, jota kukaan ei käytä, ei ole kontrolli. Haavoittuvuustiedote, joka ei muuta paikkausprioriteettia, ei ole näyttöä. Toimittajailmoitus, joka ei koskaan päädy riskirekisteriin, ei ole toimitusketjun tietoturvaa. CSIRT-hälytys, joka ei päivitä valvontaa, poikkeamien luokittelua tai johdon raportointia, on vain postilaatikon kohinaa.

Clarysecin lähestymistapa on yksinkertainen: uhkatiedustelusta on tehtävä riskipäätösten operatiivinen järjestelmä. Sen on oltava osa ISMS:n soveltamisalaa, riskien arviointia, soveltuvuuslausuntoa, poikkeamien toimintapelikirjoja, haavoittuvuuksien luokittelua ja priorisointia, lokitusta ja valvontaa, toimittajahallintaa, johdon raportointia ja auditointinäyttöä.

Miksi uhkatiedustelu on nyt hallitustason kontrolli

NIS2 muutti kyberturvallisuuden hallinnan sävyä. Sen soveltamisalaan kuuluu monia SaaS-palveluntarjoajia, pilvipalveluntarjoajia, hallinnoituja palveluntarjoajia, hallinnoituja tietoturvapalveluntarjoajia, digitaalisen infrastruktuurin organisaatioita ja digitaalisia palveluntarjoajia olennaisina tai tärkeinä toimijoina toimialasta, koosta ja jäsenvaltion määrittelystä riippuen.

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä riskien hallitsemiseksi. Näihin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, hankinnan, kehittämisen ja ylläpidon turvallisuus mukaan lukien haavoittuvuuksien käsittely ja julkistaminen, vaikuttavuuden arviointi, perustason kyberhygienia ja koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta sekä MFA tai jatkuva todennus silloin, kun se on tarkoituksenmukaista.

NIS2 Article 20 edellyttää myös, että hallintoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. Olennaisten toimijoiden hallinnollinen enimmäissakko voi olla vähintään 10 miljoonaa euroa tai 2 prosenttia maailmanlaajuisesta vuotuisesta liikevaihdosta sen mukaan, kumpi on suurempi. Tärkeillä toimijoilla se voi olla vähintään 7 miljoonaa euroa tai 1,4 prosenttia.

Uhkatiedustelun osalta hallitustason kysymys on: mistä tiedämme, että esiin nousevat uhat muuttavat kontrollejamme ennen kuin niistä tulee poikkeamia?

DORA tuo lisäkerroksen finanssialan toimijoille ja asiaankuuluville kolmansille ICT-palveluntarjoajille. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se edellyttää asianmukaista, kattavaa ja hyvin dokumentoitua ICT-riskien hallintakehystä, joka on integroitu yleiseen riskienhallintajärjestelmään. DORA:n viitekehys edellyttää, että organisaatiot tunnistavat ja luokittelevat ICT:n tukemat liiketoimintatoiminnot ja omaisuuserät, suojaavat ja ehkäisevät, havaitsevat poikkeavaa toimintaa, reagoivat ja palautuvat, hallitsevat varmuuskopioita ja palauttamista, oppivat ICT-poikkeamista, viestivät kriiseissä ja hallitsevat kolmansien osapuolten ICT-riskiä.

DORA edellyttää myös ICT:hen liittyvien poikkeamien hallintaa, luokittelua ja raportointia. Articles 17, 18 ja 19 käsittelevät poikkeamien hallintaprosesseja, ICT:hen liittyvien poikkeamien ja kyberuhkien luokittelua sekä merkittävien ICT:hen liittyvien poikkeamien raportointia. Article 10 keskittyy poikkeavan toiminnan havaitsemiseen. Articles 6 to 11 kuvaavat ICT-riskien hallintakehystä sekä tunnistamista, suojaamista, ehkäisemistä, havaitsemista, reagointia ja palautumista koskevia odotuksia.

Käytännössä DORA edellyttää uhkatietoista häiriönsietokykyä. Ei staattista häiriönsietokykyä. Ei vuosittaisen politiikan varaan rakennettua häiriönsietokykyä. Uhkatietoista häiriönsietokykyä.

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmämoottorin, joka yhdistää nämä odotukset. Kohdat 4.1 to 4.4 edellyttävät, että organisaatio ymmärtää sisäisen ja ulkoisen toimintaympäristönsä, sidosryhmät, lakisääteiset ja sääntelyvelvoitteet, ISMS:n soveltamisalan, riippuvuudet ja vuorovaikutuksessa olevat prosessit. Kohdat 6.1.1 to 6.1.3 edellyttävät toistettavaa riskien arvioinnin ja riskien käsittelyn prosessia, kontrollien valintaa, vertailua liite A:han, soveltuvuuslausuntoa, käsittelysuunnittelua sekä riskinomistajan hyväksyntää jäännösriskille.

Uhkatiedustelu kuuluu tähän kokonaisuuteen. Se ei saa olla irrallinen hallintanäkymä, vaan sen on toimittava syötteenä toimintaympäristöön, riskeihin, kontrollien valintaan, riskien käsittelyyn, valvontaan, johdon katselmointiin ja jatkuvaan parantamiseen.

Vaatimustenmukaisuuden ansa: uhkasyötteet ilman päätösten jäljitettävyyttä

Yleisin epäonnistumismalli on näennäisen yksinkertainen: organisaatio vastaanottaa uhkatiedustelua, mutta ei pysty osoittamaan, miten se muuttaa päätöksiä.

Heikko näyttöketju näyttää yleensä tältä:

Tässä Clarysecin toteutusmenetelmä auttaa organisaatioita siirtymään tilanteesta ”vastaanotamme tiedustelutietoa” tilanteeseen ”muutamme tiedustelutiedon operatiiviseksi toiminnaksi”.

Teoksessa Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Controls in Action -vaihe muuntaa uhkatiedustelun nimenomaisesti auditoitavaksi käytännöksi. Step 22, organisatoriset kontrollit, toteaa:

Laadi dokumentoitu luettelo uhkatiedustelulähteistä (5.7), kuten toimittajista, ISAC-yhteisöistä tai avoimista lähteistä, ja määritä, miten tiedustelutieto validoidaan ja integroidaan päätöksentekoon. Määritä, kuka vastaanottaa uhkapäivitykset ja miten niitä sovelletaan (esim. paikkauspriorisointi, tietoisuuskoulutus). Laadi lyhyt uhkatrendikatsaus ja jaa se neljännesvuosittain keskeisille sidosryhmille.

Tämä ohje muodostaa sillan uhkatiedon ja vaatimustenmukaisuusnäytön välille. Uhkatiedustelurekisteri ei ole pelkkä lähdeluettelo. Se osoittaa relevanssin, omistajuuden, validoinnin, reitityksen, integroinnin ja liiketoimintakäytön.

ISO 27001 -kontrollilogiikka: uhkatiedusteluketju

ISO/IEC 27002:2022 -hallintakeino 5.7, Threat intelligence, edellyttää, että organisaatiot keräävät ja analysoivat tietoturvauhkia koskevaa tietoa ja käyttävät sitä uhkatiedustelun tuottamiseen. Teoksessa Zenith Controls: The Cross-Compliance Guide Zenith Controls hallintakeino 5.7 luokitellaan ennaltaehkäiseväksi, havaitsevaksi ja korjaavaksi. Se tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa Identify-, Detect- ja Respond-kyberturvallisuuskäsitteiden kanssa ja sijoittuu uhkien ja haavoittuvuuksien hallintaan operatiivisena kyvykkyytenä.

Tällä luokituksella on merkitystä. Uhkatiedustelu ehkäisee ohjaamalla koventamista, paikkausta, koulutusta ja toimittajakontrolleja. Se havaitsee muokkaamalla valvontaa, SIEM-sääntöjä ja uhkien metsästystä. Se korjaa parantamalla tietoturvapoikkeamiin reagointia, opittujen asioiden hyödyntämistä ja riskien käsittelyä.

Zenith Controls yhdistää ISO/IEC 27002:2022 -hallintakeinon 5.7 myös sitä tukeviin hallintakeinoihin:

Yhteys haavoittuvuuksiin on erityisen tärkeä. Zenith Controls käsittelee hallintakeinoa 8.8, teknisten haavoittuvuuksien hallinta, ennaltaehkäisevänä ja suoraan hallintakeinoon 5.7 liittyvänä, koska todellisen maailman uhkatiedustelu kertoo, mitä haavoittuvuuksia käytetään aktiivisesti hyväksi. Se yhdistää 8.8:n myös hallintakeinoon 8.16, seurantatoiminnot, koska havaitut hyväksikäyttöyritykset tulee eskaloida paikkauksen kiireellisyyteen.

Tästä muodostuu käytännön uhkatiedusteluketju:

1. Ulkoinen tai sisäinen tiedustelutieto saapuu.
2. Relevanssi validoidaan omaisuuseriä, toimittajia, maantieteellistä aluetta, toimialaa, liiketoimintapalveluja ja tietoja vasten.
3. Riski päivitetään.
4. Paikkaus- ja konfiguraatioprioriteetit muuttuvat.
5. Havaitsemislogiikkaa hienosäädetään.
6. Poikkeamien toimintapelikirjat ja luokittelukynnykset katselmoidaan.
7. Toimittaja- ja pilviriippuvuudet tarkistetaan.
8. Johto saa trendiraportoinnin.
9. Näyttö säilytetään auditoijia, viranomaisia ja asiakkaita varten.

Politiikat, jotka muuttavat tiedustelun vastuutetuksi toiminnaksi

Politiikat ovat paikka, jossa kontrollilogiikka muuttuu roolipohjaiseksi vastuun osoitettavuudeksi. Clarysecin pk-yrityksille ja suuryrityksille tarkoitetut politiikkakokonaisuudet sisältävät uhkatiedustelun kytkennät riskienhallintaan, päätelaitesuojaan, haavoittuvuuksien hallintaan, lokitukseen, valvontaan ja auditointinäyttöön.

Pk-yrityksille suunnattu Endpoint Protection - Malware Policy Endpoint Protection - Malware Policy - SME asettaa suoran odotuksen hallinnointivaatimusten lausekkeessa 5.4.1:

IT-tukipalveluntarjoajan tulee seurata uskottavia uhkatiedustelulähteitä (esim. CISA, ENISA, merkittävät virustorjuntatoimittajat) ja varmistaa, että havaitsemistunnisteet pysyvät ajan tasalla

Tämän lausekkeen arvo on vastuun osoittamisessa. Uhkatiedustelu ei ole ”jonkun IT:ssä pitäisi tarkistaa hälytykset”. Se on nimenomainen palveluntarjoajan velvoite.

Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy - SME vahvistaa saman mallin rooleja ja vastuita koskevassa lausekkeessa 4.2.1:

Seuraa järjestelmiä haavoittuvuuksien ja saatavilla olevien korjauspäivitysten osalta käyttäen toimittajahälytyksiä, uhkatiedustelutiedotteita ja käyttöjärjestelmätason ilmoituksia

Se tunnistaa myös politiikan toteutusvaatimusten lausekkeessa 6.2.1.3 lähdetyypin, jonka tulee käynnistää toimenpiteet:

Luotetut uhkatiedustelutiedotteet (esim. CISA, ENISA, kansalliset CERT-hälytykset)

Suuryrityksille tarkoitettu Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy toteaa rooleja ja vastuita koskevassa lausekkeessa 4.5.1:

Seuraa uhkailmoituksia (esim. CVE, CISA KEV, toimittajien tiedotteet) ja eskaloi kriittiset haavoittuvuudet.

Eskalointivaatimus on ratkaiseva. Haavoittuvuudesta tulee kiireellinen, kun hyväksikäytettävyys, altistuminen, liiketoimintakriittisyys, tietojen arkaluonteisuus ja uhkatoiminta kohtaavat.

Risk Management Policy Risk Management Policy sisällyttää uhkatiedustelun analyysiin. Politiikan toteutusvaatimusten lauseke 6.2.2 toteaa:

Analyysissä tulee huomioida olemassa olevien kontrollien tehokkuus, relevantti uhkatiedustelu, omaisuuserän kriittisyys ja haavoittuvuuden vakavuus.

Tämä lauseke on auditointivalmiin uhkatiedustelun ydin. Se osoittaa, ettei riskianalyysi ole teoreettista.

Logging and Monitoring Policy Logging and Monitoring Policy muuntaa tiedustelun havaitsemiseksi. Sen tarkoitusta koskeva lauseke 1.2 toteaa:

Auditointilokitus, seuranta ja uhkien havaitseminen ovat kriittisiä poikkeamien havaitsemiselle, uhkiin reagoinnille, forensiselle katselmoinnille, auditointivalmiudelle ja lakisääteisten vaatimusten noudattamiselle. Tämä politiikka varmistaa, että kaikki järjestelmien tuottamat tapahtumat kirjataan, säilytetään ja korreloidaan asianmukaisesti aikasynkronoidulla tarkkuudella.

Lopuksi Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy selittää, miksi näytön hallinta on tärkeää. Tavoitteita koskeva lauseke 3.4 edellyttää, että organisaatio tuottaa näyttöä:

Tuottaa puolustettavaa näyttöä ja auditointijälki viranomaistiedustelujen, oikeudellisten menettelyjen tai asiakkaiden varmentamispyyntöjen tueksi.

Kun NIS2, DORA, asiakas tai ISO-auditoija kysyy, mitä tiesitte, milloin tiesitte sen, kuka päätti ja mikä muuttui, tämä näyttöketju erottaa kypsän varmentamisen puolustautuvasta kiireestä.

Rakenna uhkatiedustelurekisteri

Kypsässä rekisterissä on kaksi tasoa: lähteiden hallinnointi ja tapahtumien seuranta. Lähteiden hallinnointi määrittää, mihin organisaatio luottaa, kuka omistaa lähteen, miten se validoidaan ja mitä toimenpiteitä se voi käynnistää.

Tapahtumien seuranta tallentaa, miten tietystä tiedotteesta tuli näyttöä. Palataan tiistaiaamun tiedostonsiirtoskenaarioon: rekisterimerkinnän tulee sisältää riittävästi tietoa riskien, reagoinnin ja vaatimustenmukaisuuspäätösten tueksi.

Tämä ei ole byrokratiaa. Se on faktapohjainen tallenne, joka osoittaa, että organisaatiolla on määritelty vastaanotto-, validointi-, luokittelu-, eskalointi- ja näyttöprosessi.

Tiedotteesta auditointinäytöksi: käytännön työnkulku

Uhkatiedustelun työnkulun on vastattava nopeasti kuuteen kysymykseen: olemmeko altistuneita, kuinka vakava tilanne on, minkä on muututtava, kuka omistaa asian, täytyykö meidän raportoida ja mitä näyttöä on säilytettävä?

1. Validoi altistuminen ja liiketoimintavaikutus

ISO/IEC 27001:2022 kohdat 4.1 to 4.4 edellyttävät, että ISMS kuvastaa organisaation todellista toimintaympäristöä, velvoitteita ja riippuvuuksia. Ensimmäinen tehtävä ei ole paikata sokkona. Ensimmäinen tehtävä on validoida altistuminen.

Kysy:

• Käytämmekö vaikutuksen kohteena olevaa teknologiaa?
• Onko se internetiin avautuva?
• Käytetäänkö sitä kriittisessä liiketoimintapalvelussa?
• Käsitteleekö se henkilötietoja?
• Ylläpitääkö sitä toimittaja tai hallinnoitu palveluntarjoaja?
• Liittyykö se DORA:n mukaiseen kriittiseen tai tärkeään toimintoon?
• Liittyykö se NIS2:n soveltamisalaan kuuluviin palveluihin?
• Onko olemassa asiakassopimuksiin perustuvia ilmoitusvelvoitteita?
• Ovatko lokit saatavilla, täydellisiä ja aikasynkronoituja?

Jos henkilötiedot voivat olla vaikutuksen kohteena, myös GDPR:n osoitusvelvollisuus tulee osaksi analyysiä. GDPR edellyttää asianmukaista käsittelyn turvallisuutta ja todennettavaa osoitusvelvollisuutta, mukaan lukien kyky arvioida, onko tapahtunut henkilötietojen tietoturvaloukkaus ja edellyttääkö se ilmoittamista.

2. Päivitä riskirekisteri

Risk Management Policy Risk Management Policy - SME antaa yksinkertaisen ajoitussäännön hallinnointivaatimusten lausekkeessa 5.1.3:

Riskit tulee katselmoida neljännesvuosittain ja päivittää, kun merkittäviä tapahtumia ilmenee.

Uskottava aktiivista hyväksikäyttöä koskeva tiedote on merkittävä tapahtuma. Päivitystä ei tule odottaa seuraavaan neljännesvuosittaiseen katselmointiin.

Tämä liittyy suoraan ISO/IEC 27001:2022 kohtien 6.1.1-6.1.3 vaatimuksiin. Organisaatio tunnistaa riskin, analysoi todennäköisyyden ja seuraukset, priorisoi riskien käsittelyn, valitsee kontrollit, ylläpitää soveltuvuuslausuntoa, laatii käsittelysuunnitelman ja hankkii jäännösriskin hyväksynnän.

3. Priorisoi haavoittuvuuden käsittely hyväksikäyttötiedustelun perusteella

Zenith Blueprint, Controls in Action -vaihe, Step 19, Technological Controls I, selittää, miksi haavoittuvuuksien hallinta on kyberhygienian ytimessä:

Haavoittuvuuksien hallinta on yksi nykyaikaisen kyberhygienian kriittisimmistä osa-alueista. Vaikka palomuurit ja virustorjuntatyökalut tarjoavat suojaa, ne voidaan kiertää, jos paikkaamattomat järjestelmät tai virheellisesti konfiguroidut palvelut jätetään altistuneiksi. Tämän hallintakeinon täyttämiseksi organisaatioiden tulee toteuttaa jäsennelty ja toistettava prosessi haavoittuvuuksien tunnistamiseen, arviointiin ja käsittelyyn.

Pelkkä CVSS ei riitä. Keskitasoiseksi pisteytetty haavoittuvuus aktiivisen hyväksikäytön kohteena internetiin avautuvassa järjestelmässä voi olla kiireellisempi kuin korkeaksi pisteytetty haavoittuvuus segmentoidussa laboratoriossa.

Tämä tuottaa puolustettavan päätöksen. Se tukee myös NIS2 Article 21(2)(e):tä haavoittuvuuksien käsittelyssä, NIS2 Article 21(2)(g):tä kyberhygieniassa sekä DORA:n ICT-riskien hallinnan odotuksia.

4. Muunna tiedustelu seurannaksi ja havaitsemiseksi

Uhkatiedustelun on ulotuttava lokitukseen ja seurantaan. Logging and Monitoring Policy Logging and Monitoring Policy - SME toteaa politiikan toteutusvaatimusten lausekkeessa 6.2.1:

Tietoturvatyökalut (esim. virustorjunta, palomuurit, VPN:t) tulee määrittää tuottamaan hälytyksiä määritellyistä uhkaskenaarioista, mukaan lukien:

Ote ilmaisee kontrollin tarkoituksen selkeästi: määriteltyjen uhkaskenaarioiden tulee ohjata hälyttämistä.

Zenith Blueprint, Controls in Action -vaihe, Step 19, kuvaa seurantatoimintoja näin:

Jos lokitus on ympäristössä tapahtuvien asioiden kirjaamista, seuranta on näiden tapahtumien havainnointia, ymmärtämistä ja niihin reagointia. Tässä hallintakeinossa on kyse verkkojen, järjestelmien ja sovellusten aktiivisesta tarkkailusta poikkeavan toiminnan havaitsemiseksi — ei vain jälkikäteen, vaan mahdollisuuksien mukaan reaaliaikaisesti tai lähes reaaliaikaisesti.

Tiedostonsiirtoskenaariossa SOC:n tai IT-palveluntarjoajan tulee:

• Lisätä tai validoida CERT- ja toimittajatiedotteen IOC:t.
• Etsiä lokeista tunnettuja hyväksikäyttöpolkuja, epäilyttäviä latauksia, web shell -indikaattoreita, poikkeavaa prosessien suoritusta ja odottamattomia ulospäin suuntautuvia yhteyksiä.
• Varmistaa, että todennus-, ylläpitotoiminta-, tiedostokäyttö-, API- ja verkkolokit säilytetään.
• Hienosäätää SIEM-hälytykset hyväksikäyttömallille.
• Luoda tapausmuistio, jossa selitetään, mitä haettiin, mitä löydettiin ja kuka katselmoi tulokset.
• Eskaloida poikkeamaluokitukseen, jos indikaattorit osoittavat vaarantumista, tietojen altistumista tai palveluvaikutusta.

Tässä poikkeamaraportoinnista tulee käytännöllistä. NIS2 Article 23 edellyttää vaiheittaista merkittävien poikkeamien raportointia, mukaan lukien varhaisvaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa, välipäivitykset pyynnöstä ja loppuraportti viimeistään kuukauden kuluttua ilmoituksesta. DORA edellyttää, että finanssialan toimijat havaitsevat, hallitsevat, luokittelevat ja raportoivat merkittävät ICT:hen liittyvät poikkeamat asetuksen ja siihen liittyvien teknisten standardien määrittämän vaiheistetun prosessin mukaisesti.

Uhkatiedustelu auttaa määrittämään, onko organisaatio edelleen haavoittuvuuteen reagoinnissa, tietoturvatapahtuman arvioinnissa vai sääntelyn alaisessa poikkeamaraportoinnissa.

Yksi työnkulku, useita vaatimustenmukaisuusvelvoitteita

Uhkatiedustelu sopii hyvin integroiduksi vaatimustenmukaisuuden työnkuluksi, koska sama näyttö tukee useita sääntely- ja viitekehyskokonaisuuksia.

NIST CSF 2.0 on erityisen hyödyllinen johdon viestinnässä. Sen ydintoiminnot Govern, Identify, Protect, Detect, Respond ja Recover muuttavat teknisen tiedustelun hallitukselle ymmärrettäväksi kokonaisuudeksi:

• Govern: uhkatiedustelulähteet, omistajat ja raportointilinjat on määritelty.
• Identify: vaikutuksen kohteena olevat omaisuuserät, toimittajat, liiketoimintapalvelut ja tiedot on kartoitettu.
• Protect: paikkaus, koventaminen, segmentointi ja päätelaitteiden tunnisteet on päivitetty.
• Detect: seurantasäännöt, IOC:t ja uhkien metsästystehtävät on otettu käyttöön.
• Respond: poikkeamien toimintapelikirjat, luokittelu- ja priorisointisäännöt sekä ilmoituskynnykset on katselmoitu.
• Recover: varmuuskopiot, palautusprioriteetit ja opitut asiat on validoitu.

Tämä muuntaa raakamuotoisen kyberuhkatiedustelun riskien hallinnoinniksi.

Auditoijan näkökulma: mitä he pyytävät

Vahvan uhkatiedusteluprosessin tulee kestää erilaiset auditointityylit. ISO-auditoija, NIS2-arvioija, DORA:n valvontaviranomainen, NIST CSF -arvioija, COBIT 2019 -suuntautunut auditoija, ISACA-ammattilainen tai tietosuojan arvioija voi käyttää eri kieltä, mutta kaikki päätyvät näyttöön.

Zenith Controls tarjoaa näihin keskusteluihin vaatimustenmukaisuuden poikittaisen tulkinnan. Hallintakeinon 8.16, seurantatoiminnot, osalta opas yhdistää seurannan GDPR:n turvallisuuteen ja loukkausten osoitusvelvollisuuteen, NIS2:n poikkeamien käsittelyyn ja raportointiin sekä DORA:n havaitsemis- ja reagointiodotuksiin. Hallintakeinon 8.8, teknisten haavoittuvuuksien hallinta, osalta se yhdistää haavoittuvuuksien käsittelyn GDPR:n käsittelyn turvallisuuteen, NIS2 Article 21(2)(e):hen ja DORA:n ennakoivaan ICT-riskien hallintaan.

Tätä näytön lähentymistä auditoijat haluavat nähdä.

Johdon raportointi: neljännesvuosittainen uhkatrendikatsaus

Uhkatiedustelurekisterin ei tule jäädä SOC:n sisälle. Zenith Blueprint suosittelee lyhyttä neljännesvuosittaista uhkatrendikatsausta keskeisille sidosryhmille. Clarysec suosittelee yhden sivun johdon raporttia, jossa on viisi osiota:

1. Kolme merkittävintä relevanttia uhkatrendiä liiketoimintavaikutuksen perusteella.
2. Eniten altistuneet teknologiat tai toimittajat.
3. Kriittiset haavoittuvuudet, jotka on paikattu, lievennetty tai hyväksytty.
4. Toteutetut havaitsemis- ja reagointiparannukset.
5. Johdolta vaadittavat päätökset.

Vahva johdon tilannekatsaus ei luettele 400 CVE:tä. Se selittää riskin muutoksen. Esimerkiksi:

• Hallinnoituihin palveluntarjoajiin kohdistuvat kiristyshaittaohjelmat nostivat toimittajakatselmointien prioriteettia.
• Tiedostonsiirtoalustojen hyväksikäyttö käynnisti hätäpaikkauksen ja kompensoivan palomuurisäännön.
• Pilvi-identiteetteihin kohdistuvat hyökkäykset johtivat MFA-poikkeusten katselmointiin ja ehdollisen pääsyn koventamiseen.
• Toimialan ISAC-tiedustelu johti uusiin tietojenkalastelusimulaatioihin taloushallinnon ja tukitiimien henkilöstölle.
• DORA:n kriittisten toimintojen kartoitus paljasti yhden valvontapuutteen kolmannen osapuolen työnkulussa.

Tämä katsaus tukee NIS2:n johdon osoitusvelvollisuutta, DORA:n ICT-riskien hallinnointia, ISO/IEC 27001:2022 -johdon katselmointia ja asiakkaiden varmentamista.

Yleiset epäonnistumismallit

Uhkatiedusteluohjelmat näyttävät usein kypsiltä dioissa mutta heikoilta auditoinnissa. Yleisimmät epäonnistumismallit ovat:

• Liian monta syötettä eikä validointikriteerejä.
• Ei yhteyttä tiedustelutiedon ja omaisuusluettelon välillä.
• Ei dokumentoitua riskipäivitystä merkittävien tiedotteiden jälkeen.
• Paikkausprioriteetti perustuu vain skannerin vakavuusarvioon.
• Toimittajatiedotteita käsitellään ISMS:n ulkopuolella.
• SOC-sääntöjä päivitetään ilman muutostallenteita.
• Poikkeamakynnyksiä ei ole yhdenmukaistettu NIS2- tai DORA-raportointityönkulkujen kanssa.
• Hallitusraportointi keskittyy hälytysmääriin eikä liiketoimintariskiin.
• Ei näyttöä siitä, että opitut asiat muuttivat kontrolleja.
• Uhkatiedustelurekisterin ylläpidolle ei ole omistajaa.

Ratkaisu ei ole uuden syötteen ostaminen. Ratkaisu on kontrollien integrointi.

10 kohdan valmiustarkistuslista vuodelle 2026

Käytä tätä tarkistuslistaa käytännön sisäisenä arviointina.

Jos vastaus johonkin näistä on ”ei”, organisaatiolla ei ole pelkästään uhkatiedusteluongelmaa. Sillä on ISMS-integraatio-ongelma.

Miten Clarysec auttaa muuttamaan uhkatiedustelun näytöksi

Clarysecin menetelmä on suunniteltu organisaatioille, jotka tarvitsevat käytännön tietoturvaa ja uskottavaa vaatimustenmukaisuutta samanaikaisesti.

Zenith Blueprint antaa 30-vaiheisen toteutuspolun, mukaan lukien Step 22 uhkatiedustelurekisterille ja Step 19 haavoittuvuuksien hallinnalle ja seurantatoiminnoille. Clarysecin suuryritys- ja pk-yrityspolitiikat muuntavat nämä odotukset roolipohjaisiksi menettelyiksi riskienhallintaan, haavoittuvuuksien käsittelyyn, päätelaitesuojaan, lokitukseen, seurantaan ja auditointinäyttöön. Zenith Controls tarjoaa tämän jälkeen vaatimustenmukaisuuden poikittaisen tulkinnan ja osoittaa, miten ISO/IEC 27002:2022 -hallintakeinot liittyvät NIS2:een, DORA:an, GDPR:ään, NIST CSF 2.0:aan, COBIT 2019:ään ja auditointinäyttöön.

Tiistaiaamun tietoturvajohtajalle vastaus talousjohtajalle selkeytyy:

”Vastaanotimme tiedotteen, validoimme altistumisen, päivitimme riskirekisterin, priorisoimme paikkauksen aktiivisen hyväksikäytön perusteella, hienosäädimme valvontaa, tarkistimme toimittajariippuvuuden, arvioimme poikkeamaraportoinnin kynnysarvot, informoimme johtoa ja säilytimme näytön. Emme arvaile. Noudatamme ISMS-järjestelmäämme.”

Tältä ISO 27001 -standardin mukaisen uhkatiedustelun tulee näyttää NIS2-kyberhygienian ja DORA:n ICT-riskinäytön osalta vuonna 2026.

Seuraavat vaiheet

Jos organisaatiosi vastaanottaa uhkatiedustelua mutta ei pysty osoittamaan, miten se muuttaa riskipäätöksiä, kontrolleja, havaitsemista, tietoturvapoikkeamiin reagointia, toimittajahallintaa ja sääntelynäyttöä, aloita tällä viikolla kolmella toimenpiteellä:

1. Rakenna tai päivitä uhkatiedustelurekisteri käyttämällä Zenith Blueprint -aineistoa, Controls in Action -vaihetta, Step 22.
2. Kartoita nykyinen prosessisi ISO/IEC 27002:2022 -hallintakeinoihin 5.7, 8.8, 8.15, 8.16, 8.7 ja 5.25 käyttämällä Zenith Controls -aineistoa.
3. Yhdenmukaista politiikkasi, erityisesti Risk Management Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy ja Audit and Compliance Monitoring Policy, jotta jokaisesta tiedotteesta voidaan tuottaa puolustettavaa näyttöä.

Clarysec voi auttaa muuntamaan uhkasyötteet, tiedotteet, toimittajailmoitukset, haavoittuvuustiedustelun ja havaitsemissignaalit ISO/IEC 27001:2022 -yhteensopivaksi, NIS2-valmiiksi ja DORA-tietoiseksi toimintamalliksi.

Lataa Clarysecin työkalupaketit, pyydä läpikäynti tai varaa valmiuden arviointi nähdäksesi, miten nykyinen uhkatiedusteluprosessisi kestäisi ISO-auditoijan, NIS2-arvioijan, DORA:n valvontaviranomaisen tai asiakkaan varmentamispyynnön.