ITDR-strategia ISO 27001-, NIS2-, DORA- ja GDPR-vaatimuksiin

Tiistaina kello 3.00 FinScalen tietoturvajohtaja Sarah heräsi hälytykseen, jota nykyaikaiset tietoturvajohtajat pelkäävät yhä useammin. Vanhemman kehittäjän aktiivista istuntoa, joka oli todennettu MFA:lla vain muutamaa tuntia aiemmin, käytettiin poikkeavasta lähteestä tuotantotietokantojen skeemojen luettelointiin.

Ei haittaohjelman beacon-liikennettä. Ei kiristyshaittaohjelmaviestiä. Ei palomuurin hyväksikäyttöä. Vain identiteetti.

SOC havaitsi toiminnan, mutta reagointi oli hajanaista. Oliko kyse MFA:n ohituksesta, varastetusta istuntotunnisteesta vai itse identiteetintarjoajan vaarantumisesta? Kenellä oli toimivalta päättää aktiivinen istunto? Riittikö salasanan vaihtaminen, vai pitikö tiimin mitätöidä refresh tokenit, kierrättää API-tunnistetiedot ja tarkastaa OAuth-valtuutukset? Kun toiminta saatiin rajattua, hyökkääjä oli ollut aktiivinen 47 minuuttia.

Seuraavana aamuna tietoturvapoikkeamasta tuli hallintakysymys. Hallitus halusi ymmärrettävän selvityksen siitä, oliko FinScalen kyberhygienia pettänyt NIS2:n näkökulmasta. Vaatimustenmukaisuustiimi halusi tietää, voitaisiinko tapahtuma luokitella DORA:n mukaiseksi merkittäväksi ICT-liitännäiseksi poikkeamaksi. Lakitoiminto tarvitsi puolustettavissa olevan vastauksen siihen, oliko henkilötietoihin päästy GDPR Article 32:n merkityksessä ja oliko henkilötietojen tietoturvaloukkauksen arviointi tarpeen. Ulkoinen auditoija kysyi, toimivatko ISO/IEC 27001:2022 -kontrollit tehokkaasti vai oliko ne vain dokumentoitu politiikkoihin.

Sarahin ongelma ei ollut työkalujen puute. FinScalella oli identiteetintarjoaja, MFA, SIEM, päätelaitekontrollit, pilvilokit ja tietoturvapoikkeamiin reagointiprosessi. Ongelma oli, että identiteetinhallinta, lokitus, seuranta, tietoturvapoikkeamiin reagointi, tietosuojan arviointi ja todentavan aineiston käsittely toimivat siiloissa.

Tämä on vuoden 2026 Identity Threat Detection and Response -ongelma. ITDR ei ole enää pelkkä tietoturvaoperaatioiden kyvykkyys. Se on useita vaatimuskokonaisuuksia palveleva näyttömoottori ISO/IEC 27001:2022-, NIS2-, DORA- ja GDPR Article 32 -vaatimuksiin.

Clarysecin Zenith Blueprint: auditoijan 30 askeleen tiekartta Zenith Blueprint, politiikkakokonaisuus ja Zenith Controls: vaatimustenmukaisuuden viitekehysten välinen opas Zenith Controls auttavat organisaatioita muuttamaan identiteettihyökkäykset kaoottisista tutkintatilanteista toistettaviksi ja auditoitaviksi kontrolliprosesseiksi.

Miksi Identity Threat Detection and Response on nyt hallitustason kysymys

Identiteettihyökkäykset toimivat, koska ne väärinkäyttävät luvallisia pääsypolkuja. Hyökkääjä, joka varastaa istuntotunnisteen, rekisteröi haitallisen OAuth-sovelluksen, vaarantaa palvelutilin tai saa käyttäjän hyväksymään MFA-push-väsytykseen perustuvan painostuksen, voi näyttää kelvolliselta käyttäjältä järjestelmissä, jotka tarkistavat vain todennuksen onnistumisen.

Tämä erottaa ITDR:n perinteisestä verkkokehän suojauksesta. Kypsän ohjelman on pystyttävä vastaamaan seuraaviin kysymyksiin:

• Mitä henkilö-, palvelu-, toimittaja- ja sovellusidentiteettejä on olemassa?
• Mitkä identiteetit ovat etuoikeutettuja, käyttämättömiä, jaettuja tai ulkoisesti federoituja?
• Mitkä todennustapahtumat ovat normaaleja, riskialttiita tai mahdottomia?
• Mitkä OAuth-valtuutukset, SaaS-tokenit ja API-tunnistetiedot voivat käyttää arkaluonteisia tietoja?
• Mitkä hälytykset käynnistävät poikkeaman luokittelun, todentavan aineiston säilyttämisen ja sääntelypäätökset?
• Mitkä kontrollit osoittavat, että pääsy henkilötietoihin on suojattu asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä?

