Dôkazy z DMARC pre ISO 27001, NIS2, DORA a GDPR

Začína sa to tým, že finančný riaditeľ o 07:42 prepošle e-mail CISO.

„Poslali sme toto my?“

Správa vyzerá dokonale. Rovnaké logo, rovnaká pätička, rovnaký tón ako fakturačný tím. Tvrdí, že sa zmenili bankové údaje. Zobrazované meno odosielateľa je správne. Doména nie je preklep podobný skutočnej doméne. Útočník spoofuje skutočnú doménu.

O 08:15 bezpečnostný tím potvrdí nepríjemnú skutočnosť: SPF existuje, ale je príliš široké, DKIM je zapnuté iba pre hlavnú e-mailovú platformu, viaceré marketingové nástroje odosielajú nepodpísanú poštu, DMARC je stále v monitorovacom režime a nikto nevie nájsť posledné preskúmanie politiky MTA-STS pre danú doménu. Organizácia má „bezpečnosť elektronickej pošty“ v prezentácii, ale dôkazy sú roztrúsené v snímkach obrazovky DNS, portáloch dodávateľov, starých tiketoch v Jira a tabuľke, ktorú vlastnil človek, ktorý minulý rok odišiel.

O 10:30 sa právne oddelenie pýta, či mohli byť dotknuté osobné údaje zákazníkov. Útvar súladu sa pýta, či je to relevantné pre oznamovanie podľa NIS2. Zákazník z finančného sektora sa pýta, či spoločnosť vie preukázať kontroly rizík IKT zosúladené s DORA. Vnútorný audit sa pýta, ako sa to mapuje na ISO/IEC 27001:2022. Predstavenstvo položí jednoduchšiu otázku: „Prečo sa niekto mohol vydávať za nás?“

Práve preto už autentifikácia e-mailov v roku 2026 nie je úzka téma DNS. DMARC, SPF, DKIM, MTA-STS a TLS-RPT sú kontroly, ktoré vytvárajú dôkazy. Znižujú riziko phishingu a spoofingu domén, ale zároveň vytvárajú artefakty, ktoré audítori očakávajú: rozhodnutia o politike, vlastníctvo, technické východiskové stavy, zodpovednosť dodávateľov, logy, záznamy z monitorovania, výnimky, schválenia zmien a spúšťače reakcie na incidenty.

Problém súladu neznie: „Máme DMARC?“ Znie: „Vieme preukázať, že autentifikácia e-mailov je riadená, monitorovaná, preskúmavaná a prepojená s rizikom?“

Medzera v dôkazoch, ktorú audítori opakovane nachádzajú

Druhý scenár je rovnako bežný. Externý audit prebieha v rýchlo rastúcej fintech spoločnosti. Audítor prejde od kontinuity činností k riadeniu incidentov a opýta sa CISO na kompromitáciu podnikovej elektronickej pošty.

CISO vysvetlí, že spoločnosť má filtre proti phishingu a štvrťročné školenie bezpečnostného povedomia.

Audítor prikývne a potom požiada o niečo konkrétnejšie: „Ukážte mi správu a riadenie DMARC, SPF a DKIM. Potrebujem vidieť vlastníctvo, záznamy zmien, posúdenie rizík, dôkazy z monitorovania a to, ako to súvisí s kybernetickou hygienou podľa NIS2 a rámcom riadenia rizík IKT podľa DORA.“

V miestnosti nastane ticho.

Technický tím implementoval DMARC pred niekoľkými mesiacmi, ale ISMS nemá žiadny odkaz na politiku, žiadny centrálny balík dôkazov, žiadne prepojenie na register rizík a žiadny schválený plán presadzovania politiky. Kontrola môže technicky existovať, ale pre správu a riadenie je neviditeľná.

To je medzera v dôkazoch.

Zrelý program autentifikácie e-mailov odpovedá na šesť auditných otázok:

1. Ktoré domény a subdomény sú v rozsahu?
2. Kto vlastní jednotlivé domény, DNS zóny, toky pošty a odosielacie služby?
3. Ktoré systémy môžu odosielať v mene organizácie?
4. Ktoré autentifikačné mechanizmy sa presadzujú, monitorujú a preskúmavajú?
5. Ako sa schvaľujú výnimky, akceptuje riziko a ukončuje ich platnosť?
6. Aké dôkazy preukazujú, že kontrola fungovala v čase?

