⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

DMARC-i tõendusmaterjal ISO 27001, NIS2, DORA ja GDPR jaoks

Igor Petreski
14 min read
DMARC SPF DKIM MTA-STS tõendusmaterjal seostatuna ISO 27001 NIS2 DORA ja GDPR nõuetega

See algab sellest, et finantsdirektor edastab kell 07:42 infoturbejuhile e-kirja.

„Kas meie saatsime selle?“

Sõnum näeb välja laitmatu. Sama logo, sama jalus, sama toon nagu arveldusmeeskonnal. Selles väidetakse, et pangaandmed on muutunud. Saatja kuvatav nimi on õige. Domeen ei ole sarnase kirjapildiga võltsdomeen. Ründaja võltsib tegelikku domeeni.

Kell 08:15 kinnitab turbemeeskond ebamugava tõe: SPF on olemas, kuid liiga laia ulatusega; DKIM on lubatud ainult peamisel e-posti platvormil; mitu turundustööriista saadavad allkirjastamata kirju; DMARC on endiselt seirerežiimis; ning keegi ei leia domeeni MTA-STS poliitika viimast läbivaatamist. Organisatsioonil on slaidipakis „e-posti turve“, kuid tõendusmaterjal on laiali DNS-i ekraanitõmmistes, tarnijaportaalides, vanades Jira piletites ja tabelis, mille omanik lahkus eelmisel aastal.

Kell 10:30 küsib õigusosakond, kas kliendi isikuandmed võivad olla seotud. Vastavusüksus küsib, kas see on NIS2 teavitamiskohustuse seisukohast asjakohane. Finantsteenuste klient küsib, kas ettevõte suudab tõendada DORA-ga kooskõlas olevaid IKT-riski kontrollimeetmeid. Siseaudit küsib, kuidas see seostub ISO/IEC 27001:2022-ga. Juhatus küsib lihtsama küsimuse: „Kuidas sai keegi meie nime all esineda?“

See küsimus on põhjus, miks e-posti autentimine ei ole 2026. aastal enam kitsas DNS-i teema. DMARC, SPF, DKIM, MTA-STS ja TLS-RPT on tõendusmaterjali loovad kontrollimeetmed. Need vähendavad andmepüügi ja domeeni võltsimise riski, kuid loovad ka tõendusobjektid, mida audiitorid eeldavad: poliitikaotsused, vastutuse ja omandiõiguse määratlus, tehnilised lähtealused, tarnijate vastutus, logid, seirekirjed, erandid, muudatuste kinnitused ja intsidentidele reageerimise käivitajad.

Vastavusprobleem ei ole „Kas meil on DMARC?“. Probleem on „Kas suudame tõendada, et e-posti autentimine on juhitud, seiratud, läbi vaadatud ja riskidega seotud?“

Tõendusmaterjali lünk, mida audiitorid pidevalt leiavad

Teine stsenaarium on sama tavapärane. Kiiresti kasvavas finantstehnoloogia ettevõttes toimub välisaudit. Audiitor liigub talitluspidevuselt intsidendihaldusele ja küsib infoturbejuhilt ärie-posti kompromiteerimise kohta.

Infoturbejuht selgitab, et ettevõttel on andmepüügivastased filtrid ja kord kvartalis toimuv turvateadlikkuse koolitus.

Audiitor noogutab ja küsib seejärel midagi täpsemat: „Näidake mulle DMARC-i, SPF-i ja DKIM-i juhtimist. Mul on vaja näha omanikke, muudatuste kirjeid, riskihinnangut, seire tõendusmaterjali ning seda, kuidas see seostub NIS2 küberhügieeni ja DORA IKT-riskiraamistikuga.“

Ruum vaikib.

Tehniline meeskond rakendas DMARC-i mitu kuud tagasi, kuid ISMS-is puudub poliitikaviide, keskne tõenduspakett, seos riskiregistriga ja kinnitatud rakenduskava. Kontrollimeede võib tehniliselt olemas olla, kuid juhtimise jaoks on see nähtamatu.

See on tõendusmaterjali lünk.

Küps e-posti autentimise programm vastab kuuele auditiküsimusele:

  1. Millised domeenid ja alamdomeenid kuuluvad kohaldamisalasse?
  2. Kes vastutab iga domeeni, DNS-tsooni, meilivoo ja saatmisteenuse eest?
  3. Millistel süsteemidel on lubatud organisatsiooni nimel kirju saata?
  4. Milliseid autentimismehhanisme rakendatakse, seiratakse ja vaadatakse läbi?
  5. Kuidas erandeid kinnitatakse, riske aktsepteeritakse ja erandeid lõpetatakse?
  6. Milline tõendusmaterjal tõendab, et kontrollimeede toimis aja jooksul?

