Dangling DNS irányítása NIS2, DORA és GDPR megfelelőséghez

A CISO hétfőn 07:12-kor kapja meg az üzenetet.

Egy biztonsági kutató azt találta, hogy a promo.company.com egy elhagyott felhőalkalmazásra mutat. A DNS-bejegyzés továbbra is él. A felhőerőforrás már nem létezik. A kampányt korábban kiszolgáló SaaS-bérlőt hat hónappal korábban törölték, röviddel azután, hogy a marketing másik platformra költözött. A CNAME-et senki nem távolította el.

08:30-ra a kérdés már nem az, hogy „Át tudja-e valaki venni az aldomaint?”, hanem az, hogy „Miért nem tudta senki, hogy ez a vagyonelem létezik?”

09:15-re a jogi terület is bekapcsolódik, mert az aldomain korábban e-mail-címeket gyűjtött egy termék várólistájához. A beszerzés is érintett, mert a kampányplatformot egy ügynökség kezelte. A megfelelőségi terület is érintett, mert a vállalat ISO/IEC 27001:2022 felügyeleti auditra, NIS2-felkészültségre és ügyfélbizonyossági kérdőívekre készül. Az adatvédelmi tisztviselő (DPO) azt kérdezi, hogy a kitettség GDPR szerinti személyesadat-sértéssé válhat-e, ha az aldomaint támadásra használják. A CFO azt kérdezi, hogy ugyanez a gyengeség érinthet-e egy fizetési portált a csoport szabályozott pénzügyi szolgáltatási környezetében.

A technikai javítás néhány percet vehet igénybe. Az irányítási probléma rendezése hónapokig tarthat, ha a szervezet nem tudja bizonyítani, hogy minden internet felől elérhető vagyonelem ismert, kijelölt felelőssel rendelkezik, felülvizsgált, felügyelt, és szabályozott folyamat szerint kerül kivonásra.

Ezért a dangling DNS és az aldomain-átvétel megelőzése nem kezelhető szűk DNS-takarítási feladatként. Egy elavult DNS-bejegyzés gyakran mélyebb kontrollhibák látható tünete: hiányos eszköznyilvántartás, gyenge tulajdonosi elszámoltathatóság, hiányzó kivonási bizonyítékok, elégtelen változáskezelés, nem megfelelő beszállítói kiléptetés, elégtelen külső támadásifelület-felügyelet és nem egyértelmű incidensbesorolás.

A Clarysec ügyfelei számára a dangling DNS az irányítási rendszer próbája. Megmutatja, hogy a szabályzatok, kontrollok, nyilvántartások, bizonyítékok és elszámoltathatóság ténylegesen működnek-e, amikor egy elfelejtett felhőfüggőség támadói lehetőséggé válik.

Mit jelent valójában a dangling DNS

Az aldomain-átvétel akkor válik lehetővé, amikor egy DNS-bejegyzés, gyakran CNAME, olyan erőforrásra mutat, amely már nem létezik, vagy már nem áll a szervezet ellenőrzése alatt. Ha egy támadó igényelni vagy újra létrehozni tudja a cél-erőforrást a felhő- vagy SaaS-platformon, képes lehet tartalmat kiszolgálni a szervezet megbízható aldomainje alatt.

Gyakori példák:

• Olyan CNAME, amely nem igényelt felhőalkalmazás-szolgáltatásra mutat.
• DNS-ben hagyott egyedi SaaS-gazdanév a szolgáltatás-előfizetés megszüntetése után.
• Szolgáltatói konzolból eltávolított CDN-disztribúció, amelyre a nyilvános DNS továbbra is hivatkozik.
• Ügynökség által kivezetett marketing mikrowebhely DNS-eltávolítás nélkül.
• Tárolási végpont vagy statikus webhely-hozzárendelés, amely újraregisztrálható.
• Elfelejtett platform-as-a-service projekten keresztül kitett fejlesztési aldomain.

Az üzleti hatás súlyos lehet. A támadók adathalász oldalakat üzemeltethetnek, hitelesítő adatokat rögzíthetnek, malware-t terjeszthetnek, visszaélhetnek a domain reputációjával, munkamenetadatokat foghatnak el, vagy károsíthatják a márkába vetett bizalmat. Ha az aldomain korábban személyes adatokat kezelt, akár egy rövid ideig tartó átvétel is GDPR szerinti adatsértési elemzést válthat ki. Ha az érintett szolgáltatás szabályozott pénzügyi műveleteket támogat, az incidenst DORA vagy belső IKT-kockázati keretrendszerek szerint is értékelni kellhet.

