Begynn med identiteten, ikke hendelsesetiketten
Kompromiss med e-post for bedrifter beskriver et skadelig forretningsscenario, ikke ett unikt e-postautentiseringsresultat. En villedende forespørsel kan komme fra et domene som utgir seg for å være et domene, en kompromittert leverandørpostboks, en misbrukt intern konto eller en uautorisert applikasjon som bruker legitim sendeinfrastruktur. Undersøkelsen skal fastslå hvilken identitet som ble presentert, hvilket system som autentiserte den og hvilken virksomhetsmyndighet mottakeren mente den representerte. Uten den separasjonen kan et team reparere feil kontroll mens den underliggende risikoen består.
De IC3 skybasert e-postrådgivning, datert 6. april 2020, beskriver hvordan kompromitterte sky-e-postkontoer kan støtte BEC og anbefaler uavhengig verifisering og kontobeskyttelse. Det er bakgrunnsveiledning, ikke bevis på en aktuell hendelse. Microsofts veiledning for kompromitterte kontoer beskriver likeledes postboksmisbruk og etterforskning i Microsoft 365 . Ingen av kildene fastslår at noen beretning diskutert i en hypotetisk øvelse faktisk har blitt kompromittert.
Behold forespørselen og sett forretningshandlingen på pause
Det første operasjonelle spørsmålet er hva meldingen ber noen om å gjøre: endre betalingsdetaljer, frigi informasjon, godkjenne tilgang, endre en leverandøroppføring eller ta en annen følgehandling. Registrer handlingen på nøytralt språk. Sett kjøringen på pause gjennom organisasjonens etablerte prosess når forespørselen er mistenkelig. Unngå å gjøre selve undersøkelsen til en uautorisert betaling, kontoendring eller avsløring. En analytiker kan dokumentere forespørselen uten å følge den.
Ta vare på den opprinnelige meldingen og den relevante forretningsposten på et godkjent begrenset sted. Et skjermbilde kan vise presentasjon, men kan ikke erstatte fullstendig meldingsbevis. En videresendt kopi kan endre konteksten og legge til overskrifter; merke den tilsvarende. Hold en kronologi med tidssoner og identifiser hvem som samlet inn hvert element. For et delt sammendrag, fjern unødvendige personopplysninger mens du beholder distinksjonene som trengs for å sammenligne identiteter. Ikke sirkuler legitimasjon, tilgangstokener eller fullstendig sensitiv korrespondanse som rutinemessig feilsøkingsmateriell.
Konstruer en identitetsstabel
Liste det synlige visningsnavnet, analysert fra-adresse, svar-til-adresse, konvoluttavsender, DKIM signeringsdomene, mottakerautentiseringsresultat og påstått forretningsrolle. Legg til postboksen eller applikasjonskontoen bare hvis autoriserte etterforskningsbevis identifiserer det. Dette er separate rader, ikke utskiftbare etiketter for «avsender». Domenet som autentiserte en melding kan være forskjellig fra personen hvis autoritet mottakeren antydet.
RFC 9989 gjør grensen eksplisitt: DMARC bruker domenejustering og autentiserer ikke andre enheter enn domener eller analyserer innhold. Et vellykket justert resultat kan derfor ikke bekrefte en faktura, en ny bankdetalj eller en leders godkjenning. Omvendt etableres ikke et mislykket resultat kontoovertakelse. En undersøkelse bør unngå å hoppe fra et protokollresultat til en konklusjon om hvem som kontrollerte en persons konto.
Etabler tillitsgrensen for hver observasjon
Bestem hvilken mottaker som produserte autentiseringsresultatet og om posten ble oppnådd gjennom mottakerens pålitelige grensesnitt eller logger. RFC 8601 adresserer tillit til Authentication-Results påstander. En avsender kan inkludere misvisende tekst, så tilstedeværelsen av et felt er ikke nok. Dokumenter grunnlaget for å behandle en påstand som lokal og pålitelig. Hvis dette grunnlaget er fraværende, merk resultatet som ubekreftet i stedet for å gjenta det som fakta.
Applikasjonslogger og kontorevisjon svarer på forskjellige spørsmål. En sendelogg kan vise en vellykket innsending uten å bevise at mennesket hadde til hensikt det. En postboksrevisjon kan vise en regelendring uten å bevise at regelen var skadelig. Kombiner observasjoner etter tids-, konto- og meldingsidentifikatorer der det er autorisert, og bevar usikkerhet når koblingen er svak. Unngå å behandle et enkelt uvanlig sted eller isolert feil som avgjørende bevis på kompromiss.
Sammenlign mekanismer før du velger kontroller
Bruk en identitets- og kontrollmatrise. For eksakt domeneetterligning uten justert autentisering, undersøk domenepolicyen og sendebanen. For misbruk av visningsnavn eller lookalike-domene, undersøk presentasjon, gjenkjennelse og uavhengig virksomhetsverifisering. For mistenkt kontokompromittering, undersøk kontotilgang og uautoriserte handlinger. For en misbrukt applikasjon, inspiser dens autorisasjons- og meldingskonstruksjonsgrenser. Mer enn én mekanisme kan forekomme i samme tilfelle.
Microsofts veiledning viser potensielle symptomer som mistenkelige innboksregler, videresending og manglende eller slettede meldinger. Dette er etterforskningsspor, ikke automatiske dommer. Utbedringssekvensen inkluderer deaktivering av en berørt konto, tilbakekalling av tilgang og gjennomgang av autentiseringsenheter, godkjente applikasjoner, roller og videresendinger. Dette er administrative følgehandlinger for en autorisert responder. Denne artikkelen instruerer ikke en assistent til å utføre dem, gi tillatelser eller samle inn legitimasjon; den identifiserer det passende responsdomenet når bevis støtter hypotesen.
Arbeidsarket for operativ sammenligning
Lag en rad per hypotese. Inkluder den påståtte identiteten, støttende observasjon, kilden til den observasjonen, motstridende bevis, berørt kontroll, foreslått neste autoriserte kontroll og den ansvarlige. Legg til en konfidensetikett med en klarspråklig forklaring. "Trusterte mottakere rapporterer justert DKIM for leverandørdomenet" er smalere og mer nyttig enn "leverandør bekreftet trygt." "Mottakeren husker visningsnavnet" tilsvarer ikke en autentisert leverandøradresse.
Legg til en egen rad for bedriftsbekreftelse. Identifiser en kontaktkanal etablert før den mistenkelige forespørselen, den nøyaktige endringen som trenger bekreftelse, den autoriserte verifikatoren og det registrerte resultatet. Svaret skal bekrefte eller avvise den forespurte forretningshandlingen, ikke bare at kontakten gjenkjenner avsendernavnet. Ikke bruk telefonnumre, lenker eller alternative adresser som bare er oppgitt i den tvilsomme meldingen som uavhengig bekreftelse. Dette foreslåtte regnearket er ikke en utført hendelsesresponspost.
Fiktiv diagnose: en forespørsel om fakturaendring
En fiktiv produsent mottar en forespørsel om å endre en leverandørs betalingsdestinasjon. Visningsnavnet samsvarer med kontoadministratoren, og pålitelige mottakerbevis viser justert autentisering for leverandørens virkelige domene. Mottakeren antar at dette utelukker BEC. Sikkerhetsteamet registrerer i stedet en smalere konklusjon: meldingen brukte en autentisert leverandør-domenebane. Hvorvidt leverandørkontoen, en integrasjon eller en autorisert person startet endringen forblir ukjent.
Ved å bruke en tidligere registrert leverandørkontakt, ville bedriftseieren verifisere den spesifikke foreslåtte endringen. En autorisert leverandørreagerer vil undersøke sin egen konto og søknadsbevis. Hvis leverandøren avslår forespørselen, støtter avslaget å stoppe endringen, men identifiserer ikke i seg selv hvordan e-posten ble sendt. Saken forblir åpen til konto- eller tjenestebevis løser mekanismen. Hele dette eksemplet er fiktivt; ingen betalingsdetaljer, leverandørkonto eller ekte korrespondanse ble innhentet.
Lukk hver usikkerhet med riktig bevis
En god konklusjon angir hva som ble observert, hvilken mekanisme som støttes, hva som forblir usikker og hvilken kontroll som ble endret gjennom autorisasjon. Ikke merk hver melding fra det berørte domenet som skadelig, hevd at en DNS redigering inneholder en kontoovertakelse, eller erklær utbedring fullført bare fordi senere e-post autentiseres. Bekreftelse av forretningsprosesser, kontobegrensning og e-postautentisering svarer på forskjellige spørsmål.
Katalogen krever en redigert identitet-og-kontroll-sammenligning bygget fra pålitelige meldingsbevis. Det beviset forblir åpent. Dette utkastet gir en metode og en fiktiv sak, ikke pålitelig originalt meldingsmateriale. Uavhengig spesialistgjennomgang, gjeldende kildeanvendbarhet, produksjonsrutesjekker, visuell tilgjengelighet og eierfrigivelse er også åpne. Publisering bør vente på en autorisert bevispakke som demonstrerer sammenligningen uten å avsløre sensitive kontodata eller antyde at ikke-utførte responshandlinger skjedde.