ISO/IEC 27001:2022 muudab selle juhtimissüsteemi küsimuseks. Punktid 4.1 kuni 4.4 nõuavad, et organisatsioon mõistaks oma konteksti, huvitatud poolte nõudeid, käsitlusala piire, liideseid ja sõltuvusi. E-posti autentimine puudutab neid kõiki. Domeeniregistraator võib olla tarnija. DNS võib olla majutatud pilvetaristus. CRM, palgaplatvorm, arvetööriist, turundusautomaatika teenuseosutaja ja klienditoe süsteem võivad kõik saata e-kirju sinu brändi kasutades.

Punktid 5.1 kuni 5.3 muudavad selle juhtimisküsimuseks. Tippjuhtkond peab määrama vastutused ja lõimima infoturbe äriprotsessidesse. DMARC-i otsus liikuda väärtuselt p=none väärtusele p=quarantine või p=reject võib mõjutada kliendisuhtlust, finantsteavitusi, HR-i tööleasumise protsessi, müügikampaaniaid ja allhanketeenuseosutajaid.

Punktid 6.1.1 kuni 6.1.3 nõuavad riskihindamist, riskikäsitlust, kontrollimeetmete valikut ja kohaldatavusavaldust. Domeeni võltsimist tuleb käsitleda riskistsenaariumina ning SPF, DKIM, DMARC, MTA-STS ja TLS-RPT tuleb vajaduse korral valida riskikäsitluse osaks. Punkt 8.1 nõuab seejärel tegevuse planeerimist ja ohjet, sealhulgas ISMS-i seisukohast asjakohaste väliselt osutatavate protsesside, toodete ja teenuste ohjet.

Mida iga e-posti autentimise kontrollimeede tõendab

SPF, DKIM, DMARC, MTA-STS ja TLS-RPT toimivad koos, kuid tõendavad erinevaid asju.

KontrollimeedeMida see teebMillist vastavuse tõendusmaterjali see loobTavaline auditinõrkus
SPFAutoriseerib, millised meiliserverid võivad domeeni nimel kirju saataDNS-kirje, heakskiidetud saatjate register, tarnijate saatmisloend, muudatuste ajaluguKirje on liiga lai, ületab päringulimiite või sisaldab kasutuselt kõrvaldatud tarnijaid
DKIMAllkirjastab e-kirja krüptograafiliselt, et vastuvõtjad saaksid kontrollida terviklust ja seost domeenigaSelektorite register, võtmete rotatsiooni kirjed, tarnija DKIM-i konfiguratsioon, testitulemusedAllkirjastab ainult peamine e-posti platvorm, samal ajal kui SaaS-tööriistad saadavad allkirjastamata kirju
DMARCÜtleb vastuvõtjatele, mida teha, kui SPF-i või DKIM-i joondus ebaõnnestub, ning saadab aruandeidPoliitikakirje, koondaruanded, rakenduskava, erandiregister, seire juhtpaneelidJääb määramata ajaks väärtusele p=none ilma riski aktsepteerimise või sihtkuupäevata
MTA-STSÜtleb saatvatele meiliserveritele, et sinu domeenile kirjade edastamisel tuleb kasutada TLS-iPoliitikafail, DNS TXT-kirje, HTTPS-majutuse tõendusmaterjal, TLS-i valideerimine, läbivaatamise kirjedLoodud üks kord, kuid pärast meililüüsi või sertifikaadi muudatusi ei testita enam
TLS-RPTVõtab vastu aruandeid TLS-i edastusprobleemide kohtaDNS-kirje, postkast või aruandluse lõpp-punkt, triaažikirjed, intsidendipiletidAruandeid kogutakse, kuid neid ei vaadata läbi ega seostata intsidentidega

SPF ja DKIM on identiteedi ja tervikluse signaalid. DMARC on poliitikakiht, mis muudab need signaalid vastuvõtja tegevuseks. MTA-STS ja TLS-RPT toetavad turvalist e-posti transporti, aidates ennetada algoritmi nõrgendamise ja väärkonfiguratsiooni riske.

Audiitorite jaoks on sügavam väärtus korduvkasutatav tõendusmaterjal. DMARC-i koondaruanded näitavad, kes saadab sinu domeenina. TLS-i aruanded näitavad, kas krüpteeritud edastus ebaõnnestub. Muudatuste piletid näitavad, kas juhtimine on olemas. Tarnijakirjed näitavad, kas tarneahela sõltuvused on teada.

Lisa domeenid esmalt vararegistrisse

E-posti autentimist ei saa juhtida, kui domeene ei käsitleta varadena.

VKE Varahalduse poliitika-sme Varahalduse poliitika - VKE hõlmab domeenid ja e-postiga seotud identiteedid selgelt kohaldamisalasse:

„Digitaalsed autentimisandmed ja teenused: domeeninimed, digitaalsed sertifikaadid, API-võtmed, e-posti kontod, pilveteenuste sisselogimised“

Jaotisest „Kohaldamisala“, poliitikapunkt 2.2.4.

Suuremate organisatsioonide puhul rakendab ettevõtte Varahalduse poliitika Varahalduse poliitika sama loogikat:

„Loogilised varad: domeeninimed, litsentsid, kasutajakontod, konfiguratsiooni lähtealused“

Jaotisest „Kohaldamisala“, poliitikapunkt 2.2.5.

Kui domeenid on varad, saab neil olla omanikud, kriitilisuse hinnangud, läbivaatamistsüklid, tarnijasõltuvused, muudatuste kontrollid ja tõendusmaterjali asukohad. Kui need on lihtsalt DNS-kirjed, jäävad need tavaliselt haldamata seni, kuni midagi katki läheb.

Auditivalmis domeenide ja e-posti saatjate register peab sisaldama järgmist:

VäliNäide
Domeen või alamdomeenexample.com, billing.example.com
DNS-teenuseosutaja ja registraatorPilve DNS-teenuseosutaja, ettevõtte registraator
MX-teenuseosutajaMicrosoft 365, Google Workspace, turvaline e-posti lüüs
SaatmisteenusSendGrid, Salesforce, Zendesk, palgateenuse osutaja
ÄrivastutajaFinantstoimingud
Tehniline vastutajaSõnumsidetehnika
AutentimismeetodSPF ja DKIM joondatud
DKIM-i selektorselector1, vendor2026
DMARC-i tulemusLäbitud, osaline, ebaõnnestunud
MTA-STS-i staatusRakendatud, testimisel, ei kohaldu
TLS-RPT sihtkohttls-rpt@example.com
RiskistaatusHeaks kiidetud, erand, parandusmeede
Tõendusmaterjali asukohtMuudatuse pilet, DNS-i eksport, tarnija ekraanitõmmis
Läbivaatamise kuupäevKord kvartalis

See register toetab ISO/IEC 27001:2022 lisa A kontrollimeedet A.5.9 teabe ja muude seotud varade inventuur, A.8.9 konfiguratsioonihaldus, A.5.19 infoturve tarnijasuhetes ja A.5.23 infoturve pilveteenuste kasutamisel. See toetab ka NIST CSF 2.0 varade, teenuste, tarnijate ja kriitilisuse inventuuri tulemusi.

Kasuta DNS-i ja meilivoo otsuste jaoks muudatuste juhtimist

E-posti autentimine läheb katki, kui muudatuste juhtimine on nõrk. Müügimeeskond lisab väljasaatmise platvormi. HR võtab kasutusele kandidaatide jälgimise tööriista. Finants muudab arvetarkvara. Turundus liigub uue e-posti teenuseosutaja juurde. Iga äriotsus loob uue saatja.

Ettevõtte Muudatuste haldamise poliitika Muudatuste haldamise poliitika teeb tõendusmaterjali nõude selgeks:

„Kõik muudatustaotlused, läbivaatamised, kinnitused ja toetav tõendusmaterjal tuleb registreerida keskses muudatuste juhtimissüsteemis.“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.

Tugev e-posti autentimise muudatuse pilet peab sisaldama järgmist:

  • Äripõhjendus uuele saatjale.
  • Mõjutatud domeen või alamdomeen.
  • SPF-i include-mehhanismi või saatva IP mõju.
  • DKIM-i selektor ja võtme omandiõigus.
  • DMARC-i joondustesti tulemus.
  • MTA-STS-i või MX-i mõju, kui see on olemas.
  • Saadetavate sõnumite andmete klassifikatsioon.
  • Viide tarnija turbeülevaatusele.
  • Tagasipööramiskava.
  • Domeeniomaniku ja turbemeeskonna kinnitus.
  • Rakendamisjärgne testitõendusmaterjal.
  • Ajutiste seadistuste läbivaatamise kuupäev või aegumiskuupäev.

See on erinevus väidete „DNS-administraator muutis kirjet“ ja „ISMS ohjas riskiga seotud muudatust“ vahel.

Praktiline 30-päevane plaan DMARC-i, SPF-i, DKIM-i ja MTA-STS-i tõendusmaterjali jaoks

Infoturbejuht ei vaja tõendusmaterjali küpsuse parandamiseks kuuekuulist ümberkujundamisprojekti. Keskendunud 30-päevane sprint võib luua kaitstava lähteolukorra.

1. nädal: tuvasta domeenid, saatjad ja omanikud

Ekspordi kõik domeenid registraatorist ja DNS-teenuseosutajalt. Võta meilivoo andmed e-posti lüüsist, CRM-ist, kasutajatoest, turundusplatvormist, arveldussüsteemist ja pilve teavitusteenustest. Koosta domeenide ja saatjate register.

Lisa ka pargitud domeenid ja kaitseotstarbelised registreeringud. Pargitud domeene ignoreeritakse sageli, kuid neid saab siiski kuritarvitada, kui DMARC puudub või on nõrk.

2. nädal: paranda SPF-i ja DKIM-i joondus

