DMARC pierādījumi ISO 27001, NIS2, DORA un GDPR vajadzībām

Tas sākas ar to, ka finanšu direktors plkst. 07:42 pārsūta e-pastu informācijas drošības vadītājam.

“Vai mēs šo nosūtījām?”

Ziņojums izskatās nevainojami. Tas pats logotips, tā pati kājene, tas pats tonis kā norēķinu komandai. Tajā apgalvots, ka ir mainīti bankas rekvizīti. Sūtītāja parādāmais vārds ir pareizs. Domēns nav līdzīgs domēns ar pārrakstīšanās kļūdu. Uzbrucējs vilto īsto domēnu.

Plkst. 08:15 drošības komanda apstiprina neērto patiesību: SPF ir ieviests, bet ir pārāk plašs, DKIM ir iespējots tikai galvenajai e-pasta platformai, vairāki mārketinga rīki sūta neparakstītus e-pastus, DMARC joprojām ir uzraudzības režīmā, un neviens nevar atrast pēdējo domēna MTA-STS politikas pārskatīšanu. Organizācijai prezentāciju komplektā ir “e-pasta drošība”, bet pierādījumi ir izkaisīti pa DNS ekrānuzņēmumiem, piegādātāju portāliem, veciem Jira pieteikumiem un izklājlapu, kas piederēja darbiniekam, kurš aizgāja no uzņēmuma pagājušajā gadā.

Plkst. 10:30 juridiskais dienests jautā, vai varētu būt iesaistīti klientu personas dati. Atbilstības funkcija jautā, vai tas attiecas uz NIS2 ziņošanu. Finanšu pakalpojumu klients jautā, vai uzņēmums var pierādīt DORA saskaņotus IKT riska kontroles pasākumus. Iekšējais audits jautā, kā tas kartējas pret ISO/IEC 27001:2022. Valde uzdod vienkāršāku jautājumu: “Kāpēc kāds varēja uzdoties par mums?”

Tieši šī jautājuma dēļ e-pasta autentifikācija 2026. gadā vairs nav šaurs DNS temats. DMARC, SPF, DKIM, MTA-STS un TLS-RPT ir kontroles pasākumi, kas rada pierādījumus. Tie samazina pikšķerēšanas un domēna viltošanas risku, bet vienlaikus rada artefaktus, ko sagaida auditori: politikas lēmumus, īpašumtiesības, tehniskos pamatlīmeņus, piegādātāju pārskatatbildību, žurnālus, uzraudzības ierakstus, izņēmumus, izmaiņu apstiprinājumus un incidentu reaģēšanas trigerus.

Atbilstības problēma nav jautājums “Vai mums ir DMARC?”. Tā ir: “Vai varam pierādīt, ka e-pasta autentifikācija tiek pārvaldīta, uzraudzīta, pārskatīta un sasaistīta ar risku?”

Pierādījumu plaisa, ko auditori atrod atkārtoti

Tikpat izplatīts ir otrs scenārijs. Strauji augošā fintech uzņēmumā notiek ārējais audits. Auditors pāriet no darbības nepārtrauktības uz incidentu pārvaldību un jautā informācijas drošības vadītājam par biznesa e-pasta kompromitēšanu.

Informācijas drošības vadītājs paskaidro, ka uzņēmumam ir pretpikšķerēšanas filtri un ceturkšņa drošības izpratnes apmācība.

Auditors pamāj un tad prasa ko konkrētāku: “Parādiet DMARC, SPF un DKIM pārvaldību. Man jāredz īpašumtiesības, izmaiņu ieraksti, risku izvērtēšana, uzraudzības pierādījumi un tas, kā tas sasaistās ar NIS2 kiberdrošības higiēnu un DORA IKT risku ietvaru.”

Telpā iestājas klusums.

Tehniskā komanda DMARC ieviesa pirms vairākiem mēnešiem, bet ISMS nav politikas atsauces, nav centralizētas pierādījumu pakotnes, nav saites uz risku reģistru un nav apstiprinātas piemērošanas ceļkartes. Kontroles pasākums tehniski var pastāvēt, bet pārvaldībai tas ir neredzams.

