Dokazila DMARC za ISO 27001, NIS2, DORA in GDPR

Začne se tako, da finančni direktor ob 07:42 posreduje e-poštno sporočilo vodji informacijske varnosti.

»Ali smo to poslali mi?«

Sporočilo je videti brezhibno. Isti logotip, ista noga, isti ton kot pri ekipi za obračunavanje. Navaja, da so se bančni podatki spremenili. Prikazno ime pošiljatelja je pravilno. Domena ni tipkarska različica prave domene. Napadalec ponareja dejansko domeno.

Ob 08:15 varnostna ekipa potrdi neprijetno resnico: SPF obstaja, vendar je preširok, DKIM je omogočen samo za glavno e-poštno platformo, več orodij za trženje pošilja nepodpisano pošto, DMARC je še vedno v načinu spremljanja, zadnjega pregleda politike MTA-STS za domeno pa nihče ne najde. Organizacija ima »varnost e-pošte« na predstavitvenem diapozitivu, dokazila pa so razpršena med posnetki zaslona DNS, portali dobaviteljev, starimi zahtevki Jira in preglednico, ki jo je vodil nekdo, ki je lani zapustil podjetje.

Ob 10:30 pravna služba vpraša, ali so bili lahko vključeni osebni podatki strank. Služba za skladnost vpraša, ali je dogodek relevanten za poročanje po NIS2. Stranka iz sektorja finančnih storitev vpraša, ali lahko podjetje dokaže kontrole tveganj IKT, usklajene z DORA. Notranja revizija vpraša, kako se to preslika na ISO/IEC 27001:2022. Upravni odbor zastavi preprostejše vprašanje: »Zakaj se je lahko nekdo lažno predstavil kot mi?«

Zaradi tega vprašanja avtentikacija e-pošte v letu 2026 ni več nišna tema DNS. DMARC, SPF, DKIM, MTA-STS in TLS-RPT so kontrole, ki ustvarjajo dokazila. Zmanjšujejo tveganje lažnega predstavljanja in ponarejanja domen, hkrati pa ustvarjajo artefakte, ki jih pričakujejo presojevalci: odločitve o politiki, lastništvo, tehnična izhodišča, odgovornost dobaviteljev, dnevnike, zapise spremljanja, izjeme, odobritve sprememb in sprožilce za odziv na incidente.

Vprašanje skladnosti ni: »Ali imamo DMARC?« Temveč: »Ali lahko dokažemo, da je avtentikacija e-pošte upravljana, spremljana, pregledovana in povezana s tveganji?«

Vrzel v dokazilih, ki jo presojevalci vedno znova odkrijejo

Drugi scenarij je prav tako pogost. Pri hitro rastočem fintech podjetju poteka zunanja presoja. Presojevalec preide z neprekinjenega poslovanja na upravljanje incidentov in vodjo informacijske varnosti vpraša o kompromitaciji poslovne e-pošte.

Vodja informacijske varnosti pojasni, da ima podjetje filtre proti lažnemu predstavljanju in četrtletno usposabljanje za ozaveščanje o varnosti.

Presojevalec prikima, nato pa zahteva nekaj bolj konkretnega: »Pokažite mi upravljanje DMARC, SPF in DKIM. Videti moram lastništvo, zapise o spremembah, oceno tveganja, dokazila o spremljanju ter povezavo s kibernetsko higieno po NIS2 in okvirom upravljanja tveganj IKT po DORA.«

V prostoru nastane tišina.

Tehnična ekipa je DMARC uvedla pred meseci, vendar ISMS nima sklica na politiko, centralnega paketa dokazil, povezave z registrom tveganj ali odobrenega časovnega načrta za uveljavljanje. Kontrola lahko tehnično obstaja, vendar je za upravljanje nevidna.

To je vrzel v dokazilih.

Zrel program avtentikacije e-pošte odgovori na šest revizijskih vprašanj:

1. Katere domene in poddomene so v obsegu?
2. Kdo je lastnik posamezne domene, cone DNS, toka e-pošte in storitve pošiljanja?
3. Kateri sistemi smejo pošiljati v imenu organizacije?
4. Kateri avtentikacijski mehanizmi se uveljavljajo, spremljajo in pregledujejo?
5. Kako se izjeme odobrijo, kako se tveganje sprejme in kako se izjeme ukinejo?
6. Katera dokazila dokazujejo, da je kontrola delovala skozi čas?

ISO/IEC 27001:2022 iz tega naredi vprašanje sistema upravljanja. Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume kontekst, zahteve zainteresiranih strani, meje obsega, vmesnike in odvisnosti. Avtentikacija e-pošte se dotika vseh teh področij. Vaš registrar domene je lahko dobavitelj. DNS je lahko gostovan v infrastrukturi v oblaku. CRM, platforma za obračun plač, orodje za izdajanje računov, ponudnik avtomatizacije trženja in sistem za podporo strankam lahko vsi pošiljajo e-pošto z uporabo vaše blagovne znamke.

Klavzule 5.1 do 5.3 iz tega naredijo vprašanje vodenja. Najvišje vodstvo mora dodeliti odgovornosti in integrirati informacijsko varnost v poslovne procese. Odločitev o prehodu DMARC iz p=none v p=quarantine ali p=reject lahko vpliva na komunikacijo s strankami, finančna obvestila, kadrovsko uvajanje, prodajne kampanje in zunanje izvajalce.

Klavzule 6.1.1 do 6.1.3 zahtevajo oceno tveganja, obravnavo tveganja, izbiro kontrol in izjavo o uporabnosti. Ponarejanje domen je treba obravnavati kot scenarij tveganja, pri čemer se SPF, DKIM, DMARC, MTA-STS in TLS-RPT po potrebi izberejo kot del obravnave tveganja. Klavzula 8.1 nato zahteva operativno načrtovanje in nadzor, vključno z nadzorom nad zunanje zagotovljenimi procesi, proizvodi in storitvami, pomembnimi za ISMS.

Kaj dokazuje posamezna kontrola avtentikacije e-pošte

SPF, DKIM, DMARC, MTA-STS in TLS-RPT delujejo skupaj, vendar dokazujejo različne stvari.

SPF in DKIM sta signala identitete in celovitosti. DMARC je plast politike, ki te signale pretvori v dejanje prejemnika. MTA-STS in TLS-RPT podpirata varen transport e-pošte tako, da pomagata preprečevati znižanje ravni zaščite in tveganja napačne konfiguracije.

Za presojevalce je globlja vrednost v ponovljivih dokazilih. Zbirna poročila DMARC pokažejo, kdo pošilja kot vaša domena. Poročila TLS pokažejo, ali šifrirana dostava odpoveduje. Zahtevki za spremembe pokažejo, ali upravljanje obstaja. Zapisi dobaviteljev pokažejo, ali so odvisnosti dobavne verige znane.

Domene najprej vključite v register sredstev

Avtentikacije e-pošte ni mogoče upravljati, če domene niso obravnavane kot sredstva.

Politika za MSP Politika upravljanja sredstev za MSP Politika upravljanja sredstev - MSP izrecno vključuje domene in identitete, povezane z e-pošto, v obseg:

»Digitalne poverilnice in storitve: domenska imena, digitalna potrdila, ključi API, e-poštni računi, prijave v oblak«

Iz razdelka »Področje uporabe«, klavzula politike 2.2.4.

Za večje organizacije enako logiko uporablja organizacijska Politika upravljanja sredstev Politika upravljanja sredstev:

»Logična sredstva: domenska imena, licence, uporabniški računi, konfiguracijska izhodišča«

Iz razdelka »Področje uporabe«, klavzula politike 2.2.5.

Če so domene sredstva, imajo lahko lastnike, ocene kritičnosti, cikle pregledov, odvisnosti od dobaviteljev, kontrole sprememb in lokacije dokazil. Če so samo vnosi DNS, običajno ostanejo neupravljane, dokler se kaj ne pokvari.

Register domen in pošiljanja e-pošte, pripravljen za presojo, mora vključevati:

Ta register podpira kontrolo A.5.9 Popis informacij in drugih povezanih sredstev, A.8.9 Upravljanje konfiguracije, A.5.19 Informacijska varnost v odnosih z dobavitelji in A.5.23 Informacijska varnost za uporabo storitev v oblaku iz Priloge A k ISO/IEC 27001:2022. Podpira tudi rezultate popisa NIST CSF 2.0 za sredstva, storitve, dobavitelje in kritičnost.

Za odločitve o DNS in toku e-pošte uporabite upravljanje sprememb

Avtentikacija e-pošte odpove, kadar je upravljanje sprememb šibko. Prodajna ekipa doda platformo za nagovarjanje strank. Kadrovska služba uvede orodje za sledenje kandidatom. Finance zamenjajo programsko opremo za izdajanje računov. Trženje preide na novega ponudnika e-poštnih storitev. Vsaka poslovna odločitev ustvari novega pošiljatelja.

Organizacijska Politika upravljanja sprememb Politika upravljanja sprememb zahtevo glede dokazil določa izrecno:

»Vsi zahtevki za spremembe, pregledi, odobritve in podporna dokazila morajo biti zabeleženi v centraliziranem sistemu za upravljanje sprememb.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.

Dober zahtevek za spremembo avtentikacije e-pošte mora vključevati:

• Poslovno utemeljitev za novega pošiljatelja.
• Prizadeto domeno ali poddomeno.
• Vpliv vključitve SPF ali IP-naslova pošiljatelja.
• Selektor DKIM in lastništvo ključa.
• Rezultat testa poravnave DMARC.
• Vpliv na MTA-STS ali MX, če obstaja.
• Razvrstitev podatkov v poslanih sporočilih.
• Sklic na varnostni pregled dobavitelja.
• Načrt povrnitve.
• Odobritev lastnika domene in varnostne funkcije.
• Dokazilo o testiranju po implementaciji.
• Datum pregleda ali potek začasnih nastavitev.

To je razlika med »skrbnik DNS je spremenil zapis« in »ISMS je nadzoroval spremembo, relevantno za tveganje«.

Praktičen 30-dnevni načrt za dokazila DMARC, SPF, DKIM in MTA-STS

Vodja informacijske varnosti ne potrebuje šestmesečnega transformacijskega projekta za izboljšanje zrelosti dokazil. Usmerjen 30-dnevni sprint lahko vzpostavi zagovorljivo izhodišče.

1. teden: odkrijte domene, pošiljatelje in lastništvo

Izvozite vse domene iz registrarja in ponudnika DNS. Pridobite podatke o toku e-pošte iz e-poštnega prehoda, CRM, službe za pomoč uporabnikom, trženjske platforme, obračunskega sistema in storitev obveščanja v oblaku. Vzpostavite register domen in pošiljateljev.

Vključite tudi parkirane domene in obrambne registracije. Parkirane domene so pogosto prezrte, vendar jih je še vedno mogoče zlorabiti, če DMARC manjka ali je šibek.

2. teden: uredite poravnavo SPF in DKIM

Preglejte SPF glede preveč dovolilnih mehanizmov, zastarelih vključitev, podvojenih ponudnikov in tveganj omejitve poizvedb. Pri DKIM identificirajte vsakega pošiljatelja, ki ne podpisuje pošte ali podpisuje z domeno, ki se ne bo poravnala z DMARC.

Pošiljatelja SaaS ne odobrite samo zato, ker pošta deluje. Odobrite ga, ker:

• je dobavitelj naveden v registru pošiljateljev;
• sta konfiguraciji SPF in DKIM dokumentirani;
• so selektorji DKIM popisani;
• so lastništvo ključev in pričakovanja glede pregledov jasni;
• varnostna dokumentacija dobavitelja podpira varno ravnanje z e-pošto;
• poslovni lastnik sprejme morebitno začasno izjemo.