Vaata SPF üle liiga lubavate mehhanismide, aegunud include-kirjete, dubleerivate teenuseosutajate ja päringulimiitide riskide suhtes. DKIM-i puhul tuvasta iga saatja, kes ei allkirjasta kirju või allkirjastab domeeniga, mis ei joondu DMARC-iga.

Ära kinnita SaaS-saatjat ainult seetõttu, et kiri liigub. Kinnita see seetõttu, et:

  • Tarnija on saatjate registris.
  • SPF-i ja DKIM-i konfiguratsioon on dokumenteeritud.
  • DKIM-i selektorid on inventeeritud.
  • Võtme omandiõigus ja läbivaatamise ootused on selged.
  • Tarnija turbedokumentatsioon toetab turvalist e-posti käitlemist.
  • Ärivastutaja aktsepteerib ajutise erandi.

Siin muutuvad NIS2 ja DORA praktiliseks. NIS2 Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist ja hooldust, tõhususe hindamist, küberhügieeni, krüptograafiat, juurdepääsukontrolli ning turvalist sidet. DORA Article 28 nõuab, et finantsüksused haldaksid IKT kolmanda osapoole riski IKT-riskijuhtimise raamistiku osana, sealhulgas hoolsuskontrolli, lepingulisi ootusi, seiret ja väljumisplaani.

Kui turundusteenuse osutaja saadab sinu domeeni kasutades autentimata e-kirju, ei ole see üksnes turundusprobleem. See on tarnijarisk, brändi kuritarvitamise risk ja potentsiaalne kahju klientidele.

3. nädal: vii DMARC rakendamise suunas

Seirerežiim on kasulik, kuid püsiv p=none ilma kinnitatud tegevuskavata on nõrk tõendusmaterjal.

Kaitstav DMARC-i rakenduskava peab sisaldama järgmist:

  • Lähteolukorra koondaruannete läbivaatamine.
  • Legitiimsete ja mittelegitiimsete allikate tuvastamine.
  • Legitiimsete ebaõnnestuvate allikate parandusmeetmed.
  • Kriitiliste meilivoogude äriline valideerimine.
  • Poliitika järkjärguline suurendamine väärtustele pct=25, pct=50, pct=100.
  • Üleminek väärtuselt p=none väärtusele p=quarantine.
  • Üleminek väärtusele p=reject, kui risk ja äriline valmisolek seda võimaldavad.
  • Eraldi käsitlus alamdomeenidele väärtusega sp=.
  • Erandiregister aegumiskuupäevadega.
  • Juhtkonna heakskiit jääkriskile.

See toetab ISO/IEC 27001:2022 punkti 6.1.3 riskikäsitlust ja punkti 8.1 tegevuse planeerimist ja ohjet. See annab siseauditile ka selge jälje: otsus, rakendamine, seire, erand, kinnitus ja läbivaatamine.

4. nädal: valideeri MTA-STS, TLS-RPT ja seire

MTA-STS jääb sageli tähelepanuta, sest see ei peata väljuvat brändi võltsimist samal viisil nagu DMARC. Kuid see on väga asjakohane turvalise side ja edastamisel oleva teabe kaitse seisukohast. See ütleb ühilduvatele saatvatele serveritele, et sinu domeenile saadetav kiri tuleb edastada TLS-i kaudu, ning valideerib MX-identiteedi.

Ettevõtte Krüptograafiliste kontrollimeetmete poliitika Krüptograafiliste kontrollimeetmete poliitika seab selge transporditurbe baastaseme:

„Transporditurve: TLS 1.2 või uuem (eelistatavalt TLS 1.3)“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.5.

VKE-de puhul hõlmab Krüptograafiliste kontrollimeetmete poliitika-sme Krüptograafiliste kontrollimeetmete poliitika - VKE selgelt e-posti edastamist:

„E-posti, ettevõtte VPN-ide ja veebiportaalide kaudu edastatavad andmed“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.4.

Testimine peab hõlmama MX TLS-i valideerimist, MTA-STS poliitikafaili kättesaadavust, HTTPS-sertifikaadi seisundit, TLS-RPT aruannete läbivaatamist ja tõrgete triaažikirjeid.

Seo e-posti autentimine ISO/IEC 27001:2022 lisa A-ga

Claryseci Zenith Controls: ristvastavuse juhend Zenith Controls aitab siduda tehnilise tõendusmaterjali auditiootustega eri raamistikes. See ei ole eraldi kontrollimeetmete kogum. See on ISO/IEC 27001:2022 kontrollimeetmete ja seotud standardite kaardistus- ning auditijuhend.

ISO/IEC 27001:2022 lisa A kontrollimeetme A.5.14 teabe edastamine kohta selgitab Zenith Controls seost krüptograafiaga:

„Turvaline teabe edastamine tugineb krüptograafilistele kontrollimeetmetele, nagu on kirjeldatud punktis 8.24.“

