DMARC-bizonyítékok ISO 27001, NIS2, DORA és GDPR megfeleléshez

A történet azzal kezdődik, hogy a pénzügyi igazgató 07:42-kor továbbít egy e-mailt az információbiztonsági vezetőnek.

„Ezt mi küldtük?”

Az üzenet tökéletesnek tűnik. Ugyanaz a logó, ugyanaz a lábléc, ugyanaz a hangnem, mint a számlázási csapat leveleiben. Azt állítja, hogy megváltoztak a bankszámlaadatok. A feladó megjelenített neve helyes. A domain nem hasonló, elgépelésre építő változat. A támadó a valódi domaint hamisítja.

08:15-re a biztonsági csapat megerősíti a kellemetlen tényt: SPF van, de túl tágan van beállítva; a DKIM csak a fő e-mail-platformon engedélyezett; több marketingeszköz aláíratlan leveleket küld; a DMARC továbbra is monitorozó módban van; és senki sem találja a domain MTA-STS-szabályzatának legutóbbi felülvizsgálatát. A szervezetnek van „e-mail-biztonság” témájú diasora, de a bizonyítékok DNS-képernyőképek, beszállítói portálok, régi Jira-jegyek és egy olyan táblázat között szóródnak szét, amelynek tulajdonosa tavaly távozott.

10:30-kor a jogi terület megkérdezi, érintettek lehetnek-e ügyfelek személyes adatai. A megfelelési funkció azt kérdezi, releváns-e az ügy a NIS2 szerinti jelentéstétel szempontjából. Egy pénzügyi szolgáltatási ügyfél azt kérdezi, be tudja-e mutatni a vállalat a DORA-val összhangban álló IKT-kockázati kontrollokat. A belső audit azt kérdezi, hogyan kapcsolódik mindez az ISO/IEC 27001:2022 követelményeihez. Az igazgatóság egyszerűbb kérdést tesz fel: „Hogyan tudott valaki a nevünkben fellépni?”

Ezért nem szűk DNS-téma már 2026-ban az e-mail-hitelesítés. A DMARC, SPF, DKIM, MTA-STS és TLS-RPT bizonyítékot előállító kontrollok. Csökkentik az adathalászat és a domainhamisítás kockázatát, ugyanakkor létrehozzák azokat a bizonyítékokat, amelyeket az auditorok elvárnak: szabályzati döntéseket, tulajdonosi felelősséget, műszaki alapkonfigurációkat, beszállítói elszámoltathatóságot, naplókat, monitorozási nyilvántartásokat, kivételeket, változtatás-jóváhagyásokat és incidenskezelési kiváltó eseményeket.

A megfelelési kérdés nem az, hogy „Van-e DMARC-unk?” Hanem az, hogy „Bizonyítani tudjuk-e, hogy az e-mail-hitelesítés irányított, felügyelt, felülvizsgált és kockázatokhoz kapcsolt?”

A bizonyítékhiány, amelyet az auditorok rendszeresen megtalálnak

Egy másik forgatókönyv ugyanilyen gyakori. Külső audit zajlik egy gyorsan növekvő fintech vállalatnál. Az auditor az üzletmenet-folytonosságról az incidenskezelésre tér át, és az információbiztonsági vezetőt az üzleti e-mail kompromittálódásáról kérdezi.

Az információbiztonsági vezető elmondja, hogy a vállalat adathalászat elleni szűrőket és negyedéves biztonságtudatossági képzést alkalmaz.

Az auditor bólint, majd konkrétabbat kér: „Mutassa be a DMARC, SPF és DKIM körüli irányítást. Látnom kell a tulajdonosi felelősségeket, a változásbejegyzéseket, a kockázatértékelést, a monitorozási bizonyítékokat, valamint azt, hogyan kapcsolódik mindez a NIS2 kiberhigiéniai követelményeihez és a DORA IKT-kockázatkezelési keretrendszeréhez.”

A helyiség elcsendesedik.

