Uhkamallinnus ISO 27001-, NIS2- ja DORA-vaatimusten tueksi
Anya, nopeasti kasvavan fintech-yhtiön tietoturvajohtaja, sai hyväksyttäväkseen uuden B2B-maksuriskialustan lanseeraussuunnitelman. Hallitus halusi markkinoille ennen vuosineljänneksen loppua. Myynti oli jo valmistellut pankkiasiakkuuksia. Kehitysorganisaatio oli luonnostellut pilvinatiivin arkkitehtuurin, jossa oli identiteettiattribuutteja, laitesignaaleja, transaktiometatietoja, käyttäytymiseen perustuvia riskipisteitä, hallittu tietokanta ja kolmannen osapuolen analytiikkapalveluntarjoaja.
Paperilla alusta näytti kaupalliselta läpimurrolta. Anyalle se näytti viideltä samanaikaiselta vaatimustenmukaisuuskeskustelulta.
Finanssiteknologian palveluntarjoajana yhtiöön kohdistui DORA-paine. Pilvipalveluna ja digitaalisena alustapalveluntarjoajana sen oli ymmärrettävä NIS2-altistuksensa. Koska alusta käsitteli EU:ssa oleviin henkilöihin liittyviä henkilötietoja, GDPR soveltui siihen. Yritysasiakkaat odottivat ISO/IEC 27001:2022 -sertifiointia. Jos palvelusta tulisi osa verkottunutta ohjelmistotuotetta, Cyber Resilience Act toisi mukaan sisäänrakennettua tietoturvaa koskevan tuotenäytön.
Kehitystiimi ehdotti tavanomaista tietoturvasuunnitelmaa: riippuvuudet skannataan, haavoittuvuusskannaus tehdään, penetraatiotesti varataan ja kriittiset havainnot korjataan ennen tuotantokäyttöönottoa. Anya tiesi, ettei se riittäisi. Nämä toimet testaavat sitä, mikä on jo rakennettu. Ne eivät osoita, että arkkitehtuuri on suunniteltu tietoturvalliseksi, että luottamusrajat on ymmärretty, että henkilötietovirrat on minimoitu, että toimittajaoletukset on katselmoitu tai että palveluhäiriöskenaariot on huomioitu ennen lanseerausta.
Siksi hän pysäytti kokouksen neljällä kysymyksellä:
- Missä luottamusrajat ovat?
- Mitkä väärinkäyttötapaukset voisivat johtaa petokseen, tietojen paljastumiseen tai palveluhäiriöön?
- Mitkä suunnittelupäätökset pienentävät riskiä ennen kuin koodia kirjoitetaan?
- Mikä näyttö riittää ISO 27001-, NIS2-, DORA-, CRA- ja GDPR-arvioijille kuuden kuukauden kuluttua?
Neljäs kysymys on kohta, jossa moni organisaatio epäonnistuu. Uhkamallinnusta käsitellään usein hyödyllisenä kehitystyöpajana, minkä jälkeen se hautautuu wiki-sivulle. Vuonna 2026 se ei riitä. SaaS-palveluntarjoajille, fintech-yhtiöille, pilvialustoille, MSP- ja MSSP-palveluntarjoajille, digitaalisen infrastruktuurin operaattoreille ja ohjelmistovalmistajille uhkamallinnuksesta on tullut vaatimustenmukaisuusnäytön moottori.
Kypsä uhkamallinnusprosessi muuntaa STRIDE-havainnot, väärinkäyttötapaukset ja arkkitehtuuripäätökset riskirekisterimerkinnöiksi, tietoturvavaatimuksiksi, riskienkäsittelysuunnitelmiksi, testitapauksiksi, toimittajien varmentamistehtäviksi, sisäänrakennetun tietosuojan näytöksi ja soveltuvuuslausunnon jäljitettävyydeksi.
Miksi sisäänrakennetun tietoturvan näyttö on nyt tärkeää
Nykyaikaiset säädökset lähestyvät samaa odotusta: organisaatioiden on tunnistettava tietoturva- ja tietosuojariskit varhaisessa vaiheessa, osoitettava omistajuus, toteutettava oikeasuhtaiset kontrollit ja säilytettävä näyttö.
ISO/IEC 27001:2022 edellyttää riskiperusteista tietoturvallisuuden hallintajärjestelmää. Kohdat 6.1.2 ja 6.1.3 edellyttävät tietoturvariskien arviointia ja käsittelyä. Kohta 8.1 edellyttää toiminnan suunnittelua ja ohjausta. Liite A sisältää kontrollit, jotka on valittava soveltuvuuslausunnon kautta riskin, lakisääteisten vaatimusten ja liiketoimintatarpeiden perusteella.
NIS2 tuo saman periaatteen kyberturvallisuuden hallinnointiin. Article 20 edellyttää, että johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niiden toteutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, hankinnan, kehittämisen ja ylläpidon tietoturva, haavoittuvuuksien käsittely, kyberhygienia, salaus, pääsynhallinta, omaisuudenhallinta ja tarvittaessa MFA.
DORA soveltaa finanssialan operatiivisen häiriönsietokyvyn näkökulmaa 17. tammikuuta 2025 alkaen. Se edellyttää soveltamisalaan kuuluvilta finanssiyhteisöiltä vakaata, kattavaa ja dokumentoitua ICT-riskienhallinnan viitekehystä, ICT-omaisuuserien ja riippuvuuksien tunnistamista, suojaavien ja ennaltaehkäisevien toimenpiteiden soveltamista, poikkeavan toiminnan havaitsemista, digitaalisen operatiivisen häiriönsietokyvyn testaamista, ICT-kolmansien osapuolten riskien hallintaa sekä reagointi- ja palautumiskyvykkyyksien valmistelua. Soveltamisalaan kuuluville finanssiyhteisöille DORA on alakohtainen unionin säädös päällekkäisiin NIS2-velvoitteisiin nähden.
GDPR lisää osoitusvelvollisuuden sekä sisäänrakennetun ja oletusarvoisen tietosuojan. Jokaisen henkilötietoja käsittelevän järjestelmän on pystyttävä osoittamaan lainmukainen, kohtuullinen, läpinäkyvä, käyttötarkoitussidonnainen, minimoitu, säilytysajaltaan rajattu ja turvallinen käsittely. Uhkamalli, joka kuvaa henkilötietovirrat, käyttöreitit, lokit, säilytyksen, poistamisen ja siirrot kolmansille osapuolille, liittyy suoraan GDPR:n Articles 5, 25, 32 ja 35 vaatimuksiin.
Cyber Resilience Act lisää painetta tuotteille, joissa on digitaalisia elementtejä. Tuotetiimit tarvitsevat elinkaaren kattavaa näyttöä siitä, että kyberturvallisuusriskit, ennakoitavissa oleva väärinkäyttö, rajapinnat, päivitysmekanismit, todennusvirrat ja haavoittuvuuksien käsittelyä koskevat oletukset on huomioitu varhaisessa vaiheessa.
Opetus on selvä: jos arkkitehtuurikatselmointia ei voida jäljittää riskeihin, kontrolleihin, omistajiin, lieventämistoimiin ja testeihin, sitä on vaikea puolustaa vuoden 2026 auditoinnissa tai sääntelytarkastelussa.
Clarysecin malli: yksi uhkamalli, monta tuotosta
Clarysecin lähestymistapa alkaa käytännön periaatteesta: uhkamalli ei ole valmis ennen kuin se tuottaa auditoitavissa olevia päätöksiä.
Julkaisussa Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] riskienhallintavaiheen vaihe 9 antaa tiimeille yksinkertaisen muodon teknisten havaintojen muuntamiseen riskikielelle:
”Yhdistä nyt omaisuuserä + uhka + haavoittuvuus tiiviiksi riskiskenaarion kuvaukseksi. Kuvaa käytännössä mahdollinen poikkeama. Tästä tulee myöhemmin rivimerkintä riskirekisteriin. Käytä yksinkertaista muotoa: ’[Uhka] hyödyntää [haavoittuvuutta] kohteessa [omaisuuserä], mikä johtaa [vaikutukseen].’”
Tämä lause muodostaa sillan kehitystyön ja vaatimustenmukaisuuden välille.
Valkotaulumerkintä, kuten ”kumppanin API:n spoofing-riski”, muuttuu muotoon:
”Hyökkääjä hyödyntää heikkoa kumppani-API:n todennusta transaktioriski-API:ssa, mikä johtaa luvattomaan pääsyyn maksuriskipäätöksiin ja henkilötietojen paljastumiseen.”
Nyt havainnolla on omaisuuserä, uhka, haavoittuvuus ja vaikutus. Se voidaan arvioida, osoittaa omistajalle, käsitellä, testata ja hyväksyä.
Politiikkataso tekee tästä toistettavaa. P24 Turvallisen kehityksen politiikka [P24] toteaa:
”Kaikille uusille sovelluksille ja merkittäville muutoksille on tehtävä turvallisen arkkitehtuurin katselmointi ja uhkamallinnus ennen kehityksen aloittamista.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.1.
Se edellyttää myös seuraavaa:
”Suunnittelukatselmoinneissa on dokumentoitava tietovirtakaaviot, luottamusrajat ja tunnistettujen riskien lieventämistoimet.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.2.
Nämä kaksi lauseketta ovat vahvoja auditoinnin ankkureita. Ne osoittavat, että uhkamallinnus ei ole valinnaista ja että suunnittelunäytön on sisällettävä kaaviot, rajat ja lieventämispäätökset.
P06 Riskienhallintapolitiikka [P06] liittää uhkamallinnuksen organisaation riskienhallintaan:
”Kaikkien liiketoimintayksiköiden tulee tunnistaa riskejä ennakoivasti ISO/IEC 27005:2024 -standardiin perustuvilla jäsennellyillä tekniikoilla, mukaan lukien uhkamallinnus, omaisuusriippuvuuksien kartoitus ja skenaariopohjainen tunnistaminen.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.1.
Se toteaa myös:
”Tunnistetut riskit on dokumentoitava viittaamalla omaisuuden omistajaan, uhkatoimijaan, haavoittuvuuteen ja mahdolliseen vaikutukseen luottamuksellisuuteen, eheyteen ja saatavuuteen (CIA).”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.4.
Tämä on näyttöketju, jonka auditoijat haluavat nähdä: politiikkavaatimus, suunnittelutoimi, riskiskenaario, kontrollin valinta, toteutus, testaus ja hyväksyntä.
STRIDE tekee kattavuudesta järjestelmällistä, väärinkäyttötapaukset tekevät siitä todellista
STRIDE on edelleen yksi hyödyllisimmistä menetelmistä suunnitteluvaiheen uhkamallinnukseen, koska se pakottaa tiimit käsittelemään kuutta yleistä vikaantumistapaa:
- Identiteetin väärentäminen
- Tietojen luvaton muuttaminen
- Kiistämisen mahdollisuus
- Tietojen paljastuminen
- Palvelunestotilanne
- Käyttöoikeuksien korotus
Anyan maksuriskialustan osalta tiimi käytti STRIDE-menetelmää jokaisessa komponentissa, tietovirrassa ja luottamusrajassa.
Identiteetin väärentäminen nosti esiin kysymyksen siitä, voisiko kumppanin API-asiakas esiintyä pankkiasiakkaana, jos keskinäinen todennus olisi heikko. Tietojen luvaton muuttaminen paljasti riskin, että laitesignaaleja tai transaktiomääriä voitaisiin manipuloida ennen sisäänlukua. Kiistämisen mahdollisuus korosti ylläpitäjä- ja transaktioauditointilokien tarvetta. Tietojen paljastuminen kohdistui lokien, analytiikkavientien, tukityökalujen ja raportointi-API:en kautta tapahtuvaan tietovuotoon. Palvelunestotilanne pakotti tiimin huomioimaan transaktioiden huippuajat ja virheellisesti muotoiltujen pyyntöjen tulvat. Käyttöoikeuksien korotus toi esiin tukirooleihin, istuntotunnisteisiin ja hallinnollisiin toimintoihin liittyviä riskejä.
Väärinkäyttötapaukset muunsivat nämä luokat todellisiksi tarinoiksi:
- Petoksen tekijä lataa manipuloituja laitesignaaleja vaikuttaakseen riskipisteytykseen.
- Vaarantunut kumppanitunnistetieto tulvii API:n vilpillisillä pyynnöillä.
- Kehittäjä käyttää tuotannon henkilötietoja testiympäristössä.
- Pahantahtoinen sisäpiiriläinen vie asiakastunnisteita ja pisteytyslogiikkaa.
- Pilvianalytiikan toimittajan palvelukatkos estää riskipäätökset maksuikkunan aikana.
- Tallennusmääritysvirhe paljastaa ladatut henkilöllisyysasiakirjat.
- Poistotyönkulku poistaa sovellustietueen mutta jättää varmuuskopiot ja toimittajan kopiot jäljelle.
Jokaisesta väärinkäyttötapauksesta tuli suunnitteluriskitallenne, jossa kuvattiin vaikutuksen kohteena oleva omaisuuserä, uhkatoimija, haavoittuvuus, vaikutus, olemassa olevat oletukset, vaadittu lieventämistoimi, jäännösriskin omistaja, testinäyttö ja sääntelyrelevanssi.
Tämä rakenne estää epämääräiset havainnot, kuten ”API:n tietoturvariski”. Se tuottaa näyttökelpoisia riskilausumia, kuten:
”Hyökkääjä käyttää varastettuja kumppanitunnistetietoja vilpillisten pisteytyspyyntöjen lähettämiseen transaktioriski-API:n kautta, mikä johtaa riskipäätösten eheyden vaarantumiseen, mahdolliseen asiakkaiden taloudelliseen menetykseen ja henkilötietojen luvattomaan käsittelyyn.”
Uhkamallinnuksen liittäminen ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -standardeihin
ISO/IEC 27001:2022 ei edellytä uhkamallinnusta nimeltä mainiten. Se edellyttää johdonmukaista, dokumentoitua riskien arviointia ja riskien käsittelyä. Uhkamallinnus on yksi vahvimmista menetelmistä tämän näytön tuottamiseen ohjelmisto-, pilvi- ja tuoteympäristöissä.
Avain on jäljitettävyys. ZB suosittelee riskienhallintavaiheen vaiheessa 13 kontrollien kartoittamista riskeihin ja kohtiin, mukaan lukien liite A -viittaukset riskienkäsittelysuunnitelmissa sekä merkinnät siitä, missä kontrollit tukevat GDPR-, NIS2- tai DORA-vaatimuksia.
Zenith Controls: The Cross-Compliance Guide [ZC] auttaa jäsentämään tätä jäljitettävyyttä kartoittamalla ISO/IEC 27002:2022 -kontrollit niihin liittyviin kontrolleihin, auditointiodotuksiin ja ulkoisiin viitekehyksiin.
Uhkamallinnuksessa ISO/IEC 27002:2022 -kontrolli 5.8, projektinhallinnan tietoturva, on projektinhallinnan ankkuri. Se osoittaa, että tietoturva on integroitu projektin käynnistämiseen, suunnitteluun, toteutukseen ja hyväksyntään.
Kontrolli 8.25, turvallisen kehityksen elinkaari, on SDLC-ankkuri. ZC yhdistää 8.25:n tukikontrolleihin, kuten 8.26 sovellusturvallisuusvaatimukset, 8.27 turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteet, 8.28 turvallinen ohjelmointi, 8.29 tietoturvatestaus kehityksessä ja hyväksynnässä, 8.30 ulkoistettu kehittäminen ja 8.31 kehitys-, testi- ja tuotantoympäristöjen erottaminen.
| Uhkamallinnuksen näyttö | ISO/IEC 27002:2022 -ankkuri | Miksi sillä on merkitystä |
|---|---|---|
| Projektin tietoturvatarkistuspiste ennen toteutusta | 5.8 Projektinhallinnan tietoturva | Osoittaa, että tietoturva on integroitu projektin hallinnointiin, soveltamisalaan, budjettiin ja hyväksyntään |
| STRIDE- ja väärinkäyttötapauskatselmointi | 8.25 Turvallisen kehityksen elinkaari | Osoittaa, että tietoturvatoimet toteutuvat koko SDLC:n ajan, eivät vain ennen julkaisua |
| Uhista johdetut vaatimukset | 8.26 Sovellusturvallisuusvaatimukset | Muuntaa hyökkääjäskenaariot konkreettisiksi vaatimuksiksi, kuten MFA, salaus ja lokitus |
| Tietovirtakaaviot ja luottamusrajat | 8.27 Turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteet | Osoittaa, että vähimpien oikeuksien periaate, segmentointi, turvalliset oletusasetukset ja luottamusrajat on huomioitu |
| Turvallisen ohjelmoinnin tehtävät | 8.28 Turvallinen ohjelmointi | Muuntaa suunnitteluriskit toteutusstandardeiksi ja katselmointikriteereiksi |
| Lieventämistoimiin kartoitetut testit | 8.29 Tietoturvatestaus kehityksessä ja hyväksynnässä | Osoittaa, että lieventämistoimet validoitiin ennen julkaisua |
| Toimittajien kehitysvelvoitteet | 8.30 Ulkoistettu kehittäminen ja 5.19–5.22 toimittajakontrollit | Laajentaa turvallisen kehittämisen odotukset ulkoisille kehittäjille ja toimittajille |
| Ympäristöjen tietorajoitukset | 8.31 Kehitys-, testi- ja tuotantoympäristöjen erottaminen | Suojaa tuotantodataa ja tukee sisäänrakennettua tietosuojaa |
Tämä kartoitus auttaa muuttamaan suunnittelutyöpajan soveltuvuuslausunnon näytöksi. Se tukee myös ISO/IEC 27001:2022 -standardin kohtia 4–6, koska sidosryhmävaatimukset, ISMS:n soveltamisala, johdon sitoutuminen ja riskienkäsittelypäätökset ovat näkyvissä.
Yhteinen vaatimustenmukaisuuskartta NIS2-, DORA-, CRA-, GDPR- ja NIST CSF -tarpeisiin
Hyvin toteutetun uhkamallin ei tule tuottaa viittä irrallista vaatimustenmukaisuuden työvirtaa. Sen tulee tuottaa yksi suunnitteluriskien näyttöpaketti, jota voidaan käyttää uudelleen eri viitekehyksissä.
| Viitekehys tai säädös | Mitä arvioija pyrkii osoittamaan | Uhkamallinnuksen näyttö, joka auttaa |
|---|---|---|
| ISO/IEC 27001:2022 | Riskit on tunnistettu, arvioitu, käsitelty, omistettu ja liitetty kontrolleihin | Riskiskenaariot, riskienkäsittelysuunnitelma, SoA-kartoitus, hyväksyntätallenteet ja jäännösriskin hyväksyntä |
| NIS2 | Kyberturvallisuuden riskienhallintatoimenpiteet kattavat turvallisen kehittämisen, toimitusketjun, poikkeamien käsittelyn, jatkuvuuden ja pääsynhallinnan | Turvallisen suunnittelun katselmointi, toimittajaoletukset, palveluihin vaikuttavat väärinkäyttötapaukset ja poikkeamaskenaariot |
| DORA | ICT-riskiä hallinnoidaan, dokumentoidaan ja testataan sekä se yhdistetään kriittisiin toimintoihin, ICT-omaisuuseriin ja kolmannen osapuolen riippuvuuksiin | Kriittisten toimintojen kartoitus, ICT-riippuvuuskaaviot, häiriönsietokyvyn väärinkäyttötapaukset ja testaussuunnitelmat |
| CRA | Tuotteen kyberturvallisuusriskit ja sisäänrakennetun tietoturvan päätökset dokumentoidaan koko elinkaaren ajalta | Tuotteen uhkamalli, väärinkäyttötapaukset, rajapinta-analyysi ja haavoittuvuuksien käsittelyä koskevat oletukset |
| GDPR | Henkilötietoriskit on minimoitu, suojattu ja hallittu osoitettavasti sisäänrakennetusti ja oletusarvoisesti | Tietovirtakaaviot, DPIA-herätteet, tietosuojauhkien skenaariot ja pseudonymisointipäätökset |
| NIST CSF 2.0 | Kyberturvallisuuden lopputulokset ymmärretään, priorisoidaan, viestitään ja niitä parannetaan | Nykyisen ja tavoiteprofiilin syötteet, priorisoidut puutteet, riskikohteet ja toimittajaodotukset |
NIST CSF 2.0 on erityisen hyödyllinen johdon viestinnässä. Sen GOVERN-toiminto tukee lakisääteisiä, sääntelyyn perustuvia, sopimusperusteisia ja tietosuojaan liittyviä velvoitteita, ja sen toimitusketjun lopputulokset auttavat yhdistämään toimittajan kriittisyyden, sopimusvaatimukset, due diligence -arvioinnin, seurannan ja poikkeamasuunnittelun samaan uhkamallinnuksen näyttöön.
GDPR edellyttää erityistä huomiota, koska uhkamallinnuksen ja DPIA-työn tulee vahvistaa toisiaan. P17 Tietosuoja- ja yksityisyydensuojapolitiikka [P17] toteaa:
”Uhkamallinnus ja tietosuojaa koskevat vaikutustenarvioinnit (DPIA) ovat pakollisia korkean riskin käsittelyjärjestelmille.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.3.4.
Pienemmille tiimeille P17S Tietosuoja- ja yksityisyydensuojapolitiikka - SME [P17S] toteaa:
”Sisäänrakennettu ja oletusarvoinen tietosuoja on varmistettava kaikissa uusissa järjestelmissä ja palveluissa”
Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.3.1.
Tuloksena on käytännöllinen toimintamalli: käytä samoja tietovirtakaavioita, luottamusrajoja ja väärinkäyttötapauksia tietoturvariskiin, tietosuojariskiin, toimittajakatselmointiin ja sääntelynäyttöön.
90 minuutin suunnitteluriskisprintti korkean riskin ominaisuuksille
Uhkamallinnuksen ei tarvitse alkaa raskaana ohjelmana. Uuden maksu-API:n, käyttöönottotyönkulun, tekoälyä hyödyntävän ominaisuuden, identiteettipalvelun, pilvimigraation tai ulkoisen integraation osalta 90 minuutin suunnitteluriskisprintti voi tuottaa arvokasta näyttöä.
1. Avaa projektin tietoturvatarkistuspiste
Käytä P24-politiikan lauseketta 6.1.1 herätteenä. Luo jokaiselle uudelle sovellukselle tai merkittävälle muutokselle näyttökansio, jossa on:
- Arkkitehtuurikaavio
- Tietovirtakaavio
- Luottamusrajakartta
- Omaisuusluettelo
- Henkilötietoja koskevat merkinnät
- Toimittaja- ja ICT-riippuvuusluettelo
- Alustavat tietoturvavaatimukset
- Uhkamallinnuksen työpohja
- Riskirekisterimerkinnät
- Lieventämistoimien ja testauksen jäljitettävyys
- Hyväksyntätallenne
Pienemmille organisaatioille P24S Turvallisen kehityksen politiikka - SME [P24S] tukee samaa kurinalaisuutta yhdistämällä turvallisen kehityksen prosessit kehittäjien pääsynhallintaan, testaukseen, uhkamallinnukseen ja dokumentaatioon. Se edellyttää myös tarkistuslistojen, katselmointihyväksyntöjen, testausraporttien ja komponenttiluetteloiden keskitettyä säilyttämistä auditointitarkoituksia varten. Lauseke 11.3.1 viittaa kohtiin SA-3–SA-15 turvallisen kehityksen prosessien, mukaan lukien uhkamallinnuksen, määrittämiseksi.
2. Piirrä pienin käyttökelpoinen tietovirta
Älä aloita viimeistellystä kaaviosta. Aloita virroista, jotka luovat riskiä:
- Käyttäjä lataa henkilöllisyysasiakirjoja tai transaktiodataa.
- Verkkosovellus lähettää pyyntöjä API:lle.
- API kirjoittaa hallittuun tallennukseen tai tietokantaan.
- Toimittaja vastaanottaa varmennus- tai analytiikkadataa.
- Sisäinen analyytikkoportaali näyttää tulokset.
- Asiakasjärjestelmä hakee tilan tai päätökset.
- Lokit, valvontatyökalut ja varmuuskopiot vastaanottavat kopioita.
Merkitse jokainen luottamusraja: internetistä sovellukseen, sovelluksesta API:iin, sisäisestä palvelusta toimittajalle, tuotantojärjestelmästä analytiikkaan, ylläpitäjästä etuoikeutettuun toimintoon sekä tuotannosta ei-tuotantoympäristöön.
3. Käytä STRIDE-menetelmää ja väärinkäyttötapauksia yhdessä
Esitä jokaisesta rajasta STRIDE-kysymykset ja kirjoita väärinkäyttötapaukset selkeällä liiketoimintakielellä. Tavoitteena ei ole luetella jokaista kuviteltavissa olevaa hyökkäystä. Tavoitteena on tunnistaa uskottavat ja olennaiset skenaariot, jotka vaikuttavat luottamuksellisuuteen, eheyteen, saatavuuteen, tietosuojaan, häiriönsietokykyyn tai turvallisuuteen.
4. Muunna havainnot riskiskenaarioiksi
Käytä ZB-julkaisun vaiheen 9 kaavaa:
”[Uhka] hyödyntää [haavoittuvuutta] kohteessa [omaisuuserä], mikä johtaa [vaikutukseen].”
Esimerkiksi:
”Hyökkääjä hyödyntää henkilöllisyysasiakirjojen tietovaraston heikkoja objektitallennuksen pääsynhallintakontrolleja, mikä johtaa henkilötietojen luvattomaan paljastumiseen ja sääntelyilmoitusten tarpeeseen.”
Lisää tämän jälkeen omistaja, todennäköisyys, vaikutus, luontainen riski, käsittelyvaihtoehto, tavoitekontrolli, jäännösriski ja näyttö.
5. Johda vaatimukset ja testit
Uhkamalli ei ole valmis, kun riskit on listattu. Se on valmis, kun lieventämistoimet on toteutettu, testattu tai muodollisesti hyväksytty.
| Väärinkäyttötapaus | Vaatimus | Testinäyttö |
|---|---|---|
| Vaarantunut analyytikko lataa asiakirjoja massoittain | Toteuta roolipohjainen käyttöoikeuksien hallinta, MFA, vähimpien oikeuksien periaate ja latausmäärien seuranta | Pääsynhallintatesti, MFA-määrityksen näyttö ja SIEM-hälytystesti |
| Toimittaja palauttaa väärennetyn varmennustuloksen | Käytä allekirjoitettuja vastauksia, toimittajan todennusta, täsmäytystä ja poikkeamien havaitsemista | API-tietoturvatesti, integraatiotesti ja toimittajan varmentamistallenne |
| Lokit tallentavat identiteettimetatietoja | Peitä arkaluonteiset kentät ennen lokitusta ja rajoita pääsyä lokeihin | Lokitustesti, konfiguraation katselmointi ja esimerkit peitetyistä lokeista |
| Poistaminen ei kata varmuuskopioita ja toimittajan kopioita | Määritä säilytys, poistamisen eteneminen ja varmuuskopioiden vanhenemiskontrollit | Tietojen säilytystesti, toimittajan poistovahvistus ja varmuuskopiointipolitiikan näyttö |
| DoS estää käyttöönottoprosessin tai maksut | Ota käyttöön nopeusrajoitus, automaattinen skaalaus, WAF-säännöt ja palautusohjeet | Kuormitustesti, WAF-konfiguraatio ja palautusharjoituksen tallenne |
Muutoksenhallintapolitiikka - SME antaa käytännöllisen herätteen:
”Jos muutos koskee arkaluonteisia tietoja, järjestelmän käyttöoikeuksia tai ulkoisia integraatioita, tietoturvavaikutusten katselmointi on pakollinen. Nimetyn tietoturva- tai vaatimustenmukaisuusyhteyshenkilön on arvioitava, tuoko muutos uusia riskejä, ja suositeltava lisäsuojatoimia.”
Kohdasta ”Riskienkäsittely ja poikkeukset”, politiikan lauseke 7.5.1.
Arkaluonteiset tiedot, käyttöoikeudet ja ulkoiset integraatiot ovat juuri sellaisia muutoksia, jotka edellyttävät suunnitteluriskien katselmointia.
Mitä eri auditoijat kysyvät
ISO/IEC 27001:2022 -auditoija kysyy, onko uhkamallinnus osa määriteltyä riskienarviointiprosessia, ovatko kriteerit johdonmukaiset, ovatko riskinomistajat hyväksyneet jäännösriskit, liittyvätkö riskienkäsittelysuunnitelmat SoA:han ja säilytetäänkö näyttö. Auditoija etsii toistettavuutta, versiohistoriaa, näkyvyyttä johdon katselmukseen ja sisäisen auditoinnin kattavuutta.
Liite A:n osalta auditoija yhdistää näytön kohtiin 5.8, 8.25, 8.26, 8.27 ja 8.29. ZB-julkaisun vaihe 21, Controls in Action, korostaa turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteita kysymällä, mitkä periaatteet ohjaavat turvallista arkkitehtuuria. Auditoijat voivat kysyä, tehdäänkö uhkamallinnus suunnittelun aikana esimerkiksi STRIDE- tai hyökkäyspuumenetelmillä ja katselmoidaanko arkkitehtuuripäätökset ennen toteutusta.
NIS2-arvioija keskittyy hallinnointiin ja oikeasuhtaisuuteen. Hän voi kysyä, onko johto hyväksynyt kyberturvallisuuden riskienhallintatavan, kattaako se turvallisen hankinnan, kehittämisen ja ylläpidon, huomioidaanko toimittajahaavoittuvuudet, liittyvätkö poikkeamaskenaariot raportointityönkulkuihin ja onko jatkuvuusskenaarioita analysoitu. NIS2 Article 23:n vaiheittainen raportointi merkittävistä poikkeamista, mukaan lukien varhaisvaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa, tekee skenaarioiden selkeydestä erityisen arvokasta.
DORA-tarkastaja keskittyy ICT-riskien hallinnointiin, kriittisiin toimintoihin, ICT-omaisuuseriin, ulkoisiin riippuvuuksiin, häiriönsietokyvyn testaukseen ja ICT-kolmansien osapuolten palveluihin. Jos järjestelmä tukee kriittistä tai tärkeää toimintoa, tarkastaja odottaa vahvempaa näyttöä, joka yhdistää uhkaskenaariot omaisuusluetteloihin, riippuvuuskarttoihin, testaussuunnitelmiin, kolmannen osapuolen sopimuksiin ja palautumistoimenpiteisiin.
Tietosuojan arvioija tarkastaa tietovirrat ja kysyy, onko henkilötietojen käsittely tarpeellista, lainmukaista, minimoitua ja suojattua. Hän kysyy, käsitelläänkö erityisiä henkilötietoryhmiä, käytetäänkö pseudonymisointia tai salausta, onko säilytys perusteltu ja edellytetäänkö DPIA:ta. Uhkamallinnus ja DPIA ovat eri toimintoja, mutta niiden tulee jakaa kaaviot, skenaariot ja lieventämistoimet.
NIST CSF- tai COBIT 2019 -lähtöinen arvioija tarkastelee hallinnointia, prosessinomistajuutta, suorituskykyä, osoitusvelvollisuutta ja jatkuvaa parantamista. Häntä voi kiinnostaa vähemmän itse STRIDE-työpohja ja enemmän se, onko prosessi luotettava, mitattu, hyväksytty ja parannettu.
Yleiset uhkamallinnusnäytön puutteet
Yleisimmät puutteet eivät ole teknisiä. Ne ovat näyttöön liittyviä puutteita.
Tiimit tekevät uhkamallinnuksen liian myöhään, kun järjestelmä on jo rakennettu. Tällöin työpajasta tulee penetraatiotestiä edeltävä tiedotustilaisuus suunnittelukontrollin sijaan.
Havaintoja ei muunneta riskikielelle. ”Lisää auth” tai ”lokitusongelma” voi auttaa kehittäjiä, mutta auditoijat tarvitsevat omaisuuserän, uhan, haavoittuvuuden, vaikutuksen, omistajan, käsittelyn ja jäännösriskin.
Tietosuoja ja tietoturva erotetaan toisistaan. Yksi tiimi dokumentoi spoofing- ja injektioriskin, kun toinen dokumentoi säilytyksen ja oikeusperusteen. GDPR:n osoitusvelvollisuus toimii paremmin, kun tietovirrat, väärinkäyttötapaukset ja DPIA-herätteet yhdistetään.
Toimittajaoletukset jäävät dokumentoimatta. NIS2, DORA ja NIST CSF nostavat kaikki odotuksia ICT-toimitusketjun riskien suhteen. Jos lieventämistoimi riippuu toimittajan salauksesta, lokituksesta, poistamisesta, häiriönsietokyvystä tai tietoturvapoikkeamiin reagoinnista, kerää näyttö.
Testit eivät palaudu uhkiin. Penetraatiotestausraportti voi olla hyödyllinen, mutta se ei välttämättä osoita, että tietyt suunnitteluriskit on lievennetty. Jokaisella merkittävällä uhkahavainnolla tulee olla validointinäyttö.
Jäännösriskin hyväksyntä on epämuodollista. ”Hyväksymme tämän MVP:tä varten” ei riitä. ISO/IEC 27001:2022 odottaa asianmukaisten riskinomistajien hyväksyvän jäännösriskin dokumentoituna tietona.
Vuoden 2026 uhkamallinnuksen näyttöpaketti
Säilytä jokaisesta merkittävästä järjestelmästä tai olennaisesta muutoksesta vakiomuotoinen näyttöpaketti, joka tukee ISO 27001-, NIS2-, DORA-, CRA- ja GDPR-vaatimuksia sekä asiakkaiden varmentamista.
| Näyttökohde | Tarkoitus |
|---|---|
| Projektin nimi, omistaja, tarkoitus ja kriittisyys | Määrittää soveltamisalan ja vastuun osoitettavuuden |
| Arkkitehtuurikaavio ja tietovirtakaavio | Näyttää järjestelmän komponentit, tietojen liikkeen ja katselmoinnin soveltamisalan |
| Luottamusrajat ja ulkoiset rajapinnat | Tunnistaa kohdat, joissa uhat ja kontrollioletukset muuttuvat |
| Omaisuuden ja tietojen luokittelu | Yhdistää tekniset komponentit liiketoiminta- ja tietosuojavaikutuksiin |
| Toimittaja- ja ICT-riippuvuusluettelo | Tukee NIS2-, DORA- ja toimitusketjuriskien analyysia |
| STRIDE-havainnot ja väärinkäyttötapaukset | Dokumentoi uskottavat uhat ja väärinkäyttöskenaariot |
| Riskiskenaariot | Muuntaa suunnitteluhavainnot riskirekisterin kielelle |
| Riskien arviointi ja käsittelypäätökset | Osoittaa todennäköisyyden, vaikutuksen, omistajan, käsittelyn ja jäännösriskin |
| Tietoturva- ja tietosuojavaatimukset | Muuntaa uhat toteutusodotuksiksi |
| ISO/IEC 27002:2022- ja SoA-kartoitus | Yhdistää suunnitteluriskin kontrollien valintaan |
| NIS2-, DORA-, CRA-, GDPR- ja NIST CSF -merkinnät | Tukee uudelleenkäyttöä eri vaatimustenmukaisuustarpeissa |
| Lieventämistoimiin kartoitetut testitapaukset | Osoittaa, että kontrollit on validoitu |
| Toimittajan varmentamisnäyttö | Dokumentoi kolmannen osapuolen oletukset ja sitoumukset |
| Jäännösriskin hyväksyntä ja hyväksynnät | Osoittaa johdon ja riskinomistajan osoitusvelvollisuuden |
| Katselmointipäivä ja heräte-ehdot | Varmistaa, että uhkamalli pysyy ajan tasalla |
Riskienhallintapolitiikka - SME kuvaa toimintamallin hyvin:
”Se varmistaa, että riskienhallinta on aktiivinen osa suunnittelua, projektin toteutusta, toimittajan valintaa ja tietoturvapoikkeamiin reagointia ISO 27001-, ISO 31000- ja sovellettavien sääntelyvaatimusten mukaisesti.”
Kohdasta ”Tarkoitus”, politiikan lauseke 1.2.
Tämä on oikea tavoite. Uhkamallinnuksen tulee vaikuttaa suunnitteluun, kehitystyöhön, toimittajan valintaan, tietoturvapoikkeamiin reagointiin ja valmiuteen osoittaa vaatimustenmukaisuus.
Tee uhkamallinnuksesta auditointikelpoista ennen seuraavaa julkaisua
Organisaatiot, jotka selviytyvät parhaiten vuoden 2026 vaatimustenmukaisuuspaineesta, eivät ole niitä, joilla on eniten kaavioita. Ne ovat niitä, jotka voivat osoittaa yksinkertaisen ketjun:
Suunnitteluriski tunnistettiin. Riski arvioitiin. Kontrollit valittiin. Lieventämistoimet toteutettiin. Testit validoivat lieventämistoimet. Jäännösriski hyväksyttiin. Näyttö kartoittuu merkityksellisiin viitekehyksiin.
Aloita yhdestä korkean riskin muutoksesta: maksuintegraatiosta, uudesta API:sta, tekoälyä hyödyntävästä työnkulusta, identiteettiominaisuudesta, pilvimigraatiosta, asiakasrajapinnan tuotejulkaisusta tai toimittajaan kytkeytyvästä palvelusta. Toteuta 90 minuutin suunnitteluriskisprintti. Käytä ZB-julkaisua havaintojen muuntamiseen riskiskenaarioiksi, riskienkäsittelysuunnitelmiksi ja SoA-jäljitettävyydeksi. Käytä ZC-julkaisua ISO/IEC 27002:2022 -kontrollien, kuten 5.8, 8.25, 8.26, 8.27 ja 8.29, kartoittamiseen tukikontrolleihin, toimittajariskiin, tietosuojaan, testaukseen ja auditointinäyttöön. Yhdenmukaista P24, P06, P17, P24S ja muutoksenhallintamenettelysi niin, että uhkamallinnuksesta tulee pakollista, toistettavaa ja katselmoitavaa.
Jos haluat Clarysecin apua, aloita uhkamallinnuksen näytön katselmoinnilla. Arvioimme yhden todellisen projektin, tunnistamme puutteet suhteessa ISO/IEC 27001:2022-, NIS2-, DORA-, CRA- ja GDPR-odotuksiin ja annamme käytännöllisen korjaavien toimenpiteiden tiekartan, jonka kehittäjät, auditoijat ja hallitus ymmärtävät.
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