See on seos ärie-posti, DKIM-i, MTA-STS-i ja TLS-i vahel. E-post on teabe edastamise kanal. DKIM toetab sõnumi autentsust ja terviklust. MTA-STS ja TLS toetavad transpordikaitset.

Lisa A kontrollimeetme A.8.24 krüptograafia kasutamine puhul seob Zenith Controls krüptograafia teabe edastamise, privaatsuse, PII kaitse, klassifitseerimise ja haavatavuste haldusega. Lisa A kontrollimeetmete A.8.15 logimine ja A.8.16 seiretegevused puhul seob juhend logid ja seire sündmuste halduse, tõendite kogumise, läbivaatamise, analüüsi ja auditeeritavusega.

VKE Logimis- ja seirepoliitika-sme Logimis- ja seirepoliitika - VKE sätestab:

„Logimine peab olema lubatud ja konfigureeritud, kui see on saadaval“

Jaotisest „Juhtimisnõuded“, poliitikapunkt 5.5.1.1.

Ettevõtte Logimis- ja seirepoliitika Logimis- ja seirepoliitika sisaldab järgmist:

„Väline side ja tulemüürireeglite päästikud“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.6.

E-posti autentimise puhul peab väline side hõlmama meililüüsi sündmusi, DMARC-i koondaruannete töötlemist, DKIM-i tõrketrende, kahtlast lähtetaristut, TLS-RPT tõrkeid ja võltsimiskatseid, mis käivitavad intsidentide esmase hindamise.

Zenith Blueprint: audiitori 30 sammu tegevuskava Zenith Blueprint asetab selle praktilisse kontrollimeetmete valideerimisse. Faasis „Kontrollimeetmed praktikas“, samm 20, suunab see meeskondi valideerima võrguteenuste turvet:

„Loetlege kõik sise- ja välisvõrguteenused (DNS, VPN, SMTP, DHCP, API-lüüsid jne).

✓ Iga teenuse puhul kinnitage, et kasutatakse turvalisi protokolle (nt DNSSEC, TLS 1.2+, SSH Telneti asemel).
✓ Vaadake üle, kuidas kontrollitakse juurdepääsu igale teenusele (nt IP lubatud loendid, autentimine, sertifikaadid).
✓ Kui teenust haldavad kolmandad osapooled (nt DNS, SD-WAN, majutatud VPN), vaadake üle SLA või tarnijalepingu turbeklauslid. Uuendage teenuseregistrit ja märkige, kus asuvad turbevastutused — kas sisemiselt või väliselt.“

E-posti puhul muutub see tööplaaniks DNS-i, SMTP, TLS-i, majutatud meililüüside, tarnijasaatjate ja vastutuspiiride jaoks.

Ristvastavuse kaardistus: üks tõenduspakett, mitu kohustust

Sama tõenduspakett võib toetada ISO/IEC 27001:2022, NIS2, DORA, GDPR ja NIST CSF 2.0 nõudeid, kui see on õigesti struktureeritud.

TõendusobjektAsjakohasus ISO/IEC 27001:2022 jaoksAsjakohasus NIS2 jaoksAsjakohasus DORA jaoksAsjakohasus GDPR jaoksAsjakohasus NIST CSF 2.0 jaoks
Domeenide ja e-posti saatjate registerPunktid 4.3 ja 8.1, A.5.9, A.5.19, A.5.23Article 21 riskijuhtimine ja tarneahela turveArticles 6 and 28 IKT-risk ja kolmandate osapoolte juhtimineArticle 5 vastutuse tõendatavus, kui isikuandmeid saadetakse e-postigaID.AM varade ja teenuste inventuur
DMARC-i rakenduskavaPunkt 6.1.3, kohaldatavusavaldus, A.8.9, A.5.14Article 21 küberhügieen ja tõhususe hindamineArticles 6, 9 and 10 IKT-risk, kaitse ja tuvastamineArticles 5 and 32 terviklus, konfidentsiaalsus ja töötlemise turvalisusGV.RM riskile reageerimine, PR.PS platvormiturve
SPF-i ja DKIM-i läbivaatamise kirjedA.8.9 konfiguratsioonihaldus, A.8.24 krüptograafia, A.5.20 tarnijalepingudArticle 21 tarneahela turve ja turvaline hooldusArticle 28 IKT kolmanda osapoole riskijuhtimineArticle 32 asjakohased tehnilised ja korralduslikud meetmedGV.SC tarnijanõuded, ID.RA riskide jälgimine
MTA-STS-i ja TLS-RPT valideerimineA.8.24 krüptograafia kasutamine, A.8.21 võrguteenuste turve, A.8.16 seireArticle 21 turvaline side ja krüptograafiapoliitikadArticles 9 and 10 kaitse, ennetus ja tuvastamineArticle 32 töötlemise turvalisusPR.DS andmeturve, DE.CM pidev seire
ErandiregisterPunktid 6.1.3 ja 8.1, riskiomaniku heakskiit ja jääkriskArticle 21 korrigeerivad ja proportsionaalsed meetmedArticles 5, 6 and 28 juhtimine ja parandusmeetmedArticle 5 vastutuse tõendatavusGV.RM riskitaluvus ja reageerimine
Intsidentide esmase hindamise kirjedA.5.24, A.5.25 ja A.5.26 intsidendiplaan, hindamine ja reageerimineArticle 23 olulise intsidendi hindamine ja teavitamineArticles 17 and 19 intsidendiprotsess ja aruandlusArticles 33 and 34 rikkumisest teavitamine ja kommunikatsioon, kui kohaldubRS.AN analüüs, RS.CO kommunikatsioon