Tu NIS2 in DORA postaneta praktični. NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganja, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo in vzdrževanjem, oceno učinkovitosti, kibernetsko higieno, kriptografijo, nadzorom dostopa in varnimi komunikacijami. DORA Article 28 od finančnih subjektov zahteva upravljanje tveganj tretjih oseb na področju IKT kot del okvira upravljanja tveganj IKT, vključno s skrbnim pregledom, pogodbenimi pričakovanji, spremljanjem in načrtovanjem izstopa.

Če ponudnik trženja pošilja e-pošto brez avtentikacije z uporabo vaše domene, to ni samo vprašanje trženja. To je tveganje dobavitelja, tveganje lažnega predstavljanja blagovne znamke in potencialna škoda za stranke.

3. teden: premaknite DMARC proti uveljavljanju

Način spremljanja je koristen, vendar je trajni p=none brez odobrenega časovnega načrta šibko dokazilo.

Zagovorljiv načrt uveljavljanja DMARC mora vključevati:

• pregled izhodiščnih zbirnih poročil;
• identifikacijo legitimnih in nelegitimnih virov;
• sanacijo legitimnih virov z neuspešno avtentikacijo;
• poslovno potrditev kritičnih tokov e-pošte;
• postopno povečanje politike na pct=25, pct=50, pct=100;
• prehod iz p=none na p=quarantine;
• prehod na p=reject, ko to dopuščata tveganje in poslovna pripravljenost;
• ločeno obravnavo poddomen z sp=;
• register izjem z datumi poteka;
• odobritev vodstva za preostalo tveganje.

To podpira obravnavo tveganja po ISO/IEC 27001:2022 Clause 6.1.3 ter operativno načrtovanje in nadzor po Clause 8.1. Notranji presoji daje tudi jasno sled: odločitev, implementacija, spremljanje, izjema, odobritev in pregled.

4. teden: validirajte MTA-STS, TLS-RPT in spremljanje

MTA-STS je pogosto spregledan, ker izhodnega ponarejanja blagovne znamke ne ustavi na enak način kot DMARC. Vendar je zelo relevanten za varne komunikacije in zaščito informacij med prenosom. Združljivim strežnikom, ki pošiljajo e-pošto, pove, da mora biti pošta na vašo domeno dostavljena prek TLS, ter preveri identiteto MX.

Organizacijska Politika kriptografskih kontrol Politika kriptografskih kontrol določa jasno izhodišče transportne varnosti:

»Transportna varnost: TLS 1.2 ali višje (po možnosti TLS 1.3)«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.5.

Za MSP Politika kriptografskih kontrol za MSP Politika kriptografskih kontrol - MSP izrecno vključuje prenos e-pošte:

»Podatki, posredovani prek e-pošte, podjetniških navideznih zasebnih omrežij (VPN) in spletnih portalov«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.4.

Testiranje mora vključevati validacijo MX TLS, razpoložljivost datoteke politike MTA-STS, stanje digitalnega potrdila HTTPS, pregled poročil TLS-RPT in zapise triaže za odpovedi.

Preslikajte avtentikacijo e-pošte na Prilogo A k ISO/IEC 27001:2022

Clarysecov Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls pomaga povezati tehnična dokazila z revizijskimi pričakovanji v različnih okvirih. Ni ločen nabor kontrol. Je vodnik za preslikavo in presojo kontrol ISO/IEC 27001:2022 ter povezanih standardov.

Za kontrolo A.5.14 Prenos informacij iz Priloge A k ISO/IEC 27001:2022 Zenith Controls pojasnjuje povezavo s kriptografijo:

»Varen prenos informacij temelji na kriptografskih kontrolah, kot je podrobno navedeno v 8.24.«

To je povezava med poslovno e-pošto, DKIM, MTA-STS in TLS. E-pošta je kanal za prenos informacij. DKIM podpira avtentičnost in celovitost sporočil. MTA-STS in TLS podpirata zaščito transporta.