A műszaki csapat hónapokkal korábban bevezette a DMARC-ot, de az IBIR-ben nincs szabályzati hivatkozás, nincs központi bizonyítékcsomag, nincs kapcsolat a kockázati nyilvántartással, és nincs jóváhagyott kikényszerítési ütemterv. A kontroll technikailag létezhet, de az irányítás számára láthatatlan.

Ez a bizonyítékhiány.

Egy érett e-mail-hitelesítési program hat auditkérdésre ad választ:

1. Mely domainek és aldomainek tartoznak a hatályba?
2. Ki a felelőse az egyes domaineknek, DNS-zónáknak, levéláramlásoknak és küldőszolgáltatásoknak?
3. Mely rendszerek küldhetnek e-mailt a szervezet nevében?
4. Mely hitelesítési mechanizmusok vannak kikényszerítve, felügyelve és felülvizsgálva?
5. Hogyan hagyják jóvá, hogyan fogadják el kockázatként, és hogyan vezetik ki a kivételeket?
6. Milyen bizonyíték igazolja, hogy a kontroll időben folyamatosan működött?

Az ISO/IEC 27001:2022 ezt irányítási rendszer kérdésévé teszi. A 4.1–4.4 pontok megkövetelik, hogy a szervezet megértse a kontextust, az érdekelt felek követelményeit, az alkalmazási terület határait, az interfészeket és a függőségeket. Az e-mail-hitelesítés mindegyiket érinti. A domainregisztrátor beszállító lehet. A DNS felhőinfrastruktúrában üzemelhet. A CRM, a bérszámfejtési platform, a számlázóeszköz, a marketingautomatizációs szolgáltató és az ügyféltámogatási rendszer egyaránt küldhet e-mailt a szervezet márkáját használva.

Az 5.1–5.3 pontok ezt vezetői kérdéssé teszik. A felső vezetésnek ki kell jelölnie a felelősségeket, és integrálnia kell az információbiztonságot az üzleti folyamatokba. A DMARC-döntés p=none értékről p=quarantine vagy p=reject értékre hatással lehet az ügyfélkommunikációra, a pénzügyi értesítésekre, a HR beléptetésre, az értékesítési kampányokra és a kiszervezett szolgáltatókra.

A 6.1.1–6.1.3 pontok kockázatértékelést, kockázatkezelést, kontrollkiválasztást és alkalmazhatósági nyilatkozatot követelnek meg. A domainhamisítást kockázati forgatókönyvként kell kezelni, és ahol indokolt, az SPF-et, DKIM-et, DMARC-ot, MTA-STS-t és TLS-RPT-t a kockázatkezelés részeként kell kiválasztani. A 8.1 pont ezt követően működéstervezést és -szabályozást követel meg, beleértve az IBIR szempontjából releváns, külső fél által biztosított folyamatok, termékek és szolgáltatások feletti kontrollt.

Mit bizonyítanak az egyes e-mail-hitelesítési kontrollok

Az SPF, DKIM, DMARC, MTA-STS és TLS-RPT együtt működik, de eltérő dolgokat bizonyítanak.

Az SPF és a DKIM identitás- és sértetlenségi jelzések. A DMARC az a szabályzati réteg, amely ezeket a jelzéseket fogadói intézkedéssé alakítja. Az MTA-STS és a TLS-RPT a biztonságos e-mail-átvitelt támogatja az algoritmus-visszaminősítési és hibás konfigurációs kockázatok megelőzésével.

Az auditorok számára a mélyebb érték az ismételhető bizonyíték. A DMARC aggregált jelentései megmutatják, ki küld a domain nevében. A TLS-jelentések megmutatják, meghibásodik-e a titkosított kézbesítés. A változtatási jegyek megmutatják, létezik-e irányítás. A beszállítói nyilvántartások megmutatják, ismertek-e az ellátási láncbeli függőségek.

Először kerüljenek a domainek az eszköznyilvántartásba

Az e-mail-hitelesítés nem irányítható, ha a domaineket nem kezelik eszközként.

A KKV Eszközkezelési szabályzat Eszközkezelési szabályzat – KKV kifejezetten hatály alá vonja a domaineket és az e-mailhez kapcsolódó identitásokat:

„Digitális hitelesítő adatok és szolgáltatások: domainnevek, digitális tanúsítványok, alkalmazásprogramozási interfész-kulcsok, e-mail-fiókok, felhőbejelentkezések”

A „Hatály” szakasz 2.2.4 szabályzati pontjából.

Nagyobb szervezeteknél a vállalati Eszközkezelési szabályzat Eszközkezelési szabályzat ugyanezt a logikát alkalmazza:

„Logikai eszközök: domainnevek, licencek, felhasználói fiókok, konfigurációs alapbeállítások”

A „Hatály” szakasz 2.2.5 szabályzati pontjából.

Ha a domainek eszközök, lehetnek tulajdonosaik, kritikussági besorolásuk, felülvizsgálati ciklusaik, beszállítói függőségeik, változáskontrolljaik és bizonyítéktárolási helyeik. Ha csak DNS-bejegyzések, általában kezeletlenek maradnak, amíg valami el nem romlik.

Egy auditkész domain- és e-mail-küldési nyilvántartásnak tartalmaznia kell:

Ez a nyilvántartás támogatja az ISO/IEC 27001:2022 A melléklet A.5.9 Információk és más kapcsolódó vagyonelemek nyilvántartása, A.8.9 Konfigurációkezelés, A.5.19 Információbiztonság a beszállítói kapcsolatokban és A.5.23 Információbiztonság felhőszolgáltatások használatához kontrollokat. Támogatja továbbá a NIST CSF 2.0 eszközökre, szolgáltatásokra, beszállítókra és kritikusságra vonatkozó nyilvántartási eredményeit.

Alkalmazzon változáskezelést a DNS- és levéláramlási döntésekhez

Az e-mail-hitelesítés akkor romlik el, ha a változáskezelés gyenge. Az értékesítési csapat bevezet egy outreach platformot. A HR jelöltkövető eszközt alkalmaz. A pénzügy számlázószoftvert cserél. A marketing új e-mail-szolgáltatóra áll át. Minden üzleti döntés új küldőt hoz létre.

A vállalati Változáskezelési szabályzat Változáskezelési szabályzat kifejezetten rögzíti a bizonyítékkövetelményt:

„Minden változáskérelmet, felülvizsgálatot, jóváhagyást és alátámasztó bizonyítékot a központi Változáskezelő Rendszerben kell rögzíteni.”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1 szabályzati pontjából.

Egy megfelelő e-mail-hitelesítési változtatási jegynek tartalmaznia kell:

• Üzleti indoklás az új küldőhöz.
• Érintett domain vagy aldomain.
• SPF include vagy küldő IP-cím hatása.
• DKIM-szelektor és kulcstulajdonosi felelősség.
• DMARC-illeszkedési teszteredmény.
• MTA-STS- vagy MX-hatás, ha van.
• A küldött üzenetek adatosztályozása.
• Beszállítói biztonsági felülvizsgálat hivatkozása.
• Visszaállítási terv.
• Jóváhagyás a domaintulajdonos és a biztonsági terület részéről.
• Megvalósítást követő tesztbizonyíték.
• Felülvizsgálati dátum vagy lejárat az ideiglenes beállításokhoz.

Ez a különbség aközött, hogy „egy DNS-adminisztrátor módosított egy rekordot”, illetve hogy „az IBIR kontrollált egy kockázati szempontból releváns változtatást”.

Gyakorlati 30 napos terv DMARC-, SPF-, DKIM- és MTA-STS-bizonyítékokhoz

Az információbiztonsági vezetőnek nincs szüksége hat hónapos transzformációs projektre a bizonyítékok érettségének javításához. Egy fókuszált, 30 napos sprint igazolható alapállapotot hozhat létre.

1. hét: Domainek, küldők és tulajdonosi felelősségek feltárása