Tā ir pierādījumu plaisa.

Nobriedusi e-pasta autentifikācijas programma atbild uz sešiem audita jautājumiem:

1. Kuri domēni un apakšdomēni ietilpst darbības jomā?
2. Kas ir katra domēna, DNS zonas, e-pasta plūsmas un sūtīšanas pakalpojuma īpašnieks?
3. Kurām sistēmām ir atļauts sūtīt organizācijas vārdā?
4. Kuri autentifikācijas mehānismi tiek piemēroti, uzraudzīti un pārskatīti?
5. Kā tiek apstiprināti izņēmumi, kā tiek pieņemts risks un kā izņēmumi tiek izbeigti?
6. Kādi pierādījumi apliecina, ka kontroles pasākums laika gaitā darbojās?

ISO/IEC 27001:2022 to padara par pārvaldības sistēmas jautājumu. 4.1.–4.4. punkti prasa organizācijai izprast kontekstu, ieinteresēto pušu prasības, piemērošanas jomas robežas, saskarnes un atkarības. E-pasta autentifikācija skar tās visas. Jūsu domēnu reģistrators var būt piegādātājs. DNS var būt mitināts mākoņinfrastruktūrā. Jūsu CRM, algu aprēķinu platforma, rēķinu izrakstīšanas rīks, mārketinga automatizācijas pakalpojumu sniedzējs un klientu atbalsta sistēma var sūtīt e-pastus, izmantojot jūsu zīmolu.

5.1.–5.3. punkti padara to par vadības jautājumu. Augstākajai vadībai jāpiešķir atbildības un jāintegrē informācijas drošība biznesa procesos. DMARC lēmums pāriet no p=none uz p=quarantine vai p=reject var ietekmēt klientu saziņu, finanšu paziņojumus, HR ievadīšanu darbā, pārdošanas kampaņas un ārpakalpojumu sniedzējus.

6.1.1.–6.1.3. punkti prasa risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi un piemērojamības deklarāciju (SoA). Domēna viltošana jāaplūko kā riska scenārijs, kur SPF, DKIM, DMARC, MTA-STS un TLS-RPT attiecīgajos gadījumos tiek izvēlēti kā daļa no riska apstrādes. 8.1. punkts pēc tam prasa darbības plānošanu un kontroli, tostarp kontroli pār ārēji nodrošinātiem procesiem, produktiem un pakalpojumiem, kas attiecas uz ISMS.

Ko pierāda katrs e-pasta autentifikācijas kontroles pasākums

SPF, DKIM, DMARC, MTA-STS un TLS-RPT darbojas kopā, bet pierāda atšķirīgas lietas.

SPF un DKIM ir identitātes un integritātes signāli. DMARC ir politikas slānis, kas šos signālus pārvērš saņēmēju rīcībā. MTA-STS un TLS-RPT atbalsta drošu e-pasta transportu, palīdzot novērst protokolu pazemināšanas un nepareizas konfigurācijas riskus.

Auditoriem dziļāka vērtība ir atkārtojami pierādījumi. DMARC agregētie pārskati parāda, kas sūta, izmantojot jūsu domēnu. TLS pārskati parāda, vai šifrēta piegāde neizdodas. Izmaiņu pieprasījumi parāda, vai pārvaldība pastāv. Piegādātāju ieraksti parāda, vai piegādes ķēdes atkarības ir zināmas.

Vispirms iekļaujiet domēnus aktīvu reģistrā

E-pasta autentifikāciju nevar pārvaldīt, ja domēni netiek uzskatīti par aktīviem.

MVU Aktīvu pārvaldības politika Aktīvu pārvaldības politika - SME nepārprotami iekļauj darbības jomā domēnus un ar e-pastu saistītās identitātes:

“Digitālie autentifikācijas dati un pakalpojumi: domēnu nosaukumi, digitālie sertifikāti, lietojumprogrammu saskarnes atslēgas, e-pasta konti, mākoņpakalpojumu pieteikšanās dati”