Za kontrolo A.8.24 Uporaba kriptografije iz Priloge A Zenith Controls povezuje kriptografijo s prenosom informacij, zasebnostjo, zaščito osebno določljivih podatkov, razvrščanjem in upravljanjem ranljivosti. Pri kontrolah A.8.15 Dnevniško beleženje in A.8.16 Dejavnosti spremljanja iz Priloge A vodnik povezuje dnevnike in spremljanje z upravljanjem dogodkov, zbiranjem dokazil, pregledom, analizo in preverljivostjo.

Politika za MSP Politika dnevniškega beleženja in spremljanja za MSP Politika beleženja in spremljanja - MSP določa:

»Beleženje mora biti omogočeno in konfigurirano, kjer je na voljo«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.5.1.1.

Organizacijska Politika dnevniškega beleženja in spremljanja Politika beleženja in spremljanja vključuje:

»Zunanje komunikacije in sprožilci pravil požarnega zidu«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.6.

Pri avtentikaciji e-pošte morajo zunanje komunikacije vključevati dogodke poštnega prehoda, obdelavo zbirnih poročil DMARC, trende odpovedi DKIM, sumljivo izvorno infrastrukturo, odpovedi TLS-RPT in poskuse ponarejanja, ki sprožijo triažo incidentov.

Zenith Blueprint: 30-koračni časovni načrt za presojevalce Zenith Blueprint to umesti v praktično validacijo kontrol. V fazi Kontrole v praksi, korak 20, ekipam naroča validacijo varnosti omrežnih storitev:

»Navedite vse notranje in zunanje omrežne storitve (DNS, VPN, SMTP, DHCP, prehodi API itd.).

✓ Za vsako potrdite, da uporablja varne protokole (npr. DNSSEC, TLS 1.2+, SSH namesto Telnet).
✓ Preglejte, kako je nadzorovan dostop do posamezne storitve (npr. seznami dovoljenih IP-naslovov, avtentikacija, digitalna potrdila).
✓ Če storitev upravljajo tretje osebe (npr. DNS, SD-WAN, gostovani VPN), preglejte varnostne klavzule v SLA ali pogodbi z dobaviteljem. Posodobite svoj register storitev in zabeležite, kje so varnostne odgovornosti, notranje ali zunanje.«

Uporabljeno za e-pošto to postane delovni načrt za DNS, SMTP, TLS, gostovane poštne prehode, pošiljatelje dobaviteljev in meje odgovornosti.

Preslikava navzkrižne skladnosti: en paket dokazil, številne obveznosti

Isti paket dokazil lahko podpira ISO/IEC 27001:2022, NIS2, DORA, GDPR in NIST CSF 2.0, če je pravilno strukturiran.

NIS2 je posebej relevanten za bistvene in pomembne subjekte ter za določene kategorije digitalne infrastrukture in digitalnih ponudnikov. Article 20 določa upravljanje kibernetske varnosti kot odgovornost organa vodenja, Article 21 pa vzpostavlja izhodišče za upravljanje tveganj. Dokazila avtentikacije e-pošte pomagajo pokazati, da so varne komunikacije, odnosi z dobavitelji, obravnavanje incidentov, ocena učinkovitosti in kibernetska higiena operativni, ne le teoretični.

Za finančne subjekte se DORA uporablja od 17. januarja 2025. Articles 5 in 6 zahtevata odgovornost organa vodenja in dokumentiran okvir upravljanja tveganj IKT. Article 17 zahteva procese za odkrivanje, upravljanje, evidentiranje, razvrščanje, eskalacijo in sanacijo incidentov, povezanih z IKT. Article 28 določa upravljanje tveganj tretjih oseb na področju IKT kot formalno odgovornost. Ponudniki e-pošte, trženjske platforme, sistemi za obvestila o plačilih in orodja za komunikacijo s strankami lahko vsi postanejo del te verige odvisnosti IKT.

Pri GDPR je ključno vprašanje, ali se e-pošta uporablja za obdelavo osebnih podatkov. Article 5 vključuje celovitost, zaupnost in odgovornost. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe. Če računi, kadrovska sporočila, obvestila o računih, podporni zahtevki ali uvodna e-poštna sporočila vsebujejo osebne podatke, avtentikacija e-pošte in transportna varnost postaneta del dokazil o varnosti obdelave.

