Dangling DNS -riskin hallinta NIS2:n, DORA:n ja GDPR:n näkökulmasta

Tietoturvajohtaja saa viestin maanantaina klo 07.12.

Tietoturvatutkija on havainnut, että promo.company.com osoittaa hylättyyn pilvisovellukseen. DNS-tietue on edelleen aktiivinen. Pilviresurssia ei enää ole. SaaS-tenantti, joka aikanaan palveli kampanjaa, poistettiin kuusi kuukautta aiemmin pian sen jälkeen, kun markkinointi siirtyi toiseen alustaan. Kukaan ei poistanut CNAME-tietuetta.

Klo 08.30 kysymys ei enää ole: ”Voiko joku ottaa aliverkkotunnuksen haltuunsa?” Kysymys on: ”Miksi kukaan ei tiennyt, että tämä omaisuuserä oli olemassa?”

Klo 09.15 lakiasiat on mukana, koska aliverkkotunnus oli aiemmin kerännyt sähköpostiosoitteita tuotteen jonotuslistaa varten. Hankinta on mukana, koska kampanja-alustaa hallinnoi toimisto. Vaatimustenmukaisuudesta vastaavat henkilöt ovat mukana, koska yritys valmistautuu ISO/IEC 27001:2022 -valvonta-auditointiin, NIS2-valmiuteen ja asiakkaiden varmentamiskyselyihin. Tietosuojavastaava kysyy, voisiko altistuminen muuttua GDPR:n mukaiseksi henkilötietojen tietoturvaloukkaukseksi, jos aliverkkotunnusta käytettäisiin hyökkäykseen. Talousjohtaja kysyy, voisiko sama heikkous vaikuttaa maksupalveluportaaliin konsernin säännellyssä finanssipalveluympäristössä.

Tekninen korjaus voi kestää minuutteja. Hallintaongelman purkaminen voi kestää kuukausia, jos organisaatio ei pysty osoittamaan, että jokainen internetiin avautuva omaisuuserä tunnetaan, omistetaan, katselmoidaan, valvotaan ja poistetaan käytöstä hallitun prosessin kautta.

Siksi dangling DNS -riskin ja aliverkkotunnuksen haltuunoton ehkäisyä ei voi käsitellä kapeana DNS-siivoustehtävänä. Vanhentunut DNS-tietue on usein näkyvä oire syvemmistä kontrollipuutteista: puutteellisesta omaisuusluettelosta, heikosta omistajuudesta, puuttuvasta käytöstäpoiston näytöstä, heikosta muutoksenhallinnasta, riittämättömästä toimittajasuhteen päättämisen hallinnasta, puutteellisesta ulkoisen hyökkäyspinnan seurannasta ja epäselvästä poikkeamien luokittelusta.

Clarysecin asiakkaille dangling DNS on hallintajärjestelmän testi. Se osoittaa, toimivatko politiikat, kontrollit, rekisterit, näyttö ja vastuun osoitettavuus käytännössä, kun unohtuneesta pilviriippuvuudesta tulee hyökkääjän mahdollisuus.

Mitä dangling DNS käytännössä tarkoittaa

Aliverkkotunnuksen haltuunotto tulee mahdolliseksi, kun DNS-tietue, usein CNAME, osoittaa resurssiin, jota ei enää ole olemassa tai joka ei enää ole organisaation hallinnassa. Jos hyökkääjä voi varata tai luoda kohderesurssin uudelleen pilvi- tai SaaS-alustalla, hän voi pystyä tarjoamaan sisältöä organisaation luotetun aliverkkotunnuksen kautta.

Tyypillisiä esimerkkejä ovat:

• CNAME-tietue, joka osoittaa varaamattomaan pilvisovelluspalveluun.
• Brändätty SaaS-isäntänimi, joka on jätetty DNS:ään tilauksen päättämisen jälkeen.
• CDN-jakelu, joka on poistettu palveluntarjoajan hallintakonsolista mutta johon julkinen DNS edelleen viittaa.
• Markkinoinnin mikrosivusto, jonka toimisto on poistanut käytöstä poistamatta DNS-tietuetta.
• Tallennuspäätepiste tai staattisen verkkosivuston määritys, joka voidaan rekisteröidä uudelleen.
• Kehityksen aliverkkotunnus, joka altistuu unohtuneen PaaS-projektin kautta.

Liiketoimintavaikutus voi olla vakava. Hyökkääjät voivat isännöidä tietojenkalastelusivuja, kerätä tunnistetietoja, levittää haittaohjelmia, käyttää väärin verkkotunnuksen mainetta, siepata istuntotietoja tai vahingoittaa luottamusta brändiin. Jos aliverkkotunnus on aiemmin käsitellyt henkilötietoja, lyhytaikainenkin haltuunotto voi laukaista GDPR:n mukaisen tietoturvaloukkauksen arvioinnin. Jos kyseinen palvelu tukee säänneltyjä finanssitoimintoja, poikkeama voi edellyttää arviointia myös DORA:n tai sisäisten ICT-riskienhallinnan viitekehysten mukaisesti.

