En legitim tjeneste kan levere en illegitim forespørsel. En bruker kan misbruke en plattforms normale delings- eller varslingsfunksjoner, en konto kan bli kompromittert, eller en autorisert avsender kan komme med en uautorisert forretningsforespørsel. Domeneautentisering kan identifisere tjenesten eller den konfigurerte avsenderen på riktig måte, samtidig som disse risikoene ikke er løst. Etterforskningen bør forklare begge fakta uten å kalle hver ondsinnet melding som sendes for en autentiseringsfeil.
Skille tjenesten fra forespørselen
Registrer det faktiske Fra-domenet, signeringsdomenet, konvoluttidentiteten og koblingene i meldingen. Bestem hvilke identiteter som tilhører tjenesten og hvilke som tilhører et kundekontrollert domene. Ikke anta at en kjent logo eller et synlig visningsnavn betyr at meldingen stammer fra organisasjonen som blir etterlignet. DKIM knytter et signeringsdomene til en melding; den bekrefter ikke sannheten av meldingens uttalelser. RFC 6376.
Spør hva plattformen faktisk autentiserte. Den kan ha autentisert en kontoøkt, et konfigurert domene eller en varslingsarbeidsflyt. Ingen fastslår nødvendigvis at kontoeieren hadde til hensikt en betalingsendring eller at et delt dokument er trygt. Hold disse spørsmålene åpne til det er bevis fra tjenesteeieren og bedriftsmottakeren.
Bygg en krav- og bevismatrise
Bruk separate rader for domeneautentisering, kontokontroll, innholdsgjennomgang og forretningsgodkjenning. Hver rad trenger et krav, bevis, tillit, eier og neste handling. En passerende justert signatur kan tilfredsstille en smal domeneautentiseringsrad uten å tilfredsstille de andre. RFC 9989 beskriver DMARCsitt domenebaserte omfang i stedet for en generell garanti om innhold. DMARC -spesifikasjon.
For en økonomisk forespørsel er uavhengig verifisering spesielt viktig. Bruk en kjent kontaktrute i stedet for telefonnummeret eller svaradressen som nylig ble oppgitt i meldingen. FBI anbefaler uavhengig å sjekke betalingsforespørsler og endringer i kontodetaljer. FBI veiledning.
Les eksemplet med gjennomsiktig arbeidsbelastning
Det skriftlige eksemplet forutsetter en betalingsendringsmelding med justert autentisering, ingen forretningsgodkjenning og en kjent leverandørkontakt som nekter endringen. Matrisen beholder derfor autentiseringspasset mens betalingsendringen holdes på vent. Det trekker ikke ut om en konto ble kompromittert, en tjenestefunksjon ble misbrukt eller den påståtte avsenderen deltok.
Den samme hypotetiske modellen bruker en illustrativ månedlig arbeidsmengde på 10 000 meldinger, en 1 % vurderingsutvalgsrate og fire minutter per valgt melding. Regnestykket gir 100 anmeldelser og omtrent 6,67 analytikertimer. Dette er planleggingsforutsetninger, ikke målte plattformmisbruksrater, bemanningsreferanser eller leverandørpriser. De ekskluderer etterforskningseskalering, helger, falsk positiv håndtering og hendelseskoordinering, så de er ikke et fullstendig driftskostnadsestimat.
Undersøk uten å overblokkere
Ta vare på meldingsidentifikatorer og leverandørspesifikke objektreferanser hvis tilgjengelig, men unngå å spre sensitivt dokumentinnhold unødvendig. Be den autoriserte tjenesteeieren om å undersøke kontoaktivitet, delingsinnstillinger og revisjonslogger. Enhver inneslutningshandling bør tilpasses den bekreftede trusselen og tillates av organisasjonens responsprosess.
Blokkering av en hel populær tjeneste kan avbryte legitime arbeidsflyter uten å løse kontokompromittering andre steder. Vurder om en smalere avsender, objekt, URL eller kontohandling støttes og er passende. Dette er beslutningskriterier, ikke instruksjoner om å utføre en fjerning eller endre en annen persons konto uten myndighet.
Lukk med de påviste identitetsfakta, de ubekreftede årsaksforklaringene, forretningsresultatet og responseieren. Hvis tjenesten forblir brukbar, bevar autentiseringskonfigurasjonen mens du adresserer misbruksbanen. Å fjerne DKIM for å unngå tilsynelatende tillit vil svekke et nyttig signal uten å gjøre innholdet trygt. Målet er å tolke det signalet riktig og legge til de uavhengige sjekkene forespørselen krever.
Hold fire bevisrader adskilt
For dette oppfunne tilfellet er domeneautentisering fastsatt pass; e-postadministratoren eier kontroll av ekte mottaksbevis. Kontokontroll er ukjent; den autoriserte tjenesteeieren må undersøke faktisk kontoaktivitet. Innholdssikkerhet er uløst; sikkerhet eier den omfattende innholdsgjennomgangen. Forretningsgodkjenning mangler og den angitte kjente leverandøren avslår forespørselen; finans beholder betalingssperringen. Ingen reell leverandør ble kontaktet, ingen konto ble undersøkt og ingen betaling ble endret. Eksemplet gir en beslutningsstruktur, ikke bevis som identifiserer en gjerningsperson.
Kilde og utførelsesgrense
RFC 9989 avsnitt 4.4, 5.3.5 og 5.4 skille autentisering, justering og håndtering; et pass godkjenner ikke meldingsinnhold. De operasjonelle beslutningene her er anbefalinger med omfang og eksplisitt hypotetiske eksempler, ikke nye tester av en kunde, leverandør eller historisk inventar. Enhver reell endring krever sitt eget autoriserte omfang, beholdt bevis og ansvarlig beslutning.