Az auditorok egyre gyakrabban tekintik a dangling DNS-t a kontrollérettség bizonyítékának. Egyetlen elavult bejegyzés is jelezheti, hogy a szervezet nem tudja, milyen vagyonelemei vannak, ki felel értük, hogyan történik a változások felülvizsgálata, hogyan lép ki felhőszolgáltatásokból, vagy hogyan felügyeli a külső elérésű vagyonelemeket.

Ezért a Clarysec ezt a kérdést ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT 2019 auditkövetelmények szerint felelteti meg.

Miért az ISO 27001:2022 a gyakorlati alap

A dangling DNS irányításának legerősebb módja nem az, ha külön programokat hozunk létre NIS2, DORA és GDPR célokra. A helyes megközelítés az, hogy az ISO/IEC 27001:2022 szolgál az irányítási rendszer alapjaként, és a szervezet egyszer állít elő bizonyítékot több bizonyossági igényhez.

A releváns követelmények már az A melléklet előtt kezdődnek. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a kontextusát, az érdekelt felek követelményeit, az IBIR alkalmazási területét és a más szervezetekkel fennálló függőségeket. Dangling DNS irányítása esetén az alkalmazási területnek ki kell terjednie a külső DNS-re, domainekre, regisztrátorokra, felhőszolgáltatásokra, SaaS-platformokra, ügynökségekre, menedzselt tárhelyre, CDN-ekre és minden olyan harmadik félre, amely internet felől elérhető szolgáltatást hozhat létre vagy vonhat ki.

Az 5.1–5.3 pontok ezt vezetői és elszámoltathatósági kérdéssé teszik. A vezetésnek össze kell hangolnia az IBIR-t az üzleti iránnyal, erőforrásokat kell biztosítania, kommunikálnia kell az információbiztonság fontosságát, és ki kell jelölnie a felelősségi köröket. Ha a marketing mikrowebhelyet indíthat, a fejlesztési terület felhővégpontokat hozhat létre, a beszerzés pedig SaaS-szerződéseket szüntethet meg, a szervezetnek olyan irányítási modellre van szüksége, amely mindezekhez egyértelmű DNS- és szolgáltatásfelelősséget rendel.

A 6.1.1–6.1.3 pontok adják a kockázatértékelés, a kockázatkezelés és az alkalmazhatósági nyilatkozat logikáját. A dangling DNS-t reális kockázati forgatókönyvként kell rögzíteni, nem pusztán egy vizsgálóeszköz kimeneteként. Érinti a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és gyakran kapcsolódik jogi, szabályozási és szerződéses kötelezettségekhez.

A 7.5, 8.1, 8.2 és 8.3 pontok az irányítást bizonyítékokká alakítják. Előírják a kontrollált dokumentált információt, a tervezett és szabályozott működési folyamatokat, a nem szándékolt változások figyelembevételét, a külsőleg biztosított folyamatok kontrollját, az időszakos kockázatértékeléseket és a dokumentált kockázatkezelési eredményeket.

Ezt követően az A melléklet adja a kontrollkatalógust. Clarysec-projektekben az alapvető ISO/IEC 27002:2022 kapcsolatok jellemzően így néznek ki:

A lényeg egyszerű. Az ISO/IEC 27001:2022 nem egyszeri, hősies takarítást kér. Olyan szabályozott működési modellt vár el, amely megakadályozza az ismételt előfordulást.

A Zenith Controls nézőpontja: egy kockázat, három kontrollhorgony

A Zenith Controls: megfelelőségi keretrendszerek közötti útmutatóban Zenith Controls a Clarysec releváns ISO/IEC 27002:2022 kontrollokat használ megfelelőségi keretrendszerek közötti horgonyként. A dangling DNS és az aldomain-átvétel irányítása szempontjából három kontroll központi jelentőségű.

Az 5.9 kontroll, az információk és egyéb kapcsolódó vagyonelemek nyilvántartása, megelőző kontrollként van besorolva, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, az Identify kiberbiztonsági koncepcióhoz igazodik, és működési képességként az eszközkezelés alá tartozik, irányítási, ökoszisztéma- és védelmi biztonsági területekkel.

Az 5.23 kontroll, az információbiztonság felhőszolgáltatások használata során, megelőző kontrollként van besorolva, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, a Protect területhez igazodik, és működési képességként a beszállítói kapcsolatok biztonsága alá tartozik, irányítási, ökoszisztéma- és védelmi biztonsági területekkel.

A 8.8 kontroll, a műszaki sérülékenységek kezelése, megelőző kontrollként van besorolva, támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, az Identify és Protect területekhez igazodik, és működési képességként a fenyegetés- és sérülékenységkezelés alá tartozik, irányítási, ökoszisztéma-, védelmi és védelmi műveleti biztonsági területekkel.