Exportálja az összes domaint a regisztrátortól és a DNS-szolgáltatótól. Gyűjtse be a levéláramlási adatokat az e-mail-átjáróból, a CRM-ből, a helpdeskből, a marketingplatformból, a számlázórendszerből és a felhőalapú értesítési szolgáltatásokból. Hozza létre a domain- és küldőnyilvántartást.

Vegye fel a parkolt domaineket és a védelmi célú regisztrációkat is. A parkolt domaineket gyakran figyelmen kívül hagyják, de DMARC hiányában vagy gyenge DMARC-beállítás mellett ezekkel is vissza lehet élni.

2. hét: SPF- és DKIM-illeszkedés javítása

Vizsgálja felül az SPF-et a túl megengedő mechanizmusok, elavult include-ok, duplikált szolgáltatók és lekérdezési korlátokból eredő kockázatok szempontjából. DKIM esetén azonosítson minden olyan küldőt, amely nem írja alá a leveleket, vagy olyan domainnel ír alá, amely nem fog illeszkedni a DMARC-hoz.

Ne hagyjon jóvá egy SaaS-küldőt pusztán azért, mert a levél kézbesítése működik. Azért hagyja jóvá, mert:

• A beszállító szerepel a küldőnyilvántartásban.
• Az SPF- és DKIM-konfiguráció dokumentált.
• A DKIM-szelektorok nyilvántartásban vannak.
• A kulcstulajdonosi felelősség és a felülvizsgálati elvárások egyértelműek.
• A beszállítói biztonsági dokumentáció alátámasztja a biztonságos levélkezelést.
• Az üzleti tulajdonos elfogad minden ideiglenes kivételt.

Itt válik gyakorlativá a NIS2 és a DORA. A NIS2 Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést és karbantartást, a hatékonyságértékelést, a kiberhigiéniát, a kriptográfiát, a hozzáférés-szabályozást és a biztonságos kommunikációt. A DORA Article 28 megköveteli, hogy a pénzügyi szervezetek az IKT-kockázatkezelési keretrendszer részeként kezeljék a harmadik fél IKT-kockázatot, ideértve a kellő gondosságot, a szerződéses elvárásokat, a monitorozást és a kilépési tervezést.

Ha egy marketingszolgáltató hitelesítetlen e-mailt küld az Ön domainjét használva, az nem csak marketingprobléma. Ez beszállítói kockázat, márkamegszemélyesítési kockázat és potenciális ügyfélkárosodás.

3. hét: A DMARC elmozdítása a kikényszerítés felé

A monitorozó mód hasznos, de az állandó p=none jóváhagyott ütemterv nélkül gyenge bizonyíték.

Egy igazolható DMARC-kikényszerítési tervnek tartalmaznia kell:

• Alapállapoti aggregált jelentések felülvizsgálata.
• Jogos és jogosulatlan források azonosítása.
• Jogos, de sikertelen források helyesbítése.
• Kritikus levéláramlások üzleti ellenőrzése.
• Fokozatos szabályzati növelés pct=25, pct=50, pct=100 értékekre.
• Átállás p=none értékről p=quarantine értékre.
• Átállás p=reject értékre, amikor a kockázat és az üzleti felkészültség ezt lehetővé teszi.
• Aldomainek külön kezelése sp= használatával.
• Lejárati dátumokat tartalmazó kivételnyilvántartás.
• Vezetői jóváhagyás a maradványkockázathoz.

Ez támogatja az ISO/IEC 27001:2022 6.1.3 pontja szerinti kockázatkezelést és a 8.1 pont szerinti működéstervezést és -szabályozást. A belső audit számára is egyértelmű auditnyomot biztosít: döntés, megvalósítás, monitorozás, kivétel, jóváhagyás és felülvizsgálat.

4. hét: MTA-STS, TLS-RPT és monitorozás ellenőrzése

Az MTA-STS gyakran kimarad, mert nem ugyanúgy állítja meg a kimenő márkahamisítást, mint a DMARC. Ugyanakkor kifejezetten releváns a biztonságos kommunikáció és a továbbított adatok védelme szempontjából. A kompatibilis küldőszervereknek jelzi, hogy az Ön domainjére küldött leveleket TLS-en keresztül kell kézbesíteni, és ellenőrzi az MX-identitást.