NIS2 tekee tästä hallintakysymyksen. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, kontrollien tehokkuuden arviointi, kyberhygienia, koulutus, pääsynhallinta, omaisuudenhallinta sekä tarvittaessa monivaiheinen tai jatkuva todennus.

DORA asettaa samankaltaista painetta rahoitusalan toimijoille. Se edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, johtoelimen vastuuta, havaitsemismekanismeja, poikkeamien hallintaa, luokittelua, raportointia, häiriönsietokyvyn testausta ja ICT-kolmansien osapuolten riskienhallintaa. DORA:a sovelletaan 17. tammikuuta 2025 alkaen. Rahoitusalan toimijoille, jotka kuuluvat myös NIS2:n soveltamisalaan, DORA toimii toimialakohtaisena sääntökirjana päällekkäisille ICT-riski- ja poikkeamavelvoitteille.

GDPR lisää tietosuojan osoitusvelvollisuuden kerroksen. Article 5 edellyttää eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Article 4 määrittelee henkilötietojen tietoturvaloukkauksen laajasti, mukaan lukien luvattoman pääsyn henkilötietoihin. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä riskitasoa vastaavan turvallisuuden varmistamiseksi. Identiteettipoikkeamissa lokit, pääsynhallinta, todennustallenteet ja poikkeaman todentava aineisto ovat keskeisiä sen osoittamisessa, olivatko henkilötiedot suojattuja.

ISO/IEC 27001:2022 on hallintajärjestelmä, joka voi koota nämä velvoitteet yhteen. Clause 4 edellyttää, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä sekä lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset. Clause 6 edellyttää riskien arviointia, riskien käsittelyä, riskinomistajan hyväksyntää ja säilytettävää näyttöä. Liite A sisältää kontrollit identiteetinhallintaan, turvalliseen todennukseen, lokitukseen, seurantaan, poikkeamien hallintaan, todentavan aineiston keräämiseen, toimittajasuhteisiin, pilvipalveluihin ja tietosuojan suojaamiseen.

ITDR kuuluu ISMS:n piiriin, koska identiteettiriskistä tulee auditoitava vasta, kun sen soveltamisala, omistajuus, arviointi, käsittely, seuranta ja parantaminen on määritetty.

Identiteettihyökkäysskenaario, josta sääntelyviranomaiset välittävät

Tarkastellaan pilvipohjaista talousprosessien palveluntarjoajaa, joka palvelee EU-asiakkaita. Se käyttää Microsoft 365:tä, asiakastuen SaaS-alustaa, pilvi-infrastruktuuria, maksupalveluntarjoajaa ja useita API-pohjaisia integraatioita. Vanhempi tukiasiantuntija saa uskottavan kehotteen yhdistää tuottavuussovellus uudelleen. OAuth-suostumusnäkymä pyytää sähköpostilaatikon lukuoikeutta ja offline-käyttöä. Asiantuntija hyväksyy pyynnön.

Muutamassa minuutissa hyökkääjä käyttää tokenia asiakastunnisteiden ja tukiliitteiden etsimiseen. Hän luettelee ryhmäjäsenyyksiä ja yrittää pääsyä hallintaportaaliin. MFA oli käytössä, mutta hyökkääjä ei tarvitse salasanaa uudelleen, koska token antaa pysyvän pääsyn. SOC näkee poikkeavaa sähköpostilaatikon käyttöä, uuden OAuth-sovelluksen, epäonnistuneita hallintaportaalin käyttöyrityksiä ja toimintaa poikkeavalta maantieteelliseltä alueelta.

Tämä yksittäinen skenaario ylittää useita kontrollialueita:

• Identiteetin elinkaari, koska käyttäjän rooli ja käyttöoikeudet määrittävät vaikutusalueen.
• Turvallinen todennus, koska MFA ei yksin estänyt tokenin väärinkäyttöä.
• Lokitus ja seuranta, koska havaitseminen riippuu identiteetintarjoajan, SaaS-palvelun ja sovellusten lokeista.
• Tietoturvapoikkeamiin reagointi, koska tunnistetiedot, istunnot, tokenit ja OAuth-valtuutukset on peruttava nopeasti.
• Todentavan aineiston kerääminen, koska henkilötietojen altistuminen ja sääntelyraportointi voivat seurata tapahtumaa.
• Toimittaja- ja pilvihallinta, koska SaaS-lokit ja auditointi-API:t ovat osa näyttöketjua.
• Tietosuojan suojaaminen, koska pääsy henkilötietoihin on arvioitava GDPR:n mukaisesti.