ISO/IEC 27001:2022 z toho robí otázku systému manažérstva. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela kontextu, požiadavkám zainteresovaných strán, hraniciam rozsahu, rozhraniam a závislostiam. Autentifikácia e-mailov sa dotýka všetkých týchto oblastí. Váš registrátor domény môže byť dodávateľom. DNS môže byť hostované v cloudovej infraštruktúre. Váš CRM, mzdová platforma, fakturačný nástroj, poskytovateľ marketingovej automatizácie aj systém zákazníckej podpory môžu odosielať e-mail s použitím vašej značky.

Kapitoly 5.1 až 5.3 z toho robia otázku vedenia. Vrcholový manažment musí prideliť zodpovednosti a integrovať informačnú bezpečnosť do obchodných procesov. Rozhodnutie prejsť v DMARC z p=none na p=quarantine alebo p=reject môže ovplyvniť komunikáciu so zákazníkmi, finančné notifikácie, proces nástupu zamestnancov v HR, predajné kampane a outsourcovaných poskytovateľov.

Kapitoly 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, výber kontrol a vyhlásenie o aplikovateľnosti. Spoofing domény sa má riešiť ako rizikový scenár, pričom SPF, DKIM, DMARC, MTA-STS a TLS-RPT sa majú zvoliť ako súčasť ošetrenia tam, kde je to vhodné. Kapitola 8.1 následne vyžaduje prevádzkové plánovanie a riadenie vrátane kontroly externe poskytovaných procesov, produktov a služieb relevantných pre ISMS.

Čo preukazuje každá kontrola autentifikácie e-mailov

SPF, DKIM, DMARC, MTA-STS a TLS-RPT fungujú spoločne, ale preukazujú rozdielne skutočnosti.

SPF a DKIM sú signály identity a integrity. DMARC je vrstva politiky, ktorá tieto signály premieňa na akciu príjemcu. MTA-STS a TLS-RPT podporujú bezpečný prenos e-mailov tým, že pomáhajú predchádzať rizikám downgradovania a chybnej konfigurácie.

Pre audítorov je hlbšou hodnotou opakovateľný dôkaz. Súhrnné reporty DMARC ukazujú, kto odosiela ako vaša doména. Reporty TLS ukazujú, či zlyháva šifrované doručovanie. Tikety zmien ukazujú, či existuje správa a riadenie. Záznamy dodávateľov ukazujú, či sú známe závislosti v dodávateľskom reťazci.

Najprv zahrňte domény do registra aktív

Autentifikáciu e-mailov nemožno riadiť, ak sa s doménami nezaobchádza ako s aktívami.

Politika správy aktív pre MSP Politika správy aktív pre MSP výslovne zahŕňa domény a identity súvisiace s e-mailom do rozsahu:

„Digitálne prihlasovacie údaje a služby: názvy domén, digitálne certifikáty, kľúče API, e-mailové účty, cloudové prihlásenia“

Zo sekcie „Rozsah“, kapitola politiky 2.2.4.

Pre väčšie organizácie uplatňuje rovnakú logiku podniková Politika správy aktív Politika správy aktív:

„Logické aktíva: názvy domén, licencie, používateľské účty, referenčné konfigurácie“

Zo sekcie „Rozsah“, kapitola politiky 2.2.5.

Ak sú domény aktívami, môžu mať vlastníkov, hodnotenie kritickosti, cykly preskúmania, dodávateľské závislosti, riadenie zmien a umiestnenia dôkazov. Ak sú len DNS záznamami, zvyčajne zostávajú neriadené, kým sa niečo nepokazí.

Register domén a odosielania e-mailov pripravený na audit má obsahovať:

Tento register podporuje kontrolu ISO/IEC 27001:2022 Annex A A.5.9 Inventarizácia informácií a iných súvisiacich aktív, A.8.9 Riadenie konfigurácie, A.5.19 Informačná bezpečnosť vo vzťahoch s dodávateľmi a A.5.23 Informačná bezpečnosť pri používaní cloudových služieb. Podporuje aj výstupy inventarizácie NIST CSF 2.0 pre aktíva, služby, dodávateľov a kritickosť.