NIS2 on eriti asjakohane olulistele ja tähtsatele üksustele ning teatud digitaristu ja digiteenuse osutajate kategooriatele. Article 20 muudab küberturvalisuse juhtimise juhtorgani vastutuseks, samas kui Article 21 sätestab riskijuhtimise baastaseme. E-posti autentimise tõendusmaterjal aitab näidata, et turvaline side, tarnijasuhted, intsidentide käsitlemine, tõhususe hindamine ja küberhügieen on operatiivsed, mitte teoreetilised.

Finantsüksuste puhul kohaldatakse DORA-t alates 17. jaanuarist 2025. Articles 5 and 6 nõuavad juhtorgani vastutust ja dokumenteeritud IKT-riskijuhtimise raamistikku. Article 17 nõuab protsesse IKT-ga seotud intsidentide tuvastamiseks, haldamiseks, registreerimiseks, klassifitseerimiseks, eskaleerimiseks ja parandusmeetmete võtmiseks. Article 28 muudab IKT kolmanda osapoole riskijuhtimise ametlikuks vastutuseks. E-posti teenuseosutajad, turundusplatvormid, makseteavituste süsteemid ja kliendisuhtluse tööriistad võivad kõik saada selle IKT-sõltuvusahela osaks.

GDPR-i puhul on põhiküsimus, kas e-posti kasutatakse isikuandmete töötlemiseks. Article 5 hõlmab terviklust, konfidentsiaalsust ja vastutuse tõendatavust. Article 32 nõuab asjakohaseid tehnilisi ja korralduslikke meetmeid. Kui arved, HR-sõnumid, kontoteavitused, toe piletid või tööleasumise e-kirjad sisaldavad isikuandmeid, muutuvad e-posti autentimine ja transporditurve töötlemise turvalisuse tõendusmaterjali osaks.

Intsidentidele reageerimine: kui aruannetest saab varajane hoiatus

DMARC-i koondaruanded ei ole ainult vastavuse tõendusmaterjal. Need on varajase hoiatuse andmed. Ebaõnnestunud autentimiste järsk kasv tundmatust taristust võib viidata aktiivsele võltsimisele, varjatud IT-le, tarnija väärkonfiguratsioonile või kompromiteeritud saatjale.

NIS2 Article 23 kohaselt peavad olulised ja tähtsad üksused teavitama olulistest intsidentidest põhjendamatu viivituseta, kasutades etapiviisilist aruandlust, mis hõlmab varajast hoiatust, intsidenditeavitust ja lõpparuannet. Mitte iga võltsimiskatse ei ole teatamiskohustuslik, kuid organisatsioon peab suutma hinnata tõsidust, tegevushäiret, finantskahju, piiriülest mõju ja kahju adressaatidele.

DORA Article 17 kohaselt peavad finantsüksused määratlema ja rakendama IKT-ga seotud intsidendihalduse protsessi, registreerima intsidendid ja olulised küberohud, tuvastama algpõhjused, kasutama varajase hoiatuse indikaatoreid, klassifitseerima tõsiduse ja teenuse kriitilisuse alusel, määrama rollid, määratlema kommunikatsiooni ning eskaleerima suuremad intsidendid. DORA Article 19 käsitleb seejärel suuremate IKT-ga seotud intsidentide aruandlust.

GDPR-i puhul on küsimus selles, kas sündmus põhjustas isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise, loata avalikustamise või neile juurdepääsu. Võltsitud e-kiri, mis meelitab kliente esitama isikuandmeid ründajale, võib käivitada isikuandmetega seotud rikkumise hindamise isegi siis, kui sisemisi süsteeme ei kompromiteeritud.

Ettevõtte Auditi ja vastavusseire poliitika Audit ja vastavuse seire poliitika selgitab, miks distsiplineeritud tõendusmaterjal on oluline:

„Luua kaitstav tõendusmaterjal ja auditijälg regulatiivsete päringute, kohtumenetluste või klientidele kindluse andmise taotluste toetamiseks.“

Jaotisest „Eesmärgid“, poliitikapunkt 3.4.

VKE Auditi ja vastavusseire poliitika-sme Audit ja vastavuse seire poliitika - VKE lisab tõendusmaterjali kvaliteedinõude:

„Metaandmed (nt kes selle kogus, millal ja millisest süsteemist) tuleb dokumenteerida.“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.2.3.

