Kyberuhkatiedon jakaminen ISO 27001:n mukaisesti vuonna 2026

Tiistaiaamuna kello 7.40 Maria, nopeasti kasvavan eurooppalaisen maksualustan tietoturvajohtaja, saa finanssipalvelualan ISAC-yhteisöltä korkean luotettavuustason tiedotteen. Tunnistetietojen varastamiseen tähtäävä kampanja kohdistuu maksupalveluntarjoajiin, jotka käyttävät tiettyä identiteetintarjoajan integraatiota. Tiedote sisältää komentopalvelinverkkotunnuksia, epäilyttäviä OAuth-sovellusten nimiä, user-agent-merkkijonoja, havaittuja toimintatapoja sekä suosituksen salaisuuksien kierrättämisestä vaikutuksen alaisissa vuokraajakohtaisissa ympäristöissä.
Muutamassa minuutissa liiketoiminta alkaa esittää kysymyksiä, jotka määrittävät kyberuhkatiedon jakamisen vuonna 2026.
SOC haluaa viedä vaarantumisindikaattorit SIEM-järjestelmään välittömästi. Lakitiimi kysyy, voiko yhtiö jakaa omaa telemetriaansa takaisin ISAC-yhteisölle. Tietosuojavastaava kysyy, sisältävätkö IP-osoitteet, käyttäjätunnukset, tikettiotteet, todennuslokit tai päätelaitetiedot henkilötietoja. Operatiivinen johtaja haluaa tietää, pitääkö asiakkaita varoittaa. Toimitusjohtaja, joka on juuri osallistunut NIS2-johdon koulutukseen, välittää hälytyksen kahdella sanalla: ”Suunnitelmamme?”
Sitten vaatimustenmukaisuuspäällikkö esittää tärkeimmän kysymyksen: ”Jos valvontaviranomainen kysyy tästä ensi kuussa, voimmeko osoittaa, että kyberuhkatiedon jakamisemme oli lainmukaista, hyväksyttyä, hyödyllistä ja hallittua?”
Tämä on uusi todellisuus. DORA on siirtynyt täytäntöönpanon määräajoista valvonnalliseen tarkasteluun. NIS2 on siirtynyt valmiushankkeista operatiiviseen yhteistyöhön. GDPR soveltuu edelleen, vaikka tiedot olisivat tietoturvatelemetriaa. Kyberuhkatiedon jakaminen ei ole enää epämuodollinen Slack-keskustelu tietoturvatiimien välillä. Se on hallinnoitu toiminto, johon liittyvät luottamuksellisuus, henkilötietojen minimointi, luovutushyväksynnät, tallenteet, viranomaisodotukset ja auditointinäyttö.
Tietoturvajohtajille, vaatimustenmukaisuuspäälliköille, auditoijille ja liiketoimintavastaaville kysymys ei ole siitä, pitäisikö kyberuhkatiedon jakamisjärjestelyihin osallistua. Todellinen kysymys on, miten tietoa jaetaan riittävän nopeasti puolustajien tukemiseksi samalla kun estetään lainvastainen luovuttaminen, asiakkaiden luottamuksellisuuden rikkominen, kilpailullisesti arkaluonteisten tietojen vuotaminen, hallitsematon haavoittuvuuksien julkaiseminen ja puutteellinen näyttö.
ISO/IEC 27001:2022 on hallintamalli, joka tekee tämän mahdolliseksi. Ei seinällä olevana sertifikaattina, vaan hallintajärjestelmänä, joka muuttaa kyberuhkatiedon jakamisen toistettavaksi, perusteltavaksi ja GDPR:n mukaiseksi toimintamalliksi.
Miksi kyberuhkatiedon jakaminen muuttui vuonna 2026
DORA- ja NIS2-valmistelujen ensimmäinen aalto keskittyi soveltamisalaan, poikkeamien raportointimääräaikoihin, ICT-kolmansien osapuolten riskiin, hallituksen vastuuseen ja puuteanalyyseihin. Tämä työ oli välttämätöntä, mutta valvontaviranomaiset ja asiakkaat esittävät nyt operatiivisempia kysymyksiä:
- Mihin ISACeihin, CERTeihin, CSIRTeihin, toimittajafoorumeihin tai luotettuihin yhteisöihin osallistutte?
- Kenellä on valtuus edustaa organisaatiota ulkoisesti?
- Miten päätätte, mitä voidaan jakaa?
- Miten estätte henkilötietojen, asiakassalaisuuksien, haavoittuvuustietojen ja arkaluonteisen arkkitehtuuritiedon luovuttamisen?
- Miten uhkatietosyötteet päivittävät valvontasääntöjä, paikkausprioriteetteja, riskirekistereitä, poikkeamien toimintapelikirjoja, toimittajakatselmointeja ja häiriönsietokyvyn testejä?
- Missä todentava näyttö on?
DORA on finanssialan toimijoille erityisen selkeä. Se käsittelee digitaalista häiriönsietokykyä hallituksen omistamana ICT-riskienhallintajärjestelmänä, ei IT-tarkistuslistana. DORAa sovelletaan 17. tammikuuta 2025 alkaen, joten vuonna 2026 monia finanssialan toimijoita arvioidaan sen perusteella, toimivatko niiden prosessit käytännössä.
DORA Article 45 sallii finanssialan toimijoiden jakaa kyberuhkia koskevia tietoja ja uhkatiedustelua, kun tarkoituksena on vahvistaa digitaalista häiriönsietokykyä. Jakamisen on tapahduttava luotetuissa yhteisöissä ja järjestelyissä, jotka suojaavat arkaluonteisia liiketoimintatietoja, henkilötietoja, luottamuksellisuutta, immateriaalioikeuksia ja kilpailuoikeudellisia rajoja. Yksinkertaisesti sanottuna DORA ei tarkoita ”jaa kaikki”. Se tarkoittaa ”jaa turvallisesti, harkitusti ja hallituissa olosuhteissa”.
NIS2 luo vastaavaa painetta finanssisektorin ulkopuolella. Sitä sovelletaan moniin keskeisiin ja tärkeisiin toimijoihin erittäin kriittisillä ja muilla kriittisillä sektoreilla, mukaan lukien digitaalinen infrastruktuuri, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, pilvipalveluntarjoajat, datakeskuspalveluntarjoajat, verkkomarkkinapaikat, hakukoneet, sosiaalisen verkostoitumisen alustat, pankkitoiminta ja rahoitusmarkkinainfrastruktuurit. NIS2 Article 20 tekee johtoelimistä vastuullisia kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä, niiden toteutuksen valvonnasta ja koulutuksen vastaanottamisesta. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta, MFA ja turvallinen viestintä. Article 23 edellyttää vaiheittaista raportointia merkittävistä poikkeamista, mukaan lukien 24 tunnin ennakkovaroitus, 72 tunnin poikkeamailmoitus ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta.
GDPR lisää tietosuojarajoitteen. Henkilötietoja ovat kaikki tiedot, jotka liittyvät tunnistettuun tai tunnistettavissa olevaan luonnolliseen henkilöön. Tietoturvalokit, IP-osoitteet, käyttäjätunnukset, sähköpostiosoitteet, päätelaitteiden nimet, todennustapahtumat, tukitiketit, haittaohjelmanäytteet, kuvakaappaukset ja petostutkinnan muistiinpanot voivat kaikki olla henkilötietoja. GDPR edellyttää lainmukaista, kohtuullista, läpinäkyvää, käyttötarkoitussidonnaista, minimoitua, täsmällistä, säilytysrajoitettua ja turvallista käsittelyä. Se edellyttää myös osoitusvelvollisuutta, eli organisaation on pystyttävä osoittamaan vaatimustenmukaisuus.
Lopputulos on hallinnointiongelma. Kyberuhkatiedon jakamisen on oltava riittävän nopeaa puolustuksen parantamiseksi, riittävän hallittua valvontaviranomaisten vaatimusten täyttämiseksi ja riittävän kurinalaista tietosuoja- ja luottamuksellisuusloukkausten välttämiseksi.
ISO 27001 kyberuhkatiedon jakamisen vaatimustenmukaisuuden perustana
ISO/IEC 27001:2022 soveltuu hyvin tähän haasteeseen, koska se alkaa toimintaympäristöstä, sidosryhmistä, soveltamisalasta, riskistä, johtajuudesta, operatiivisesta ohjauksesta, seurannasta, sisäisestä auditoinnista, johdon katselmuksesta ja jatkuvasta parantamisesta.
Kohdat 4.1–4.4 edellyttävät, että organisaatiot ymmärtävät sisäiset ja ulkoiset tekijät, tunnistavat sidosryhmät ja niiden vaatimukset, määrittävät ISMS:n soveltamisalan ja ylläpitävät hallintajärjestelmää. DORA- tai NIS2-organisaatiossa sidosryhmiä voivat olla toimivaltaiset viranomaiset, CSIRT-ryhmät, asiakkaat, ICT-palveluntarjoajat, ISACit, sektoriryhmät, käsittelijät, rekisterinpitäjät, vakuuttajat, sisäinen tarkastus ja hallitus.
Kohdat 5.1–5.3 edellyttävät johdon sitoutumista, politiikan mukaista ohjausta, vastuun osoittamista, resursseja ja määritettyjä vastuita. Tämä on olennaista, koska kyberuhkatiedon jakaminen epäonnistuu, jos se jätetään epämuodollisen teknisen harkinnan varaan. Jos SOC-analyytikko, lakimies, tietosuojavastaava, tietoturvajohtaja, viestintävastaava ja liiketoimintavastaava soveltavat kaikki eri oletuksia, organisaatio joko jakaa liikaa, lamaantuu tai reagoi liian myöhään.
Kohdat 6.1.1–6.1.3 muuttavat sääntelykysymyksen riskien arvioinniksi, riskien käsittelyksi, kontrollien valinnaksi, soveltuvuuslausunnon päätöksiksi, riskienkäsittelysuunnitelmiksi ja jäännösriskin hyväksynnäksi. Tyypillisiä kyberuhkatiedon jakamisen riskejä ovat:
- Henkilötietoja jaetaan ilman oikeusperustetta tai tietojen minimointia.
- Asiakkaan luottamuksellisia tietoja luovutetaan foorumille.
- Haavoittuvuustiedot julkaistaan ennen kuin lieventäminen on saatavilla.
- Indikaattoreita vastaanotetaan, mutta niitä ei viedä operatiiviseen käyttöön.
- ISAC-osallistuminen ei näy tietoturvapoikkeamiin reagoinnissa, lokituksessa, haavoittuvuuksien hallinnassa tai toimittajariskissä.
- Näyttö puuttuu siitä, kuka hyväksyi luovuttamisen ja miksi.
- Kilpailuoikeudellinen riski kaupallisesti arkaluonteisten markkinatietojen jakamisesta.
- Epäjohdonmukainen sääntely- ja asiakasviestintä merkittävän poikkeaman aikana.
Kohta 8.1 edellyttää tämän jälkeen, että suunnitellut prosessit toteutetaan ja pidetään hallinnassa ja että dokumentoitua tietoa on riittävästi osoittamaan prosessien toimineen suunnitellusti. Kohdat 9 ja 10 edellyttävät seurantaa, mittaamista, sisäistä auditointia, johdon katselmusta, poikkeamien käsittelyä, korjaavia toimenpiteitä ja jatkuvaa parantamista. Lyhyesti: ISO/IEC 27001:2022 muuttaa kyberuhkatiedon jakamisen auditoitavaksi toimintamalliksi.
Kaksi ISO-kontrollia, jotka tekevät jakamisesta toimivaa
Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint käsittelee tätä aihetta Kontrollit käytännössä -vaiheen osana, vaiheessa 22: organisatoriset kontrollit. Kaksi ISO/IEC 27002:2022 -kontrollia ovat keskeisiä: 5.6, yhteydenpito erityisryhmiin, ja 5.7, uhkatiedustelu.
Zenith Blueprint tekee selväksi, ettei ISAC-osallistuminen ole symbolista verkostoitumista:
Osallistuminen tällaisiin ryhmiin ei ole symbolinen ele. Se on strateginen investointi tiedusteluun, yhteistyöhön ja yhteiseen häiriönsietokykyyn.
Kontrollissa 5.6 erityisryhmiä voivat olla kansalliset tai sektorikohtaiset kyberuhkatiedusteluverkostot, ISACit, sääntelyfoorumit, toimittajien tietoturvatiedoteryhmät, avoimen lähdekoodin yhteisöt ja akateemiset työryhmät. Ulkoisen jakamisen on kuitenkin oltava tarkoituksellista, lainmukaista ja hyväksyttyä. Zenith Blueprint lisää kypsyysodotuksen:
Kypsät ISMS-toteutukset käsittelevät SIG-osallistumista hallinnoituna toimintona, eivät epämuodollisena etuna.
Tämä tarkoittaa liityttyjen ryhmien ja foorumien rekisterin ylläpitämistä, virallisten osallistujien nimeämistä, pöytäkirjojen tai yhteenvetojen tallentamista sekä havaintojen integrointia sisäisiin katselmointeihin tai kontrollipäivityksiin.
Kontrolli 5.7 muuttaa ulkoisen tiedon toiminnaksi. Zenith Blueprint toteaa:
Organisaatio ei voi puolustautua sellaista vastaan, mitä se ei ymmärrä.
Se varoittaa myös sekoittamasta paikkaussyötteitä uhkatiedusteluun. Aito tiedustelu sisältää uhkatoimijoiden profilointia, taktiikoita, tekniikoita ja menettelyjä, vaarantumisindikaattoreita, sektorikohtaisia varoituksia, haavoittuvuuskontekstia ja strategisia liiketoimintavaikutuksia. Hyödyllinen tiedustelu yhdistää sisäisen valvonnan, ulkoiset kumppanuudet, CERT- tai ISAC-suhteet, kaupalliset syötteet ja avoimen lähdekoodin lähteet, mutta vain, jos joku katselmoi, priorisoi ja muuntaa sen toiminnaksi.
Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls vahvistaa vaatimustenmukaisuuksien välisen arvon. Se kartoittaa kontrollin 5.6 ennaltaehkäiseväksi ja korjaavaksi, tukemaan luottamuksellisuutta, eheyttä ja saatavuutta, ja hallinnointi on ensisijainen operatiivinen kyvykkyys. Se kytkee 5.6:n kontrolliin 5.7 Uhkatiedustelu, 5.5 Yhteydenpito viranomaisiin, 5.31 Lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset sekä 8.8 Teknisten haavoittuvuuksien hallinta. Se kartoittaa 5.7:n ennaltaehkäiseväksi, havaitsevaksi ja korjaavaksi, yhteyteen Identify-, Detect- ja Respond-toimintojen kanssa, ja operatiivinen kyvykkyys liittyy uhkien ja haavoittuvuuksien hallintaan.
Viesti on yksinkertainen: kypsässä kyberuhkatiedon jakamisohjelmassa on kaksi puolta. Ensimmäinen on hallitut suhteet. Toinen on vastaanotetun ja jaetun tiedon hallittu käyttö.
Käytännön toimintamalli hallitulle jakamiselle
Puolustettavan vuoden 2026 toimintamallin on vastattava kuuteen kysymykseen ennen ensimmäisen indikaattorin jakamista.
| Hallinnointikysymys | Käytännön vastaus | Auditoijien odottama näyttö |
|---|---|---|
| Kuka saa osallistua? | Nimetyt roolit, hyväksytyt foorumit, varayhteyshenkilöt, valtuuksien rajat | SIG- ja ISAC-rekisteri, nimitystiedot, roolikuvaukset |
| Mitä voidaan vastaanottaa? | Uhkaraportit, IOC:t, TTP:t, haavoittuvuustiedotteet, sektorihälytykset | Vastaanottoloki, lähteen luokittelu, käsittelysäännöt |
| Mitä voidaan jakaa? | Sanitisoidut indikaattorit, ei-attribuoidut mallit, hyväksytyt tiedotteet, viranomaisvalmiit faktat | Luovutuksen hyväksyntätallenne, minimointikatselmointi, lakitoiminnon tai tietosuojavastaavan hyväksyntä |
| Miten tiedustelua käytetään? | SIEM-säännöt, EDR-estot, haavoittuvuuksien priorisointi, riskirekisterin päivitykset, toimintapelikirjojen muutokset | Muutostiketit, havaitsemissäännöt, riskipäivitykset, kokouspöytäkirjat |
| Miten tietosuoja varmistetaan? | Tietojen minimointi, pseudonymisointi, peittäminen, oikeusperusteen tarkistus, säilytysrajat | DPIA tai tietosuojakatselmointi, jakamismalli, säilytysloki |
| Miten vaikuttavuutta katselmoidaan? | Mittarit, pöytäharjoitukset, auditointihavainnot, johdon katselmointi | KPI:t, poikkeamista opitut asiat, sisäinen auditointiraportti, korjaavat toimenpiteet |
Clarysec toteuttaa tämän tyypillisesti kevyenä mutta muodollisena työnkulkuna:
- Vastaanota ja luokittele uhkatieto.
- Varmista merkityksellisyys omaisuuserien, toimittajien, palvelujen, maantieteellisten alueiden ja asiakkaiden kannalta.
- Muunna uhkatieto toiminnaksi, kuten valvontasäännöiksi, haavoittuvuustiketeiksi, käyttäjähälytyksiksi, toimittajakyselyiksi tai riskipäivityksiksi.
- Päätä, onko lähtevä jakaminen tarpeellista, lainmukaista, turvallista ja jäsenyyssääntöjen sallimaa.
- Käytä peittämistä, aggregointia, pseudonymisointia tai anonymisointia.
- Hanki vaaditut hyväksynnät.
- Jaa hyväksytyn kanavan kautta.
- Kirjaa, mitä jaettiin, kenelle, miksi, milloin ja kenen valtuutuksella.
- Katselmoi tulokset ja päivitä kontrollit.
Tämä estää kaksi klassista epäonnistumista: tietoturvatiimi vastaanottaa hyödyllistä uhkatietoa, mutta mikään ei muutu, tai tietoturvatiimi jakaa hyödyllistä uhkatietoa, mutta luo oikeudellisen, sopimusperusteisen tai tietosuojaan liittyvän riskialtistuksen.
DORA Article 45: hallittu jakaminen luottamuksellisuutta menettämättä
Finanssialan toimijoille DORA Article 45 on muunnettava sisäiseksi kyberuhkatiedon jakamisen standardiksi. Käytännön tulkintaan sisältyy viisi ehtoa.
Ensinnäkin tarkoituksen on oltava häiriönsietokyky. Jakamisen on autettava ehkäisemään, havaitsemaan, käsittelemään kyberuhkia tai palautumaan niistä. Sen ei saa laajentua hinnoitteluun, asiakasluetteloihin, markkinastrategiaan tai kaupallisesti arkaluonteiseen tiedusteluun.
Toiseksi yhteisön on oltava luotettu. Tämä tarkoittaa selkeitä jäsenyyssääntöjä, luottamuksellisuusvelvoitteita, suojattuja kanavia, pääsynhallintaa ja jatkoluovutuksen rajoituksia. ISO/IEC 27010:2015 tukee turvallista tietojenvaihtoa luottamusyhteisöissä, mukaan lukien luottamuksellisuussäännöt, vastavuoroisuus ja luotetut viestintäkanavat. ISO/IEC 27032:2023 tukee kyberturvallisuustiedon jakamista ja tilannetietoisuutta. ISO/IEC 27035-2:2023 kytkee tietojen jakamisen tietoturvapoikkeamiin reagoinnin suunnitteluun, mukaan lukien osallistuminen CERTeihin ja toimialaryhmiin.
Kolmanneksi arkaluonteinen tieto on suojattava. Tähän kuuluvat liikesalaisuudet, arkkitehtuurikaaviot, haavoittuvuustiedot, tunnistetiedot, asiakastunnisteet ja henkilötiedot. Clarysecin pk-yrityksille tarkoitettu Tiedon luokittelu- ja merkintäpolitiikka Tiedon luokittelu- ja merkintäpolitiikka - pk-yritys toteaa:
Ulkoinen jakaminen on nimenomaisesti valtuutettava ja kirjattava lokiin.
Tämä lause on DORA Article 45 -työnkulun taustalla oleva kontrolliperiaate. Organisaation on tiedettävä, mikä luokittelu soveltuu, kuka hyväksyi luovutuksen ja missä tallenne säilytetään.
Neljänneksi henkilötiedot on minimoitava. Yritystason Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka toteaa:
Vain tiettyyn, perusteltuun liiketoimintatarkoitukseen tarvittavia tietoja saa kerätä ja käsitellä.
Pk-yritysvastine, Tietosuoja- ja yksityisyydensuojapolitiikka - pk-yritys Tietosuoja- ja yksityisyydensuojapolitiikka - pk-yritys, toteaa:
Vain välttämättömät vähimmäishenkilötiedot on kerättävä ja säilytettävä.
Tämä on tärkeää, koska uhkatiedustelu houkuttelee tiimejä usein kopioimaan raakalokeja ulkoisiin kanaviin. Sen sijaan niiden on jaettava vain se, mitä vastaanottaja tarvitsee, kuten haitallinen verkkotunnus, tiiviste, aikaleimaväli, yleinen malli tai pseudonymisoitu tapausviite.
Viidenneksi organisaation on säilytettävä näyttö. DORA rakentuu dokumentoidun ICT-riskienhallinnan, poikkeamien luokittelun, raportoinnin, testauksen, kolmansien osapuolten hallinnan ja johdon vastuun ympärille. Jos jakaminen vaikuttaa tietoturvapoikkeamiin reagointiin, häiriönsietokyvyn testiskenaarioon tai toimittajariskipäätökseen, sen on näyttävä ISMS-tallenteissa.
NIS2-yhteistyö: oikeudellisesta soveltamisalasta operatiivisiin suhteisiin
NIS2 laajentaa keskustelua finanssialan toimijoiden ulkopuolelle. Sitä sovelletaan sektorin, koon ja kriittisyyden perusteella, ja sitä voidaan soveltaa koosta riippumatta myös tiettyihin toimijoihin, kuten luottamuspalvelujen tarjoajiin, DNS-palveluntarjoajiin, TLD-rekistereihin, kriittisiin toimijoihin ja verkkotunnusten rekisteröintipalveluihin.
Kyberuhkatiedon jakamisessa keskeinen oppi on hallinnointi. Article 20 tekee johtoelimistä vastuullisia kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. Article 23 edellyttää vaiheittaista raportointia merkittävistä poikkeamista.
Kyberuhkatiedon jakaminen liittyy näihin kaikkiin. Jos ISAC-tiedote osoittaa, että toimittajan hallinnoitua palvelua hyödynnetään, Article 21:n toimitusketjuodotukset tulevat merkityksellisiksi. Jos tiedustelu osoittaa käynnissä olevan merkittävän poikkeaman, Article 23:n raportointi- ja asiakasviestintätyönkulut voivat käynnistyä. Jos merkittävä kyberuhka voi vaikuttaa palvelun vastaanottajiin, organisaatio tarvitsee hallitun varoitusprosessin.
Zenith Blueprint käsittelee tätä ISMS-perusta ja johtajuus -vaiheessa, vaiheessa 5, Viestintä, tietoisuus ja pätevyys. Se suosittelee ulkoisen viestinnän suunnittelua, jossa tunnistetaan asiakkaat, valvontaviranomaiset, kumppanit ja yleisö sekä määritetään, mitä viestitään, milloin, kenen toimesta ja millä hyväksynnällä. Se antaa käytännön esimerkin poikkeamaviestinnän menettelystä, jossa tietoturvajohtaja laatii ilmoituksen, lakitoiminto katselmoi sen ja toimitusjohtaja hyväksyy sen ennen lähettämistä.
Pk-yrityksen Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka - pk-yritys toteaa:
Toimitusjohtaja (GM) vastaa kaikkien poikkeamien eskalointipäätösten, sääntelyilmoitusten ja ulkoisen viestinnän valtuuttamisesta.
Suuremmille organisaatioille yritystason Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka määrittää näytön perustason:
Kaikki poikkeamat on kirjattava Tietoturvapoikkeamien hallintajärjestelmään (SIMS), mukaan lukien:
Kun uhkatiedustelu muuttuu poikkeamaksi, asiakasvaroitukseksi, viranomaisilmoitukseksi tai ulkoiseksi tiedotteeksi, sen ei tule elää vain sähköposteissa ja keskusteluketjuissa. Se kuuluu poikkeamien hallintajärjestelmään luokittelun, toimenpiteiden, hyväksyntöjen, näytön ja opittujen asioiden kanssa.
GDPR:n mukainen luovuttaminen: jaa tiedustelua, älä tarpeettomia henkilötietoja
GDPR sallii tietoturvaoperaatiot, mutta se ei luo vapaata aluetta hallitsemattomalle telemetrian jakamiselle. Monet uhkatiedustelun artefaktit voivat sisältää henkilötietoja:
- Käyttäjätoimintaan liittyvät IP-osoitteet.
- Tietojenkalasteluyrityksissä käytetyt sähköpostiosoitteet.
- Käyttäjätunnukset, laitenimet, päätelaitetunnisteet tai asiakaskohtaisten ympäristöjen tunnisteet.
- Todennuslokit.
- Tukitiketit.
- Kuvakaappaukset.
- Petostutkinnan muistiinpanot.
- Haittaohjelmanäytteet, jotka sisältävät asiakirjoja tai henkilökohtaisia tiedostoja.
- Haavoittuvuusraportit, jotka sisältävät asiakkaan tietojen altistumista.
Clarysecin mallissa jokainen lähtevän jakamisen päätös kulkee tietosuoja- ja luottamuksellisuussuodattimen läpi.
| Suodatin | Päätöskysymys | Tyypillinen kontrollitoimi |
|---|---|---|
| Tarkoitus | Onko jakaminen tarpeen kyberpuolustusta, lakisääteistä raportointia tai koordinoitua lieventämistä varten? | Kirjaa tarkoitus jakamislokiin |
| Oikeusperuste | Onko dokumentoitu oikeusperuste tai lakisääteinen velvoite olemassa? | Lisää lakitoiminnon tai tietosuojavastaavan katselmointi henkilötiedoille |
| Minimointi | Voidaanko sama tulos saavuttaa vähemmillä kentillä? | Poista käyttäjätunnukset, sähköpostit, tikettimerkinnät ja asiakkaiden nimet |
| Pseudonymisointi | Voidaanko tunnisteet korvata tapaustunnuksilla tai tokeneilla? | Säilytä yhdistämisavain sisäisesti rajoitetulla pääsyllä |
| Luottamuksellisuus | Paljastaako sisältö arkkitehtuuria, haavoittuvuustietoja tai asiakassalaisuuksia? | Luokittele luottamukselliseksi tai erittäin luottamukselliseksi ja rajoita jakamista |
| Säilytys | Kuinka kauan jaettu tallenne ja hyväksyntänäyttö on säilytettävä? | Sovella säilytyssääntöä ja poistamisen katselmointia |
Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 5.34, Yksityisyys ja henkilötietojen suoja, on kartoitettu ennaltaehkäiseväksi ja yhdistetty luokitteluun, omaisuusluetteloon, tietojen maskaukseen, pilviturvallisuuteen, tietojen siirtoon, pääsynhallintaan, identiteetinhallintaan sekä projekti- tai muutoskatselmointiin. Se kytkeytyy myös GDPR Articles 25 ja 32:een sisäänrakennetun tietosuojan, käsittelyn turvallisuuden, salauksen, pseudonymisoinnin, pääsynhallinnan ja todennettavan hallinnoinnin kautta. Tukevia standardeja ovat ISO/IEC 27701:2021 yksityisyyden hallintaan, ISO/IEC 27018:2019 henkilötietojen suojaan julkisen pilven käsittelijäympäristöissä ja ISO/IEC 29100:2011 tietosuojaperiaatteisiin.
Kyberuhkatiedon jakamisessa tietosuojavastaavan ja tietoturvatiimin ei pidä tavata ensimmäistä kertaa kriisin aikana. Niiden on hyväksyttävä ennakolta mallit, pohjat, peittämissäännöt ja eskalointikynnykset.
Käytännön esimerkki: ISAC-hälytyksestä näyttöön perustuvaan häiriönsietokykyyn
Palataan Marian maksualustaan. ISAC-tiedote sisältää haitallisia verkkotunnuksia, epäilyttäviä OAuth-sovellusten nimiä, user-agent-merkkijonoja ja huomion siitä, että useat jäsenet ovat havainneet tilien kaappausyrityksiä talousoperaatioiden käyttäjiä vastaan. Yhtiö löytää myös omista lokeistaan kolme epäilyttävää kirjautumisyritystä.
Näin Clarysec operationalisoisi reagoinnin käyttäen ISO/IEC 27001:2022:ta, Zenith Blueprint -opasta, Zenith Controls -opasta ja politiikkatyökalupakkia.
| Vaihe | Toimi | Omistaja | Näyttö tai kontrolliyhteys |
|---|---|---|---|
| 1. Kirjaa vastaanotto | Kirjaa lähde, päivämäärä, luotettavuus, omaisuuserät, vaikutuksen alainen teknologia ja käsittelyrajoitukset | SOC-analyytikko | Uhkatiedon vastaanottoloki, ISO/IEC 27002:2022 -kontrolli 5.7 |
| 2. Luokittele | Merkitse tiedote Luottamukselliseksi tai Erittäin luottamukselliseksi, jos se sisältää arkaluonteisia jäsentietoja | Tietoturvavastaava | Tietojen luokittelutallenne, ulkoisen jakamisen valtuutussääntö |
| 3. Varmista merkityksellisyys | Tarkista identiteetti-integraation tuotantokäyttö, altistuneet käyttäjät, OAuth-myönnöt, DNS, välityspalvelin, EDR ja SIEM-lokit | SOC ja alustatiimi | Triage-muistiinpanot, valvontanäyttö, haavoittuvuuskatselmointi |
| 4. Muunna toiminnaksi | Lisää havaitsemiset, katselmoi myönnöt, kierrätä salaisuudet tarvittaessa, kysy toimittajalta, päivitä riskirekisteri | SOC, tekninen tiimi, riskinomistaja | SIEM-sääntötiketit, muutostallenteet, toimittajaeskalointi |
| 5. Katselmoi lähtevä jakaminen | Pelkistä raakalöydökset aikaikkunaksi, malliksi, haitalliseksi verkkotunnukseksi ja vaikutuksen alaiseksi roolityypiksi | Tietoturvajohtaja, lakitoiminto, tietosuojavastaava | Luovutushyväksyntä, minimointiarviointi |
| 6. Jaa turvallisesti | Lähetä vain hyväksytty uhkatieto ISACin salatun kanavan kautta | Tietoturvajohtaja tai delegoitu henkilö | Jakamisloki, kanavatallenne, hyväksynnän aikaleima |
| 7. Paranna | Raportoi mittarit ja opitut asiat ISMS-katselmuksessa | Tietoturvajohtaja ja GRC | Johdon katselmuksen pöytäkirjat, korjaavat toimenpiteet |
Lähtevä viesti sisältää alun perin aikaleimoja, lähde-IP-osoitteita, kohdekäyttäjätunnuksia, asiakaskohtaisten ympäristöjen tunnisteita ja kuvakaappauksia. Tietosuojavastaavan ja lakitoiminnon katselmoinnin jälkeen se supistetaan seuraaviin:
- Aikaikkuna UTC-aikana.
- Hyökkäysmalli.
- Havaittu haitallinen verkkotunnus.
- Yleinen vaikutuksen alainen roolityyppi, kuten talousoperaatioiden käyttäjät.
- Ei käyttäjätunnuksia.
- Ei asiakaskohtaisten ympäristöjen tunnisteita.
- Ei kuvakaappauksia.
- Ei asiakkaiden nimiä.
- Ei raakalokeja, ellei niitä pyydetä hallitun kanavan kautta.
Jos toiminnasta tulee poikkeama, Tietoturvapoikkeamien hallintapolitiikan kontrollit ottavat ohjauksen. Jos forensisia artefakteja kerätään, sovelletaan pk-yrityksen Todisteiden keräämisen ja forensiikan politiikkaa Todisteiden keräämisen ja forensiikan politiikka - pk-yritys:
Jokainen digitaalisen todistusaineiston kohde on kirjattava seuraavilla tiedoilla:
Politiikka jatkuu sisäisesti todistusaineiston metatietovaatimuksiin, mutta auditointiperiaate on selvä: jokainen tutkinnassa, jakamisessa, viranomaisraportoinnissa tai asiakasviestinnässä käytetty artefakti tarvitsee jäljitettävyyden.
Haavoittuvuuksien julkistaminen ei ole sama asia kuin kyberuhkatiedon jakaminen
Yleinen virhe on käsitellä haavoittuvuuden julkistamista, poikkeamailmoitusta ja kyberuhkatiedon jakamista samana prosessina. Ne limittyvät, mutta eivät ole identtisiä.
Kyberuhkatiedon jakaminen voi koskea indikaattoreita, taktiikoita, sektorivaroituksia, vastapuolen käyttäytymistä, lievennyksiä tai havaittuja yrityksiä. Haavoittuvuuksien koordinoitu julkistaminen koskee tiettyä heikkoutta tuotteessa tai palvelussa, usein ilmoittajaa, korjausaikataulua, tiedotetta ja julkista julkistamispäätöstä. Poikkeamailmoitus koskee sääntelyyn tai sopimukseen perustuvaa raportointia tapahtumasta, joka vaikuttaa palveluihin, tietoihin tai asiakkaisiin.
Clarysec erottaa nämä työnkulut mutta pitää ne kytkettyinä ISMS:n kautta. Yritystason Haavoittuvuuksien koordinoidun julkistamisen politiikka Haavoittuvuuksien koordinoidun julkistamisen politiikka toteaa:
Koordinointi ja julkistaminen: Organisaation tulee koordinoida julkinen julkistaminen ilmoittajan kanssa. Oletusarvoisesti haavoittuvuustietoja ei saa julkistaa ennen kuin korjaus tai lieventäminen on saatavilla tai vähintään käynnissä. Kriittisissä ongelmissa, joissa korjausta ei voida toimittaa nopeasti, organisaatio voi antaa tietoturvatiedotteen ja kiertotapaan perustuvat ohjeet käyttäjien varoittamiseksi, tarvittaessa asiaankuuluvia viranomaisia kuullen. Ilmoittajan odotetaan pidättäytyvän julkisesta julkistamisesta, kunnes organisaatio antaa luvan tai julkaisee tiedotteen. Yleisenä sääntönä organisaatio pyrkii julkaisemaan tiedotteen 90 päivän kuluessa raportin vastaanottamisesta tai muussa keskinäisesti sovitussa määräajassa alan käytännön mukaisesti, mukaan lukien ilmoittajan mainitseminen, jos suostumus on annettu.
Sama politiikka toteaa myös:
Luottamuksellisuus: Julkiseen julkistamiseen asti kaikkia ilmoitettuun haavoittuvuuteen liittyviä tietoja on käsiteltävä Erittäin luottamuksellisina. Tietoja saa jakaa sisäisesti vain tarpeellisuusperiaatteen mukaisesti henkilöstölle, jonka on validoitava tai korjattava ongelma. Ilmoittajan henkilöllisyys on pidettävä luottamuksellisena, jos sitä pyydetään. Kaikki viestintä ilmoittajan kanssa tulee salata, mukaan lukien organisaation PGP-avaimen käyttö, arkaluonteisten haavoittuvuustietojen suojaamiseksi.
Tämä on ratkaisevaa DORA Article 45:n ja NIS2-yhteistyön kannalta. Luotettu yhteisö voi olla oikea paikka jakaa lievennyksiä tai ylätason indikaattoreita, mutta ei välttämättä hyväksikäyttötietoja, asiakaskohtaisia tietoja tai paikkaamattomia haavoittuvuustietoja.
Ulkoinen viestintä tarvitsee saman kurinalaisuuden. Yritystason Sosiaalisen median ja ulkoisen viestinnän politiikka Sosiaalisen median ja ulkoisen viestinnän politiikka osoittaa sisällön katselmointivastuun, jotta varmistetaan vaatimustenmukaisuus luottamuksellisuutta, sisäpiiritietojen julkistamista, immateriaalioikeuksia ja kunnianloukkausta koskevien lakien kanssa. Tämä on tärkeää, kun teknisestä tiedotteesta tulee julkinen kannanotto, asiakasilmoitus, verkkosivustopäivitys tai viranomaiselle suunnattu viesti.
Vaatimustenmukaisuuksien välinen kartoitus: yksi työnkulku, monta velvoitetta
Vahvan kyberuhkatiedon jakamisen työnkulun on täytettävä useiden viitekehysten vaatimukset ilman päällekkäisiä prosesseja.
| Viitekehys | Mitä se odottaa | Miten Clarysec kartoittaa sen |
|---|---|---|
| ISO/IEC 27001:2022 | Toimintaympäristö, johtajuus, riskien käsittely, operatiivinen ohjaus, dokumentoitu näyttö, seuranta, auditointi, jatkuva parantaminen | ISMS:n soveltamisala, riskirekisteri, soveltuvuuslausunto, viestintäsuunnitelma, sisäinen auditointi, johdon katselmointi |
| ISO/IEC 27002:2022 -kontrollit 5.6 ja 5.7 | Hallinnoitu yhteydenpito erityisryhmiin ja toiminnaksi muunnettava uhkatiedustelu | SIG-rekisteri, uhkatiedon vastaanotto, analyysityönkulku, havaitsemispäivitykset, jakamishyväksynnät |
| DORA Article 45 | Luotettu kyberuhkatiedon jakaminen, joka suojaa luottamuksellisuuden, henkilötiedot, liikesalaisuudet, immateriaalioikeudet ja kilpailuoikeudelliset rajat | Hyväksytyt yhteisöt, luovutusehdot, lakitoiminnon ja tietosuojavastaavan katselmointi, suojatut kanavat, näyttölokit |
| NIS2 Articles 20, 21 ja 23 | Hallituksen valvonta, kyberturvallisuuden riskienhallintatoimenpiteet, yhteistyö, poikkeamien käsittely, toimitusketjun turvallisuus, haavoittuvuuksien käsittely, vaiheittainen raportointi | Hallitusraportointi, poikkeamaviestintä, toimittajaeskalointi, CSIRT-yhteystietoluettelo, uhkalähtöiset riskipäivitykset |
| GDPR Articles 5, 6, 25 ja 32 | Henkilötietojen lainmukainen, minimoitu, käyttötarkoitussidonnainen, turvallinen ja osoitusvelvollinen käsittely | Tietosuojasuodatin, peittäminen, pseudonymisointi, säilytyssäännöt, tietosuojavastaavan katselmointi, jakamisloki |
| NIST CSF 2.0 | GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-tulokset oikeudellisten velvoitteiden ja viestintäkanavien kanssa | Organisaatioprofiili, nyky- ja tavoitetila, havaitsemisen ja reagoinnin parannukset, ulkoisten sidosryhmien viestintä |
| COBIT 2019 | Ulkoisten vaatimusten seuranta, tietoturvauhkien hallinta, kontrollien tehokkuuden arviointi, tietosuojan hallinta | Vaatimustenmukaisuuden seuranta, uhkamittarit, hallinnointiraportointi, tietosuojaohjelman yhdenmukaistaminen |
NIST CSF 2.0 on hyödyllinen neutraalina jäsentelykerroksena, koska sen GOVERN-toiminto käsittelee sidosryhmiä, oikeudellisia velvoitteita, riippuvuuksia, riskinottohalukkuutta, rooleja, politiikkoja ja valvontaa. Sen DETECT- ja RESPOND-toiminnot odottavat seurantaa, uhkatiedustelun integrointia, poikkeaman julistamista, todistusaineiston säilyttämistä, ilmoittamista ja ulkoista viestintää.
COBIT 2019 lisää johdon vastuun. Käytännöt, kuten DSS05.04 Manage security threats, APO12 Manage risk, MEA03 Managed compliance with external requirements ja APO13 Managed security, auttavat auditoijia testaamaan, parantaako tiedustelu kontrollien suorituskykyä ja hallinnointiraportointia.
Miten auditoijat testaavat jakamisohjelmaanne
ISO/IEC 27001:2022 -auditoija aloittaa hallintajärjestelmästä. Hän kysyy, miten oikeudelliset, sääntelyyn perustuvat, sopimusperusteiset ja sidosryhmävaatimukset tunnistettiin kohtien 4.1 ja 4.2 mukaisesti. Hän tarkistaa, kuuluuko kyberuhkatiedon jakaminen soveltamisalaan, onko riskit arvioitu, sisältyvätkö kontrollit 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15 ja 8.16 soveltuvuuslausuntoon tai onko niiden poisjättö perusteltu, ja osoittaako näyttö, että prosessi toimi suunnitellusti.
DORA-painotteinen auditoija tai valvontaviranomainen etsii hallinnointia, hallituksen vastuuta, ICT-riskin integrointia, poikkeamien luokittelua, häiriönsietokyvyn testausta, kolmansien osapuolten vaikutuksia ja Article 45:n ehtoja. Hän kysyy, onko osallistuminen tietojenvaihtojärjestelyihin dokumentoitu, suojataanko arkaluonteiset tiedot ja henkilötiedot, päivittääkö tiedustelu ICT-riskienhallinnan viitekehystä ja vaikuttaako se testiskenaarioihin.
NIS2-suuntautunut katselmoija keskittyy hallituksen valvontaan, Article 21:n toimenpiteisiin, poikkeamien käsittelyyn, toimittajariippuvuuksiin, haavoittuvuuksien käsittelyyn, asiakas- tai palvelun vastaanottajaviestintään sekä yhteistyöhön CSIRT-ryhmien tai toimivaltaisten viranomaisten kanssa. Hän testaa, onko uhkatiedustelu kytketty merkittävän poikkeaman arviointiin ja vaiheittaiseen raportointiin.
Tietosuojan auditoija keskittyy GDPR-periaatteisiin. Hän kysyy, olivatko jaetut tiedot henkilötietoja, mikä oikeusperuste soveltui, toteutettiinko minimointi, olisiko pseudonymisointi tai peittäminen ollut mahdollista, oliko säilytys hallinnassa ja pystyykö organisaatio osoittamaan osoitusvelvollisuuden.
Hyvä näyttö sisältää:
- Hyväksytty ISAC- tai SIG-rekisteri.
- Nimetyt osallistujat ja varahenkilöt.
- Jäsenyysehdot ja luottamuksellisuusvelvoitteet.
- Uhkatiedon vastaanottoloki.
- Triage- ja merkityksellisyysarvioinnit.
- Havaitsemistekniikan tiketit.
- Haavoittuvuuksien priorisointimuutokset.
- Toimittajariskin eskaloinnit.
- Luovutushyväksyntöjen tallenteet.
- Tietosuojavastaavan tai tietosuojakatselmoinnin muistiinpanot.
- Peitetyt lähtevät viestit.
- Poikkeamatallenteet SIMS-järjestelmässä.
- Todistusaineiston hallussapitoketjulokit.
- Johdon katselmuksen pöytäkirjat.
- Sisäisen auditoinnin havainnot ja korjaavat toimenpiteet.
Yleiset kompastuskivet, joita Clarysec näkee kentällä
Yleisin epäonnistuminen on epämuodollinen osallistuminen. Tietoturvainsinööri liittyy yksityiseen foorumiin, saa hyödyllistä uhkatietoa ja jakaa sisäisiä havaintoja ilman muodollista valtuutusta. Tarkoitus on hyvä, mutta näyttöketju on heikko ja luottamuksellisuusriski korkea.
Toinen epäonnistuminen on passiivinen kuluttaminen. Organisaatio tilaa syötteitä, osallistuu ISAC-puheluihin ja välittää tiedotteita, mutta kukaan ei pysty osoittamaan, miten tiedustelu muutti kontrolleja. Uhkatiedustelun on päivitettävä havaitsemislogiikkaa, paikkausprioriteetteja, toimintapelikirjoja, riskirekistereitä, toimittajakatselmointeja, tietoisuuskampanjoita tai häiriönsietokyvyn testejä.
Kolmas epäonnistuminen on raakalokien jakaminen. Tiimit lähettävät kuvakaappauksia, SIEM-vientejä, sähköpostiotsakkeita tai pakettikaappauksia ulkoisesti ilman minimointia. Tämä voi paljastaa henkilötietoja, asiakastunnisteita, sisäisiä isäntänimiä, tokeneita tai luottamuksellista arkkitehtuuria.
Neljäs epäonnistuminen on suhdetoiminnan sekoittaminen säänneltyyn viestintään. LinkedIn-julkaisu hyökkäystrendistä ei ole sama asia kuin asiakasvaroitus, viranomaisilmoitus, CSIRT-päivitys tai koordinoitu tiedote. Clarysec erottaa nämä kanavat, osoittaa hyväksyntävastuulliset ja edellyttää tallenteita.
Viides epäonnistuminen on toimittajien sivuuttaminen. Monet tiedusteluhälytykset koskevat kolmannen osapuolen ohjelmistoja, pilvialustoja, hallinnoituja palveluntarjoajia tai identiteetti-integraatioita. DORA:n, NIS2:n, NIST CSF:n, COBIT 2019:n ja ISO/IEC 27002:2022:n toimittajakontrollien nojalla uhkatiedustelun on syötettävä toimittajariskien hallintaan.
Rakenna vuoden 2026 kyberuhkatiedon jakamispaketti
Useimmat organisaatiot eivät tarvitse raskasta erillistä byrokratiaa. Ne tarvitsevat tiiviin hallinnointipaketin, joka toimii todellisen poikkeaman aikana. Clarysec suosittelee:
- Kyberuhkatiedon jakamismenettely.
- Hyväksyttyjen jakamisyhteisöjen rekisteri.
- Uhkatiedon vastaanotto- ja triage-lomake.
- Lähtevän luovutuksen hyväksyntälomake.
- Tietosuoja- ja luottamuksellisuuskatselmoinnin tarkistuslista.
- Ulkoisen viestinnän matriisi.
- ISAC-kokousyhteenvetopohja.
- Todistusaineiston ja poikkeamien yhteyssäännöt.
- Mittaristo.
- Sisäisen auditoinnin testaussuunnitelma.
Menettelyssä on viitattava ISO/IEC 27001:2022:n riskienhallinnan, viestinnän, operatiivisen ohjauksen, suorituskyvyn arvioinnin, sisäisen auditoinnin ja jatkuvan parantamisen kohtiin. Sen on kartoituduttava ISO/IEC 27002:2022 -kontrolleihin 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16 ja asiaankuuluviin toimittajakontrolleihin. Sen on viitattava myös DORA Article 45:een, NIS2-yhteistyöhön ja poikkeamaviestintävelvoitteisiin sekä GDPR-periaatteisiin.
Tärkeintä on, että menettelyä voidaan käyttää paineen alla. Jos prosessi edellyttää 12 henkilön kokousta ennen haitallisen verkkotunnuksen jakamista luotetulle ISAC-yhteisölle, se epäonnistuu. Jos se sallii asiakkaiden raakalokien liittämisen yhteisöportaaliin, se epäonnistuu myös. Tavoitteena on hallittu nopeus.
Muuta kyberuhkatiedon jakaminen näyttöön perustuvaksi häiriönsietokyvyksi
Kyberuhkatiedon jakaminen vuonna 2026 ei ole pelkkä tietoturvan kypsyysmerkki. Finanssialan toimijoille se liittyy DORA Article 45:een ja digitaaliseen häiriönsietokykyyn. Keskeisille ja tärkeille toimijoille se tukee NIS2-yhteistyötä, poikkeamien käsittelyä, haavoittuvuuksiin reagointia, toimittajaturvallisuutta ja palvelun vastaanottajien varoittamista. Kaikille EU:n henkilötietoja käsitteleville organisaatioille sen on oltava suunnitellusti GDPR:n mukaista.
Clarysec auttaa organisaatioita rakentamaan tämän toimintamallin hidastamatta puolustajia. Yhdistämme Zenith Blueprint -oppaan Zenith Blueprint, politiikkatyökalupakin ja Zenith Controls -oppaan Zenith Controls toimivaksi ISMS-prosessiksi: hyväksytyt yhteisöt, selkeät roolit, tietosuojaturvallinen luovuttaminen, poikkeamayhteys, näyttötallenteet, auditointivalmius ja viitekehysten välinen kartoitus.
Jos organisaationne osallistuu ISACiin, vastaanottaa kybertiedotteita, jakaa indikaattoreita vertaistahojen kanssa, raportoi viranomaisille tai käsittelee haavoittuvuuksien julkistamista, nyt on aika virallistaa työnkulku. Aloittakaa tunnin katselmoinnilla nykyisistä jakamisjärjestelyistä ja kartoittakaa ne sitten ISO/IEC 27001:2022:een, DORA Article 45:een, NIS2:een ja GDPR:ään.
Clarysec voi auttaa rakentamaan rekisterin, politiikkalausekkeet, hyväksyntäpohjat, auditointinäyttömallin ja johdon raportointipaketin, joita tarvitaan, jotta kyberuhkatiedon jakaminen on nopeaa, lainmukaista ja perusteltavissa.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