Používajte riadenie zmien pre rozhodnutia o DNS a tokoch pošty

Autentifikácia e-mailov zlyháva, keď je riadenie zmien slabé. Predajný tím pridá platformu na oslovovanie. HR prijme nástroj na sledovanie kandidátov. Financie zmenia fakturačný softvér. Marketing prejde k novému poskytovateľovi e-mailových služieb. Každé obchodné rozhodnutie vytvára nového odosielateľa.

Podniková Politika riadenia zmien Politika riadenia zmien výslovne stanovuje požiadavku na dôkazy:

„Všetky žiadosti o zmenu, preskúmania, schválenia a podporné dôkazy musia byť zaznamenané v centralizovanom systéme riadenia zmien.“

Zo sekcie „Požiadavky na implementáciu politiky“, kapitola politiky 6.1.1.

Kvalitný tiket zmeny pre autentifikáciu e-mailov má obsahovať:

• Obchodné odôvodnenie nového odosielateľa.
• Dotknutú doménu alebo subdoménu.
• Vplyv SPF include alebo odosielacej IP adresy.
• Selektor DKIM a vlastníctvo kľúča.
• Výsledok testu zarovnania DMARC.
• Vplyv na MTA-STS alebo MX, ak existuje.
• Klasifikáciu údajov v odosielaných správach.
• Odkaz na bezpečnostné preskúmanie dodávateľa.
• Plán návratu zmien.
• Schválenie vlastníkom domény a bezpečnostným tímom.
• Dôkazy z testovania po implementácii.
• Dátum preskúmania alebo skončenia platnosti dočasných nastavení.

Toto je rozdiel medzi tvrdením „DNS administrátor zmenil záznam“ a „ISMS riadil zmenu relevantnú z hľadiska rizika“.

Praktický 30-dňový plán pre dôkazy z DMARC, SPF, DKIM a MTA-STS

CISO nepotrebuje šesťmesačný transformačný projekt, aby zlepšil zrelosť dôkazov. Cielený 30-dňový sprint môže vytvoriť obhájiteľný východiskový stav.

1. týždeň: Zistite domény, odosielateľov a vlastníctvo

Exportujte všetky domény z registrátora a poskytovateľa DNS. Získajte údaje o tokoch pošty z e-mailovej brány, CRM, helpdesku, marketingovej platformy, fakturačného systému a cloudových notifikačných služieb. Vytvorte register domén a odosielania.

Zahrňte aj parkované domény a defenzívne registrácie. Parkované domény sa často ignorujú, ale ak DMARC chýba alebo je slabý, stále sa dajú zneužiť.

2. týždeň: Opravte zarovnanie SPF a DKIM

Preskúmajte SPF z hľadiska príliš benevolentných mechanizmov, neaktuálnych include, duplicitných poskytovateľov a rizík limitu vyhľadávania. Pri DKIM identifikujte každého odosielateľa, ktorý poštu nepodpisuje alebo podpisuje doménou, ktorá nebude zarovnaná s DMARC.

Neschvaľujte odosielateľa SaaS len preto, že pošta funguje. Schváľte ho preto, že:

• Dodávateľ je uvedený v registri odosielania.
• Konfigurácia SPF a DKIM je zdokumentovaná.
• Selektory DKIM sú inventarizované.
• Vlastníctvo kľúčov a očakávania preskúmania sú jasné.
• Bezpečnostná dokumentácia dodávateľa podporuje bezpečné nakladanie s poštou.
• Vlastník za oblasť činnosti akceptuje každú dočasnú výnimku.

Tu sa NIS2 a DORA stávajú praktickými. NIS2 Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného obstarávania a údržby, posudzovania účinnosti, kybernetickej hygieny, kryptografie, riadenia prístupu a bezpečnej komunikácie. DORA Article 28 vyžaduje, aby finančné subjekty riadili riziká externých poskytovateľov IKT ako súčasť rámca riadenia rizík IKT vrátane due diligence, zmluvných očakávaní, monitorovania a plánovania ukončenia spolupráce.