Ez azért fontos, mert a dangling DNS nem csak eszközkontroll-hiba, nem csak felhőkontroll-hiba, és nem csak sérülékenység. Mindhárom egyszerre. A szervezetnek bizonyítania kell, hogy az eszköznyilvántartás, a felhőhasználat irányítása és a sérülékenységkezelés egymást erősíti.

A Clarysec gyakran támogató gyakorlatokat is kapcsol ezekhez a horgonyokhoz: ISO/IEC 27005 a kockázatértékelési és kockázatkezelési fegyelemhez, ISO/IEC 27017 a felhőszolgáltatások biztonsági irányításához, ISO/IEC 27018 ott, ahol felhőszolgáltatások PII-t kezelnek, ISO/IEC 27701 az adatvédelmi információkezeléshez, valamint ISO 22301, ahol az üzletmenet-folytonosság és a válságreagálás releváns.

Azok a szabályzati bizonyítékok, amelyek már előírják a DNS-életciklus kontrollját

Sok szervezetnek már vannak olyan szabályzatai, amelyek megfelelő végrehajtás esetén megakadályoznák a dangling DNS-t. A hiányosság az, hogy a DNS-életciklus kontrollja nincs kifejezetten összekapcsolva ezekkel a szabályzatokkal.

A Clarysec Eszközkezelési szabályzat-sme Eszközkezelési szabályzat-sme - KKV dokumentumának szabályzat-végrehajtási követelményei között a 6.6.1 pont kimondja:

A felhőalapú vagyonelemeket (például tárhelyfiókokat, SaaS-platformokat, webdomaineket) is szerepeltetni kell a nyilvántartásban.

Ugyanez a szabályzat a 6.6.2 pontban hozzáteszi:

Dokumentálni kell a tulajdonosi felelősséget, a célt, a hozzáférési jogosultságokat és a megújítási határidőket.

Dangling DNS irányítása esetén ez azt jelenti, hogy minden éles aldomainnek és minden lényeges nem éles aldomainnek rendelkeznie kell megnevezett felelőssel, üzleti céllal, kapcsolódó szolgáltatással, hozzáférési modellel és felülvizsgálati dátummal.

A legfontosabb, hogy a 6.6.3 pont kimondja:

A lejárt vagy nem használt szolgáltatásokat deaktiválni kell, és el kell távolítani a nyilvántartásból.

DNS esetében ezt körültekintően kell értelmezni. Nem elég a szolgáltatást eltávolítani a nyilvántartásból. A DNS-bejegyzést, a felhőkötést, a SaaS egyedi domain igénylését, a tanúsítványt, a WAF-szabályt, a CDN-konfigurációt és a felügyeleti bejegyzést is felül kell vizsgálni.

A vállalati verzió megerősíti ezt a tágabb eszközfogalmat. A Clarysec Eszközkezelési szabályzat Eszközkezelési szabályzat dokumentumának alkalmazási területéről szóló 2.2.5 pontja kimondja:

Logikai vagyonelemek: domainnevek, licencek, felhasználói fiókok, konfigurációs alapbeállítások

A domainnevek és konfigurációk nem adminisztratív részletkérdések. Bizalmat hordozó vagyonelemek, amelyek támadási útvonalakká válhatnak.

A változáskezelési kapcsolat ugyanilyen fontos. A Clarysec Változáskezelési szabályzat Változáskezelési szabályzat dokumentumának célról szóló 1.1 pontja kimondja:

Ez a szabályzat formális keretrendszert hoz létre a szervezet információs rendszereit, infrastruktúráját, alkalmazásait és kapcsolódó folyamatait érintő változások kezdeményezésére, értékelésére, jóváhagyására, végrehajtására és felülvizsgálatára.

A DNS-eltávolításnak, SaaS-megszüntetésnek, felhőalkalmazás törlésének, CDN-migrációnak vagy marketing mikrowebhely kivonásának ezért változáskezelési bizonyítékot kell előállítania. A változásjegy hiánya gyakran az első auditfigyelmeztetés.

A felhőirányítást is össze kell kapcsolni. A Clarysec Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat dokumentumának irányítási követelményei között az 5.5 pont kimondja:

Az információbiztonsági csapatnak rendszeresen értékelnie kell a hálózati forgalmat, a DNS-tevékenységet és a naplókat a nem engedélyezett felhőhasználat (shadow IT) észlelése érdekében. Az észlelt szabálysértéseket haladéktalanul ki kell vizsgálni.

Az aldomain-átvétel megelőzésénél a DNS-tevékenység felügyelete nem csak a shadow IT-ról szól. A „stale IT”-ról is szól: azokról a vagyonelemekről, amelyek korábban engedélyezettek voltak, de már nem állnak ellenőrzés alatt.

Gyakorlati Clarysec-munkafolyamat a dangling DNS irányításához