Parempi kysymys ei ole ”Mikä työkalu epäonnistui?” Parempi kysymys on, oliko organisaatiolla suunniteltu, testattu ja auditoitavissa oleva ITDR-kontrolliketju.

Tehokkaan ITDR:n taustalla oleva ISO 27001:2022 -kontrolliketju

Tehokkaimmat ITDR-ohjelmat yhdistävät ennaltaehkäisevät, havaitsevat, korjaavat ja näyttöä tuottavat kontrollit.

Zenith Controls käsittelee ISO/IEC 27001:2022 -kontrollia 5.16 Identiteetinhallinta ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy suoraan kontrolleihin 5.15 Pääsynhallinta, 5.17 Todentamistiedot, 5.18 Käyttöoikeudet, 5.19 Tietoturva toimittajasuhteissa, 5.36 Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen sekä 8.2 Etuoikeutetut käyttöoikeudet.

Tämä on tärkeää, koska identiteettiin liittyvä havaitseminen epäonnistuu, kun identiteettien hallinta on heikkoa. Jos palvelutiliä ei ole dokumentoitu, toimittajaidentiteettiä ei hallita tai etuoikeutetulla roolilla ei ole omistajaa, seuranta voi havaita tapahtuman, mutta reagointitiimi ei pysty tulkitsemaan sitä nopeasti.

Kontrolli 8.5 Turvallinen todennus on toinen ITDR:n kiintopiste. Zenith Controls yhdistää sen identiteetinhallintaan, todentamistietoihin, etuoikeutettuihin käyttöoikeuksiin, tiedonsaannin rajoittamiseen, seurantatoimiin, poikkeamien hallintaan ja PII-tietojen suojaamiseen. Todennus ei pääty kirjautumiseen. Istunnon hallinta, tokenien käsittely, tunnistetietojen suojaus ja jäljitettävyys ovat osa samaa näyttökokonaisuutta.

Kontrolli 8.16 Seurantatoimet on nivel lokien keräämisen ja päätöksenteon välillä. Se riippuu kontrollista 8.15 Lokitus ja tukee kontrolleja 5.25 Tietoturvatapahtumien arviointi ja päätöksenteko, 5.26 Tietoturvapoikkeamiin reagointi sekä laajempaa poikkeamien hallintaa. ITDR:ssä 8.16 on kohta, jossa epäilyttävä identiteettikäyttäytyminen muuttuu triage-käsitellyksi tapahtumaksi, julistetuksi poikkeamaksi tai dokumentoiduksi vääräksi positiiviseksi havainnoksi.

Taulukko ei ole teoreettinen kartoitus. Se on käytännön näyttöketju, jota auditoija, hallituksen jäsen tai sääntelyviranomainen odottaa identiteettipoikkeaman jälkeen.

Mitä Clarysecin politiikat tuovat lisää: omistajuus, herätteet ja näyttösäännöt

Identiteettityökalut eivät automaattisesti luo osoitusvelvollisuutta. Kriisin aikana reagointitiimi tarvitsee valtuudet perua istuntoja, poistaa tilejä käytöstä, viedä lokeja, säilyttää todentavaa aineistoa ja tehdä eskalointipäätöksiä. Auditoijien on nähtävä, ettei näitä toimia improvisoitu.

Clarysecin politiikkakokonaisuus tarjoaa tämän toimintamallin.

Yritystason Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka, hallinnointivaatimusten kohta 5.9, toteaa:

Organisaation on ylläpidettävä yksityiskohtaista luetteloa kaikista aktiivisista ja käyttämättömistä tunnistetiedoista, etuoikeutetuista tileistä ja järjestelmätason palvelutileistä. Tätä luetteloa on päivitettävä jatkuvasti ja katselmoitava neljännesvuosittain.

Tämä muuttaa identiteettiluettelon nimenomaiseksi kontrollivelvoitteeksi. Se on erityisen tärkeää, koska palvelutilit, API-avaimet ja käyttämättömät tunnistetiedot ovat yleisiä ITDR:n katvealueita.

Sama politiikka toteaa hallinnointivaatimusten kohdassa 5.8:

Kaikki hallinnolliset toimet ja etuoikeutettujen tilien toimet on kirjattava lokiin peukaloinnin paljastavalla tavalla, ja niitä on seurattava poikkeamien tai politiikan rikkomusten varalta.

Tämä kohta yhdistää etuoikeutetun pääsyn hallinnan havaitsemiseen. Etuoikeutettua toimintoa ei vain sallita tai estetä. Sitä on seurattava käyttäytymisen varalta, joka ei sovi käyttäjään, rooliin, lähteeseen, aikaan tai liiketoimintaprosessiin.