Ak marketingový poskytovateľ odosiela neautentifikovaný e-mail s použitím vašej domény, nie je to len marketingový problém. Je to dodávateľské riziko, riziko vydávania sa za značku a potenciálna ujma zákazníka.

3. týždeň: Posuňte DMARC smerom k presadzovaniu politiky

Monitorovací režim je užitočný, ale trvalé p=none bez schváleného plánu postupu je slabý dôkaz.

Obhájiteľný plán presadzovania DMARC má obsahovať:

• Preskúmanie východiskových súhrnných reportov.
• Identifikáciu legitímnych a nelegitímnych zdrojov.
• Nápravu legitímnych zlyhávajúcich zdrojov.
• Obchodné overenie kritických poštových tokov.
• Postupné zvýšenie politiky na pct=25, pct=50, pct=100.
• Prechod z p=none na p=quarantine.
• Prechod na p=reject, keď to riziko a pripravenosť organizácie umožňujú.
• Samostatné zaobchádzanie so subdoménami pomocou sp=.
• Register výnimiek s dátumami skončenia platnosti.
• Schválenie zostatkového rizika manažmentom.

Toto podporuje ISO/IEC 27001:2022 Clause 6.1.3 ošetrenie rizík a Clause 8.1 prevádzkové plánovanie a riadenie. Vnútornému auditu to zároveň poskytuje jasnú stopu: rozhodnutie, implementácia, monitorovanie, výnimka, schválenie a preskúmanie.

4. týždeň: Validujte MTA-STS, TLS-RPT a monitorovanie

MTA-STS sa často prehliada, pretože nezastavuje odchádzajúci spoofing značky rovnakým spôsobom ako DMARC. Je však veľmi relevantné pre bezpečnú komunikáciu a ochranu informácií pri prenose. Kompatibilným odosielajúcim serverom hovorí, že pošta do vašej domény sa má doručovať cez TLS, a validuje identitu MX.

Podniková Politika kryptografických kontrol Politika kryptografických kontrol stanovuje jasnú východiskovú úroveň bezpečnosti prenosu:

„Bezpečnosť prenosu: TLS 1.2 alebo vyššie (preferovane TLS 1.3)“

Zo sekcie „Požiadavky na implementáciu politiky“, kapitola politiky 6.1.1.5.

Politika kryptografických kontrol pre MSP Politika kryptografických kontrol pre MSP výslovne zahŕňa prenos e-mailom:

„Údaje prenášané prostredníctvom e-mailu, podnikových VPN a webových portálov“

Zo sekcie „Požiadavky na implementáciu politiky“, kapitola politiky 6.1.1.4.

Testovanie má zahŕňať validáciu MX TLS, dostupnosť súboru politiky MTA-STS, stav HTTPS certifikátu, preskúmanie reportov TLS-RPT a záznamy triáže zlyhaní.

Namapujte autentifikáciu e-mailov na ISO/IEC 27001:2022 Annex A

Clarysec Zenith Controls: sprievodca krížovým súladom Zenith Controls pomáha prepájať technické dôkazy s auditnými očakávaniami naprieč rámcami. Nie je to samostatný súbor kontrol. Je to mapovací a auditný sprievodca pre kontroly ISO/IEC 27001:2022 a súvisiace normy.

Pre kontrolu ISO/IEC 27001:2022 Annex A A.5.14 Prenos informácií Zenith Controls vysvetľuje vzťah ku kryptografii:

„Bezpečný prenos informácií sa opiera o kryptografické kontroly podľa 8.24.“

To je vzťah medzi podnikovým e-mailom, DKIM, MTA-STS a TLS. E-mail je kanál na prenos informácií. DKIM podporuje autentickosť a integritu správy. MTA-STS a TLS podporujú ochranu prenosu.

Pri kontrole Annex A A.8.24 Použitie kryptografie Zenith Controls prepája kryptografiu s prenosom informácií, ochranou súkromia, ochranou osobne identifikovateľných údajov (PII), klasifikáciou a riadením zraniteľností. Pri kontrolách Annex A A.8.15 Logovanie a A.8.16 Monitorovacie činnosti sprievodca prepája logy a monitorovanie s riadením udalostí, zberom dôkazov, preskúmaním, analýzou a auditovateľnosťou.

