Een risicoregister voor e-mailauthenticatie moet uitleggen welke zakelijke dienstverlening schade kan oplopen en welke beslissing dat risico verkleint. “DMARC 'ontbrekend' is een technische bevinding, geen volledige risicoverklaring. Koppel de voorwaarde aan een geloofwaardig dreigings- of faalpad, een getroffen proces, bestaande waarborgen en een verantwoordelijke eigenaar.
Beschrijf de service en het scenario
Noteer voor elke invoer de service, het domein, de eigenaar van de applicatie, de technische staat, de bewijstijd en het waarschijnlijke gevolg. Houd onzekerheid expliciet. Een niet-geobserveerde afzender is een bewijslacune, terwijl een geverifieerde, niet-gebonden legitieme afzender een authenticatiefout is. Geen van beide bewijst automatisch dat een aanvaller de dienst heeft misbruikt.
RFC 9989 specificeert domeinverificatie en uitlijning gedrag. De beveiliging ervan garandeert niet dat elk geauthenticeerd verzoek legitiem is. Een risicoregister moet onderscheid maken tussen directe nabootsing van uw domein en een gecompromitteerd geautoriseerd account of een lookalike-domein dat de authenticatie voor zichzelf doorgeeft.
Scheid inherent en resterend risico
Beschrijf het scenario vóór de controles en leg vervolgens uit wat elke bestaande beveiliging verandert. Voor factuurinstructies kan verificatie van terugbelbetalingen frauduleuze zakelijke verzoeken behandelen die domeinauthenticatie alleen niet kan oplossen. Impliceer niet dat het bestaan van een schriftelijk terugbelbeleid bewijst dat mensen dit consequent volgen.
Gebruik de overeengekomen waarschijnlijkheids- en impactdefinities van de organisatie. Vermijd het presenteren van verzonnen precisie, zoals een jaarlijkse fraudekans van 17,3% zonder bewijs. Als er onvoldoende gegevens zijn, gebruik dan een kwalitatieve beoordeling met de bijbehorende grondgedachte en beoordelingstrigger. Leg vast wie de bevoegdheid heeft om het resterende risico te accepteren, in plaats van de technische goedkeuring van een e-mailbeheerder te beschouwen als zakelijke acceptatie.
Gebruik een gekoppeld voorbeeld
Stel dat hypothetische invoer R-1 betrekking heeft op de loonadministratie. De voorwaarde is dat er geen actueel bewijs is van een geregistreerde kritieke dienst. Het potentiële gevolg is gemiste loonmeldingen als een niet-geteste route mislukt tijdens de handhaving. Dit is een voorwaardelijk scenario, geen claim dat werknemers berichten hebben gemist. Financiën is eigenaar van de dienst, het postteam is eigenaar van onderzoek en afsluiting vereist een huidige routetest plus bevestiging van de diensteigenaar.
R-2 omvat het nabootsen van de identiteit van facturen via een lookalike-domein dat eigendom is van de aanvaller. De voorgestelde controle is onafhankelijke verificatie via een reeds vertrouwde contactroute. Het publiceren van een sterker beleid op het domein van het slachtoffer voldoet niet aan de afsluitingstest van R-2. Vereist voor elke inschrijving een bevinding, eigenaar, beslissing en expliciet afsluitingsbewijs voordat het voorgestelde register als volledig wordt beschouwd. Dit is een aanbevolen beoordelingsregel, geen uitgevoerde validatie of bewijs dat een controle werkt.
Houd het register bruikbaar
Kies expliciet voor een behandeling: herstel, vermijd de risicovolle activiteit, draag waar nodig een gedefinieerde blootstelling over, of accepteer het resterende risico via het geautoriseerde besluitvormingsproces. Stel een vervaldatum en beoordelingstrigger in. Een behandelplan is geen bewijs van voltooiing; bewaar het feitelijke test- of beslissingsverslag afzonderlijk.
Deze hypothetische vermeldingen illustreren verschillende scenario's, niet waargenomen aanvallen of geaccepteerde bedrijfsrisico's. Een volledigheidsbeoordeling kan ontbrekende velden identificeren, maar kan een risicobeoordeling niet valideren of vaststellen dat echte waarborgen werken. Houd het feitelijke bewijsmateriaal en het geautoriseerde acceptatiebesluit gescheiden van de voorgestelde behandeling.
Controleer het register na migraties, nieuwe afzenders, incidenten en zakelijke wijzigingen. Sluit alleen het specifieke scenario waarvan het bewijs voldoet aan de genoemde test, en bewaar voldoende geschiedenis om uit te leggen waarom het werd gesloten.
NIST SP 800-30 Rev. 1 paragrafen 2.3 en 3.2 beschrijven risicofactoren, beoordelingsbenaderingen en het documenteren van beoordelingsresultaten. Ze ondersteunen het expliciet maken van waarschijnlijkheid, impact en onzekerheid; de e-mailspecifieke registervelden en voorbeelden hierboven zijn een voorgestelde toepassing en geen voorgeschreven compliancechecklist. Gids voor risicobeoordeling.