Auditoijat pitävät dangling DNS -havaintoja yhä useammin kontrollien kypsyystason näyttönä. Yksittäinen vanhentunut tietue voi osoittaa, ettei organisaatio tiedä, mitä se omistaa, kuka sen omistaa, miten muutoksia katselmoidaan, miten pilvipalveluista irtaudutaan tai miten ulkoisesti näkyviä omaisuuseriä valvotaan.

Siksi Clarysec kartoittaa tämän kysymyksen ISO/IEC 27001:2022 ISO/IEC 27001:2022-, ISO/IEC 27002:2022 ISO/IEC 27002:2022-, NIS2-, DORA-, GDPR-, NIST CSF 2.0- ja COBIT 2019 -auditointiodotuksiin.

Miksi ISO 27001:2022 on käytännön selkäranka

Vahvin tapa hallita dangling DNS -riskiä ei ole erillisten ohjelmien luominen NIS2:lle, DORA:lle ja GDPR:lle. Vahvin tapa on käyttää ISO/IEC 27001:2022 -standardia hallintajärjestelmän selkärankana ja tuottaa näyttöä kerran useita varmentamistarpeita varten.

Asiaankuuluvat vaatimukset alkavat jo ennen liitettä A. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmävaatimuksensa, ISMS:n soveltamisalan ja riippuvuudet muihin organisaatioihin. Dangling DNS -hallinnassa soveltamisalan tulee kattaa ulkoinen DNS, verkkotunnukset, rekisterinpitäjät, pilvipalvelut, SaaS-alustat, toimistot, hallittu hosting, CDN-palvelut ja kaikki kolmannet osapuolet, jotka voivat luoda tai poistaa käytöstä internetiin avautuvia palveluja.

Kohdat 5.1–5.3 tekevät tästä johtamista ja vastuun osoitettavuutta koskevan kysymyksen. Johdon tulee sovittaa ISMS liiketoiminnan suuntaan, varata resurssit, viestiä tietoturvallisuuden merkityksestä ja osoittaa vastuut. Jos markkinointi voi julkaista mikrosivuston, kehitys voi luoda pilvipäätepisteitä ja hankinta voi päättää SaaS-sopimuksia, organisaatio tarvitsee hallintamallin, joka määrittää selkeän DNS- ja palveluomistajuuden kaikkien näiden toimintojen yli.

Kohdat 6.1.1–6.1.3 antavat riskien arvioinnin, riskien käsittelyn ja soveltuvuuslausunnon logiikan. Dangling DNS tulee kirjata realistisena riskiskenaariona, ei pelkkänä skannerin löydöksenä. Se vaikuttaa luottamuksellisuuteen, eheyteen ja saatavuuteen, ja se liittyy usein lakisääteisiin, sääntelyperusteisiin ja sopimusvelvoitteisiin.

Kohdat 7.5, 8.1, 8.2 ja 8.3 muuttavat hallinnan näytöksi. Ne edellyttävät hallittua dokumentoitua tietoa, suunniteltuja ja hallittuja operatiivisia prosesseja, tahattomien muutosten huomioimista, ulkoisesti tuotettujen prosessien hallintaa, säännöllisiä riskien arviointeja ja dokumentoituja riskienkäsittelyn tuloksia.

Liite A antaa tämän jälkeen kontrollikatalogin. Clarysecin projekteissa keskeiset ISO/IEC 27002:2022 -yhteydet näyttävät yleensä tältä:

Ydin on yksinkertainen. ISO/IEC 27001:2022 ei edellytä sankarillista kertaluonteista siivousta. Se edellyttää hallittua toimintamallia, joka estää toistumisen.

Zenith Controls -näkymä: yksi riski, kolme kontrolliankkuria

Julkaisussa Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec käyttää asiaankuuluvia ISO/IEC 27002:2022 -kontrolleja vaatimustenmukaisuuden yhteisinä ankkureina. Dangling DNS -riskin ja aliverkkotunnuksen haltuunoton hallinnassa kolme kontrollia on keskeisiä.

Kontrolli 5.9, Tietojen ja muiden niihin liittyvien omaisuuserien luettelo, on luokiteltu ennaltaehkäiseväksi, tukee luottamuksellisuutta, eheyttä ja saatavuutta, kohdistuu Identify-kyberturvallisuuskäsitteeseen ja sijoittuu omaisuudenhallinnan operatiivisen kyvykkyyden alle, jossa tietoturvan osa-alueina ovat hallinto, ekosysteemi ja suojaus.