No sadaļas “Piemērošanas joma”, politikas punkts 2.2.4.

Lielākām organizācijām uzņēmuma Aktīvu pārvaldības politika Aktīvu pārvaldības politika piemēro to pašu loģiku:

“Loģiskie aktīvi: domēnu nosaukumi, licences, lietotāju konti, pamatkonfigurācijas”

No sadaļas “Piemērošanas joma”, politikas punkts 2.2.5.

Ja domēni ir aktīvi, tiem var būt īpašnieki, kritiskuma vērtējumi, pārskatīšanas cikli, piegādātāju atkarības, izmaiņu kontroles un pierādījumu atrašanās vietas. Ja tie ir tikai DNS ieraksti, tie parasti netiek pārvaldīti līdz brīdim, kad kaut kas pārstāj darboties.

Auditam gatavam domēnu un e-pasta sūtītāju reģistram jāietver:

Šis reģistrs atbalsta ISO/IEC 27001:2022 Annex A kontroles pasākumu A.5.9 Informācijas un citu saistīto aktīvu uzskaite, A.8.9 Konfigurāciju pārvaldība, A.5.19 Informācijas drošība piegādātāju attiecībās un A.5.23 Informācijas drošība mākoņpakalpojumu izmantošanā. Tas arī atbalsta NIST CSF 2.0 uzskaites rezultātus attiecībā uz aktīviem, pakalpojumiem, piegādātājiem un kritiskumu.

Izmantojiet izmaiņu pārvaldību DNS un e-pasta plūsmas lēmumiem

E-pasta autentifikācija pārstāj darboties, ja izmaiņu pārvaldība ir vāja. Pārdošanas komanda pievieno uzrunāšanas platformu. HR ievieš kandidātu izsekošanas rīku. Finanses maina rēķinu programmatūru. Mārketings pāriet uz jaunu e-pasta pakalpojumu sniedzēju. Katrs biznesa lēmums rada jaunu sūtītāju.

Uzņēmuma Izmaiņu pārvaldības politika Izmaiņu pārvaldības politika skaidri nosaka pierādījumu prasību:

“Visi izmaiņu pieprasījumi, pārskatīšanas, apstiprinājumi un atbalsta pierādījumi jāreģistrē centralizētajā Izmaiņu pārvaldības sistēmā.”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

Spēcīgā e-pasta autentifikācijas izmaiņu pieprasījumā jāiekļauj:

• Biznesa pamatojums jaunajam sūtītājam.
• Ietekmētais domēns vai apakšdomēns.
• SPF include vai sūtīšanas IP ietekme.
• DKIM selektors un atslēgas īpašumtiesības.
• DMARC saskaņošanas testa rezultāts.
• MTA-STS vai MX ietekme, ja tāda ir.
• Nosūtīto ziņojumu datu klasifikācija.
• Atsauce uz piegādātāja drošības pārskatīšanu.
• Atcelšanas plāns.
• Domēna īpašnieka un drošības funkcijas apstiprinājums.
• Testēšanas pierādījumi pēc ieviešanas.
• Pagaidu iestatījumu pārskatīšanas datums vai derīguma termiņš.

Tā ir atšķirība starp “DNS administrators mainīja ierakstu” un “ISMS kontrolēja ar risku saistītu izmaiņu”.

Praktisks 30 dienu plāns DMARC, SPF, DKIM un MTA-STS pierādījumiem

Informācijas drošības vadītājam nav vajadzīgs sešu mēnešu transformācijas projekts, lai uzlabotu pierādījumu briedumu. Fokusēts 30 dienu sprints var nodrošināt pamatotu pamatlīmeni.

1. nedēļa: atklājiet domēnus, sūtītājus un īpašumtiesības

Eksportējiet visus domēnus no reģistratora un DNS pakalpojumu sniedzēja. Iegūstiet e-pasta plūsmas datus no e-pasta vārtejas, CRM, palīdzības dienesta, mārketinga platformas, norēķinu sistēmas un mākoņpaziņojumu pakalpojumiem. Izveidojiet domēnu un sūtītāju reģistru.

