DMARC įrodymai ISO 27001, NIS2, DORA ir GDPR kontekste

Viskas prasideda 07:42, kai finansų direktorius persiunčia el. laišką CISO.

„Ar mes tai siuntėme?“

Žinutė atrodo nepriekaištingai. Tas pats logotipas, ta pati poraštė, tas pats tonas kaip atsiskaitymų komandos. Joje teigiama, kad pasikeitė banko rekvizitai. Siuntėjo rodomas vardas teisingas. Domenas nėra panašus klaidingai parašytas variantas. Užpuolikas klastoja tikrąjį domeną.

08:15 saugumo komanda patvirtina nepatogią tiesą: SPF yra, bet per platus, DKIM įjungtas tik pagrindinėje el. pašto platformoje, keli rinkodaros įrankiai siunčia nepasirašytus laiškus, DMARC vis dar veikia stebėsenos režimu, o paskutinės domeno MTA-STS politikos peržiūros niekas neranda. Organizacija skaidrėse turi „el. pašto saugumą“, tačiau įrodymai išbarstyti DNS ekrano kopijose, tiekėjų portaluose, senose Jira užklausose ir skaičiuoklėje, kuri priklausė pernai išėjusiam darbuotojui.

10:30 teisininkai klausia, ar galėjo būti susiję klientų asmens duomenys. Atitikties funkcija klausia, ar tai aktualu NIS2 pranešimų teikimui. Finansinių paslaugų klientas klausia, ar įmonė gali pagrįsti su DORA suderintas IRT rizikos kontrolės priemones. Vidaus auditas klausia, kaip tai susiejama su ISO/IEC 27001:2022. Valdyba užduoda paprastesnį klausimą: „Kodėl kažkas galėjo apsimesti mumis?“

Būtent todėl 2026 m. el. pašto autentifikavimas nebėra nišinė DNS tema. DMARC, SPF, DKIM, MTA-STS ir TLS-RPT yra įrodymus generuojančios kontrolės priemonės. Jos mažina duomenų viliojimo ir domeno klastojimo riziką, bet taip pat sukuria artefaktus, kurių tikisi auditoriai: politikos sprendimus, atsakomybę, techninius bazinius parametrus, tiekėjų atskaitomybę, registravimo duomenis, stebėsenos įrašus, išimtis, pakeitimų patvirtinimus ir reagavimo į incidentus paleidiklius.

Atitikties problema nėra „Ar turime DMARC?“ Ji yra „Ar galime įrodyti, kad el. pašto autentifikavimas yra valdomas, stebimas, peržiūrimas ir susietas su rizika?“

Įrodymų spraga, kurią auditoriai nuolat randa

Antras scenarijus toks pat dažnas. Išorės auditas vyksta sparčiai augančioje fintech įmonėje. Auditorius pereina nuo veiklos tęstinumo prie incidentų valdymo ir klausia CISO apie verslo el. pašto kompromitavimą.

CISO paaiškina, kad įmonė turi apsaugos nuo duomenų viliojimo filtrus ir kas ketvirtį vykdomus saugumo informuotumo mokymus.

Auditorius linkteli ir tada paprašo konkrečiau: „Parodykite DMARC, SPF ir DKIM valdyseną. Turiu matyti atsakomybę, pakeitimų įrašus, rizikos vertinimą, stebėsenos įrodymus ir kaip tai susieta su NIS2 kibernetine higiena bei DORA IRT rizikos valdymo sistema.“

Kambaryje įsivyrauja tyla.

Techninė komanda DMARC įdiegė prieš kelis mėnesius, tačiau ISVS nėra politikos nuorodos, nėra centrinio įrodymų paketo, nėra sąsajos su rizikų registru ir nėra patvirtinto įgyvendinimo veiksmų plano. Kontrolės priemonė techniškai gali egzistuoti, bet valdysenai ji nematoma.

Tai ir yra įrodymų spraga.

Brandži el. pašto autentifikavimo programa atsako į šešis audito klausimus:

1. Kurie domenai ir subdomenai patenka į taikymo sritį?
2. Kas yra kiekvieno domeno, DNS zonos, el. pašto srauto ir siuntimo paslaugos savininkas?
3. Kurioms sistemoms leidžiama siųsti organizacijos vardu?
4. Kurie autentifikavimo mechanizmai taikomi, stebimi ir peržiūrimi?
5. Kaip tvirtinamos išimtys, priimama rizika ir kaip jos panaikinamos?
6. Kokie įrodymai patvirtina, kad kontrolės priemonė veikė laikui bėgant?