A vállalati Kriptográfiai kontrollok szabályzata Kriptográfiai kontrollok szabályzata egyértelmű átviteli biztonsági alapkövetelményt határoz meg:

„Átviteli biztonság: TLS 1.2 vagy magasabb verzió (lehetőleg TLS 1.3)”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1.5 szabályzati pontjából.

KKV-k esetében a Kriptográfiai kontrollok szabályzata – KKV Kriptográfiai kontrollok szabályzata – KKV kifejezetten tartalmazza az e-mailben történő továbbítást:

„E-mailen, vállalati VPN-eken és webportálokon keresztül továbbított adatok”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1.4 szabályzati pontjából.

A tesztelésnek ki kell terjednie az MX TLS-ellenőrzésre, az MTA-STS-szabályzatfájl elérhetőségére, a HTTPS-tanúsítvány állapotára, a TLS-RPT-jelentések felülvizsgálatára és a hibák triage-bejegyzéseire.

Az e-mail-hitelesítés megfeleltetése az ISO/IEC 27001:2022 A melléklet követelményeihez

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls segít összekapcsolni a technikai bizonyítékokat a keretrendszereken átívelő auditelvárásokkal. Ez nem külön kontrollkészlet, hanem megfeleltetési és auditútmutató az ISO/IEC 27001:2022 kontrolljaihoz és kapcsolódó szabványaihoz.

Az ISO/IEC 27001:2022 A melléklet A.5.14 Információátvitel kontrolljához a Zenith Controls így magyarázza a kriptográfiához való kapcsolatot:

„A biztonságos információátvitel a 8.24-ben részletezett kriptográfiai kontrollokra támaszkodik.”

Ez írja le az üzleti e-mail, a DKIM, az MTA-STS és a TLS kapcsolatát. Az e-mail információátviteli csatorna. A DKIM támogatja az üzenet hitelességét és sértetlenségét. Az MTA-STS és a TLS támogatja az átviteli védelmet.

Az A melléklet A.8.24 Kriptográfia használata kontrolljához a Zenith Controls a kriptográfiát az információátvitelhez, az adatvédelemhez, a személyes információk (PII) védelméhez, az osztályozáshoz és a sérülékenységkezeléshez kapcsolja. Az A melléklet A.8.15 Naplózás és A.8.16 Monitorozási tevékenységek kontrolljaihoz az útmutató a naplókat és a monitorozást az eseménykezeléshez, a bizonyítékgyűjtéshez, a felülvizsgálathoz, az elemzéshez és az ellenőrizhetőséghez kapcsolja.

A KKV Naplózási és monitorozási szabályzat Naplózási és felügyeleti szabályzat – KKV kimondja:

„A naplózást engedélyezni és konfigurálni kell, ahol rendelkezésre áll”

Az „Irányítási követelmények” szakasz 5.5.1.1 szabályzati pontjából.

A vállalati Naplózási és monitorozási szabályzat Naplózási és felügyeleti szabályzat tartalmazza:

„Külső kommunikáció és tűzfalszabály-kiváltók”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1.6 szabályzati pontjából.

E-mail-hitelesítés esetén a külső kommunikációnak tartalmaznia kell a levelezési átjáró eseményeit, a DMARC aggregált jelentéseinek feldolgozását, a DKIM-hibák trendjeit, a gyanús forrásinfrastruktúrát, a TLS-RPT-hibákat és azokat a hamisítási kísérleteket, amelyek incidensek előzetes értékelését váltják ki.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint mindezt gyakorlati kontroll-ellenőrzésbe helyezi. A „Controls in Action” fázis 20. lépésében a csapatok számára a hálózati szolgáltatások biztonságának ellenőrzését írja elő:

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