Politika logovania a monitorovania pre MSP Politika logovania a monitorovania pre MSP uvádza:

„Logovanie musí byť zapnuté a nakonfigurované tam, kde je dostupné“

Zo sekcie „Požiadavky na správu a riadenie“, kapitola politiky 5.5.1.1.

Podniková Politika logovania a monitorovania Politika logovania a monitorovania obsahuje:

„Externá komunikácia a spúšťače pravidiel firewallu“

Zo sekcie „Požiadavky na implementáciu politiky“, kapitola politiky 6.1.1.6.

Pri autentifikácii e-mailov má externá komunikácia zahŕňať udalosti poštovej brány, spracovanie súhrnných reportov DMARC, trendy zlyhaní DKIM, podozrivú zdrojovú infraštruktúru, zlyhania TLS-RPT a pokusy o spoofing, ktoré spúšťajú triedenie incidentov.

Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint zasadzuje túto oblasť do praktickej validácie kontrol. Vo fáze Controls in Action, krok 20, vyzýva tímy, aby validovali bezpečnosť sieťových služieb:

„Vypíšte všetky interné a externé sieťové služby (DNS, VPN, SMTP, DHCP, brány API atď.).

✓ Pri každej potvrďte, že používa bezpečné protokoly (napr. DNSSEC, TLS 1.2+, SSH namiesto Telnet).
✓ Preskúmajte, ako je riadený prístup ku každej službe (napr. zoznamy povolených IP adries, autentifikácia, certifikáty).
✓ Ak sú spravované tretími stranami (napr. DNS, SD-WAN, hostovaná VPN), preskúmajte bezpečnostné doložky v SLA alebo v zmluve s dodávateľom. Aktualizujte register služieb a zaznamenajte, kde leží zodpovednosť za bezpečnosť, interne alebo externe.“

Pri aplikovaní na e-mail sa z toho stáva pracovný plán pre DNS, SMTP, TLS, hostované poštové brány, dodávateľských odosielateľov a hranice zodpovednosti.

Mapovanie krížového súladu: jeden balík dôkazov, viacero povinností

Rovnaký balík dôkazov môže podporovať ISO/IEC 27001:2022, NIS2, DORA, GDPR a NIST CSF 2.0, ak je správne štruktúrovaný.

NIS2 je osobitne relevantná pre základné a dôležité subjekty a pre určité kategórie digitálnej infraštruktúry a digitálnych poskytovateľov. Article 20 robí zo správy kybernetickej bezpečnosti zodpovednosť riadiaceho orgánu, zatiaľ čo Article 21 stanovuje základ riadenia rizík. Dôkazy z autentifikácie e-mailov pomáhajú preukázať, že bezpečná komunikácia, vzťahy s dodávateľmi, riešenie incidentov, posudzovanie účinnosti a kybernetická hygiena sú prevádzkové, nie teoretické.

Pre finančné subjekty sa DORA uplatňuje od 17. januára 2025. Articles 5 a 6 vyžadujú zodpovednosť riadiaceho orgánu a zdokumentovaný rámec riadenia rizík IKT. Article 17 vyžaduje procesy na detekciu, riadenie, zaznamenávanie, klasifikáciu, eskaláciu a nápravu incidentov súvisiacich s IKT. Article 28 robí z riadenia rizík externých poskytovateľov IKT formálnu zodpovednosť. Poskytovatelia e-mailu, marketingové platformy, systémy platobných notifikácií a nástroje zákazníckej komunikácie sa môžu stať súčasťou tohto reťazca závislostí IKT.

Pri GDPR je kľúčovou otázkou, či sa e-mail používa na spracúvanie osobných údajov. Article 5 zahŕňa integritu, dôvernosť a preukázateľnú zodpovednosť. Article 32 vyžaduje primerané technické a organizačné opatrenia. Ak faktúry, HR správy, oznámenia o účtoch, podporné tikety alebo onboardingové e-maily obsahujú osobné údaje, autentifikácia e-mailov a bezpečnosť prenosu sa stávajú súčasťou dôkazov o bezpečnosti spracúvania.

Reakcia na incidenty: keď sa reporty stanú včasným varovaním