Egy erős dangling DNS program nem bonyolult. Fegyelmezett, ismételhető, és kapcsolódik az IBIR-hez, a sérülékenységkezeléshez, a változáskezeléshez és a beszállítói életciklushoz.

KKV-k esetében ez indulhat könnyített nyilvántartásként. Vállalatoknál jellemzően integrálja a DNS-exportokat, a külső támadási felület kezelését, a felhővagyon-nyilvántartásokat, CMDB-bejegyzéseket, sérülékenységvizsgálókat, SIEM-riasztásokat és jegykezelő rendszereket.

Az irányítási kérdés változatlan: bizonyítani tudja-e, hogy minden kívülről elérhető aldomain ismert, kijelölt felelőssel rendelkezik, felügyelt, és szabályozott folyamatban eltávolítható?

Az elhagyott kampányaldomain helyes kezelése

Térjünk vissza a hétfői incidenshez. A promo.company.com egy elhagyott SaaS-kampányoldalra mutat.

Először a biztonsági vezető sérülékenységi bejegyzést hoz létre, mert a vagyonelem külső elérésű. A Clarysec Sérülékenység- és javításkezelési szabályzat Sérülékenység- és javításkezelési szabályzat dokumentumának szabályzat-végrehajtási követelményei között a 6.1.1 pont kimondja:

Minden rendszert legalább havonta vizsgálni kell; a magas kockázatú vagy külső kitettségű vagyonelemeket hetente kell vizsgálni.

KKV-k esetében az egyenértékű szabályzat pontosítja a priorizálást. A Sérülékenység- és javításkezelési szabályzat-sme Sérülékenység- és javításkezelési szabályzat-sme - KKV dokumentumának szabályzat-végrehajtási követelményei között a 6.5.1 pont kimondja:

Elsőbbséget kell adni a vizsgálatok és frissítések során azoknak a rendszereknek, amelyek személyes adatokat kezelnek, távoli hozzáférést biztosítanak, vagy külső elérésűek.

Másodszor, a felelőst az eszköznyilvántartáson keresztül kell azonosítani. Ha a felelős ismeretlen, az eszközirányítási kontroll hibájának minősül. A nyilvántartást frissíteni kell a DNS-névvel, a cél-szolgáltatóval, az eredeti üzleti felelőssel, az adatosztályozással, a beszállítóval és az állapottal.

Harmadszor, az IT ellenőrzi a felhő- vagy SaaS-platformot. Ha a felhőfiókot törölték, a Clarysec Felhőszolgáltatások használatára vonatkozó szabályzat-sme Felhőszolgáltatások használatára vonatkozó szabályzat-sme - KKV dokumentumának szabályzat-végrehajtási követelményei között a 6.3.6 pont közvetlenül releváns:

A törölt felhőfiókokat az IT-szolgáltatónak vagy az ügyvezetőnek felül kell vizsgálnia fennmaradó hozzáférés, gazdátlan adatok vagy figyelmen kívül hagyott tartalom szempontjából.

Negyedszer, a változásgazda sürgősségi vagy gyorsított változásjegyet nyit a DNS-bejegyzés eltávolítására vagy az erőforrás ideiglenes visszaigénylésére az eltávolítás előtt. A jegy tartalmazza a hatásvizsgálatot, a visszaállítási tervet, a jóváhagyásokat, a végrehajtási bizonyítékokat és a változtatás utáni ellenőrzést.

Ötödször, az adatvédelmi felelős értékeli, hogy az aldomain kezelt-e vagy kitehetett-e személyes adatokat. A Clarysec PII-biztonsági és hozzáférés-szabályozási szabályzat PII-biztonsági és hozzáférés-szabályozási szabályzat dokumentumának biztonságos konfigurációról és sérülékenységkezelésről szóló 4.7.4 pontja kimondja:

[Mindkét szerepben] A rendszergazda / Alkalmazástulajdonos KÖTELES legalább negyedévente és lényeges műszaki változás után rögzíteni a PII-t kezelő rendszerek sérülékenységértékelési lefedettségét a REG12-ben.

A 4.7.5 pont hozzáteszi:

[Mindkét szerepben] Az információbiztonsági vezető KÖTELES az ellenőrzéstől számított öt munkanapon belül rögzíteni a REG12-ben a PII-t érintő, megoldatlan magas kockázatú sérülékenységeket.

Ezek a pontok akkor is alkalmazandók, ha a szervezet adatkezelőként, és akkor is, ha adatfeldolgozóként jár el, mert [Mindkét szerepben] jelölést kaptak. PII-t érintő dangling DNS-probléma esetén a bizonyíték nem maradhat kizárólag technikai jegyben. Meg kell jelennie a PII sérülékenységi bizonyítéknyilvántartásában is.