ISO/IEC 27001:2022 tai paverčia vadybos sistemos klausimu. 4.1–4.4 punktai reikalauja, kad organizacija suprastų kontekstą, suinteresuotųjų šalių reikalavimus, taikymo srities ribas, sąsajas ir priklausomybes. El. pašto autentifikavimas paliečia visus šiuos aspektus. Jūsų domenų registratorius gali būti tiekėjas. DNS gali būti talpinamas debesijos infrastruktūroje. Jūsų CRM, darbo užmokesčio platforma, sąskaitų faktūrų įrankis, rinkodaros automatizavimo teikėjas ir klientų aptarnavimo sistema visi gali siųsti el. laiškus naudodami jūsų prekės ženklą.

5.1–5.3 punktai tai paverčia vadovybės klausimu. Aukščiausioji vadovybė turi priskirti atsakomybes ir integruoti informacijos saugumą į verslo procesus. DMARC sprendimas pereiti nuo p=none prie p=quarantine arba p=reject gali paveikti klientų komunikaciją, finansinius pranešimus, HR įvedimo į darbą procesus, pardavimo kampanijas ir išorės paslaugų teikėjus.

6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, kontrolės priemonių parinkimo ir Taikomumo pareiškimo. Domeno klastojimas turi būti vertinamas kaip rizikos scenarijus, o SPF, DKIM, DMARC, MTA-STS ir TLS-RPT, kai tinkama, turi būti parinkti kaip rizikos tvarkymo dalis. 8.1 punktas tada reikalauja veiklos planavimo ir kontrolės, įskaitant ISVS aktualių iš išorės teikiamų procesų, produktų ir paslaugų kontrolę.

Ką įrodo kiekviena el. pašto autentifikavimo kontrolės priemonė

SPF, DKIM, DMARC, MTA-STS ir TLS-RPT veikia kartu, tačiau įrodo skirtingus dalykus.

SPF ir DKIM yra tapatybės ir vientisumo signalai. DMARC yra politikos sluoksnis, kuris šiuos signalus paverčia gavėjo veiksmais. MTA-STS ir TLS-RPT palaiko saugų el. pašto perdavimą, padėdami užkirsti kelią saugumo lygio sumažinimo ir neteisingos konfigūracijos rizikai.

Auditoriams didesnė vertė yra pakartojami įrodymai. DMARC agreguotos ataskaitos parodo, kas siunčia kaip jūsų domenas. TLS ataskaitos parodo, ar šifruotas pristatymas stringa. Pakeitimų užklausos parodo, ar valdysena egzistuoja. Tiekėjų įrašai parodo, ar žinomos tiekimo grandinės priklausomybės.

Pirmiausia įtraukite domenus į turto registrą

El. pašto autentifikavimas negali būti valdomas, jei domenai nelaikomi turtu.

MVĮ Turto valdymo politika-sme Turto valdymo politika - SME aiškiai įtraukia domenus ir su el. paštu susijusias tapatybes į taikymo sritį:

„Skaitmeniniai prisijungimo duomenys ir paslaugos: domenų vardai, skaitmeniniai sertifikatai, API raktai, el. pašto paskyros, debesijos prisijungimai“

Iš skyriaus „Taikymo sritis“, politikos punktas 2.2.4.

Didesnėms organizacijoms įmonės Turto valdymo politika Turto valdymo politika taiko tą pačią logiką:

„Loginis turtas: domenų vardai, licencijos, naudotojų paskyros, konfigūracijų baziniai parametrai“

Iš skyriaus „Taikymo sritis“, politikos punktas 2.2.5.

Jei domenai yra turtas, jie gali turėti savininkus, kritiškumo įvertinimus, peržiūros ciklus, tiekėjų priklausomybes, pakeitimų kontrolę ir įrodymų vietas. Jei tai tik DNS įrašai, jie paprastai nevaldomi, kol kas nors nesugenda.

Auditui tinkamas domenų ir el. pašto siuntimo registras turėtų apimti:

Šis registras palaiko ISO/IEC 27001:2022 Annex A kontrolės priemonę A.5.9 Informacijos ir kito susijusio turto apskaita, A.8.9 konfigūracijų valdymas, A.5.19 Informacijos saugumas santykiuose su tiekėjais ir A.5.23 Informacijos saugumas naudojant debesijos paslaugas. Jis taip pat palaiko NIST CSF 2.0 turto, paslaugų, tiekėjų ir kritiškumo apskaitos rezultatus.