Pienemmille organisaatioille User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME antaa tiiviin odotuksen soveltamista ja vaatimustenmukaisuutta koskevassa kohdassa 8.1.1:

IT-vastaavan on säännöllisesti katselmoitava järjestelmälokit luvattomien pääsyyritysten, kirjautumispoikkeamien tai hyväksymättömien käyttöoikeusmuutosten varalta.

Tästä monet pk-yritysten ITDR-ohjelmat alkavat. Se ei edellytä suurta SOC:ia. Se edellyttää nimettyä omistajuutta ja oikeiden identiteettisignaalien säännöllistä tarkastelua.

Lokituspolitiikka luo näyttöpohjan. Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME määrittää hallinnointivaatimusten kohdassa 5.4.2:

Todennuslokit: onnistuneet ja epäonnistuneet kirjautumisyritykset, istunnon kesto, MFA:n käyttö

Nämä kentät eivät ole valinnaisia. Ne auttavat osoittamaan, liittyikö epäilyttävään tapahtumaan onnistunut todennus, toistuvia epäonnistumisia, MFA:n käyttö, istunnon pysyvyys tai poikkeava kesto.

Yritystason Lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka laajentaa vaadittua lokituksen soveltamisalaa politiikan toteutusvaatimusten kohdassa 6.1.1:

Kaikkien soveltamisalaan kuuluvien järjestelmien on tuotettava lokit, jotka tallentavat: 6.1.1.1 käyttäjien todennus- ja pääsyyritykset 6.1.1.2 etuoikeutettujen käyttäjien toimet 6.1.1.3 konfiguraatiomuutokset 6.1.1.4 epäonnistuneet pääsyyritykset tai järjestelmätapahtumat 6.1.1.5 haittaohjelmahavainnot ja tietoturvahälytykset 6.1.1.6 ulkoisen viestinnän ja palomuurisääntöjen herätteet

Konfiguraatiomuutokset ovat erityisen tärkeitä identiteettihyökkäyksissä. Hyökkääjät lisäävät usein OAuth-valtuutuksia, luovat edelleenlähetyssääntöjä, rekisteröivät laitteita, muuttavat MFA-menetelmiä tai luovat hätäkäyttöpolkuja.

Tietoturvapoikkeamiin reagointipolitiikka antaa tämän jälkeen reagointitiimille toimivallan. Yritystason Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka toteaa politiikan toteutusvaatimusten kohdassa 6.2.1:

SOC:n on välittömästi eristettävä vaikutuksen kohteena olevat järjestelmät, peruttava vaarantuneet tunnistetiedot tai estettävä haitallinen liikenne palomuuri- tai päätelaitesuojaustyökaluilla.

Pk-yrityksille tarkoitettu Incident Response Policy - SME Incident Response Policy - SME toteaa rooleja ja vastuita koskevassa kohdassa 4.2.2:

Toteuttaa rajaamis- ja palautustoimet esimerkiksi poistamalla käyttöoikeuden käytöstä tai palauttamalla varmuuskopiot.

ITDR:ssä salasanan vaihtaminen ei riitä. Palautusohjeiden on sisällettävä tilien poistaminen käytöstä, istuntojen peruminen, OAuth-valtuutusten mitätöinti, salaisuuksien kierto, MFA-menetelmien nollaus ja delegoitujen käyttöoikeuksien tarkastaminen.

Todentavan aineiston käsittely erottaa reagoinnin todistamisesta. Yritystason Todisteiden keräämisen ja forensiikan politiikka Todisteiden keräämisen ja forensiikan politiikka toteaa hallinnointivaatimusten kohdassa 5.5:

Kaikki kerätty todentava aineisto on yksilöitävä, merkittävä ja säilytettävä turvallisessa tietovarastossa, jossa on: 5.5.1 eheyden varmistus, kuten SHA-256-tiivistearvot 5.5.2 aikaleimatut käyttölokit 5.5.3 kunkin aineiston haltijan allekirjoittamat hallussapitoketjumerkinnät

Pk-yrityksille tarkoitettu Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME toteaa politiikan toteutusvaatimusten kohdassa 6.1.1:

Forensinen kopio tai vienti on aina luotava; alkuperäistä todentavaa aineistoa ei saa koskaan muokata suoraan.

FinScale-skenaariossa tämä tarkoittaa, että SOC vie identiteetintarjoajan lokit, SaaS-auditointilokit, sähköpostilaatikon käyttötallenteet, OAuth-suostumustallenteet, istuntojen perumistallenteet ja SIEM-hälytykset todentavan aineiston tietovarastoon, jossa on eheyssuojaus ja hallussapitoketju.