✓ Mindegyiknél erősítse meg, hogy biztonságos protokollokat használnak (pl. DNSSEC, TLS 1.2+, SSH a Telnet helyett).
✓ Vizsgálja felül, hogyan szabályozzák az egyes szolgáltatásokhoz való hozzáférést (pl. IP-engedélyezési listák, hitelesítés, tanúsítványok).
✓ Ha harmadik felek kezelik őket (pl. DNS, SD-WAN, hosztolt VPN), vizsgálja felül az SLA-ban vagy a beszállítói szerződésben szereplő biztonsági záradékokat. Frissítse a szolgáltatásnyilvántartást, és rögzítse, hol helyezkednek el a biztonsági felelősségek: belül vagy kívül.”

E-mailre alkalmazva ez munkatervvé válik a DNS, SMTP, TLS, hosztolt levelezési átjárók, beszállítói küldők és felelősségi határok kezeléséhez.

Több megfelelési követelmény lefedése: egy bizonyítékcsomag, sok kötelezettség

Ugyanaz a bizonyítékcsomag támogathatja az ISO/IEC 27001:2022, NIS2, DORA, GDPR és NIST CSF 2.0 megfelelést, ha megfelelően strukturált.

A NIS2 különösen releváns az alapvető és fontos szervezetek, valamint bizonyos digitális infrastruktúra- és digitális szolgáltatói kategóriák esetében. Az Article 20 a kiberbiztonsági irányítást a vezető testület felelősségévé teszi, míg az Article 21 meghatározza a kockázatkezelési alapkövetelményt. Az e-mail-hitelesítési bizonyítékok segítenek bemutatni, hogy a biztonságos kommunikáció, a beszállítói kapcsolatok, az incidenskezelés, a hatékonyságértékelés és a kiberhigiénia működőképes, nem csupán elméleti.

Pénzügyi szervezetek esetében a DORA 2025. január 17-től alkalmazandó. Az Articles 5 and 6 vezető testületi elszámoltathatóságot és dokumentált IKT-kockázatkezelési keretrendszert követel meg. Az Article 17 olyan folyamatokat ír elő, amelyek észlelik, kezelik, rögzítik, osztályozzák, eszkalálják és helyesbítik az IKT-vel kapcsolatos incidenseket. Az Article 28 a harmadik fél IKT-kockázatkezelést formális felelősséggé teszi. Az e-mail-szolgáltatók, marketingplatformok, fizetési értesítési rendszerek és ügyfélkommunikációs eszközök mind az IKT-függőségi lánc részévé válhatnak.

GDPR esetén a kulcskérdés az, hogy az e-mailt személyes adatok kezelésére használják-e. Az Article 5 tartalmazza a sértetlenséget, a bizalmasságot és az elszámoltathatóságot. Az Article 32 megfelelő technikai és szervezeti intézkedéseket követel meg. Ha a számlák, HR-üzenetek, fiókértesítések, támogatási jegyek vagy beléptetési e-mailek személyes adatokat tartalmaznak, az e-mail-hitelesítés és az átviteli biztonság az adatkezelés biztonságára vonatkozó bizonyítékok részévé válik.

Incidenskezelés: amikor a jelentések korai figyelmeztetéssé válnak

A DMARC aggregált jelentések nemcsak megfelelési bizonyítékok. Korai figyelmeztető adatok is. Az ismeretlen infrastruktúrából érkező sikertelen hitelesítések kiugró növekedése aktív hamisítást, shadow IT-t, beszállítói hibás konfigurációt vagy kompromittálódott küldőt jelezhet.

A NIS2 Article 23 alapján az alapvető és fontos szervezeteknek indokolatlan késedelem nélkül be kell jelenteniük a jelentős incidenseket, szakaszos jelentéstétellel, amely korai figyelmeztetést, incidensbejelentést és zárójelentést foglal magában. Nem minden hamisítási kísérlet bejelentésköteles, de a szervezetnek képesnek kell lennie a súlyosság, az operatív zavar, a pénzügyi veszteség, a határokon átnyúló hatás és a címzetteknek okozott kár értékelésére.