Iekļaujiet arī novietotos domēnus un aizsardzības reģistrācijas. Novietotie domēni bieži tiek ignorēti, bet tos joprojām var ļaunprātīgi izmantot, ja DMARC nav ieviests vai ir vājš.

2. nedēļa: sakārtojiet SPF un DKIM saskaņošanu

Pārskatiet SPF attiecībā uz pārlieku atļaujošiem mehānismiem, novecojušiem include ierakstiem, dublētiem pakalpojumu sniedzējiem un vaicājumu ierobežojumu riskiem. DKIM gadījumā identificējiet katru sūtītāju, kas neparaksta e-pastu vai paraksta ar domēnu, kurš nebūs saskaņots ar DMARC.

Neapstipriniet SaaS sūtītāju tikai tāpēc, ka e-pasts darbojas. Apstipriniet to tāpēc, ka:

• Piegādātājs ir iekļauts sūtītāju reģistrā.
• SPF un DKIM konfigurācija ir dokumentēta.
• DKIM selektori ir uzskaitīti.
• Atslēgas īpašumtiesības un pārskatīšanas prasības ir skaidras.
• Piegādātāja drošības dokumentācija atbalsta drošu e-pasta apstrādi.
• Biznesa īpašnieks pieņem jebkuru pagaidu izņēmumu.

Šeit NIS2 un DORA kļūst praktiski. NIS2 Article 21 prasa atbilstošus un samērīgus tehniskos, darbības un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi un uzturēšanu, efektivitātes izvērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, piekļuves kontroli un drošu saziņu. DORA Article 28 prasa finanšu subjektiem pārvaldīt IKT trešo pušu risku kā daļu no IKT risku pārvaldības ietvara, tostarp sākotnējo izpēti, līgumiskās prasības, uzraudzību un izstāšanās plānošanu.

Ja mārketinga pakalpojumu sniedzējs sūta neautentificētu e-pastu, izmantojot jūsu domēnu, tā nav tikai mārketinga problēma. Tas ir piegādātāju risks, zīmola uzdošanās risks un potenciāls kaitējums klientiem.

3. nedēļa: virziet DMARC uz piemērošanu

Uzraudzības režīms ir noderīgs, bet pastāvīgs p=none bez apstiprinātas ceļkartes ir vājš pierādījums.

Pamatotā DMARC piemērošanas plānā jāiekļauj:

• Sākotnējā agregēto pārskatu pārskatīšana.
• Leģitīmo un neleģitīmo avotu identificēšana.
• Leģitīmo, bet pārbaudi neizturošo avotu trūkumu novēršana.
• Kritisko e-pasta plūsmu biznesa validācija.
• Pakāpeniska politikas palielināšana līdz pct=25, pct=50, pct=100.
• Pāreja no p=none uz p=quarantine.
• Pāreja uz p=reject, kad to pieļauj risks un biznesa gatavība.
• Atsevišķa apakšdomēnu apstrāde ar sp=.
• Izņēmumu reģistrs ar derīguma termiņiem.
• Vadības apstiprinājums atlikušajam riskam.

Tas atbalsta ISO/IEC 27001:2022 6.1.3. punkta riska apstrādi un 8.1. punkta darbības plānošanu un kontroli. Tas arī sniedz iekšējam auditam skaidru audita pēdu: lēmums, ieviešana, uzraudzība, izņēmums, apstiprinājums un pārskatīšana.

4. nedēļa: validējiet MTA-STS, TLS-RPT un uzraudzību

MTA-STS bieži netiek pamanīts, jo tas neaptur izejošo zīmola viltošanu tādā pašā veidā kā DMARC. Taču tas ir ļoti būtisks drošai saziņai un informācijas aizsardzībai pārsūtē. Tas norāda saderīgiem sūtīšanas serveriem, ka e-pasts uz jūsu domēnu jāpiegādā pa TLS, un validē MX identitāti.