Hatodszor, ha a kampányt ügynökség vagy SaaS-szolgáltató hosztolta, a beszerzés ellenőrzi a harmadik félre vonatkozó nyilvántartásokat. A Clarysec Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat dokumentumának kapcsolat-azonosításról és besorolásról szóló 4.1.2 pontja kimondja:

[Minden esetben] A folyamatgazda / üzlettulajdonos KÖTELES minden olyan tervezett harmadik féllel fennálló kapcsolatot azonosítani a REG08-ban a beszerzés, beléptetés, megújítás vagy harmadik féllel fennálló adatvédelmi kapcsolat lényeges változása előtt, amely PII-t kezel, ahhoz hozzáfér, azt megkapja, tárolja, továbbítja, támogatja vagy más módon érinti.

A 4.5.5 pont előírja:

[Mindkét szerepben] A beszállító / beszerzési felelős KÖTELES rögzíteni a REG08-ban az adatkezelési helyeket, tárhelyhelyeket és nemzetközi adattovábbítási indikátorokat, valamint a vonatkozó adattovábbítási bizonyítékokat a REG09-hez kapcsolni adatfeldolgozó, al-adatfeldolgozó, helyszínváltozás vagy adattovábbítás szempontjából releváns szolgáltatásváltozás jóváhagyása előtt.

Végül a megfelelőségi vezető összeállítja a bizonyítékokat. A Clarysec Audit- és megfelelésfelügyeleti szabályzat Audit- és megfelelésfelügyeleti szabályzat dokumentumának célkitűzésekről szóló 3.4 pontja szerint az egyik cél:

Igazolható bizonyítékok és auditnyom előállítása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.

Pontosan erre az eredményre van szüksége a CISO-nak, amikor egy ügyfél, szabályozó hatóság vagy auditor azt kérdezi: „Honnan tudják, hogy ez nem fog újra megtörténni?”

Hol illeszkedik a Zenith Blueprint

A Clarysec Zenith Blueprint: auditori 30 lépéses ütemterv Zenith Blueprint a kontrollokat auditra alkalmas működési gyakorlatokká alakítja. A dangling DNS négy területhez kapcsolódik szorosan.

A Controls in Action fázisban a 22. lépés az 5.1–5.18 szervezeti kontrollokat fedi le, beleértve az ISO/IEC 27002:2022 5.9 kontrollt. A Zenith Blueprint kimondja:

Egyetlen szervezet sem tudja megvédeni azt, amiről nem tudja, hogy a birtokában van. Az 5.9 kontroll ezt az alapelvet formalizálja, előírva az IBIR szempontjából releváns valamennyi információ és kapcsolódó vagyonelem naprakész nyilvántartásának létrehozását és fenntartását.

Majd így folytatja:

Stratégiai értelemben az eszköznyilvántartás az IBIR központi idegrendszereként működik.

Az aldomain-nyilvántartás nem melléklista. Táplálja a hozzáférési döntéseket, a sérülékenységvizsgálatokat, a naplózást, a beszállító-kezelést, az adatvédelmi megfeleltetést és az incidensreagálást.

A 20. lépésben a Zenith Blueprint a 8.18–8.26 technológiai kontrollokat fedi le. A 8.21 kontroll, a hálózati szolgáltatások biztonsága kapcsán arra utasítja a szervezeteket, hogy ellenőrizzék a hálózati szolgáltatások biztonságát:

Sorolja fel az összes belső és külső hálózati szolgáltatást (DNS, VPN, SMTP, DHCP, API-átjárók stb.).

Ezért a DNS-szolgáltatóknak, regisztrátoroknak, felhőalapú DNS-nek, CDN-platformoknak és SaaS egyedi domain funkcióknak szerepelniük kell a szolgáltatásnyilvántartásban.

A 19. lépésben a Zenith Blueprint a 8.1–8.17 technológiai kontrollokat fedi le. A 8.8 kontroll kapcsán kimondja:

A sérülékenységek kezelése a modern kiberhigiénia egyik legkritikusabb területe. Bár a tűzfalak és vírusirtó eszközök védelmet nyújtanak, hatásuk aláásható, ha nem javított rendszerek vagy hibásan konfigurált szolgáltatások maradnak kitéve.

A dangling DNS-bejegyzés hibásan konfigurált külső szolgáltatási útvonal. Még ha nincs is CVE, sérülékenységkezelésen keresztül kell kezelni: ellenőrizni, pontozni, hozzárendelni, javítani, újratesztelni és lezárni.

A 23. lépésben a Zenith Blueprint az 5.19–5.37 szervezeti kontrollokat tárgyalja. Az 5.23 kontroll kapcsán ezt javasolja:

Sorolja fel az összes jelenleg használt felhőszolgáltatást (5.23), beleértve az ismert shadow IT-t is. Azonosítsa, ki hagyta jóvá őket, és elvégezték-e a kellő gondosságot. Készítsen könnyített értékelési ellenőrzőlistát, amely lefedi az adatok helyét, a hozzáférési modellt, a naplózást és a titkosítást.

Az aldomain-átvétel megelőzéséhez ehhez a felhőszolgáltatás-értékelési ellenőrzőlistához hozzá kell adni az egyedi domaineket, a DNS-függőségeket, a kivonás felelősét és a kilépési bizonyítékokat.

NIS2, DORA és GDPR szerinti megfeleltetés

A NIS2 sok alapvető és fontos szervezet számára vezető testületi szintű kérdéssé teszi a dangling DNS irányítását. Article 20 előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását, és vegyenek részt kiberbiztonsági képzésben. Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő minden veszélyforrásra kiterjedő megközelítéssel. Minimumterületei közé tartozik a kockázatelemzés, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés, fejlesztés és karbantartás, a sérülékenységkezelés, az eredményesség értékelése, a kiberhigiénia, a képzés, a hozzáférés-szabályozás és az eszközkezelés.

A dangling DNS program tisztán megfeleltethető ezeknek a területeknek. Article 21(3) azt is előírja, hogy az ellátási lánc biztonságának figyelembe kell vennie az egyes közvetlen beszállítókra vagy szolgáltatókra jellemző sérülékenységeket. Ha marketingügynökség, SaaS-beszállító, menedzselt tárhelyszolgáltató vagy felhőplatform kezel egyedi domaineket, a beszállítóspecifikus kontrolloknak le kell fedniük a DNS-tulajdonosi felelősséget, a szolgáltatásból való kilépést, az incidens-támogatást és a bizonyítékok átadását.

Article 23 akkor lényeges, ha átvétel történik, vagy az súlyos működési zavart, pénzügyi veszteséget, illetve jelentős vagyoni vagy nem vagyoni kárt okozhat. A NIS2 szakaszos jelentéstételt alkalmaz: korai figyelmeztetés a jelentős incidensről való tudomásszerzéstől számított 24 órán belül, bejelentés 72 órán belül, köztes jelentések kérésre, valamint végső jelentés az incidensbejelentéstől számított egy hónapon belül.

Pénzügyi szervezetek esetében a DORA az ágazatspecifikus digitális működési reziliencia szabályozási rendszere. Articles 5 és 6 belső irányítási és kontrollkeretrendszert ír elő az IKT-kockázatkezeléshez, a vezető testület végső felelősségével, egyértelmű IKT-szerepkörökkel, az adatok rendelkezésre állására, hitelességére, sértetlenségére és bizalmasságára vonatkozó szabályzatokkal, audittervekkel, erőforrásokkal, harmadik fél szolgáltatásokra vonatkozó szabályzattal és dokumentált IKT-kockázatkezelési keretrendszerrel.

Articles 8–14 alkotják a működési magot. Article 8 előírja az IKT-val támogatott üzleti funkciók, információs vagyon, IKT-vagyonelemek, függőségek, IKT harmadik fél összekapcsolódások, nyilvántartások, kockázati forgatókönyvek és örökölt rendszerek azonosítását, osztályozását és dokumentálását. A dangling CNAME gyakran elmulasztott függőség. Article 9 védelmet és megelőzést ír elő. Article 10 rendellenes tevékenységek, IKT-incidensek és lehetséges egyedi hibapontok észlelését írja elő. Articles 11 és 12 a folytonossággal, helyreállítással, biztonsági mentéssel és visszaállítással foglalkoznak. Article 13 előírja a sérülékenységekből, fenyegetésekből, incidensekből és tesztekből való tanulást.

Articles 17–19 formalizálják az incidenskezelést, a besorolást és a jelentéstételt. Articles 28–30 életciklus-alapúvá teszik a harmadik fél IKT-kockázat kezelését. A pénzügyi szervezetek teljes felelőssége fennmarad IKT-szolgáltatók igénybevétele esetén is. DORA-felkészültséghez a Clarysec azt javasolja, hogy minden DNS- és felhőszolgáltatási nyilvántartásba kerüljön négy mező: kritikus vagy fontos funkció támogatása, IKT-szolgáltatást nyújtó harmadik fél, szerződés- vagy nyilvántartási hivatkozás, valamint kilépési teszt státusza.

A GDPR akkor alkalmazandó, ha az ügy személyes adatokat érint. Az aldomain-átvétel önmagában nem automatikusan személyesadat-sértés, de azzá válhat, ha az érintett aldomain hitelesítő adatokat gyűjt, űrlapadatokat rögzít, szolgáltatást személyesít meg, felhasználói azonosítókat tesz ki, vagy jogosulatlan hozzáférést tesz lehetővé személyes adatokhoz. GDPR Article 5 sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. Article 32 megfelelő adatkezelési biztonságot követel meg. Article 33 felügyeleti hatósági értesítést tehet szükségessé, ha a személyesadat-sértés valószínűsíthetően kockázattal jár a természetes személyek jogaira és szabadságaira nézve.