A DORA Article 17 alapján a pénzügyi szervezeteknek meg kell határozniuk és be kell vezetniük egy IKT-vel kapcsolatos incidenskezelési folyamatot, rögzíteniük kell az incidenseket és jelentős kiberfenyegetéseket, azonosítaniuk kell a gyökérokokat, korai figyelmeztető indikátorokat kell használniuk, súlyosság és szolgáltatáskritikusság szerint kell osztályozniuk, szerepköröket kell kijelölniük, kommunikációt kell meghatározniuk, és eszkalálniuk kell a súlyos incidenseket. A DORA Article 19 ezt követően a súlyos IKT-vel kapcsolatos incidensek jelentésével foglalkozik.

GDPR esetén az a kérdés, hogy az esemény személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy azokhoz való jogosulatlan hozzáférést okozott-e. Egy hamisított e-mail, amely ráveszi az ügyfeleket, hogy személyes adatokat adjanak meg egy támadónak, személyesadat-sértési értékelést válthat ki akkor is, ha a belső rendszerek nem kompromittálódtak.

A vállalati Audit- és megfelelésmonitorozási szabályzat Audit- és megfelelésfelügyeleti szabályzat elmagyarázza, miért fontos a fegyelmezett bizonyítékkezelés:

„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.”

A „Célkitűzések” szakasz 3.4 szabályzati pontjából.

A KKV Audit- és megfelelésmonitorozási szabályzat Audit- és megfelelésfelügyeleti szabályzat – KKV bizonyítékminőségi követelményt is hozzáad:

„A metaadatokat (pl. ki gyűjtötte, mikor és melyik rendszerből) dokumentálni kell.”

A „A szabályzat végrehajtásának követelményei” szakasz 6.2.3 szabályzati pontjából.

Egy DMARC-vizsgálati dossziénak ezért dokumentálnia kell a jelentés forrását, a gyűjtés időpontját, az elemzőt, az érintett domaineket, a feltételezett küldő IP-címeket, a hitelesítési eredményeket, az üzleti hatásvizsgálatot, a meghozott döntéseket és a lezárás jóváhagyását.

Mit fognak kérni az auditorok

A különböző auditorok eltérő nyelvezetet használnak, de a bizonyítékok átfednek.

Gyakorlati kérdésekre számítson:

• Mutassa be az elmúlt negyedév DMARC-jelentéseit.
• Mutassa be, hogyan vizsgálták felül ezeket.
• Mutassa be a kivételt ehhez a sikertelen küldőhöz.
• Mutassa be, ki hagyta jóvá ezt az SPF-változtatást.
• Mutassa be, hogy a DKIM-szelektorok nyilvántartásban vannak-e és felülvizsgálják-e őket.
• Mutassa be, hogyan tesztelik az MTA-STS-t a levelezési átjáró változásai után.
• Mutassa be, hogyan kerülnek a hamisítási események az incidensek előzetes értékelésébe.
• Mutassa be, hogyan távolítják el a beszállítói küldőket a szerződés megszűnésekor.

Tömör 2026-os belső auditos ellenőrzőlista

Használja ezt az ellenőrzőlistát kiindulópontként belső audithoz, kontrollteszteléshez vagy e-mail-hitelesítési bizonyítékok felülvizsgálatához.

• Minden domain és aldomain szerepel az eszköznyilvántartásban.
• A parkolt és védelmi célú domainekre kiterjed a DMARC.
• Minden engedélyezett küldőnek van üzleti tulajdonosa és műszaki tulajdonosa.
• Az SPF-rekordokat felülvizsgálják elavult include-ok és túlzott hatókör szempontjából.
• A DKIM engedélyezett a jogos küldőknél, ahol támogatott.
• A DKIM-szelektorok nyilvántartásban vannak és felülvizsgálják őket.
• A DMARC be van vezetve a gyökérdomainekhez és a releváns aldomainekhez.
• A DMARC rendelkezik kikényszerítési ütemtervvel, nem marad határozatlan idejű monitorozó módban.
• A DMARC aggregált jelentéseit meghatározott ütemezés szerint felülvizsgálják.
• Az MTA-STS konfigurálva van a bejövő levelezési domainekre, ahol alkalmazható.
• A TLS-RPT-jelentéseket gyűjtik és triage alá vonják.
• Az e-mail-hitelesítési változtatások a változáskezelést követik.
• A beszállítói beléptetés tartalmazza az e-mail-küldési követelményeket.
• A beszállítói kiléptetés eltávolítja az SPF include-okat, a DKIM-szelektorokat és a küldési jogosultságokat.
• A kivételekhez kockázatgazdák, lejárati dátumok és kompenzáló kontrollok tartoznak.
• A hamisítási kiugrások és hitelesítési hibák bekerülnek az incidenskezelésbe.
• A bizonyíték tartalmazza a metaadatokat, a forrást, a dátumot, a gyűjtőt és a rendszert.
• A vezetés rendszeres mutatókat és kockázati frissítéseket kap.