Uzņēmuma Kriptogrāfisko kontroles pasākumu politika Kriptogrāfisko kontroles pasākumu politika nosaka skaidru transporta drošības pamatlīmeni:

“Transporta drošība: TLS 1.2 vai augstāka versija (vēlams TLS 1.3)”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.5.

MVU Kriptogrāfisko kontroles pasākumu politika Kriptogrāfisko kontroles pasākumu politika - SME tieši ietver e-pasta pārsūtīšanu:

“Dati, kas tiek pārsūtīti pa e-pastu, uzņēmuma VPN un tīmekļa portāliem”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.4.

Testēšanā jāiekļauj MX TLS validācija, MTA-STS politikas datnes pieejamība, HTTPS sertifikāta stāvoklis, TLS-RPT pārskatu pārskatīšana un kļūmju triāžas ieraksti.

Kartējiet e-pasta autentifikāciju pret ISO/IEC 27001:2022 Annex A

Clarysec Zenith Controls: Starpatbilstības ceļvedis Zenith Controls palīdz sasaistīt tehniskos pierādījumus ar audita gaidām dažādos ietvaros. Tas nav atsevišķs kontroles pasākumu kopums. Tas ir kartēšanas un audita ceļvedis ISO/IEC 27001:2022 kontroles pasākumiem un saistītajiem standartiem.

ISO/IEC 27001:2022 Annex A kontroles pasākumam A.5.14 Informācijas pārsūtīšana Zenith Controls skaidro saistību ar kriptogrāfiju:

“Droša informācijas pārsūtīšana balstās uz kriptogrāfiskajiem kontroles pasākumiem, kā detalizēti aprakstīts 8.24.”

Tā ir saikne starp biznesa e-pastu, DKIM, MTA-STS un TLS. E-pasts ir informācijas pārsūtīšanas kanāls. DKIM atbalsta ziņojuma autentiskumu un integritāti. MTA-STS un TLS atbalsta aizsardzību pārsūtē.

Annex A kontroles pasākumam A.8.24 Kriptogrāfijas izmantošana Zenith Controls sasaista kriptogrāfiju ar informācijas pārsūtīšanu, privātumu, personu identificējošas informācijas (PII) aizsardzību, klasifikāciju un ievainojamību pārvaldību. Annex A kontroles pasākumiem A.8.15 Žurnālfiksēšana un A.8.16 Uzraudzības darbības ceļvedis sasaista žurnālus un uzraudzību ar notikumu pārvaldību, pierādījumu vākšanu, pārskatīšanu, analīzi un auditējamību.

MVU Žurnālfiksēšanas un uzraudzības politika Žurnālfiksēšanas un uzraudzības politika - SME nosaka:

“Žurnālfiksēšana jāiespējo un jākonfigurē, kur tā ir pieejama”

No sadaļas “Pārvaldības prasības”, politikas punkts 5.5.1.1.

Uzņēmuma Žurnālfiksēšanas un uzraudzības politika Žurnālfiksēšanas un uzraudzības politika ietver:

“Ārējās komunikācijas un ugunsmūra noteikumu trigeri”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.6.

E-pasta autentifikācijas kontekstā ārējai komunikācijai jāietver e-pasta vārtejas notikumi, DMARC agregēto pārskatu apstrāde, DKIM kļūmju tendences, aizdomīga avota infrastruktūra, TLS-RPT kļūmes un viltošanas mēģinājumi, kas aktivizē incidentu triāžu.

Zenith Blueprint: auditora 30 soļu ceļkarte Zenith Blueprint to pārvērš praktiskā kontroles validācijā. Posmā “Kontroles pasākumi darbībā”, 20. solī, tas norāda komandām validēt tīkla pakalpojumu drošību:

“Uzskaitiet visus iekšējos un ārējos tīkla pakalpojumus (DNS, VPN, SMTP, DHCP, lietojumprogrammu saskarnes vārtejas u. c.).