Súhrnné reporty DMARC nie sú len dôkazy súladu. Sú to údaje včasného varovania. Nárast zlyhaní autentifikácie z neznámej infraštruktúry môže naznačovať aktívny spoofing, shadow IT, chybnú konfiguráciu dodávateľa alebo kompromitovaného odosielateľa.

Podľa NIS2 Article 23 musia základné a dôležité subjekty oznamovať významné incidenty bez zbytočného odkladu, a to prostredníctvom fázovaného oznamovania, ktoré zahŕňa včasné varovanie, oznámenie incidentu a záverečné oznámenie. Nie každý pokus o spoofing podlieha hláseniu, ale organizácia musí vedieť posúdiť závažnosť, narušenie prevádzky, finančnú stratu, cezhraničný dopad a ujmu príjemcom.

Podľa DORA Article 17 musia finančné subjekty definovať a implementovať proces riadenia incidentov súvisiacich s IKT, zaznamenávať incidenty a významné kybernetické hrozby, identifikovať koreňové príčiny, používať ukazovatele včasného varovania, klasifikovať podľa závažnosti a kritickosti služby, priraďovať roly, definovať komunikáciu a eskalovať závažné incidenty. DORA Article 19 sa následne venuje oznamovaniu závažných incidentov súvisiacich s IKT.

Pri GDPR je otázkou, či udalosť spôsobila náhodné alebo nezákonné zničenie, stratu, zmenu, neoprávnené zverejnenie osobných údajov alebo neoprávnený prístup k nim. Spoofovaný e-mail, ktorý prinúti zákazníkov odoslať osobné údaje útočníkovi, môže spustiť posúdenie porušenia ochrany osobných údajov, aj keď interné systémy neboli kompromitované.

Podniková Politika monitorovania auditov a súladu Politika monitorovania auditov a súladu vysvetľuje, prečo sú disciplinované dôkazy dôležité:

„Vytvárať obhájiteľné dôkazy a auditnú stopu na podporu regulačných preverení, právnych konaní alebo požiadaviek zákazníkov na preukázanie súladu.“

Zo sekcie „Ciele“, kapitola politiky 3.4.

Politika monitorovania auditov a súladu pre MSP Politika monitorovania auditov a súladu pre MSP dopĺňa požiadavku na kvalitu dôkazov:

„Metadáta (napr. kto ich zozbieral, kedy a z ktorého systému) musia byť zdokumentované.“

Zo sekcie „Požiadavky na implementáciu politiky“, kapitola politiky 6.2.3.

Vyšetrovací spis DMARC má preto dokumentovať zdroj reportu, čas zberu, analytika, dotknuté domény, podozrivé IP adresy odosielateľov, výsledky autentifikácie, posúdenie dopadu na podnikanie, prijaté rozhodnutia a schválenie uzavretia.

Čo budú audítori požadovať

Rôzni audítori používajú odlišný jazyk, ale dôkazy sa prekrývajú.

Očakávajte praktické otázky:

• Ukážte reporty DMARC za posledný štvrťrok.
• Ukážte, ako boli preskúmané.
• Ukážte výnimku pre tohto zlyhávajúceho odosielateľa.
• Ukážte, kto schválil túto zmenu SPF.
• Ukážte, či sú selektory DKIM inventarizované a preskúmavané.
• Ukážte, ako sa MTA-STS testuje po zmenách poštovej brány.
• Ukážte, ako spoofingové udalosti vstupujú do triedenia incidentov.
• Ukážte, ako sa dodávateľskí odosielatelia odstraňujú pri ukončení zmluvy.

Stručný kontrolný zoznam vnútorného auditu na rok 2026

Použite tento kontrolný zoznam ako východisko pre vnútorný audit, testovanie kontrol alebo preskúmanie dôkazov autentifikácie e-mailov.