Kontrolli 5.23, Pilvipalvelujen käytön tietoturva, on luokiteltu ennaltaehkäiseväksi, tukee luottamuksellisuutta, eheyttä ja saatavuutta, kohdistuu Protect-toimintoon ja sijoittuu toimittajasuhteiden turvallisuuden operatiivisen kyvykkyyden alle, jossa tietoturvan osa-alueina ovat hallinto, ekosysteemi ja suojaus.

Kontrolli 8.8, Teknisten haavoittuvuuksien hallinta, on luokiteltu ennaltaehkäiseväksi, tukee luottamuksellisuutta, eheyttä ja saatavuutta, kohdistuu Identify- ja Protect-toimintoihin ja sijoittuu uhkien ja haavoittuvuuksien hallinnan operatiivisen kyvykkyyden alle, jossa tietoturvan osa-alueina ovat hallinto, ekosysteemi, suojaus ja puolustus.

Tällä on merkitystä, koska dangling DNS ei ole vain omaisuuskontrollin epäonnistuminen, pelkkä pilvikontrollin epäonnistuminen eikä pelkkä haavoittuvuus. Se on näitä kaikkia. Organisaation tulee osoittaa, että omaisuusluettelo, pilvipalvelujen käytön hallinta ja haavoittuvuuksien hallinta vahvistavat toisiaan.

Clarysec lisää usein näiden ankkurien ympärille tukevia käytäntöjä: ISO/IEC 27005 riskien arvioinnin ja käsittelyn kurinalaisuuteen, ISO/IEC 27017 pilvipalvelujen tietoturvan hallintaan, ISO/IEC 27018 tilanteisiin, joissa pilvipalvelut käsittelevät henkilötietoja, ISO/IEC 27701 henkilötietojen hallintajärjestelmään sekä ISO 22301 tilanteisiin, joissa jatkuvuus ja kriisinhallinta ovat olennaisia.

Politiikkanäyttö, joka jo edellyttää DNS-elinkaaren hallintaa

Monilla organisaatioilla on jo politiikkoja, jotka oikein toteutettuina estäisivät dangling DNS -riskin. Puute on siinä, ettei DNS-elinkaaren hallintaa ole kytketty nimenomaisesti näihin politiikkoihin.

Clarysecin Asset Management Policy-sme Asset Management Policy-sme - SME, Policy Implementation Requirements, kohta 6.6.1 toteaa:

Pilvipohjaiset omaisuuserät, kuten tallennustilit, SaaS-alustat ja verkkotunnukset, on myös sisällytettävä omaisuusluetteloon.

Sama politiikka lisää kohdassa 6.6.2:

Omistajuus, tarkoitus, käyttöoikeudet ja uusimisaikataulut on dokumentoitava.

Dangling DNS -hallinnassa tämä tarkoittaa, että jokaisella tuotannon aliverkkotunnuksella ja olennaisella ei-tuotannon aliverkkotunnuksella tulee olla nimetty omistaja, liiketoimintatarkoitus, linkitetty palvelu, käyttöoikeusmalli ja katselmointipäivä.

Tärkeintä on, että kohta 6.6.3 toteaa:

Vanhentuneet tai käyttämättömät palvelut on poistettava käytöstä ja poistettava luettelosta.

DNS:n osalta tätä on tulkittava huolellisesti. Palvelun poistaminen luettelosta ei riitä. Myös DNS-tietue, pilvisidonta, SaaS-palvelun mukautetun verkkotunnuksen varaus, varmenne, WAF-sääntö, CDN-konfiguraatio ja seurannan kohde on katselmoitava.

Yritysversio vahvistaa tätä laajempaa omaisuuseräkäsitettä. Clarysecin Asset Management Policy Asset Management Policy, Scope, kohta 2.2.5 toteaa:

Loogiset omaisuuserät: verkkotunnukset, lisenssit, käyttäjätilit, peruskonfiguraatiot

Verkkotunnukset ja konfiguraatiot eivät ole hallinnollisia yksityiskohtia. Ne ovat luottamusta kantavia omaisuuseriä, joista voi muodostua hyökkäyspolkuja.

Yhteys muutoksenhallintaan on yhtä tärkeä. Clarysecin Change Management Policy Change Management Policy, Purpose, kohta 1.1 toteaa:

Tämä politiikka muodostaa muodollisen viitekehyksen organisaation tietojärjestelmiin, infrastruktuuriin, sovelluksiin ja niihin liittyviin prosesseihin kohdistuvien muutosten käynnistämiselle, arvioinnille, hyväksymiselle, toteuttamiselle ja katselmoinnille.

DNS-poiston, SaaS-sopimuksen päättämisen, pilvisovelluksen poistamisen, CDN-migraation tai markkinoinnin mikrosivuston käytöstäpoiston tulee siksi tuottaa muutosta koskevaa näyttöä. Muutostiketin puuttuminen on usein ensimmäinen auditoinnin hälytysmerkki.

Myös pilvipalvelujen hallinta on kytkettävä mukaan. Clarysecin Cloud Usage Policy Cloud Usage Policy, Governance Requirements, kohta 5.5 toteaa:

Tietoturvatiimin on säännöllisesti arvioitava verkkoliikennettä, DNS-toimintaa ja lokeja luvattoman pilvipalvelujen käytön eli varjo-IT:n havaitsemiseksi. Havaitut rikkomukset on tutkittava viipymättä.

Aliverkkotunnuksen haltuunoton ehkäisyssä DNS-toiminnan seuranta ei koske vain varjo-IT:tä. Se koskee myös vanhentunutta IT:tä: omaisuuseriä, jotka olivat aiemmin hyväksyttyjä mutta eivät ole enää hallinnassa.

Käytännön Clarysec-työnkulku dangling DNS -hallintaan

Vahva dangling DNS -ohjelma ei ole monimutkainen. Se on kurinalainen, toistettava ja kytketty ISMS:ään, haavoittuvuuksien hallintaan, muutoksenhallintaan ja toimittajan elinkaareen.

Pk-yrityksissä tämä voi alkaa kevyenä rekisterinä. Suurissa organisaatioissa se yleensä yhdistää DNS-viennit, ulkoisen hyökkäyspinnan hallinnan, pilviomaisuusluettelot, CMDB-tiedot, haavoittuvuusskannerit, SIEM-hälytykset ja tikettijärjestelmät.

Hallintakysymys pysyy samana: voitteko osoittaa, että jokainen ulkoisesti saavutettava aliverkkotunnus tunnetaan, omistetaan, sitä valvotaan ja se voidaan poistaa hallitun prosessin kautta?

Hylätty kampanja-aliverkkotunnus oikein käsiteltynä

Palataan maanantain poikkeamaan. promo.company.com osoittaa hylättyyn SaaS-kampanjasivustoon.

Ensiksi tietoturvavastaava luo haavoittuvuustallenteen, koska omaisuuserä näkyy ulospäin. Clarysecin Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, Policy Implementation Requirements, kohta 6.1.1 toteaa:

Kaikki järjestelmät on skannattava vähintään kuukausittain; korkean riskin tai ulkoisesti altistuvat omaisuuserät on skannattava viikoittain.

Pk-yrityksille vastaava politiikka tarkentaa priorisointia. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Policy Implementation Requirements, kohta 6.5.1 toteaa:

Henkilötietoja käsittelevät, etäkäyttöä tarjoavat tai ulkoisesti näkyvät järjestelmät on priorisoitava skannauksiin ja päivityksiin.

Toiseksi omistaja tunnistetaan omaisuusrekisterin kautta. Jos omistaja on tuntematon, kyse on omaisuudenhallintaan liittyvästä kontrollin epäonnistumisesta. Rekisteriin päivitetään DNS-nimi, kohdepalveluntarjoaja, alkuperäinen liiketoimintavastaava, tietojen luokittelu, toimittaja ja tila.

Kolmanneksi IT tarkistaa pilvi- tai SaaS-alustan. Jos pilvitili on poistettu, Clarysecin Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, Policy Implementation Requirements, kohta 6.3.6 on suoraan relevantti:

IT-palveluntarjoajan tai toimitusjohtajan on katselmoitava poistetut pilvitilit jäännöskäyttöoikeuksien, orpojen tietojen tai huomaamatta jääneen sisällön varalta.

Neljänneksi muutoksen omistaja avaa hätämuutoksen tai nopeutetun muutostiketin DNS-tietueen poistamiseksi tai resurssin tilapäiseksi uudelleenvaraamiseksi ennen poistamista. Tiketti sisältää vaikutusten arvioinnin, palautussuunnitelman, hyväksynnät, toteutusnäytön ja muutoksen jälkeisen validoinnin.

Viidenneksi tietosuojavastaava arvioi, käsittelikö aliverkkotunnus henkilötietoja tai olisiko se voinut altistaa niitä. Clarysecin PII Security and Access Control Policy PII Security and Access Control Policy, Secure configuration and vulnerability management, kohta 4.7.4 toteaa:

[Molemmat] Järjestelmän omistajan / sovelluksen omistajan ON kirjattava REG12:een henkilötietoja käsittelevien järjestelmien haavoittuvuuksien arvioinnin kattavuus vähintään neljännesvuosittain ja olennaisen teknisen muutoksen jälkeen.

Kohta 4.7.5 lisää:

[Molemmat] Tietoturvavastaavan ON kirjattava REG12:een henkilötietoihin vaikuttavat ratkaisemattomat korkean riskin haavoittuvuudet viiden arkipäivän kuluessa validoinnista.

Nämä kohdat soveltuvat riippumatta siitä, toimiiko organisaatio rekisterinpitäjänä vai henkilötietojen käsittelijänä, koska ne on merkitty [Molemmat]. Henkilötietoihin liittyvässä dangling DNS -tapauksessa näyttö ei saa jäädä vain tekniseen tikettiin. Sen on näyttävä henkilötietojen haavoittuvuuksia koskevassa todentavan aineiston rekisterissä.