A Clarysec PII-incidens- és adatsértés-kezelési szabályzat PII-incidens- és adatsértés-kezelési szabályzat dokumentumának besorolásról és adatsértési értékelésről szóló 4.2.6 pontja támogatja ezt a több szabályozási rezsimre kiterjedő kiváltóok-elemzést:

[Feltételesen] Az adatvédelmi vezető / PIMS-vezető KÖTELES minden nagy hatású PII-incidens esetében értékelni az alkalmazandó jogi, ágazati, pénzügyi szektorbeli, kiberbiztonsági, szerződéses, ügyfél- és szolgáltatás igénybe vevői jelentéstételi kiváltó okokat, és az alkalmazhatóság eredményét rögzíteni a REG01-ben, REG08-ban és REG10-ben.

Pontosan ilyen döntési feljegyzésre van szükség, amikor egy aldomain-átvétel GDPR-t, NIS2-t, DORA-t, szerződéseket és ügyfélértesítést is érinthet.

Hogyan fogják az auditorok tesztelni a bizonyítékokat

Egy integrált IBIR-nek lehetővé kell tennie, hogy a szervezet különböző auditoroknak ugyanazzal a bizonyítékalappal válaszoljon. A kérdés megfogalmazása változik, de a bizonyíték gyakran ugyanaz.

A tágabb bizonyossági nézőpont gyakran magában foglalja a NIST CSF 2.0 és COBIT 2019 keretrendszereket is. A NIST CSF 2.0 segít a célállapot megfogalmazásában a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER eredményeken keresztül. Egy jelenlegi profil mutathat manuális negyedéves DNS-felülvizsgálatokat és következetlen SaaS-kiléptetést. Egy célprofil előírhat automatizált heti átvételi ellenőrzéseket, kötelező felelőskijelölést, beszállítói kilépési bizonyítékot és integrációt a változáskezeléssel.

Egy COBIT 2019 vagy ISACA-orientált auditor jellemzően azt kérdezi, ki felel a folyamatért, hogyan értékelik és irányítják a kockázatot, kontrolláltak-e a változások, kezelik-e a beszállítókat, megbízhatók-e a konfigurációk és vagyonelemek, valamint a bizonyossági bizonyítékok támogatják-e a vezetői jelentéstételt. Nem feltétlenül CNAME-listát kérnek először. Lehet, hogy azt kérdezik, honnan tudja a vezetés, hogy a külső digitális szolgáltatások a teljes életciklusuk alatt kontroll alatt állnak.

Milyen a jó auditbizonyíték

A dangling DNS auditcsomagnak elég kicsinek kell lennie ahhoz, hogy fenntartható legyen, de elég teljesnek ahhoz, hogy védhető legyen. A Clarysec jellemzően a következő bizonyítékkészletet javasolja:

• DNS-zónanyilvántartás forrással, dátummal, rekordtípussal, céllal és felelőssel.
• Külső támadásifelület-vizsgálati eredmények átvételi ellenőrzésekkel.
• Eszköznyilvántartási bejegyzések domainekre, aldomainekre, felhőszolgáltatásokra, SaaS-alkalmazásokra és CDN-ekre.
• Szolgáltatásnyilvántartás, amely mutatja a belső vagy beszállítói felelősséget.
• Változásjegyek DNS-bejegyzések létrehozására, módosítására és törlésére.
• Felhő- és SaaS-belépési ellenőrzőlisták egyedi domain- és DNS-felülvizsgálattal.
• Beszállítói szerződések vagy biztonsági záradékok DNS-re, tárhelyre, incidens-támogatásra és kilépésre.
• Sérülékenységi jegyek súlyossággal, felelőssel, javítási dátummal és újratesztelési bizonyítékkal.
• PII-értékelés, ha az aldomain személyes adatokat kezel vagy korábban kezelt.
• Incidensbesorolási bejegyzések gyanított vagy megerősített átvétel esetén.
• Levont tanulságok és frissített eljárások a megállapítások után.

A mutatók is számítanak. A vezetésnek látnia kell a külső aldomainek számát, a kijelölt felelőssel rendelkező aldomainek arányát, a dangling megállapítások számát, a javításig eltelt átlagos időt, a lejárt magas kockázatú megállapításokat, az aktuális szerződéses hivatkozás nélküli, beszállító által hosztolt aldomaineket, valamint azon felhőkilépések arányát, amelyek rendelkeznek DNS-eltávolítási bizonyítékkal.