Odziv na incidente: ko poročila postanejo zgodnje opozorilo

Zbirna poročila DMARC niso samo dokazila o skladnosti. So podatki za zgodnje opozarjanje. Porast neuspele avtentikacije iz neznane infrastrukture lahko kaže na aktivno ponarejanje, nenadzorovano IKT, napačno konfiguracijo dobavitelja ali kompromitiranega pošiljatelja.

Po NIS2 Article 23 morajo bistveni in pomembni subjekti pomembne incidente sporočiti brez nepotrebnega odlašanja, s faznim poročanjem, ki vključuje zgodnje opozorilo, obvestilo o incidentu in končno poročilo. Vsak poskus ponarejanja ni prijavljiv, vendar mora biti organizacija sposobna oceniti resnost, operativno motnjo, finančno izgubo, čezmejni vpliv in škodo za prejemnike.

Po DORA Article 17 morajo finančni subjekti opredeliti in uvesti proces upravljanja incidentov, povezanih z IKT, evidentirati incidente in pomembne kibernetske grožnje, prepoznati temeljne vzroke, uporabljati kazalnike zgodnjega opozarjanja, razvrščati po resnosti in kritičnosti storitve, dodeliti vloge, opredeliti komunikacije in eskalirati večje incidente. DORA Article 19 nato obravnava poročanje o večjih incidentih, povezanih z IKT.

Pri GDPR je vprašanje, ali je dogodek povzročil nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih. Ponarejena e-pošta, ki stranke zavede v posredovanje osebnih podatkov napadalcu, lahko sproži oceno kršitve varnosti osebnih podatkov, tudi če notranji sistemi niso bili kompromitirani.

Organizacijska Politika spremljanja presoje in skladnosti Politika spremljanja presoje in skladnosti pojasnjuje, zakaj so disciplinirana dokazila pomembna:

»Za ustvarjanje zagovorljivih dokazil in revizijske sledi v podporo regulativnim poizvedbam, pravnim postopkom ali zahtevam strank glede zagotavljanja zaupanja.«

Iz razdelka »Cilji«, klavzula politike 3.4.

Politika za MSP Politika spremljanja presoje in skladnosti za MSP Politika spremljanja presoje in skladnosti - MSP dodaja zahtevo glede kakovosti dokazil:

»Metapodatki (npr. kdo jih je zbral, kdaj in iz katerega sistema) morajo biti dokumentirani.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.3.

Preiskovalna datoteka DMARC mora zato dokumentirati vir poročila, čas zbiranja, analitika, prizadete domene, domnevne IP-naslove pošiljateljev, rezultate avtentikacije, oceno vpliva na poslovanje, sprejete odločitve in odobritev zaprtja.

Kaj bodo zahtevali presojevalci

Različni presojevalci uporabljajo različen jezik, vendar se dokazila prekrivajo.

Pričakujte praktična vprašanja:

• Pokažite poročila DMARC za zadnje četrtletje.
• Pokažite, kako so bila pregledana.
• Pokažite izjemo za tega pošiljatelja z neuspešno avtentikacijo.
• Pokažite, kdo je odobril to spremembo SPF.
• Pokažite, ali so selektorji DKIM popisani in pregledani.
• Pokažite, kako se MTA-STS testira po spremembah poštnega prehoda.
• Pokažite, kako dogodki ponarejanja vstopijo v triažo incidentov.
• Pokažite, kako se pošiljatelji dobaviteljev odstranijo ob prekinitvi pogodbe.

Kratek kontrolni seznam za notranjo presojo v letu 2026

Ta kontrolni seznam uporabite kot izhodišče za notranjo presojo, testiranje kontrol ali pregled dokazil avtentikacije e-pošte.