Kuudenneksi hankinta tarkistaa kolmannen osapuolen tallenteet, jos kampanjaa isännöi toimisto tai SaaS-palveluntarjoaja. Clarysecin Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Relationship identification and classification, kohta 4.1.2 toteaa:

[Kaikki] Prosessin omistajan / liiketoimintaomistajan ON tunnistettava REG08:ssa jokainen ehdotettu kolmannen osapuolen suhde, joka käsittelee, käyttää, vastaanottaa, säilyttää, siirtää, tukee tai muutoin vaikuttaa henkilötietoihin, ennen hankintaa, käyttöönottoa, uusimista tai olennaista kolmannen osapuolen tietosuojamuutosta.

Kohta 4.5.5 edellyttää:

[Molemmat] Toimittaja- / hankintavastaavan ON kirjattava REG08:aan käsittelypaikat, hosting-sijainnit ja kansainvälisen siirron indikaattorit sekä linkitettävä soveltuva siirtoa koskeva näyttö REG09:ään ennen henkilötietojen käsittelijän, alikäsittelijän, sijaintimuutoksen tai siirron kannalta relevantin palvelumuutoksen hyväksymistä.

Lopuksi vaatimustenmukaisuudesta vastaava henkilö kokoaa näytön. Clarysecin Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Objectives, kohta 3.4 toteaa, että yhtenä tavoitteena on:

Tuottaa puolustettavissa olevaa näyttöä ja auditointijälki viranomaistiedustelujen, oikeudenkäyntien tai asiakkaiden varmentamispyyntöjen tueksi.

Tämä on tulos, jota tietoturvajohtaja tarvitsee, kun asiakas, valvontaviranomainen tai auditoija kysyy: ”Mistä tiedätte, ettei tämä tapahdu uudelleen?”

Mihin Zenith Blueprint sijoittuu

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint muuntaa kontrollit auditointivalmiiksi toimintakäytännöiksi. Dangling DNS liittyy vahvasti neljään alueeseen.

Controls in Action -vaiheessa vaihe 22 kattaa organisatoriset kontrollit 5.1–5.18, mukaan lukien ISO/IEC 27002:2022 -kontrollin 5.9. Zenith Blueprint toteaa:

Mikään organisaatio ei voi suojata sitä, mitä se ei tiedä omistavansa. Kontrolli 5.9 tekee tästä periaatteesta muodollisen ja edellyttää ajantasaisen luettelon perustamista ja ylläpitoa kaikista ISMS:n kannalta olennaisista tiedoista ja niihin liittyvistä omaisuuseristä.

Se jatkaa:

Strategisimmassa muodossaan omaisuusluettelo toimii ISMS:n keskushermostona.

Aliverkkotunnusluettelo ei ole sivulista. Se syöttää tietoa käyttöoikeuspäätöksiin, haavoittuvuusskannauksiin, lokitukseen, toimittajahallintaan, tietosuojakartoitukseen ja tietoturvapoikkeamiin reagointiin.

Vaiheessa 20 Zenith Blueprint kattaa teknologiset kontrollit 8.18–8.26. Kontrollin 8.21, Verkkopalvelujen turvallisuus, osalta se ohjeistaa organisaatioita validoimaan verkkopalvelujen turvallisuuden:

Listaa kaikki sisäiset ja ulkoiset verkkopalvelut (DNS, VPN, SMTP, DHCP, API-yhdyskäytävät jne.).

Siksi DNS-palveluntarjoajat, rekisteröijät, pilvi-DNS, CDN-alustat ja SaaS-palvelujen mukautettujen verkkotunnusten ominaisuudet kuuluvat palvelurekisteriin.

Vaiheessa 19 Zenith Blueprint kattaa teknologiset kontrollit 8.1–8.17. Kontrollista 8.8 se toteaa:

Haavoittuvuuksien hallinta on yksi modernin kyberhygienian kriittisimmistä osa-alueista. Vaikka palomuurit ja virustorjuntatyökalut tarjoavat suojaa, suoja voi heikentyä, jos paikkaamattomia järjestelmiä tai virheellisesti konfiguroituja palveluja jätetään alttiiksi.

Dangling DNS -tietue on virheellisesti konfiguroitu ulkoinen palvelupolku. Vaikka CVE-tunnistetta ei olisi, se tulee käsitellä haavoittuvuuksien hallinnan kautta: validoi, pisteytä, osoita omistajalle, korjaa, testaa uudelleen ja sulje.

Vaiheessa 23 Zenith Blueprint käsittelee organisatorisia kontrolleja 5.19–5.37. Kontrollin 5.23 osalta se neuvoo:

Listaa kaikki tällä hetkellä käytössä olevat pilvipalvelut (5.23), mukaan lukien tunnettu varjo-IT. Tunnista, kuka ne hyväksyi ja tehtiinkö due diligence. Laadi kevyt arviointitarkistuslista, joka kattaa tietojen sijainnin, käyttöoikeusmallin, lokituksen ja salauksen.

Aliverkkotunnuksen haltuunoton ehkäisyä varten lisää tähän pilvipalvelujen arviointitarkistuslistaan mukautetut verkkotunnukset, DNS-riippuvuudet, käytöstäpoiston omistaja ja irtautumisnäyttö.

NIS2-, DORA- ja GDPR-kartoitus

NIS2 tekee dangling DNS -hallinnasta hallitustason kysymyksen monille keskeisille ja tärkeille toimijoille. Article 20 edellyttää, että hallintoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat toteutusta ja osallistuvat kyberturvallisuuskoulutukseen. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä kaikki vaarat huomioon ottavalla lähestymistavalla. Sen vähimmäisalueisiin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta, kehittäminen ja ylläpito, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, koulutus, pääsynhallinta ja omaisuudenhallinta.

Dangling DNS -ohjelma kartoittuu näihin alueisiin selkeästi. Article 21(3) edellyttää myös, että toimitusketjun turvallisuudessa otetaan huomioon kullekin suoralle toimittajalle tai palveluntarjoajalle ominaiset haavoittuvuudet. Jos markkinointitoimisto, SaaS-toimittaja, hallinnoitu hosting-palveluntarjoaja tai pilvialusta hallinnoi mukautettuja verkkotunnuksia, toimittajakohtaisten kontrollien tulee kattaa DNS-omistajuus, palvelusta irtautuminen, poikkeamatuki ja näytön luovutus.

Article 23 on olennainen, jos haltuunotto tapahtuu tai voi aiheuttaa vakavan toiminnallisen häiriön, taloudellista tappiota tai huomattavaa aineellista tai aineetonta vahinkoa. NIS2 käyttää vaiheistettua raportointia: ennakkovaroitus 24 tunnin kuluessa merkittävän poikkeaman tietoon tulemisesta, ilmoitus 72 tunnin kuluessa, väliraportit pyynnöstä ja loppuraportti kuukauden kuluessa poikkeamailmoituksesta.

Finanssialan toimijoille DORA on alakohtainen digitaalisen häiriönsietokyvyn sääntelykehys. Articles 5 ja 6 edellyttävät sisäistä hallinto- ja kontrollikehystä ICT-riskien hallintaan, hallintoelimen viimekätistä vastuuta, selkeitä ICT-rooleja, politiikkoja tietojen saatavuuden, aitouden, eheyden ja luottamuksellisuuden varmistamiseksi, auditointisuunnitelmia, resursseja, kolmannen osapuolen palveluja koskevaa politiikkaa ja dokumentoitua ICT-riskienhallinnan viitekehystä.

Articles 8–14 muodostavat operatiivisen ytimen. Article 8 edellyttää ICT-tuettujen liiketoimintatoimintojen, tietovarojen, ICT-omaisuuserien, riippuvuuksien, kolmannen osapuolen ICT-yhteyksien, inventaarioiden, riskiskenaarioiden ja legacy-järjestelmien tunnistamista, luokittelua ja dokumentointia. Dangling CNAME on usein huomaamatta jäänyt riippuvuus. Article 9 edellyttää suojausta ja ennaltaehkäisyä. Article 10 edellyttää poikkeavan toiminnan, ICT-poikkeamien ja mahdollisten yksittäisten vikapisteiden havaitsemista. Articles 11 ja 12 käsittelevät jatkuvuutta, toipumista, varmuuskopiointia ja palautusta. Article 13 edellyttää oppimista haavoittuvuuksista, uhista, poikkeamista ja testeistä.

Articles 17–19 tekevät poikkeamien hallinnasta, luokittelusta ja raportoinnista muodollista. Articles 28–30 tekevät kolmannen osapuolen ICT-riskistä elinkaariperusteista. Finanssialan toimijat pysyvät täysin vastuussa käyttäessään ICT-palveluntarjoajia. DORA-valmiutta varten Clarysec suosittelee lisäämään jokaiseen DNS- ja pilvipalvelurekisteriin neljä kenttää: kriittisen tai tärkeän toiminnon tuki, kolmannen osapuolen ICT-palveluntarjoaja, sopimus- tai rekisteriviite sekä irtautumistestin tila.

GDPR soveltuu, kun asia koskee henkilötietoja. Aliverkkotunnuksen haltuunotto ei automaattisesti ole henkilötietojen tietoturvaloukkaus, mutta siitä voi tulla sellainen, jos kyseinen aliverkkotunnus kerää tunnistetietoja tai lomaketietoja, esiintyy palveluna, altistaa käyttäjätunnisteita tai mahdollistaa luvattoman pääsyn henkilötietoihin. GDPR Article 5 edellyttää eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Article 32 edellyttää asianmukaista käsittelyn turvallisuutta. Article 33 voi edellyttää ilmoitusta valvontaviranomaiselle, jos henkilötietojen tietoturvaloukkaus todennäköisesti aiheuttaa riskin luonnollisten henkilöiden oikeuksille ja vapauksille.