✓ Katram apstipriniet, ka tiek izmantoti droši protokoli (piem., DNSSEC, TLS 1.2+, SSH Telnet vietā).
✓ Pārskatiet, kā tiek kontrolēta piekļuve katram pakalpojumam (piem., IP atļauto saraksti, autentifikācija, sertifikāti).
✓ Ja tos pārvalda trešās puses (piem., DNS, SD-WAN, mitināts VPN), pārskatiet drošības klauzulas SLA vai piegādātāja līgumā. Atjauniniet savu pakalpojumu reģistru un norādiet, kur atrodas drošības atbildība — iekšēji vai ārēji.”

Piemērojot to e-pastam, tas kļūst par darba plānu DNS, SMTP, TLS, mitinātām e-pasta vārtejām, piegādātāju sūtītājiem un atbildības robežām.

Starpatbilstības kartēšana: viena pierādījumu pakotne, daudzi pienākumi

Tā pati pierādījumu pakotne var atbalstīt ISO/IEC 27001:2022, NIS2, DORA, GDPR un NIST CSF 2.0, ja tā ir pareizi strukturēta.

NIS2 ir īpaši būtiska būtiskajām un svarīgajām vienībām, kā arī noteiktām digitālās infrastruktūras un digitālo pakalpojumu sniedzēju kategorijām. Article 20 nosaka kiberdrošības pārvaldību kā vadības institūcijas atbildību, savukārt Article 21 nosaka risku pārvaldības pamatlīmeni. E-pasta autentifikācijas pierādījumi palīdz parādīt, ka droša saziņa, piegādātāju attiecības, incidentu apstrāde, efektivitātes izvērtēšana un kiberdrošības higiēna ir praktiski īstenotas, nevis teorētiskas.

Finanšu subjektiem DORA ir piemērojama kopš 2025. gada 17. janvāra. Articles 5 un 6 prasa vadības institūcijas pārskatatbildību un dokumentētu IKT risku pārvaldības ietvaru. Article 17 prasa procesus ar IKT saistītu incidentu atklāšanai, pārvaldībai, reģistrēšanai, klasificēšanai, eskalācijai un trūkumu novēršanai. Article 28 nosaka IKT trešo pušu risku pārvaldību kā formālu atbildību. E-pasta pakalpojumu sniedzēji, mārketinga platformas, maksājumu paziņojumu sistēmas un klientu saziņas rīki var kļūt par šīs IKT atkarību ķēdes daļu.

GDPR kontekstā galvenais jautājums ir, vai e-pasts tiek izmantots personas datu apstrādei. Article 5 ietver integritāti, konfidencialitāti un pārskatatbildību. Article 32 prasa atbilstošus tehniskos un organizatoriskos pasākumus. Ja rēķini, HR ziņojumi, konta paziņojumi, atbalsta pieteikumi vai ievadīšanas e-pasti satur personas datus, e-pasta autentifikācija un transporta drošība kļūst par daļu no apstrādes drošības pierādījumiem.

Incidentu reaģēšana: kad pārskati kļūst par agrīnu brīdinājumu

DMARC agregētie pārskati nav tikai atbilstības pierādījumi. Tie ir agrīna brīdinājuma dati. Straujš neveiksmīgas autentifikācijas pieaugums no nepazīstamas infrastruktūras var liecināt par aktīvu viltošanu, ēnu IT, piegādātāja nepareizu konfigurāciju vai kompromitētu sūtītāju.

Saskaņā ar NIS2 Article 23 būtiskajām un svarīgajām vienībām ir bez nepamatotas kavēšanās jāpaziņo par nozīmīgiem incidentiem, izmantojot pakāpenisku ziņošanu, kas ietver agrīnu brīdinājumu, incidenta paziņojumu un galīgo ziņojumu. Ne katrs viltošanas mēģinājums ir ziņojams, bet organizācijai jāspēj izvērtēt smaguma pakāpi, darbības traucējumus, finansiālos zaudējumus, pārrobežu ietekmi un kaitējumu saņēmējiem.