• Vse domene in poddomene so navedene v registru sredstev.
• Parkirane in obrambne domene imajo pokritost z DMARC.
• Vsak pooblaščen pošiljatelj ima poslovnega in tehničnega lastnika.
• Zapisi SPF se pregledujejo glede zastarelih vključitev in preširokega obsega.
• DKIM je omogočen za legitimne pošiljatelje, kjer je podprt.
• Selektorji DKIM so popisani in pregledani.
• DMARC je uveden za korenske domene in relevantne poddomene.
• DMARC ima časovni načrt uveljavljanja, ne nedoločenega spremljanja.
• Zbirna poročila DMARC se pregledujejo po določeni periodiki.
• MTA-STS je konfiguriran za domene vhodne pošte, kjer je to relevantno.
• Poročila TLS-RPT se zbirajo in triažirajo.
• Spremembe avtentikacije e-pošte sledijo upravljanju sprememb.
• Uvajanje dobaviteljev vključuje zahteve glede pošiljanja e-pošte.
• Izstop dobaviteljev odstrani vključitve SPF, selektorje DKIM in dovoljenja za pošiljanje.
• Izjeme imajo lastnike tveganj, datume poteka in kompenzacijske kontrole.
• Porasti ponarejanja in odpovedi avtentikacije se vključujejo v odziv na incidente.
• Dokazila vključujejo metapodatke, vir, datum, zbiratelja in sistem.
• Vodstvo prejema periodične kazalnike in posodobitve tveganj.

Zenith Blueprint, faza upravljanja tveganj, korak 14, priporoča pripravo tabel regulativnega preslikovanja za veljavne obveznosti:

»Za vsak predpis, če je relevanten, lahko pripravite preprosto tabelo preslikave (lahko kot prilogo poročilu), ki navaja ključne varnostne zahteve predpisa in pripadajoče kontrole/politike v vašem ISMS. To v ISO 27001 ni obvezno, vendar je koristna notranja vaja, da zagotovite, da nič ni ostalo spregledano. Na presojevalce/ocenjevalce naredi tudi dober vtis, ker pokaže, da varnosti ne upravljate v vakuumu, temveč se zavedate pravnega konteksta.«

Za avtentikacijo e-pošte ta tabela postane most med tehnično resničnostjo DNS in zagotovilom na ravni upravnega odbora.

Pretvorite avtentikacijo e-pošte v dokazila, pripravljena za presojo

Vaše stranke morda nikoli ne bodo vprašale, ali ima vaš zapis SPF popolno sintakso. Vprašale bodo, ali lahko zaščitite svojo blagovno znamko, zmanjšate tveganje lažnega predstavljanja, zagotovite varne komunikacije, upravljate dobavitelje in dokažete, da vaše kontrole delujejo.

Clarysec organizacijam pomaga pretvoriti avtentikacijo e-pošte iz krhkih tehničnih nastavitev v kontrolni sistem, pripravljen za presojo. Praktičen naslednji korak je usmerjen pregled dokazil avtentikacije e-pošte:

1. Vzpostavite register domen in pošiljateljev.
2. Preslikajte status SPF, DKIM, DMARC, MTA-STS in TLS-RPT.
3. Identificirajte dobavitelje, skrite pošiljatelje in izjeme.
4. Pripravite časovni načrt uveljavljanja DMARC.
5. Validirajte dokazila upravljanja sprememb, dnevniškega beleženja in odziva na incidente.
6. Povežite dokazila z ISO/IEC 27001:2022, NIS2, DORA, GDPR in NIST CSF 2.0.
7. Pripravite paket dokazil za presojevalce z uporabo Zenith Blueprint, Zenith Controls in relevantnih politik Clarysec.

Če se vaša organizacija pripravlja na certifikacijo ISO/IEC 27001:2022, pripravljenost na NIS2, zagotavljanje zaupanja po DORA, preglede odgovornosti po GDPR ali varnostne vprašalnike strank, začnite s kontrolami, ki jih napadalci najbolj vidno zlorabljajo: vašimi domenami, vašimi pošiljatelji in vašo verigo zaupanja v e-pošto.

Prenesite Zenith Blueprint, uporabite Zenith Controls za preslikavo navzkrižne skladnosti in izvedite 30-dnevni pregled dokazil avtentikacije e-pošte, preden naslednji incident ponarejanja ali revizijska zahteva prisili pogovor.