DNS ir el. pašto srauto sprendimams taikykite pakeitimų valdymą

El. pašto autentifikavimas sutrinka, kai pakeitimų valdymas silpnas. Pardavimų komanda prideda kontaktų paieškos platformą. HR įdiegia kandidatų stebėjimo įrankį. Finansai pakeičia sąskaitų faktūrų programinę įrangą. Rinkodara pereina prie naujo el. pašto paslaugų teikėjo. Kiekvienas verslo sprendimas sukuria naują siuntėją.

Įmonės Pakeitimų valdymo politika Pakeitimų valdymo politika aiškiai nustato įrodymų reikalavimą:

„Visos pakeitimų užklausos, peržiūros, patvirtinimai ir pagrindžiantys įrodymai turi būti registruojami centralizuotoje pakeitimų valdymo sistemoje.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.

Tvirtoje el. pašto autentifikavimo pakeitimo užklausoje turėtų būti:

• Verslo pagrindimas dėl naujo siuntėjo.
• Paveiktas domenas arba subdomenas.
• SPF įtraukimo arba siunčiančio IP poveikis.
• DKIM selektorius ir rakto savininkystė.
• DMARC suderinimo testo rezultatas.
• MTA-STS arba MX poveikis, jei yra.
• Siunčiamų žinučių duomenų klasifikavimas.
• Tiekėjo saugumo peržiūros nuoroda.
• Grąžinimo į ankstesnę būseną planas.
• Domeno savininko ir saugumo patvirtinimas.
• Testavimo po įgyvendinimo įrodymai.
• Laikinų nustatymų peržiūros data arba galiojimo pabaiga.

Tai skirtumas tarp „DNS administratorius pakeitė įrašą“ ir „ISVS kontroliavo su rizika susijusį pakeitimą“.

Praktinis 30 dienų planas DMARC, SPF, DKIM ir MTA-STS įrodymams

CISO nereikia šešių mėnesių transformacijos projekto, kad pagerintų įrodymų brandą. Kryptingas 30 dienų sprintas gali sukurti pagrįstą bazinį lygį.

1 savaitė: nustatykite domenus, siuntėjus ir atsakomybę

Eksportuokite visus domenus iš registratoriaus ir DNS teikėjo. Surinkite el. pašto srauto duomenis iš el. pašto šliuzo, CRM, pagalbos tarnybos, rinkodaros platformos, atsiskaitymų sistemos ir debesijos pranešimų paslaugų. Sukurkite domenų ir siuntimo registrą.

Taip pat įtraukite rezervuotus domenus ir apsaugines registracijas. Rezervuoti domenai dažnai ignoruojami, tačiau jie vis tiek gali būti naudojami piktnaudžiavimui, jei DMARC nėra arba jis silpnas.

2 savaitė: sutvarkykite SPF ir DKIM suderinimą

Peržiūrėkite SPF dėl pernelyg leidžiančių mechanizmų, pasenusių įtraukimų, pasikartojančių teikėjų ir užklausų ribų rizikos. DKIM atveju nustatykite kiekvieną siuntėją, kuris nepasirašo laiškų arba pasirašo domenu, kuris nesuderinamas su DMARC.

Netvirtinkite SaaS siuntėjo vien todėl, kad laiškai veikia. Patvirtinkite jį todėl, kad:

• Tiekėjas įtrauktas į siuntimo registrą.
• SPF ir DKIM konfigūracija dokumentuota.
• DKIM selektoriai įtraukti į apskaitą.
• Rakto savininkystė ir peržiūros lūkesčiai aiškūs.
• Tiekėjo saugumo dokumentacija pagrindžia saugų el. pašto tvarkymą.
• Verslo savininkas priima bet kurią laikiną išimtį.

Čia NIS2 ir DORA tampa praktiškos. NIS2 Article 21 reikalauja tinkamų ir proporcingų techninių, veiklos ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir priežiūrą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, prieigos kontrolę ir saugią komunikaciją. DORA Article 28 reikalauja, kad finansų subjektai valdytų IRT trečiųjų šalių riziką kaip IRT rizikos valdymo sistemos dalį, įskaitant deramą patikrinimą, sutartinius lūkesčius, stebėseną ir pasitraukimo planavimą.