Saskaņā ar DORA Article 17 finanšu subjektiem jādefinē un jāievieš ar IKT saistītu incidentu pārvaldības process, jāreģistrē incidenti un būtiski kiberdraudi, jānosaka pamatcēloņi, jāizmanto agrīnās brīdināšanas indikatori, jāklasificē pēc smaguma pakāpes un pakalpojuma kritiskuma, jāpiešķir lomas, jādefinē komunikācija un jāeskalē būtiski incidenti. DORA Article 19 tālāk attiecas uz būtisku ar IKT saistītu incidentu ziņošanu.

GDPR gadījumā jautājums ir, vai notikums izraisīja personas datu nejaušu vai nelikumīgu iznīcināšanu, nozaudēšanu, izmainīšanu, nesankcionētu izpaušanu vai piekļuvi tiem. Viltots e-pasts, kas maldina klientus iesniegt personas datus uzbrucējam, var izraisīt datu aizsardzības pārkāpuma izvērtēšanu, pat ja iekšējās sistēmas nav kompromitētas.

Uzņēmuma Audita un atbilstības uzraudzības politika Audita un atbilstības uzraudzības politika skaidro, kāpēc disciplinēti pierādījumi ir svarīgi:

“Radīt aizstāvamus pierādījumus un audita pēdu regulatīvo pieprasījumu, tiesvedības vai klientu apliecinājuma pieprasījumu atbalstam.”

No sadaļas “Mērķi”, politikas punkts 3.4.

MVU Audita un atbilstības uzraudzības politika Audita un atbilstības uzraudzības politika - SME pievieno pierādījumu kvalitātes prasību:

“Metadati (piem., kas tos savāca, kad un no kuras sistēmas) ir jādokumentē.”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.2.3.

Tāpēc DMARC izmeklēšanas datnei jādokumentē pārskata avots, vākšanas laiks, analītiķis, ietekmētie domēni, aizdomīgās sūtītāju IP adreses, autentifikācijas rezultāti, biznesa ietekmes novērtējums, pieņemtie lēmumi un slēgšanas apstiprinājums.

Ko auditori prasīs

Dažādi auditori izmanto atšķirīgu terminoloģiju, taču pierādījumi pārklājas.

Sagaidiet praktiskus jautājumus:

• Parādiet DMARC pārskatus par pēdējo ceturksni.
• Parādiet, kā tie tika pārskatīti.
• Parādiet izņēmumu šim sūtītājam, kurš neiztur pārbaudi.
• Parādiet, kas apstiprināja šo SPF izmaiņu.
• Parādiet, vai DKIM selektori ir uzskaitīti un pārskatīti.
• Parādiet, kā MTA-STS tiek testēts pēc e-pasta vārtejas izmaiņām.
• Parādiet, kā viltošanas notikumi nonāk incidentu triāžā.
• Parādiet, kā piegādātāju sūtītāji tiek noņemti, izbeidzot līgumu.

Īss 2026. gada iekšējā audita kontrolsaraksts

Izmantojiet šo kontrolsarakstu kā sākumpunktu iekšējam auditam, kontroles testēšanai vai e-pasta autentifikācijas pierādījumu pārskatīšanai.

• Visi domēni un apakšdomēni ir uzskaitīti aktīvu reģistrā.
• Novietotajiem un aizsardzības domēniem ir DMARC pārklājums.
• Katram autorizētajam sūtītājam ir biznesa īpašnieks un tehniskais īpašnieks.
• SPF ieraksti tiek pārskatīti attiecībā uz novecojušiem include ierakstiem un pārmērīgu tvērumu.
• DKIM ir iespējots leģitīmiem sūtītājiem, kur tas tiek atbalstīts.
• DKIM selektori ir uzskaitīti un pārskatīti.
• DMARC ir izvietots saknes domēniem un attiecīgajiem apakšdomēniem.
• DMARC ir piemērošanas ceļkarte, nevis beztermiņa uzraudzība.
• DMARC agregētie pārskati tiek pārskatīti noteiktā regularitātē.
• MTA-STS ir konfigurēts ienākošā pasta domēniem, kur tas ir piemērojams.
• TLS-RPT pārskati tiek vākti un triāžēti.
• E-pasta autentifikācijas izmaiņas ievēro izmaiņu pārvaldību.
• Piegādātāju ieviešana ietver e-pasta sūtīšanas prasības.
• Piegādātāju attiecību izbeigšana noņem SPF include ierakstus, DKIM selektorus un sūtīšanas atļaujas.
• Izņēmumiem ir riska īpašnieki, derīguma termiņi un kompensējošie kontroles pasākumi.
• Viltošanas pieaugumi un autentifikācijas kļūmes nonāk incidentu reaģēšanā.
• Pierādījumi ietver metadatus, avotu, datumu, vācēju un sistēmu.
• Vadība periodiski saņem metriku un riska atjauninājumus.