Clarysecin PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Classification and breach assessment, kohta 4.2.6 tukee tätä usean sääntelykehikon ilmoituskynnysten analyysia:

[Ehdollinen] Tietosuojavastaavan / PIMS-päällikön ON arvioitava soveltuvat lakisääteiset, alakohtaiset, finanssialan, kyberturvallisuuteen liittyvät, sopimusperusteiset, asiakas- ja palvelun vastaanottajaa koskevat raportointikynnykset jokaiselle vaikutuksiltaan merkittävälle henkilötietopoikkeamalle ja kirjattava soveltuvuuden lopputulos REG01:een, REG08:aan ja REG10:een.

Juuri tällaista päätöskirjausta tarvitaan, kun aliverkkotunnuksen haltuunotto voi koskea GDPR:ää, NIS2:ta, DORA:a, sopimuksia ja asiakasilmoituksia.

Miten auditoijat testaavat näyttönne

Integroitu ISMS mahdollistaa vastaamisen eri auditoijille samalla näyttöpohjalla. Kysymyksen sanamuoto muuttuu, mutta todentava aineisto on usein sama.

Laajempi varmentamisnäkökulma sisältää usein myös NIST CSF 2.0:n ja COBIT 2019:n. NIST CSF 2.0 auttaa kuvaamaan tavoitetilan GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-tulosten kautta. Nykyprofiili voi osoittaa manuaalisia neljännesvuosittaisia DNS-katselmointeja ja epäyhtenäistä SaaS-offboardingia. Tavoiteprofiili voi edellyttää automatisoituja viikoittaisia haltuunottotarkistuksia, pakollista omistajan osoittamista, toimittajan irtautumisnäyttöä ja integraatiota muutoksenhallintaan.

COBIT 2019- tai ISACA-suuntautunut auditoija kysyy yleensä, kuka omistaa prosessin, miten riskiä arvioidaan ja ohjataan, hallitaanko muutoksia, hallitaanko toimittajia, ovatko konfiguraatio ja omaisuuserät luotettavia ja tukeeko varmentamisnäyttö johdon raportointia. Hän ei välttämättä kysy ensimmäiseksi CNAME-luetteloa. Hän voi kysyä, miten johto tietää, että ulkoiset digitaaliset palvelut ovat hallinnassa koko elinkaarensa ajan.

Miltä hyvä auditointinäyttö näyttää

Dangling DNS -auditointipaketin tulee olla riittävän pieni ylläpidettäväksi mutta riittävän kattava puolustettavaksi. Clarysec suosittelee yleensä seuraavaa näyttökokonaisuutta:

• DNS-vyöhykeluettelo, jossa ovat lähde, päivämäärä, tietuetyyppi, kohde ja omistaja.
• Ulkoisen hyökkäyspinnan skannaustulokset, jotka osoittavat haltuunottotarkistukset.
• Omaisuusrekisterimerkinnät verkkotunnuksista, aliverkkotunnuksista, pilvipalveluista, SaaS-sovelluksista ja CDN-palveluista.
• Palvelurekisteri, joka osoittaa sisäisen tai toimittajan vastuun.
• Muutostiketit DNS-tietueiden luomisesta, muuttamisesta ja poistamisesta.
• Pilvi- ja SaaS-käyttöönoton tarkistuslistat, jotka sisältävät mukautetun verkkotunnuksen ja DNS-katselmoinnin.
• Toimittajasopimukset tai tietoturvalausekkeet, jotka kattavat DNS:n, hostingin, poikkeamatuen ja irtautumisen.
• Haavoittuvuustiketit, joissa ovat vakavuus, omistaja, korjauspäivä ja uudelleentestauksen näyttö.
• Henkilötietoja koskeva arviointi, kun aliverkkotunnus käsittelee tai on aiemmin käsitellyt henkilötietoja.
• Poikkeamaluokittelun tallenteet epäillystä tai vahvistetusta haltuunotosta.
• Opit ja havaintojen jälkeen päivitetyt menettelyt.

Myös mittareilla on merkitystä. Johdon tulee nähdä ulkoisten aliverkkotunnusten määrä, omistajalla varustettujen osuus, dangling DNS -havaintojen määrä, keskimääräinen korjausaika, myöhässä olevat korkean riskin havainnot, toimittajan isännöimät aliverkkotunnukset ilman ajantasaista sopimusviitettä sekä pilvipalveluista irtautumisten osuus, jossa DNS-poistosta on näyttö.

Nämä mittarit muuttavat teknisen hygienian johdon valvonnan näytöksi.