Jei rinkodaros teikėjas siunčia neautentifikuotus el. laiškus naudodamas jūsų domeną, tai nėra tik rinkodaros problema. Tai tiekėjų rizika, apsimetimo prekės ženklu rizika ir galimai žala klientams.

3 savaitė: perkelkite DMARC link taikymo

Stebėsenos režimas naudingas, tačiau nuolatinis p=none be patvirtinto veiksmų plano yra silpni įrodymai.

Pagrįstas DMARC taikymo planas turėtų apimti:

• Bazinių agreguotų ataskaitų peržiūrą.
• Teisėtų ir neteisėtų šaltinių identifikavimą.
• Teisėtų, bet nesėkmingai autentifikuojamų šaltinių taisomuosius veiksmus.
• Kritinių el. pašto srautų verslo validavimą.
• Laipsnišką politikos didinimą iki pct=25, pct=50, pct=100.
• Perėjimą nuo p=none prie p=quarantine.
• Perėjimą prie p=reject, kai leidžia rizika ir verslo pasirengimas.
• Atskirą subdomenų tvarkymą naudojant sp=.
• Išimčių registrą su galiojimo pabaigos datomis.
• Vadovybės patvirtinimą dėl likutinės rizikos.

Tai palaiko ISO/IEC 27001:2022 6.1.3 punkto rizikos tvarkymą ir 8.1 punkto veiklos planavimą bei kontrolę. Tai taip pat suteikia vidaus auditui aiškų pėdsaką: sprendimas, įgyvendinimas, stebėsena, išimtis, patvirtinimas ir peržiūra.

4 savaitė: validuokite MTA-STS, TLS-RPT ir stebėseną

MTA-STS dažnai praleidžiamas, nes jis nestabdo išeinančio prekės ženklo klastojimo taip, kaip tai daro DMARC. Tačiau jis labai aktualus saugiai komunikacijai ir perduodamos informacijos apsaugai. Jis nurodo suderinamiems siunčiantiems serveriams, kad laiškai į jūsų domeną turi būti pristatomi per TLS, ir validuoja MX tapatybę.

Įmonės Kriptografinių kontrolės priemonių politika Kriptografinių kontrolės priemonių politika nustato aiškų transporto saugumo bazinį lygį:

„Transporto saugumas: TLS 1.2 arba naujesnė versija (pageidautina TLS 1.3)“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.5.

MVĮ Kriptografinių kontrolės priemonių politika-sme Kriptografinių kontrolės priemonių politika - SME aiškiai įtraukia el. pašto perdavimą:

„Duomenys, perduodami el. paštu, organizacijos VPN ir žiniatinklio portalais“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.4.

Testavimas turėtų apimti MX TLS validavimą, MTA-STS politikos failo prieinamumą, HTTPS sertifikato būklę, TLS-RPT ataskaitų peržiūrą ir nesėkmių pirminio įvertinimo įrašus.

Susiekite el. pašto autentifikavimą su ISO/IEC 27001:2022 Annex A

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls padeda susieti techninius įrodymus su audito lūkesčiais skirtinguose karkasuose. Tai nėra atskiras kontrolės priemonių rinkinys. Tai ISO/IEC 27001:2022 kontrolės priemonių ir susijusių standartų susiejimo bei audito vadovas.

Dėl ISO/IEC 27001:2022 Annex A kontrolės priemonės A.5.14 Informacijos perdavimas Zenith Controls paaiškina ryšį su kriptografija:

„Saugus informacijos perdavimas remiasi kriptografinėmis kontrolės priemonėmis, kaip išsamiai nurodyta 8.24.“

Tai ryšys tarp verslo el. pašto, DKIM, MTA-STS ir TLS. El. paštas yra informacijos perdavimo kanalas. DKIM palaiko pranešimo autentiškumą ir vientisumą. MTA-STS ir TLS palaiko perdavimo apsaugą.

Annex A kontrolės priemonės A.8.24 Kriptografijos naudojimas atveju Zenith Controls susieja kriptografiją su informacijos perdavimu, privatumu, PII apsauga, klasifikavimu ir pažeidžiamumų valdymu. Annex A kontrolės priemonių A.8.15 Registravimas ir A.8.16 Stebėsenos veiklos atveju vadovas susieja registravimą ir stebėseną su įvykių valdymu, įrodymų rinkimu, peržiūra, analize ir audituojamumu.