Zenith Blueprint risku pārvaldības posma 14. solis iesaka izveidot regulatīvās kartēšanas tabulas piemērojamiem pienākumiem:

“Katrai regulai, ja piemērojams, var izveidot vienkāršu kartēšanas tabulu (piemēram, kā pielikumu pārskatā), kurā uzskaitītas regulas galvenās drošības prasības un atbilstošie kontroles pasākumi/politikas jūsu ISMS. Tas nav obligāti ISO 27001 ietvaros, bet ir noderīgs iekšējs uzdevums, lai nodrošinātu, ka nekas nav palicis nepamanīts. Tas arī atstāj labu iespaidu uz auditoriem/vērtētājiem, jo parāda, ka drošība netiek pārvaldīta vakuumā, bet ar izpratni par tiesisko kontekstu.”

E-pasta autentifikācijai šī tabula kļūst par tiltu starp tehnisko DNS realitāti un valdes līmeņa pārliecību.

Pārvērtiet e-pasta autentifikāciju auditam gatavos pierādījumos

Jūsu klienti var nekad nepajautāt, vai jūsu SPF ierakstam ir perfekta sintakse. Viņi jautās, vai jūs spējat aizsargāt savu zīmolu, samazināt pikšķerēšanas risku, nodrošināt drošu saziņu, pārvaldīt piegādātājus un pierādīt, ka jūsu kontroles pasākumi darbojas.

Clarysec palīdz organizācijām pārvērst e-pasta autentifikāciju no trausliem tehniskiem iestatījumiem auditam gatavā kontroles sistēmā. Praktiskais nākamais solis ir fokusēta e-pasta autentifikācijas pierādījumu pārskatīšana:

1. Izveidojiet domēnu un sūtītāju reģistru.
2. Kartējiet SPF, DKIM, DMARC, MTA-STS un TLS-RPT statusu.
3. Identificējiet piegādātājus, ēnas sūtītājus un izņēmumus.
4. Izveidojiet DMARC piemērošanas ceļkarti.
5. Validējiet izmaiņu pārvaldības, žurnālfiksēšanas un incidentu reaģēšanas pierādījumus.
6. Sasaistiet pierādījumus ar ISO/IEC 27001:2022, NIS2, DORA, GDPR un NIST CSF 2.0.
7. Sagatavojiet auditoram gatavu pierādījumu pakotni, izmantojot Zenith Blueprint, Zenith Controls un attiecīgās Clarysec politikas.

Ja jūsu organizācija gatavojas ISO/IEC 27001:2022 sertifikācijai, NIS2 gatavībai, DORA apliecinājumam, GDPR pārskatatbildības pārskatīšanai vai klientu drošības anketām, sāciet ar kontroles pasākumiem, kurus uzbrucēji ļaunprātīgi izmanto visredzamāk: jūsu domēniem, jūsu sūtītājiem un jūsu e-pasta uzticamības ķēdi.

Lejupielādējiet Zenith Blueprint, izmantojiet Zenith Controls starpatbilstības kartēšanai un veiciet 30 dienu e-pasta autentifikācijas pierādījumu pārskatīšanu, pirms nākamais viltošanas incidents vai audita pieprasījums piespiež sākt šo sarunu.