ITDR-tiekartan rakentaminen Zenith Blueprintin avulla

Zenith Blueprint muuntaa kontrolliketjun toteutusvaiheiksi.

Controls in Action -vaiheen Step 19, Technological Controls I, on todennuksen osalta yksiselitteinen:

Mahdollisuuksien mukaan pelkkään salasanaan perustuvaa todennusta tulisi välttää, erityisesti hallinnollisilla tileillä, pilvikonsoleissa, etäkäyttötyökaluissa ja kaikissa internetiin avautuvissa järjestelmissä. MFA, jossa käytetään toista tekijää, kuten laitteistoavainta, mobiilisovellusta tai biometriikkaa, on nyt perustaso, ei ylellisyys. Se lieventää tunnistetietojen varkauksien, tietojenkalastelun ja brute force -hyökkäysten riskejä.

Sama vaihe menee salasanoja pidemmälle. Se edellyttää todennustietojen turvallista säilytystä ja siirtoa, API-tokenien, istuntotunnisteiden ja OAuth-tunnistetietojen turvallista käsittelyä, salaisuuksien hallintaa koneiden välisessä todennuksessa, tokenien kiertoa, istuntojen elinkaarikontrolleja, turvallisia evästelippuja ja todennuslokien katselmointia.

Step 22, Organizational Controls, muodollistaa pääsyn elinkaaren. Se ohjaa tiimejä integroimaan käyttöoikeuksien myöntämisen ja poistamisen henkilöstöhallintoon, tekemään dokumentoidut neljännesvuosittaiset käyttöoikeuskatselmoinnit, määrittämään identiteettityypit, kuten henkilökohtaiset tilit, jaetut tilit ja palvelutilit, vaatimaan MFA:ta etuoikeutetuille tileille, poistamaan käyttämättömät tilit ja kierrättämään palvelutunnistetiedot.

Step 19 antaa myös lokituksen kehittämispolun: välitä kriittiset lokit SIEM- tai lokien koontiratkaisuun, validoi säilytys, jäljitä tuore tapahtuma lokien avulla, dokumentoi lokien eheysominaisuudet ja vahvista hälytys epäonnistuneista kirjautumisista tai käyttöoikeuksien korotuksista. Aikasynkronointi on tärkeää, koska poikkeaman rekonstruointi epäonnistuu, jos identiteetintarjoajan, SaaS-palvelun, päätelaitteen ja pilviympäristön lokit ovat eri mieltä aikaleimoista.

Step 23, Organizational Controls for 5.19 to 5.37, validoi poikkeamien hallinnan kyvykkyydet. Se edellyttää ajantasaista tietoturvapoikkeamiin reagointisuunnitelmaa, määriteltyjä ilmoitettavia tapahtumia, pöytäharjoituksia, dokumentoituja päätöksiä, viestintätallenteita, oppeja sekä forensisen todistusaineiston säilyttämistä, kuten lokitilannevedoksia, varmuuskopioita ja turvallista eristämistä.

Käytännöllinen Clarysecin ITDR-järjestys näyttää tältä:

1. Määritä identiteettityypit ja omistajat.
2. Suojaa todennus, tokenit ja istunnot.
3. Kerää todennus-, käyttöoikeus- ja SaaS-lokit.
4. Seuraa riskialtista käyttäytymistä.
5. Määritä tapahtumasta poikkeamaksi siirtymisen päätössäännöt.
6. Säilytä todentava aineisto.
7. Raportoi, palaudu ja paranna.

Yhden viikon ITDR-näyttöpaketti

Kohdennettu ”identiteettipoikkeaman näyttöpaketti” on yksi nopeimmista tavoista paljastaa puutteita. Valitse yksi korkean riskin skenaario, esimerkiksi: ”Etuoikeutettu SaaS-käyttäjä antaa suostumuksen luvattomalle OAuth-sovellukselle, ja tokenia käytetään asiakastietojen käyttöön.”

Rakenna sitten näyttöpaketti yhdessä viikossa.

Sisällytä mukaan vähintään yksi todellinen jälki. Ota vaaraton tuore kirjautumispoikkeama ja osoita, miten tiimi siirtyy hälytyksestä käyttäjäidentiteettiin, laitteeseen, lähde-IP-osoitteeseen, MFA-menetelmään, istunnon kestoon, käytettyihin SaaS-resursseihin, käsiteltyihin tietoihin ja rajaamispäätökseen. Jos organisaatio ei pysty rekonstruoimaan tätä ketjua pöytäharjoituksessa, sillä on vaikeuksia todellisessa poikkeamassa.