MVĮ Registravimo ir stebėsenos politika-sme Registravimo ir stebėsenos politika - SME nustato:

„Registravimas turi būti įjungtas ir sukonfigūruotas ten, kur tai įmanoma“

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.5.1.1.

Įmonės Registravimo ir stebėsenos politika Registravimo ir stebėsenos politika apima:

„Išorinės komunikacijos ir ugniasienės taisyklių paleidikliai“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.6.

El. pašto autentifikavimo atveju išorinės komunikacijos turėtų apimti pašto šliuzo įvykius, DMARC agreguotų ataskaitų apdorojimą, DKIM nesėkmių tendencijas, įtartiną šaltinio infrastruktūrą, TLS-RPT nesėkmes ir klastojimo bandymus, kurie inicijuoja pirminį incidentų įvertinimą.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint tai perkelia į praktinį kontrolės validavimą. Kontrolės priemonių taikymo fazėje, 20 žingsnyje, komandoms nurodoma validuoti tinklo paslaugų saugumą:

„Išvardykite visas vidines ir išorines tinklo paslaugas (DNS, VPN, SMTP, DHCP, API šliuzus ir kt.).

✓ Kiekvienai patvirtinkite, kad naudojami saugūs protokolai (pvz., DNSSEC, TLS 1.2+, SSH vietoje Telnet).
✓ Peržiūrėkite, kaip kontroliuojama prieiga prie kiekvienos paslaugos (pvz., IP leidžiamųjų sąrašai, autentifikavimas, sertifikatai).
✓ Jei valdoma trečiųjų šalių (pvz., DNS, SD-WAN, talpinamas VPN), peržiūrėkite SLA arba tiekėjo sutarties saugumo nuostatas. Atnaujinkite paslaugų registrą ir pažymėkite, kur tenka saugumo atsakomybės – viduje ar išorėje.“

Pritaikius el. paštui, tai tampa DNS, SMTP, TLS, talpinamų pašto šliuzų, tiekėjų siuntėjų ir atsakomybių ribų darbų planu.

Skirtingų reikalavimų atitikties susiejimas: vienas įrodymų paketas, daug įpareigojimų

Tas pats įrodymų paketas gali palaikyti ISO/IEC 27001:2022, NIS2, DORA, GDPR ir NIST CSF 2.0, jei jis tinkamai struktūrizuotas.

NIS2 ypač aktuali esminiams ir svarbiems subjektams, taip pat tam tikroms skaitmeninės infrastruktūros ir skaitmeninių paslaugų teikėjų kategorijoms. Article 20 kibernetinio saugumo valdyseną paverčia valdymo organo atsakomybe, o Article 21 nustato rizikos valdymo bazinį lygį. El. pašto autentifikavimo įrodymai padeda parodyti, kad saugi komunikacija, tiekėjų santykiai, incidentų valdymas, veiksmingumo vertinimas ir kibernetinė higiena yra veikiančios, o ne teorinės priemonės.

Finansų subjektams DORA taikoma nuo 2025 m. sausio 17 d. Articles 5 ir 6 reikalauja valdymo organo atskaitomybės ir dokumentuotos IRT rizikos valdymo sistemos. Article 17 reikalauja procesų, skirtų aptikti, valdyti, registruoti, klasifikuoti, eskaluoti ir šalinti su IRT susijusius incidentus. Article 28 IRT trečiųjų šalių rizikos valdymą paverčia formalia atsakomybe. El. pašto teikėjai, rinkodaros platformos, mokėjimo pranešimų sistemos ir klientų komunikacijos įrankiai visi gali tapti šios IRT priklausomybių grandinės dalimi.

GDPR kontekste esminis klausimas yra, ar el. paštas naudojamas asmens duomenims tvarkyti. Article 5 apima vientisumą, konfidencialumą ir atskaitomybę. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių. Jei sąskaitose faktūrose, HR žinutėse, paskyrų pranešimuose, pagalbos užklausose ar įvedimo į darbą el. laiškuose yra asmens duomenų, el. pašto autentifikavimas ir transporto saugumas tampa tvarkymo saugumo įrodymų dalimi.

Reagavimas į incidentus: kai ataskaitos tampa ankstyvuoju perspėjimu

