Start med autoritet, versjon og jurisdiksjon
En EU-e-postsikkerhetsdiskusjon kan involvere et direktiv, en direkte gjeldende forskrift, nasjonal implementering, veiledning til tilsyn, kontrakter og tekniske standarder. Disse kildene har ikke samme omfang eller rettsvirkning. Før du anbefaler en autentiseringsendring som et samsvarstiltak, identifiser den eksakte autoriteten og organisasjonen eller behandlingsaktiviteten den kan gjelde.
Denne artikkelen beholder de offisielle EUR-Lex originale publiserte tekstene til direktiv (EU) 2022/2555, ofte kalt NIS2, og forordning (EU) 2016/679, GDPR . Deres originalpublikasjons-URLer presenteres ikke som en fullført bekreftelse av hver påfølgende endring, gjennomføringsrett, nasjonal innføring eller tolkning av regulatorer. En gjeldende jurisdiksjonsspesifikk gjennomgang er fortsatt nødvendig før du fremsetter et krav om organisasjonsoverholdelse.
Hensikten her er teknisk og bevismessig: Vis hvordan du unngår å gjøre brede sikkerhetsoppgaver om til ikke-støttede påstander om én protokoll. Dette er ikke juridisk rådgivning, en avgjørelse av en enhets regulatoriske status eller en sertifisering av at et domene er i samsvar.
Bestem NIS2 -anvendelighet før du velger bevis
Artikkel 2 i den beholdte NIS2 teksten definerer omfang etter enhetstyper, størrelse og tilleggsbetingelser, inkludert kategorier som kan falle innenfor virkeområdet uavhengig av størrelse. Vedlegg identifiserer relevante sektorer og enhetstyper. Et selskaps nettstedplassering eller besittelse av et EU-domene-suffiks er ikke en erstatning for denne analysen. Enheten, aktivitetene, tjenestetypene og relevant jurisdiksjon må identifiseres.
Artikkel 41 tar for seg medlemsstatens innføring og angir datoer for vedtakelse og anvendelse av tiltak. Disse datoene fastslår ikke at hver medlemsstats faktiske gjennomføring er identisk eller at en bestemt organisasjons forpliktelser kan konkluderes fra direktivet alene. Skaff den gjeldende nasjonale teksten og kvalifisert gjennomgang i stedet for å ekstrapolere fra et generelt EU-sammendrag.
Anvendelsesarket bør bevare enhetsklassen, land, aktiviteter, kildeversjon, nasjonal implementeringsreferanse og uløste spørsmål. Ikke merk en organisasjon fritatt bare fordi den beskriver seg selv som liten, eller dekket bare fordi en leverandør bruker uttrykket kritisk infrastruktur. NIS2 , artikkel 2 og 41 og vedlegg I–II
Les risikostyringsoppgaver uten å finne opp en protokollkommando
Artikkel 21 i det beholdte direktivet krever hensiktsmessige og forholdsmessige tekniske, operasjonelle og organisatoriske tiltak for de dekkede enhetene, med en risikobasert og alle-faretilnærming. Artikkel 20 omhandler ledelsesgodkjenning og tilsyn med tiltakene. Disse bestemmelsene støtter et ansvarlig sikkerhetsprogram, ikke en snarvei der publisering av én DNS policy lukker enhver forpliktelse.
E-postautentisering kan foreslås som en del av et dokumentert svar på relevante risikoer for etterligning. Begrunnelsen bør forklare trusselen, domenet og avsenderomfanget, kontrollens begrensninger, utfyllende sikkerhetstiltak og bevis for drift. Ikke omskriv de siterte generelle bestemmelsene som en universell instruks om at enhver EU-organisasjon må publisere en bestemt DMARC politikkverdi.
En snevrere sektorspesifikk eller nasjonal regel vil kunne kreve ytterligere tiltak. Den muligheten er en grunn til å sjekke den faktiske gjeldende kilden, ikke tillatelse til å finne den opp. Oppbevar lovkravsteksten og den tekniske kontrollkartleggingen i separate felt slik at en anmelder kan se begrunnelsen. NIS2 , artikkel 20 og 21
Vurder personvern i rapporteringsarbeidsflyten
GDPR anvendelse gjelder behandling av personopplysninger under dets materielle og territorielle omfang, ikke bare om et selskap publiserer DMARC . Der relevante personopplysninger behandles i autentiseringslogger, støtteprøver eller rapporter, må gjennomgangen omhandle behandlingsformål, roller og gjeldende krav. Den beholdte artikkel 3-teksten gir territorielle betingelser; den faktiske organisatoriske bestemmelsen krever fortsatt kvalifisert vurdering.
Artikkel 5 inkluderer formålsbegrensning, dataminimering og lagringsbegrensning. Artikkel 32 krever passende tekniske og organisatoriske sikkerhetstiltak i lys av behandlingen og risikoene. Disse prinsippene støtter spørsmål om hvilke felt som er nødvendige, hvem som har tilgang til dem, hvor lenge de beholdes og hvordan deres sikkerhet vurderes. De oppretter ikke én universell rapportoppbevaringsperiode eller fastslår at hvert aggregert felt er personopplysninger i enhver sammenheng.
Ikke anta at sikkerhetsovervåking automatisk tillater ubegrenset innsamling eller deling. En leverandørbevispakke bør ha en definert mottaker, formål og minimert omfang, med relevante spørsmål om lovlig behandling og kontraktsmessige vurderinger separat. Ingen faktisk rapport eller personlig informasjon ble samlet inn eller overført for dette manuskriptet. GDPR , artikkel 3, 5 og 32
Hold protokollbevis innenfor dets beskyttende omfang
DMARC evaluerer justert autentisering i forhold til meldingens Fra-domene. Den kan støtte en bestemt anti-spoofing-kontroll, men den beviser ikke at en autentisert meldings forretningsforespørsel er trygg, at alle lookalike-angrep er forhindret eller at alle organisatoriske sikkerhetsforpliktelser er oppfylt. En teknisk vurdering bør beskrive disse grensene eksplisitt.
Rapportering trenger også sin egen personvern- og sikkerhetsgjennomgang. Samlet rapportering og feilrapportering er forskjellig, og ingen av dem skal behandles som en fullstendig oversikt over alle meldinger eller som iboende pålitelige input. Standardbeviset hjelper til med å forklare mekanismen; den kan ikke erstatte en enhetsspesifikk juridisk anvendbarhetsanalyse eller en full kontroll-effektivitetsvurdering. RFC 9989 , avsnitt 2.4 og 4.4; RFC 9990 , seksjon 7 og 8
Kontroll-til-bevis regneark og fiktivt eksempel
Lag et regneark med separate kolonner for autoritet og versjon, anvendelighetsbegrunnelse, eksakt krav, risiko adressert, foreslått teknisk kontroll, berørte domener og ruter, bevis, eier, vurderingsdato og gjenværende begrensninger. Inkluder referanser for nasjonal implementering og personvernvurdering der det er relevant. En rad skal forbli uløst når den gjeldende juridiske kilden eller faktiske operasjonelle bevis mangler.
Se for deg en fiktiv organisasjon som vurderer DMARC håndhevelse mens de vurderer sin NIS2 posisjon og rapportbehandlingspraksis. Sikkerhetsteamet kan utarbeide en avsenderinventar og en foreslått plan for autentiseringsbevis. Dens juridiske kontrollør må separat bestemme enhetens omfang og gjeldende nasjonale forpliktelser. Personverneieren må gjennomgå rapportfelt, mottakere og oppbevaring. Ingen kan lukke den fullstendige samsvarsvurderingen bare fordi et offentlig DNS oppslag viser p=reject.
Hvis den fiktive organisasjonen senere innhenter bevis i samsvar med meldinger, kan det støtte den tekniske kontrollraden innenfor dens definerte omfang. Den avgjør fortsatt ikke ledelsesstyring, hendelseshåndtering, forsyningskjedekrav eller personvernspørsmål. Eksemplet er en foreslått deling av bevisansvar, ikke en utført vurdering eller en påstand om en reell organisasjon.
Uløst gjennomgang og utgivelsesstatus
Katalogen krever autoritativ gjeldende tekst og passende jurisdiksjonsspesifikk samsvarsgjennomgang før det fremsettes et samsvarskrav. Beholdte originale EU-publikasjoner støtter de snevre forklaringene ovenfor, men gjeldende endringer, gjennomføringstiltak, nasjonal lov og organisatorisk anvendelighet er ikke fullstendig bedømt her. Kravet om originalbevis forblir derfor åpent.
Alle seks utløserportene forblir åpne. Ingen DNS endringer, regulatorisk innsending, juridisk forpliktelse, leietakertilgang eller samsvarssertifisering skjedde. Før du publiserer en fullført organisasjonsvurdering, behold gjeldende gjeldende myndigheter, kvalifisert gjennomgang og faktisk kontrollbevis. Angi omfanget og de uløste spørsmålene tydelig i stedet for å presentere e-postautentisering som en komplett løsning for overholdelse av juridiske krav.