Tuotoksesta tulee uudelleenkäytettävää näyttöä ISO/IEC 27001:2022 -sisäisiin auditointeihin, DORA:n ICT-poikkeamaprosessin testaukseen, NIS2:n kyberhygienian valvontaan ja GDPR:n osoitusvelvollisuuteen.

ITDR:n kartoitus NIS2-, DORA- ja GDPR Article 32 -vaatimuksiin

Yhtenäisen ITDR-mallin vahvuus on, että sama näyttö täyttää useita velvoitteita, mutta kunnioittaa silti kunkin viitekehyksen omaa kieltä.

NIS2 Article 21 edellyttää riskiperusteisia, oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. ITDR:n osalta tämä tarkoittaa pääsynhallintaa, omaisuudenhallintaa, kyberhygieniaa, koulutusta, poikkeamien käsittelyä, kontrollien tehokkuuden arviointia sekä MFA:ta tai jatkuvaa todennusta tarvittaessa. Article 23 luo vaiheistetun raportoinnin merkittäville poikkeamille, mukaan lukien ennakkovaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa.

DORA Articles 8 to 14 edellyttävät ICT-omaisuuserien ja riippuvuuksien tunnistamista, suojausta ja ennaltaehkäisyä, havaitsemismekanismeja, jatkuvuutta ja palautumista, oppimista ja viestintää. Articles 17 to 19 edellyttävät poikkeamien hallintaa, juurisyyn tunnistamista, ennakkovaroitusindikaattoreita, luokittelua vakavuuden ja palvelun kriittisyyden perusteella, eskalointia, ilmoittamista johtoelimelle, raportointia toimivaltaiselle viranomaiselle ja asiakasilmoitusta, kun taloudelliset edut voivat vaarantua.

GDPR edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä sekä todennettavaa osoitusvelvollisuutta. Identiteettihyökkäyksissä GDPR-kysymyksiä ovat esimerkiksi, tapahtuiko luvaton pääsy, mitä henkilötietoja asia koski, toimivatko suojatoimet ja ylittyvätkö tietoturvaloukkauksesta ilmoittamisen kynnysarvot.

Fintech-yrityksille NIS2:n ja DORA:n välinen suhde on tärkeä. DORA:a pidetään soveltamisalaan kuuluvien rahoitusalan toimijoiden toimialakohtaisena viitekehyksenä, kun päällekkäisiä ICT-riski- ja poikkeamaraportointivelvoitteita on olemassa. Käytännössä organisaatioiden tulisi rakentaa yksi ITDR-näyttömalli ja kartoittaa raportointipäätökset sovellettavaan oikeudelliseen reittiin.

SaaS-, pilvi-, hallinnoitujen palvelujen, hallinnoitujen tietoturvapalvelujen ja digitaalisten alustojen organisaatioiden on tarkistettava NIS2-soveltamisala huolellisesti. NIS2 kattaa monet Annex I- ja Annex II -toimialat, mukaan lukien digitaalinen infrastruktuuri, pilvipalveluntarjoajat, datakeskukset, luottamuspalvelut, DNS, TLD-rekisterit, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkkomarkkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat. ISO/IEC 27001:2022 Clause 4:n soveltamisalan määrittely ja sidosryhmäanalyysi eivät siksi ole paperityötä. Ne määrittävät, mitä velvoitteita ISMS:n on käsiteltävä.

Toimittajiin ja SaaS-palveluihin liittyvä identiteettiriski

Identiteettipoikkeamat riippuvat usein toimittajan tuottamasta näytöstä. Voiko SaaS-palveluntarjoaja viedä auditointilokit? Näyttääkö se OAuth-suostumustapahtumat? Tukeeko se turvallista pääsynhallintaa, lokitusta ja tietosuojaa? Onko sopimuksessa käsitelty poikkeama-avun, tietojen sijainnin, alihankinnan, käyttöoikeuksien ja irtautumisen ehdot?

Clarysecin Cloud Usage Policy - SME Cloud Usage Policy - SME sisältää suoran vaatimuksen hallinnointivaatimusten kohdassa 5.2.4:

Palvelu tarjoaa turvalliset pääsynhallinta-, lokitus- ja tietosuojakyvykkyydet

Tämä yksinkertainen lause on hankintakontrolli. Jos SaaS-alusta ei pysty tuottamaan tietoturvapoikkeamiin reagoinnissa tarvittavia identiteettilokeja, se aiheuttaa vaatimustenmukaisuusriskin.