Clarysecin havaitsemat yleiset epäonnistumismallit

SaaS-, fintech-, terveysteknologia-, hallinnoitujen palvelujen ja verkkokauppa-asiakkaiden keskuudessa samat mallit toistuvat.

Ensinnäkin DNS-omistajuus on jaettu tiimien kesken. Kehitys omistaa pilven. Markkinointi omistaa kampanjat. IT omistaa pääsyn DNS-palveluntarjoajaan. Hankinta omistaa SaaS-sopimuksen päättämisen. Kukaan ei omista koko elinkaarta.

Toiseksi pilvipalvelun poistamista pidetään palvelun päätepisteenä. Todellisuudessa DNS, varmenteet, WAF-säännöt, seuranta, salaisuudet, dokumentaatio ja toimittajatallenteet voivat jäädä jäljelle.

Kolmanneksi haavoittuvuusskannerit keskittyvät eläviin isäntiin mutta eivät havaitse palveluntarjoajakohtaisia haltuunoton edellytyksiä. Organisaatiot tarvitsevat ulkoisen hyökkäyspinnan tarkistuksia, jotka ymmärtävät yleiset SaaS- ja pilvipalvelujen virhetilat.

Neljänneksi toimittajasuhteen päättämismenettelyt keskittyvät laskuihin ja tietojen palauttamiseen, eivät mukautettuihin verkkotunnuksiin, DNS-tietueisiin ja alikäsittelijämuutoksiin.

Viidenneksi tietosuojatiimeille ilmoitetaan liian myöhään. Jos aliverkkotunnus käsitteli henkilötietoja, tietosuojavastaavan tai tietosuojasta vastaavan henkilön tulee olla mukana luokittelussa ennen oletusten tekemistä.

Kuudenneksi näyttöä on olemassa, mutta se on hajallaan. DNS-vienti on yhdessä työkalussa, muutostiketit toisessa, toimittajasopimukset hankinnassa, haavoittuvuusraportit skannereissa ja tietosuoja-analyysi sähköpostissa. Auditoijat näkevät hajanaisuuden heikkoutena.

Clarysecin työkalupaketti ratkaisee tämän yhdistämällä politiikat, rekisterit, kontrollit ja näytön työnkulut.

30 päivän toimintasuunnitelma DNS-hallintaan

Jos löysitte yhden dangling DNS -tietueen, olettakaa, että niitä on lisää. Jos ette löytäneet yhtään, varmistakaa, että pystytte osoittamaan miksi.

Aloittakaa tällä 30 päivän suunnitelmalla:

1. Vie kaikki auktoritatiiviset DNS-vyöhykkeet.
2. Tunnista CNAME-, ALIAS-, A- ja AAAA-tietueet, jotka osoittavat pilvi-, SaaS-, CDN- ja toimiston hallinnoimiin palveluihin.
3. Osoita omistajat ja liiketoimintatarkoitukset.
4. Suorita haltuunottotarkistukset ja validoi epäilyttävät tietueet manuaalisesti.
5. Luo haavoittuvuustiketit vahvistetuille riskeille.
6. Poista tai varaa uudelleen altistuneet tietueet muutoksenhallinnan kautta.
7. Päivitä omaisuusrekisteri, pilvipalvelurekisteri ja toimittajarekisteri.
8. Arvioi, käsittelikö jokin vaikutuksen kohteena oleva aliverkkotunnus henkilötietoja.
9. Lisää DNS-elinkaaren tarkistukset pilvipalvelujen käyttöönottoon, SaaS-hankintaan ja toimittajasuhteen päättämiseen.
10. Raportoi mittarit johdolle.

Dangling DNS -riskin tekninen korjaus on usein yksinkertainen. Hallintakorjaus estää seuraavan haltuunoton.

Clarysec voi auttaa operationalisoimaan tämän käyttämällä Zenith Blueprint Zenith Blueprint- ja Zenith Controls Zenith Controls -ratkaisuja sekä politiikkatyökalupakkiamme omaisuudenhallintaan, pilvipalvelujen käyttöön, haavoittuvuuksien hallintaan, toimittajahallintaan, henkilötietojen turvallisuuteen, tietoturvapoikkeamiin reagointiin ja auditointinäyttöön.

Jos haluatte auditointivalmiin lähestymistavan, Clarysec voi auttaa rakentamaan DNS- ja pilvialtistumisen näyttöpaketin, kartoittamaan sen ISO/IEC 27001:2022 -standardiin, NIS2:een, DORA:an ja GDPR:ään sekä muuttamaan unohtuneet aliverkkotunnukset hallituiksi, omistetuiksi ja valvotuiksi omaisuuseriksi. Lataa asiaankuuluva Clarysec-työkalupaketti, pyydä demo tai varaa DNS-hallinnan arviointi ennen kuin penetraatiotestaaja, auditoija tai hyökkääjä löytää seuraavan unohtuneen osoittimen.