DMARC agreguotos ataskaitos nėra tik atitikties įrodymai. Tai ankstyvojo perspėjimo duomenys. Nesėkmingo autentifikavimo šuolis iš nežinomos infrastruktūros gali rodyti aktyvų klastojimą, šešėlinę IT, tiekėjo neteisingą konfigūraciją arba kompromituotą siuntėją.

Pagal NIS2 Article 23 esminiai ir svarbūs subjektai turi be nepagrįsto delsimo pranešti apie reikšmingus incidentus, taikydami etapais vykdomą pranešimų teikimą, apimantį ankstyvąjį perspėjimą, pranešimą apie incidentą ir galutinę ataskaitą. Ne kiekvienas klastojimo bandymas yra praneštinas, tačiau organizacija turi gebėti įvertinti sunkumą, veiklos sutrikimą, finansinius nuostolius, tarpvalstybinį poveikį ir žalą gavėjams.

Pagal DORA Article 17 finansų subjektai turi apibrėžti ir įgyvendinti su IRT susijusių incidentų valdymo procesą, registruoti incidentus ir reikšmingas kibernetines grėsmes, nustatyti pagrindines priežastis, naudoti ankstyvojo perspėjimo indikatorius, klasifikuoti pagal sunkumą ir paslaugos kritiškumą, priskirti vaidmenis, apibrėžti komunikaciją ir eskaluoti reikšmingus incidentus. DORA Article 19 reglamentuoja pranešimą apie reikšmingus su IRT susijusius incidentus.

GDPR atveju klausimas yra, ar įvykis sukėlė atsitiktinį ar neteisėtą asmens duomenų sunaikinimą, praradimą, pakeitimą, neautorizuotą atskleidimą arba prieigą prie jų. Suklastotas el. laiškas, priverčiantis klientus pateikti asmens duomenis užpuolikui, gali inicijuoti asmens duomenų saugumo pažeidimo vertinimą, net jei vidinės sistemos nebuvo kompromituotos.

Įmonės Audito ir atitikties stebėsenos politika Audito ir atitikties stebėsenos politika paaiškina, kodėl drausmingas įrodymų tvarkymas svarbus:

„Generuoti dokumentuotus įrodymus ir audito pėdsaką, pagrindžiantį atsakymus į reglamentavimo institucijų paklausimus, teisinius procesus ar klientų patikinimo prašymus.“

Iš skyriaus „Tikslai“, politikos punktas 3.4.

MVĮ Audito ir atitikties stebėsenos politika-sme Audito ir atitikties stebėsenos politika - SME papildo įrodymų kokybės reikalavimą:

„Metaduomenys (pvz., kas juos surinko, kada ir iš kurios sistemos) turi būti dokumentuojami.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.2.3.

Todėl DMARC tyrimo faile turi būti dokumentuojamas ataskaitos šaltinis, surinkimo laikas, analitikas, paveikti domenai, įtariami siuntėjo IP adresai, autentifikavimo rezultatai, verslo poveikio vertinimas, priimti sprendimai ir uždarymo patvirtinimas.

Ko prašys auditoriai

Skirtingi auditoriai vartoja skirtingą kalbą, tačiau įrodymai sutampa.

Tikėkitės praktinių klausimų:

• Parodykite paskutinio ketvirčio DMARC ataskaitas.
• Parodykite, kaip jos buvo peržiūrėtos.
• Parodykite šio nesėkmingo siuntėjo išimtį.
• Parodykite, kas patvirtino šį SPF pakeitimą.
• Parodykite, ar DKIM selektoriai įtraukti į apskaitą ir peržiūrimi.
• Parodykite, kaip MTA-STS testuojamas po pašto šliuzo pakeitimų.
• Parodykite, kaip klastojimo įvykiai patenka į pirminį incidentų įvertinimą.
• Parodykite, kaip tiekėjų siuntėjai pašalinami nutraukus sutartį.

Glaustas 2026 m. vidaus audito kontrolinis sąrašas

Naudokite šį kontrolinį sąrašą kaip pradinį tašką vidaus auditui, kontrolės priemonių testavimui arba el. pašto autentifikavimo įrodymų peržiūrai.