DORA tekee tämän nimenomaiseksi ICT-kolmansien osapuolten riskivelvoitteiden kautta. Rahoitusalan toimijat säilyvät vastuussa vaatimustenmukaisuudesta, niiden on ylläpidettävä ICT-palvelusopimusten rekistereitä, erotettava kriittiset tai tärkeät toiminnot, tehtävä huolellisuusarviointeja, arvioitava keskittymäriskiä, sisällytettävä sopimuksiin auditointi- ja pääsyoikeudet, määritettävä poikkeama-apu ja varmistettava exit-strategiat.

Zenith Controls yhdistää ISO/IEC 27001:2022 -kontrollin 8.16 Seurantatoimet kontrolliin 5.22 Toimittajapalvelujen seuranta, katselmointi ja muutostenhallinta. Tämä vastaa operatiivista todellisuutta. Identiteetintarjoajan hälytykset, SaaS-auditointilokit, pilviympäristön ylläpitäjätoiminta ja hallinnoitujen palveluntarjoajien tilit muodostavat kaikki osan ITDR-pinta-alasta.

Miten auditoijat arvioivat ITDR:ää

Vahvan ITDR-ohjelman tulisi kestää useita auditointinäkökulmia. Kukin kohderyhmä kysyy eri asioita, mutta näytön tulisi tulla samasta kontrollijärjestelmästä.

ISO/IEC 27001:2022 -auditoija kysyy, sisältyvätkö identiteettiuhat riskien arviointiin, ovatko riskinomistajat hyväksyneet käsittelyn, sisältääkö soveltuvuuslausunto olennaiset liite A:n kontrollit, onko politiikat toteutettu ja osoittaako näyttö kontrollien toimivan. Auditoija voi ottaa näytteeksi etuoikeutetun tilin ja jäljittää hyväksynnän, MFA-asetuksen, lokitoiminnan, käyttöoikeuskatselmoinnin ja käyttöoikeuksien poistamisen.

NIST CSF 2.0 -arvioija tarkastelee GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-tuloksia. ITDR sopii luonnollisesti profiiliin, jonka soveltamisala on identiteetin vaarantuminen, SaaS-tokenien väärinkäyttö tai etuoikeutetun pääsyn väärinkäyttö.

DORA-tarkastaja etsii johtoelimen vastuun osoittamista, ICT-tuettuja liiketoimintatoimintoja, havaitsemismekanismeja, poikkeamien luokittelukriteerejä, eskalointia, asiakasviestinnän sääntöjä, juurisyyanalyysiä ja ICT-kolmansien osapuolten riippuvuuksia.

GDPR-arvioija kysyy, pystyykö organisaatio osoittamaan henkilötietojen asianmukaisen turvallisuuden. Hän tarkastelee pääsyn rajoittamista, luvattoman pääsyn havaitsemista, lokeja, jotka osoittavat, mitä tietoja on mahdollisesti käytetty, tietoturvaloukkauksen arviointia ja osoitusvelvollisuutta koskevaa näyttöä.

COBIT 2019- tai ISACA-tyylinen auditoija tarkastelee hallintaa, kontrollitavoitteita, omistajuutta, suorituskyvyn seurantaa ja varmennusta.

Zenith Controls on tässä hyödyllinen, koska se toimii vaatimustenmukaisuuden viitekehysten välisenä oppaana. Se ei luo erillisiä ”Zenith-kontrolleja”. Se kartoittaa ISO/IEC 27001:2022 -kontrollialueet niihin liittyviin ISO-kontrolleihin, muihin standardeihin, auditointiodotuksiin ja toteutussuhteisiin.

Mittarit, jotka osoittavat ITDR:n toimivan

Hallitukset ja auditoijat eivät tarvitse raakaa SIEM-kohinaa. He tarvitsevat näyttöä siitä, että identiteettikontrollit toimivat ja paranevat. Hyödyllisiä ITDR-mittareita ovat:

• Niiden etuoikeutettujen tilien osuus, joilla on tietojenkalastelua kestävä MFA.
• Käyttämättömien tilien määrä, jotka ovat politiikassa määritettyä kynnysarvoa vanhempia.
• Palvelutilien määrä, joilta puuttuu omistaja tai kierrätyspäivä.
• Kriittisten SaaS-alustojen osuus, jotka lähettävät todennuslokit SIEMiin.
• Keskimääräinen aika epäilyttävän identiteettitoiminnan havaitsemiseen.
• Keskimääräinen aika vaarantuneiden istuntojen ja tokenien perumiseen.
• Hyväksyttyjen, hylättyjen tai poistettujen OAuth-sovellusten määrä.
• Niiden identiteettipoikkeamien osuus, joilla on täydellinen näyttöpaketti.
• Erääntyneiden käyttöoikeuskatselmointihavaintojen määrä.
• Niiden toimittaja-alustojen määrä, joilta puuttuvat vaaditut identiteettilokit.