Ezek a mutatók a technikai higiéniát vezetői felügyeleti bizonyítékká alakítják.

Gyakori hibamintázatok, amelyeket a Clarysec talál

SaaS-, fintech-, egészségtechnológiai, menedzselt szolgáltatási és e-kereskedelmi ügyfeleknél ugyanazok a mintázatok ismétlődnek.

Először: a DNS-felelősség megoszlik a csapatok között. A fejlesztési terület felel a felhőért. A marketing felel a kampányokért. Az IT kezeli a DNS-szolgáltatói hozzáférést. A beszerzés intézi a SaaS-megszüntetést. Senki nem felel a teljes életciklusért.

Másodszor: a felhő törlését a szolgáltatás végének tekintik. Valójában DNS-bejegyzések, tanúsítványok, WAF-szabályok, felügyeleti beállítások, titkok, dokumentáció és beszállítói nyilvántartások is megmaradhatnak.

Harmadszor: a sérülékenységvizsgálók az élő hosztokra fókuszálnak, de nem észlelik a szolgáltatóspecifikus átvételi feltételeket. A szervezeteknek olyan külső támadásifelület-ellenőrzésekre van szükségük, amelyek értik a gyakori SaaS- és felhőhibás állapotokat.

Negyedszer: a beszállítói kilépési eljárások a számlákra és az adatok visszaadására fókuszálnak, nem pedig az egyedi domainekre, DNS-bejegyzésekre és al-adatfeldolgozói változásokra.

Ötödször: az adatvédelmi csapatok túl későn kapnak értesítést. Ha egy aldomain PII-t kezelt, a DPO-nak vagy az adatvédelmi vezetőnek részt kell vennie a besorolásban, mielőtt feltételezések születnek.

Hatodszor: léteznek bizonyítékok, de szétszórtan. A DNS-export az egyik eszközben van, a változásjegyek egy másikban, a beszállítói szerződések a beszerzésnél, a sérülékenységi jelentések a vizsgálóeszközökben, az adatvédelmi elemzés pedig e-mailben. Az auditorok a töredezettséget gyengeségként értékelik.

A Clarysec eszközkészlete ezt úgy oldja meg, hogy összekapcsolja a szabályzatokat, nyilvántartásokat, kontrollokat és bizonyítékmunkafolyamatokat.

30 napos cselekvési terv DNS-irányításhoz

Ha talált egy dangling DNS-bejegyzést, feltételezze, hogy van több is. Ha nem talált egyet sem, győződjön meg arról, hogy bizonyítani tudja, miért.

Kezdje ezzel a 30 napos tervvel:

1. Exportálja az összes hiteles DNS-zónát.
2. Azonosítsa a felhő-, SaaS-, CDN- és ügynökség által kezelt szolgáltatásokra mutató CNAME, ALIAS, A és AAAA rekordokat.
3. Rendeljen hozzá felelősöket és üzleti célokat.
4. Futtasson átvételi ellenőrzéseket, és manuálisan ellenőrizze a gyanús rekordokat.
5. Hozzon létre sérülékenységi jegyeket a megerősített kockázatokhoz.
6. Távolítsa el vagy igényelje vissza a kitett rekordokat változáskezelésen keresztül.
7. Frissítse az eszköznyilvántartást, a felhőszolgáltatási nyilvántartást és a beszállítói nyilvántartást.
8. Vizsgálja felül, hogy bármely érintett aldomain kezelt-e PII-t.
9. Építse be a DNS-életciklus ellenőrzéseit a felhőbeléptetésbe, a SaaS-beszerzésbe és a beszállítói kilépésbe.
10. Jelentse a mutatókat a vezetésnek.

A dangling DNS technikai javítása gyakran egyszerű. Az irányítási javítás akadályozza meg a következő átvételt.

A Clarysec segít ennek működésbe állításában a Zenith Blueprint Zenith Blueprint, a Zenith Controls Zenith Controls, valamint az eszközkezelésre, felhőhasználatra, sérülékenységkezelésre, beszállítói irányításra, PII-biztonságra, incidensreagálásra és auditbizonyítékokra vonatkozó szabályzati eszközkészletünk segítségével.

Ha auditra alkalmas megközelítést szeretne, a Clarysec segít felépíteni a DNS- és felhőkitettségi bizonyítékcsomagot, megfeleltetni azt ISO/IEC 27001:2022, NIS2, DORA és GDPR szerint, és az elfelejtett aldomaineket kontrollált, felelőssel rendelkező és felügyelt vagyonelemekké alakítani. Töltse le a releváns Clarysec eszközkészletet, kérjen demót, vagy ütemezzen DNS-irányítási értékelést, mielőtt egy penetrációs tesztelő, auditor vagy támadó megtalálja a következő elfelejtett mutatót.