A Zenith Blueprint kockázatkezelési fázisának 14. lépése azt javasolja, hogy az alkalmazandó kötelezettségekre készüljenek szabályozási megfeleltetési táblázatok:

„Minden jogszabályhoz, ha alkalmazható, készíthet egy egyszerű megfeleltetési táblázatot (akár jelentésmellékletként), amely felsorolja a jogszabály kulcsfontosságú biztonsági követelményeit és az IBIR-ben található megfelelő kontrollokat/szabályzatokat. Ez ISO 27001 szerint nem kötelező, de hasznos belső gyakorlat annak biztosítására, hogy semmi ne maradjon ki. Az auditorok/értékelők számára is kedvező benyomást kelt, hogy a biztonságot nem légüres térben kezeli, hanem tisztában van a jogi kontextussal.”

E-mail-hitelesítés esetén ez a táblázat képezi a hidat a technikai DNS-valóság és az igazgatósági szintű bizonyosság között.

Alakítsa az e-mail-hitelesítést auditkész bizonyítékká

Ügyfelei lehet, hogy soha nem kérdezik meg, tökéletes-e az SPF-rekord szintaxisa. Azt fogják kérdezni, meg tudja-e védeni a márkáját, csökkenteni tudja-e az adathalászati kockázatot, biztonságossá tudja-e tenni a kommunikációt, képes-e kezelni a beszállítókat, és bizonyítani tudja-e, hogy a kontrolljai működnek.

A Clarysec segít a szervezeteknek abban, hogy az e-mail-hitelesítést sérülékeny technikai beállításokból auditkész kontrollrendszerré alakítsák. A gyakorlati következő lépés egy fókuszált e-mail-hitelesítési bizonyíték-felülvizsgálat:

1. Hozza létre a domain- és küldőnyilvántartást.
2. Térképezze fel az SPF, DKIM, DMARC, MTA-STS és TLS-RPT állapotát.
3. Azonosítsa a beszállítókat, shadow IT-küldőket és kivételeket.
4. Hozzon létre DMARC-kikényszerítési ütemtervet.
5. Ellenőrizze a változáskezelési, naplózási és incidenskezelési bizonyítékokat.
6. Kapcsolja a bizonyítékokat az ISO/IEC 27001:2022, NIS2, DORA, GDPR és NIST CSF 2.0 követelményeihez.
7. Készítsen auditori felhasználásra alkalmas bizonyítékcsomagot a Zenith Blueprint, a Zenith Controls és a releváns Clarysec szabályzatok használatával.

Ha szervezete ISO/IEC 27001:2022 tanúsításra, NIS2 felkészültségre, DORA-bizonyosságra, GDPR elszámoltathatósági felülvizsgálatra vagy ügyfélbiztonsági kérdőívekre készül, kezdje azokkal a kontrollokkal, amelyeket a támadók a leglátványosabban használnak ki: a domainekkel, a küldőkkel és az e-mail bizalmi lánccal.

Töltse le a Zenith Blueprint anyagot, használja a Zenith Controls útmutatót a több keretrendszert lefedő megfeleltetéshez, és futtasson le egy 30 napos e-mail-hitelesítési bizonyíték-felülvizsgálatot, mielőtt a következő hamisítási incidens vagy auditkérés kényszeríti ki a beszélgetést.