DMARC-i uurimistoimik peab seetõttu dokumenteerima aruande allika, kogumise aja, analüütiku, mõjutatud domeenid, kahtlustatavad saatja IP-d, autentimistulemused, ärimõju hinnangu, tehtud otsused ja sulgemise kinnituse.

Mida audiitorid küsivad

Eri audiitorid kasutavad eri sõnastust, kuid tõendusmaterjal kattub.

Audiitori vaadeTõenäoline fookusEttevalmistatav tõendusmaterjal
ISO/IEC 27001:2022 audiitorKas e-posti autentimine on kohaldamisalas, riskihinnatud, käsitletud, toimiv ja läbi vaadatudRiskihinnang, kohaldatavusavalduse põhjendus, vararegister, muudatuste piletid, seirekirjed, siseauditi leiud
ISO/IEC 27002:2022 kontrollimeetmete läbivaatajaKas teabe edastamise, logimise, krüptograafia, tarnijateenuste ja võrguteenuste kontrollimeetmed on rakendatudTeabe edastamise protseduur, krüptograafiline register, lüüsi seadistused, DMARC-i aruanded, TLS-i testid, tarnijakirjed
NIS2 hindajaKas meetmed on asjakohased, proportsionaalsed, juhtkonna juhitud ning seotud intsidentide käsitlemise ja tarnijaturbegaJuhtkonna heakskiit, küberhügieeni tõendusmaterjal, tarnijasaatjate register, intsidendi esmase hindamise töövoog, tõhususe ülevaatused
DORA audiitorKas e-posti autentimine toetab IKT-riskijuhtimist, kolmanda osapoole riski, intsidentide klassifitseerimist ja vastupidavustIKT-riskiregister, tarnijate hoolsuskontroll, intsidendikirjed, seire juhtpaneelid, parandusmeetmete jälgimine, juhtkonna aruandlus
GDPR-i läbivaatajaKas e-postiga saadetavaid isikuandmeid kaitstakse asjakohaste tehniliste ja korralduslike meetmetegaAndmevoogude kirjed, Article 32 turbe põhjendus, krüptimise ja transpordi kontrollimeetmed, rikkumise hindamise protseduur, vastutuse tõendatavuse tõendusmaterjal
NIST- või ISACA-laadis audiitorKas juhtimine, risk, kontrollimeetme ülesehitus, toimimine, seire ja täiustamine on tõendatavadPraegune ja sihtprofiil, kontrollimeetmete testitulemused, POA&M, erandiregister, mõõdikud, parandusmeetmed

Oodata võib praktilisi küsimusi:

  • Näidake eelmise kvartali DMARC-i aruandeid.
  • Näidake, kuidas need läbi vaadati.
  • Näidake selle ebaõnnestuva saatja erandit.
  • Näidake, kes kinnitas selle SPF-i muudatuse.
  • Näidake, kas DKIM-i selektorid on inventeeritud ja läbi vaadatud.
  • Näidake, kuidas MTA-STS-i testitakse pärast meililüüsi muudatusi.
  • Näidake, kuidas võltsimissündmused jõuavad intsidentide esmasesse hindamisse.
  • Näidake, kuidas tarnijasaatjad lepingu lõppemisel eemaldatakse.

Lühike 2026. aasta siseauditi kontrollnimekiri

Kasuta seda kontrollnimekirja lähtepunktina siseauditi, kontrollimeetmete testimise või e-posti autentimise tõendusmaterjali ülevaatuse jaoks.

  • Kõik domeenid ja alamdomeenid on kantud vararegistrisse.
  • Pargitud ja kaitseotstarbelised domeenid on DMARC-iga kaetud.
  • Igal autoriseeritud saatjal on ärivastutaja ja tehniline vastutaja.
  • SPF-kirjed vaadatakse läbi aegunud include-kirjete ja liiga laia ulatuse suhtes.
  • DKIM on lubatud legitiimsetele saatjatele, kus see on toetatud.
  • DKIM-i selektorid on inventeeritud ja läbi vaadatud.
  • DMARC on juurutatud juurdomeenidele ja asjakohastele alamdomeenidele.
  • DMARC-il on rakenduskava, mitte määramata ajaks kestev seire.
  • DMARC-i koondaruandeid vaadatakse läbi määratud sagedusega.
  • MTA-STS on asjakohastel juhtudel sissetuleva posti domeenidele konfigureeritud.
  • TLS-RPT aruanded kogutakse ja hinnatakse esmase triaaži käigus.
  • E-posti autentimise muudatused järgivad muudatuste juhtimist.
  • Tarnija kaasamine sisaldab e-posti saatmise nõudeid.
  • Tarnija lahkumisprotsess eemaldab SPF-i include-kirjed, DKIM-i selektorid ja saatmisõigused.
  • Eranditel on riskiomanikud, aegumiskuupäevad ja kompenseerivad kontrollimeetmed.
  • Võltsimise järsud kasvud ja autentimistõrked suunatakse intsidentidele reageerimisse.
  • Tõendusmaterjal sisaldab metaandmeid, allikat, kuupäeva, kogujat ja süsteemi.
  • Juhtkond saab perioodilisi mõõdikuid ja riskiuuendusi.