• Visi domenai ir subdomenai įtraukti į turto registrą.
• Rezervuoti ir apsauginiai domenai turi DMARC aprėptį.
• Kiekvienas autorizuotas siuntėjas turi verslo savininką ir techninį savininką.
• SPF įrašai peržiūrimi dėl pasenusių įtraukimų ir perteklinės aprėpties.
• DKIM įjungtas teisėtiems siuntėjams, kai palaikomas.
• DKIM selektoriai įtraukti į apskaitą ir peržiūrimi.
• DMARC įdiegtas šakniniams domenams ir aktualiems subdomenams.
• DMARC turi įgyvendinimo veiksmų planą, o ne neribotą stebėseną.
• DMARC agreguotos ataskaitos peržiūrimos nustatytu periodiškumu.
• MTA-STS sukonfigūruotas įeinančio pašto domenams, kai taikoma.
• TLS-RPT ataskaitos renkamos ir atliekamas jų pirminis įvertinimas.
• El. pašto autentifikavimo pakeitimams taikomas pakeitimų valdymas.
• Tiekėjų įtraukimas apima el. pašto siuntimo reikalavimus.
• Tiekėjų išvedimas pašalina SPF įtraukimus, DKIM selektorius ir siuntimo leidimus.
• Išimtys turi rizikos savininkus, galiojimo pabaigos datas ir kompensuojančias kontrolės priemones.
• Klastojimo šuoliai ir autentifikavimo nesėkmės perduodami reagavimui į incidentus.
• Įrodymai apima metaduomenis, šaltinį, datą, rinkėją ir sistemą.
• Vadovybė periodiškai gauna rodiklius ir rizikos atnaujinimus.

Zenith Blueprint Rizikos valdymo fazės 14 žingsnyje rekomenduojama kurti taikomų įpareigojimų reglamentavimo susiejimo lenteles:

„Kiekvienam reglamentui, jei taikoma, galite sukurti paprastą susiejimo lentelę (ji galėtų būti ataskaitos priedas), kurioje išvardyti pagrindiniai reglamento saugumo reikalavimai ir atitinkamos jūsų ISVS kontrolės priemonės / politikos. ISO 27001 to nereikalauja, tačiau tai naudinga vidinė užduotis, padedanti užtikrinti, kad niekas neliktų nepastebėta. Tai taip pat daro įspūdį auditoriams / vertintojams, nes parodo, kad saugumo nevaldote vakuume ir suprantate teisinį kontekstą.“

El. pašto autentifikavimo atveju ši lentelė tampa tiltu tarp techninės DNS realybės ir valdybos lygmens patikinimo.

Paverskite el. pašto autentifikavimą auditui tinkamais įrodymais

Jūsų klientai gali niekada nepaklausti, ar jūsų SPF įrašo sintaksė tobula. Jie paklaus, ar galite apsaugoti savo prekės ženklą, sumažinti duomenų viliojimo riziką, apsaugoti komunikaciją, valdyti tiekėjus ir įrodyti, kad jūsų kontrolės priemonės veikia.

Clarysec padeda organizacijoms paversti el. pašto autentifikavimą iš trapių techninių nustatymų į auditui tinkamą kontrolės sistemą. Praktinis kitas žingsnis – kryptinga el. pašto autentifikavimo įrodymų peržiūra:

1. Sukurkite domenų ir siuntimo registrą.
2. Susiekite SPF, DKIM, DMARC, MTA-STS ir TLS-RPT būsenas.
3. Nustatykite tiekėjus, šešėlinės IT siuntėjus ir išimtis.
4. Sukurkite DMARC taikymo veiksmų planą.
5. Validuokite pakeitimų valdymo, registravimo ir reagavimo į incidentus įrodymus.
6. Susiekite įrodymus su ISO/IEC 27001:2022, NIS2, DORA, GDPR ir NIST CSF 2.0.
7. Parenkite auditoriams tinkamą įrodymų paketą naudodami Zenith Blueprint, Zenith Controls ir aktualias Clarysec politikas.

Jei jūsų organizacija rengiasi ISO/IEC 27001:2022 sertifikavimui, NIS2 pasirengimui, DORA patikinimui, GDPR atskaitomybės peržiūroms ar klientų saugumo klausimynams, pradėkite nuo kontrolės priemonių, kuriomis užpuolikai piktnaudžiauja matomiausiai: jūsų domenų, jūsų siuntėjų ir jūsų el. pašto pasitikėjimo grandinės.

Atsisiųskite Zenith Blueprint, naudokite Zenith Controls skirtingų reikalavimų atitikties susiejimui ir atlikite 30 dienų el. pašto autentifikavimo įrodymų peržiūrą prieš kitam klastojimo incidentui ar audito užklausai priverčiant pradėti šį pokalbį.