• Všetky domény a subdomény sú uvedené v registri aktív.
• Parkované a defenzívne domény majú pokrytie DMARC.
• Každý autorizovaný odosielateľ má vlastníka za oblasť činnosti a technického vlastníka.
• SPF záznamy sa preskúmavajú z hľadiska neaktuálnych include a nadmerného rozsahu.
• DKIM je zapnuté pre legitímnych odosielateľov tam, kde je podporované.
• Selektory DKIM sú inventarizované a preskúmavané.
• DMARC je nasadený pre koreňové domény a relevantné subdomény.
• DMARC má plán presadzovania politiky, nie neurčité monitorovanie.
• Súhrnné reporty DMARC sa preskúmavajú v definovanej periodicite.
• MTA-STS je nakonfigurované pre domény prichádzajúcej pošty tam, kde sa uplatňuje.
• Reporty TLS-RPT sa zbierajú a triedia.
• Zmeny autentifikácie e-mailov sa riadia procesom riadenia zmien.
• Zavedenie dodávateľa zahŕňa požiadavky na odosielanie e-mailov.
• Ukončenie dodávateľa odstraňuje SPF include, selektory DKIM a oprávnenia na odosielanie.
• Výnimky majú vlastníkov rizika, dátumy skončenia platnosti a kompenzačné kontroly.
• Nárasty spoofingu a zlyhania autentifikácie vstupujú do reakcie na incidenty.
• Dôkazy obsahujú metadáta, zdroj, dátum, osobu, ktorá ich zozbierala, a systém.
• Manažment dostáva pravidelné metriky a aktualizácie rizík.

Zenith Blueprint, fáza Risk Management, krok 14, odporúča vytvoriť regulačné mapovacie tabuľky pre uplatniteľné povinnosti:

„Pre každý predpis, ak sa uplatňuje, môžete vytvoriť jednoduchú mapovaciu tabuľku (môže byť prílohou správy), ktorá uvádza kľúčové bezpečnostné požiadavky daného predpisu a zodpovedajúce kontroly/politiky vo vašom ISMS. V ISO 27001 to nie je povinné, ale je to užitočné interné cvičenie, ktoré pomáha zabezpečiť, aby nič neprepadlo medzi trhliny. Zároveň to robí dobrý dojem na audítorov/posudzovateľov, pretože bezpečnosť neriadite vo vákuu, ale uvedomujete si právny kontext.“

Pri autentifikácii e-mailov sa táto tabuľka stáva mostom medzi technickou realitou DNS a uistením na úrovni predstavenstva.

Premeňte autentifikáciu e-mailov na dôkazy pripravené na audit

Vaši zákazníci sa možno nikdy neopýtajú, či má váš SPF záznam dokonalú syntax. Opýtajú sa, či viete chrániť svoju značku, znížiť riziko phishingu, zabezpečiť komunikáciu, riadiť dodávateľov a preukázať, že vaše kontroly fungujú.

Clarysec pomáha organizáciám premeniť autentifikáciu e-mailov z krehkých technických nastavení na systém kontrol pripravený na audit. Praktickým ďalším krokom je cielené preskúmanie dôkazov autentifikácie e-mailov:

1. Vytvorte register domén a odosielania.
2. Namapujte stav SPF, DKIM, DMARC, MTA-STS a TLS-RPT.
3. Identifikujte dodávateľov, neoficiálnych odosielateľov a výnimky.
4. Vytvorte plán presadzovania DMARC.
5. Validujte dôkazy riadenia zmien, logovania a reakcie na incidenty.
6. Prepojte dôkazy s ISO/IEC 27001:2022, NIS2, DORA, GDPR a NIST CSF 2.0.
7. Pripravte balík dôkazov pre audítora pomocou Zenith Blueprint, Zenith Controls a relevantných politík Clarysec.

Ak sa vaša organizácia pripravuje na certifikáciu podľa ISO/IEC 27001:2022, pripravenosť na NIS2, uistenie podľa DORA, preskúmania preukázateľnej zodpovednosti podľa GDPR alebo zákaznícke bezpečnostné dotazníky, začnite kontrolami, ktoré útočníci zneužívajú najviditeľnejšie: vašimi doménami, vašimi odosielateľmi a vaším reťazcom dôvery v e-mailoch.

Stiahnite si Zenith Blueprint, použite Zenith Controls na mapovanie krížového súladu a vykonajte 30-dňové preskúmanie dôkazov autentifikácie e-mailov skôr, než ďalší spoofingový incident alebo auditná požiadavka vynúti túto diskusiu.