Näiden mittareiden tulisi syöttää tietoa ISO/IEC 27001:2022 -johdon katselmukseen, NIS2:n hallintavalvontaan, DORA:n ICT-riskiraportointiin ja GDPR:n osoitusvelvollisuutta koskeviin keskusteluihin.

Yleiset ITDR-auditointihavainnot ja korjaukset

Clarysec näkee yleisesti viisi toistuvaa havaintoa.

Ensiksi organisaatiot ottavat MFA:n käyttöön, mutta eivät seuraa MFA-käyttäytymistä. Korjaa tämä kirjaamalla lokiin MFA-menetelmien muutokset, epäonnistuneet haasteet, mahdoton matkustus, uuden laitteen rekisteröinti ja toistuvat push-yritykset.

Toiseksi palvelutilit jätetään identiteettien hallinnan ulkopuolelle. Korjaa tämä luetteloimalla järjestelmätason tilit, nimeämällä omistajat, kierrättämällä salaisuudet, poistamalla upotetut tunnistetiedot ja seuraamalla poikkeavaa API-käyttäytymistä.

Kolmanneksi SaaS-suostumuksia ei hallita. Korjaa tämä rajoittamalla käyttäjien suostumuksia, katselmoimalla OAuth-sovellukset, seuraamalla uusia valtuutuksia, dokumentoimalla hyväksytyt integraatiot ja poistamalla käyttämättömät sovellukset.

Neljänneksi todentavaa aineistoa muutetaan tutkinnan aikana. Korjaa tämä noudattamalla Todisteiden keräämisen ja forensiikan politiikan sääntöä: luo forensiset kopiot tai viennit, älä koskaan muokkaa alkuperäisiä suoraan ja säilytä todentava aineisto tiivisteiden ja hallussapitoketjutallenteiden kanssa.

Viidenneksi poikkeamien luokittelu on liian hidasta. Korjaa tämä määrittämällä ennakkoon identiteettitapahtumien kynnysarvot, mukaan lukien etuoikeutetun tilin vaarantuminen, pääsy henkilötietoihin, asiakkaisiin vaikuttava SaaS-tokenin väärinkäyttö, kriittisen palvelun häiriö ja toimittajaidentiteetin vaarantuminen.

Jokaisella havainnolla on kontrolli-, politiikka- ja näyttövastaus. Tämä on yhtenäisen ITDR-ohjelman käytännön arvo: se määrittää, mitä on omistettava, seurattava, testattava, todistettava ja parannettava.

Muunna identiteettiriski auditointivalmiiksi näytöksi

Jos seuraava identiteettipoikkeamasi tapahtuisi huomenna, pystyisitkö osoittamaan, kuka käytti mitä, miten hänet todennettiin, mitä tokenia tai istuntoa käytettiin, mitä tietoja käsiteltiin, kuka päätti sääntelyluokituksesta ja mitkä korjaavat toimenpiteet saatiin päätökseen?

Jos vastaus on epävarma, aloita kohdennetulla ITDR-valmiussprintillä.

Käytä Zenith Blueprint -tiekarttaa toteutuspolun jäsentämiseen todennuksen, pääsyn elinkaaren, lokituksen, seurannan, tietoturvapoikkeamiin reagoinnin ja todentavan aineiston käsittelyn osalta. Käytä Clarysecin pääsynhallinta-, lokitus-, pilvi-, tietoturvapoikkeamiin reagointi- ja forensiikkapolitiikkoja omistajuuden ja reagointivaltuuksien määrittämiseen. Käytä Zenith Controls -opasta identiteetinhallinnan, turvallisen todennuksen ja seurantatoimien kartoittamiseen ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR- ja NIST CSF 2.0 -vaatimuksiin sekä auditointiodotuksiin.

Tavoite on yksinkertainen: tee identiteettihyökkäyksistä havaittavia, rajattavia, raportoitavia ja puolustettavissa olevia.

Clarysec voi auttaa sinua rakentamaan ITDR-näyttöpaketin, testaamaan sen pöytäharjoituksessa ja muuntamaan havainnot riskienkäsittelysuunnitelmaksi, jonka hallitus, sääntelyviranomainen ja auditoija ymmärtävät. Aloita katselmoimalla Lokitus- ja valvontapolitiikka, User Account and Privilege Management Policy - SME, Zenith Blueprint ja Zenith Controls, ja aikatauluta sen jälkeen ITDR-valmiusarviointi, jolla identiteettiriski muutetaan auditointivalmiiksi näytöksi.