Zenith Blueprint, riskijuhtimise faasi samm 14, soovitab koostada kohaldatavate kohustuste jaoks regulatiivsed kaardistustabelid:

„Iga regulatsiooni kohta võib vajaduse korral koostada lihtsa kaardistustabeli (näiteks aruande lisana), mis loetleb regulatsiooni peamised turbenõuded ja vastavad kontrollimeetmed/poliitikad sinu ISMS-is. See ei ole ISO 27001 puhul kohustuslik, kuid on kasulik sisemine harjutus veendumaks, et midagi ei jäänud kahe silma vahele. See avaldab muljet ka audiitoritele/hindajatele, sest näitab, et sa ei halda turvet vaakumis, vaid oled teadlik õiguslikust kontekstist.“

E-posti autentimise puhul saab sellest tabelist sild tehnilise DNS-i tegelikkuse ja juhatuse tasandi kindluse vahel.

Muuda e-posti autentimine auditivalmis tõendusmaterjaliks

Sinu kliendid ei pruugi kunagi küsida, kas SPF-kirje süntaks on täiuslik. Nad küsivad, kas suudad kaitsta oma brändi, vähendada andmepüügiriski, tagada turvalise side, juhtida tarnijaid ja tõendada, et kontrollimeetmed toimivad.

Clarysec aitab organisatsioonidel muuta e-posti autentimise hapratest tehnilistest seadistustest auditivalmis kontrollisüsteemiks. Praktiline järgmine samm on keskendunud e-posti autentimise tõendusmaterjali ülevaatus:

  1. Koosta domeenide ja saatjate register.
  2. Kaardista SPF-i, DKIM-i, DMARC-i, MTA-STS-i ja TLS-RPT staatus.
  3. Tuvasta tarnijad, varjatud saatjad ja erandid.
  4. Loo DMARC-i rakenduskava.
  5. Valideeri muudatuste juhtimise, logimise ja intsidentidele reageerimise tõendusmaterjal.
  6. Seo tõendusmaterjal ISO/IEC 27001:2022, NIS2, DORA, GDPR ja NIST CSF 2.0 nõuetega.
  7. Valmista audiitorile sobiv tõenduspakett, kasutades Zenith Blueprint, Zenith Controls ja asjakohaseid Claryseci poliitikaid.

Kui sinu organisatsioon valmistub ISO/IEC 27001:2022 sertifitseerimiseks, NIS2 valmisolekuks, DORA kindlustunde andmiseks, GDPR-i vastutuse tõendatavuse ülevaatusteks või klientide turbeküsimustikeks, alusta kontrollimeetmetest, mida ründajad kõige nähtavamalt kuritarvitavad: sinu domeenid, sinu saatjad ja sinu e-posti usaldusahel.

Laadi alla Zenith Blueprint, kasuta Zenith Controls ristvastavuse kaardistuseks ning vii läbi 30-päevane e-posti autentimise tõendusmaterjali ülevaatus enne, kui järgmine võltsimisintsident või auditipäring sunnib selle arutelu peale.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

ENISA EUVD 2026: ISO 27001 NIS2 ja CRA jaoks

ENISA EUVD 2026: ISO 27001 NIS2 ja CRA jaoks

ENISA EUVD muudab seda, kuidas ELi organisatsioonid kasutavad haavatavuste ohuteavet, haldavad CVD-d, koordineerivad tarnijaid ning tõendavad NIS2, DORA, GDPR ja CRA aruandlusotsuseid. See juhend näitab, kuidas ISO/IEC 27001:2022, Clarysec poliitikad, Zenith Blueprint ja Zenith Controls muudavad haavatavuste teavitused auditeeritavaks tegevusmudeliks.

SBOM-id ISO 27001, NIS2 ja DORA vastavustõenduse jaoks

SBOM-id ISO 27001, NIS2 ja DORA vastavustõenduse jaoks

SBOM-id on nüüd tarkvara tarneahela vastavustõenduse keskne tõendusmaterjal. See juhend näitab, kuidas rakendada SBOM-e ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 ja Clarysec poliitikate toel.

CVD NIS2 ja DORA kontekstis: ISO 27001 tõendusmaterjali kaart

CVD NIS2 ja DORA kontekstis: ISO 27001 tõendusmaterjali kaart

Praktiline juhend infoturbejuhtidele koordineeritud haavatavuste avalikustamise kohta NIS2, DORA, GDPR ja ISO/IEC 27001:2022 alusel, hõlmates poliitikateksti, vastuvõtu töövoogu, tarnijate eskaleerimist, audititõendusmaterjali ja kontrollimeetmete kaardistust.